# Code Snippets #0: Circular Sectors

When doing research for programmatically creating the circular sectors used for the cannon firing range, I encountered a few instances of other people having questions about this topic. So, I thought it might hopefully prove useful to others to share the code I wrote to solve this problem.

I mainly used an enum and two functions, one to calculate the points that define the circular sector and one that takes those points and generates a mesh from them.

Enum:

Function to calculate points defining the defining points of a circular vector:

Function to generate a mesh from those points:

### Making things work in an arbitrary plane

As the code is right now, it only works with circular sectors that lie on the plane defined by the x- and y-axis (z -axis component of 0). There are mainly two reasons for this:

1. I need the points defining the circular sector not only for mesh generation but also for generating a 2DPolygonColider, which expects the collider path to be defined in by a series of Vector2 values. To avoid unnecessary data/space translations and data sanity checks, it was easiest to work with Vector2 to begin with
2. A more generic approach would cause input computation/conversion to be a little more complex which in turn means more room for errors. And if we can avoid that without any drawbacks, why not?

However, it would be very easy to make this code more generic so it works with arbitrary planes. If you are in need of that and don’t know how to go about it, feel free to drop me a message in the comments.

### Words of caution

This code isn’t meant to be the solution to this problem. I’m certain there are more efficient ways to get the same results if you have a deeper knowledge of trigonometry, linear algebra, etc.
But for me, it’s good enough. It’s not the worst way you could solve it and more importantly readable to me. It’s good enough until it isn’t and should that moment ever come, I’ll change it then. I’m repeating myself but”Done is better than perfect” ðŸ˜‰

So, please, apply critical thinking when using this code and keep in mind that there are certainly other and probably more elegant solutions to this problem.

# Progress Report: May 2018

I’m happy to say that I got a little more done in May than I was originally expecting. Having a week of vacation certainly didn’t hurt ðŸ™‚

• Implemented a second, alternative algorithm for calculating wind influence on ship speed. This provides a slightly different feel to how the ships move.
• Added some place holder graphics from the great Kenney to the first sea battle prototype. This isn’t the art style I have in mind in the end but it’s way more motivating andÂ  pleasing to the eye than my previous “graphics” ðŸ™‚
• Max range and angle of ship cannons can now be set in the editor. Geometry for graphical indicators of cannon range and colliders for detecting enemies within range get calculated from code according to the respective editor settings.
• Color indication if enemy is within firing range ofÂ  cannons or not.

Detecting if an enemy is within firing range (green) or not (red)

### Current challenges:

One of the bigger hurdles right nowÂ  is the question of how good/polished certain parts of a prototype need to be.
It’s a balancing act in a topic I have no real experience in.

For example, there’s a very wide spectrum of quality between the two extremes of “The ship can’t move at all” and “Ship movement feels exactly right”.
If ships don’t move at all, that’s certainly not good enough of a prototype to give me a clear idea of how this kind of battle would feel in a polished version. Then again, making ship controls feel just right could take dozens of hours and isn’t feasible either.
I have to find a sweet spot that doesn’t take too long to accomplish yet where the controls are just good enough for me to be able to imagine how they would feel like when implemented properly.
But ifÂ  the controls don’t feel fun and the whole reason for the prototype is, to find out if it’s fun in the first place, it’s very hard to tell if it’s because they’re not yet polished enough or because they won’t ever be fun, even with all the polish in the world and when working exactly as I’m imagining them in my head.

# Progress Report: April 2018

Since I had to move to a new apartment, I had a ton of other things that required my attention and didn’t get too much done in April, unfortunately. The same will probably be true for May as well but I really hope to pick up speed again as soon as I’ve finally settled in and got all the things done that come with a move.

What I’m currently working on is a first prototype for sea battles. How sea battles will exactly play out is currently one of the least clearly defined parts in my vision of what the game should be and feel like in the end.
There’s a ton of considerations that go into this, for which I don’t yet have a clear answer. It’s not only about if the game play in and of it self would be fun but also about a myriad of other things like if the depth and feel of the battle system matches the rest of the game, if the average length of a battle fits nicely into the overall flow of the game, how feasible it would be to develop a satisfactory AI for a certain kind of game playÂ  (skill level I have, time it would take develop the AI, how easy it would be to adjust the difficulty and so on), etc. etc.

I thought about all this a lot and still have no real answers. That’s why I felt there’s probably no other way than to just make a few prototypes, see what feels right and maybe even get totally new ideas from the prototypes that I’m currently not even thinking of.
AÂ  good friend even showed interest in potentially helping me designing a battle system. That thought really gets me excited and if we indeed would start a collaboration, I can’t wait to hear some of his ideas ðŸ™‚
I postponed working on the battle system for quite some time because there was always this feeling of wasting time when I do work, I know won’t end up in the game,Â  when time currently is the scarcest of all resources.
On a logical level I know it’s the right thing to do. I know that probably only a fraction of all the work done really ends up in the final game in most productions. I know that you often first have to find out what doesn’t work in order to figure out what does. Yet, it’s hard not to feel like potentially wasting time when starting work on a prototype that could take a few months to develop, just for me to realize that the idea doesn’t really work.

Enough talking, here’s a screenshot of the current prototype. At the moment I’m figuring out the basic ship controls and how wind influences the ship’s speed.