It’s alive! It’s alive!


At long last, I can happily present the first version of the ship-to-ship combat AI!
It’s really simple, for instance it’s trying to aim at the center of the enemy ship, while often aiming a bit more towards the bow would make more sense.
But for a concept of proof, I’m more than happy with it!

Here’s a short video demonstrating the AI. The black ship is controlled by me, the yellow one by the AI:

ST2U2DNavMeshImporter (Oops!… I did it again♪)

For the tilemaps, I’m using Thorbjørn Lindeijer’s Tiled and Sean Barton‘s SuperTiled2Unity. Since I just made a project to bake 2D colliders into NavMeshes, I went ahead and created a SuperTiled2Unity importer that automatically creates a NavMeshSurface with the correct position, rotation, size and all the necessary components.

All that’s left to bake your NavMesh after importing the tilemap is the press of a button!

You can find the project here:

Here’s an example of an imported tilemap. All I did after the import was, to press the “Bake 2D”-button:

The project is published under the MIT license, so, you’re practically allowed to use it in whatever way you wish.


Currently, Unity only offers the ability to generate NavMeshes (the objects telling the path finding system where NPCs can move) from 3D obstacles. Since I’m developing a 2D game and would like to make use of Unity’s inbuilt path finding, this posed a problem.

That’s why I developed a solution that worked for my case. When everything worked, I thought to myself that it wouldn’t take too much additional effort to polish this a little, make it more multi purpose (e.g. I only needed it to detect polygon colliders and had no personal need for also handling circle colliders, etc.) and easy enough to use so it might be useful to other people as well.

What I ended up with is a solution to easily bake 2D colliders into a NavMeshSurface.

Supported colliders:

  • BoxCollider2D
  • CircleCollider2D
  • PolygonCollider2D
  • CompositeCollider2D
  • TilemapCollider2D (For those to work, you have to make them part of a CompositeCollider2D, though!)

You can find the end result here:

Here’s an example of a baked NavMesh for a hex tilemap (red tiles have a collider):

The project is published under the MIT license, so, you’re practically allowed to use it in whatever way you wish.

Unfortunately, as is often the case, I was very, very wrong about the effort it would take to make the project more useful to others as well.
Getting it to work for my specific use case took about a day of work, making it more general purpose, easier to use ,cleaning up the code, setting up the GitHub repository, adding instructions and a project example, writing this blog post, etc. took at least two more full days of work.

Now, I’m torn about how I should handle such things in the future.

On one hand, I’m really very happy to have made something that might be of use to others (I’ve seen people looking for exactly this functionality multiple times) and to give something back to the community. After all, there’s lot’s of people out there that helped me out in one way or another and even if it’s not always possible to pay them back, this feels like a way to at least pay it forward.
On the other hand, polishing and releasing this made the task more than 3 times as long as it would have been if I just stopped at the point where it was good enough for my own purposes.

If we’re honest, the project I’m trying to create is way out of scope and a monumental task that will still take me years to finish.
I only work on this in my spare time and when I feel like it because I know I’ll never finish it as soon as I have the feeling that I must work on it.
Currently, I’m on vacation and make quite good progress. But during the rest of the year, I maybe get to work on this project somewhere between 1 and 2 full days a week (likely closer to 1..) on average. Which means that making the NavMeshSurface2DBaker presentable and releasing it cost me about half a month of normal (=non vacation) development time.
With all the things that I already know still have to be done and the rate at which I discover new things that will also have to be done, I’m not really sure if I can afford and justify such escapades.


Progress Report: December 2018

  • Added some more commands for AI controlled ships.
  • Upgraded to Unity 2018.3 which required quite a bit of effort on my side but also got me some nice new features.
  • Replaced the system to import maps into the project because the old one wasn’t 100% compatible with Unity 2018.3.
  • Lots of refactoring in preparation to write an AI for ships.

What’s next?

Short term, my current goal is still to get a simple naval combat ship AI up and running.
All the building blocks are there now but even if I’m only aiming for a very simple AI right now, I will probably have to spend quite some time on research to make sure that whatever I come up with will also lend itself to plug in more complex AIs.

…and theeeeeeen (are we there yet?!)?

I’m not sure yet. There’s a myriad of things I could tackle after that but right now, I’m really not sure what would make the most sense. I’ll have to think it over some more.

Since this will probably be my last post in 2018, I already wish you all a happy 2019!

Progress Report: November 2018

One of my next goals is, to implement a simple naval combat AI to finally have something playable. I feel, this should have happened way sooner. Sure, you can sail around a map, enter ports, buy some things, etc. but that doesn’t feel like a game (no matter, how rough).

An AI deciding “I should catch up to the other ship!” or “The ship is in bad shape, I should flee!” is no good, if it doesn’t know how to catch up/flee/etc.
That’s why I’m currently working on some simple movement patterns.

Progress Report: September 2018

The focus of September was on AI ship movement, mainly on path finding.

There are a lot of common path finding algorithms out there but there is one drawback they have:  while they can take some  information like terrain movement cost into consideration, they generally just find the shortest way assuming an agent could move however he wanted. This also means that they can’t calculate a path considering possible agent restrictions like that the agent can’t fully slow down (or only with some delay), an agent might have a limited turn rate and only be able to turn whilst also moving forward, etc.
Another thing they can’t do, for example, would be to also consider the wind direction and it’s influence on ship speed, to calculate the quickest/best path.

Unfortunately,  an algorithm supporting all this would most likely be not only be computationally too expensive but also out of my league, time and ability wise.

So, what I opted for instead was the following idea: I use some standard path finding but instead of just moving ships along this optimal path, I’ll try to stick to the optimal path as much as possible but will only move/rotate the ship as much as the calculated restrictions allow. For example, when the calculated path tells me the ship should rotate 5° in a frame and the ship can only rotate 3° considering alignment to wind, wind speed, etc. I only rotate the ship 3° and will then try to rotate the rest in the next frame.

Following, you can see a video where I try this out with different turn rate settings. One important thing to note is that, at least currently, the ship can’t slow down and will always move as fast as possible as it can under the current circumstances (wind direction, etc), which further exacerbates the problems you’ll witness. This isn’t entirely realistic but might be kept for game play reasons. But even if not, the ship would most likely still have some inertia that will keep it from slowing down instantly.

Things to note

  • As long as there are no tight turns, movement works flawlessly.
  • Tight turns pose big problems.
  • With higher turn speeds, the problems become fewer but are still present.
  • There are situations in the video. where you can see the problem I described in the beginning: Since it has problems making quick turns, it would make way more sense for the ship to continue sailing around an obstacle and make a soft turn instead of trying to immediately turn around. But because traditional path finding calculates what it determines the most ideal path without considering the ships slow turning speed, the calculated path is totally different and causes the ship to do an almost 180° turn practically on the spot.
    This picture shows the problem as well:

    Traditional path finding doesn’t always lend itself to finding paths that make sense for a ship… (Yellow line = desired path, end of line = desired destination)

Why this might not matter

I currently won’t try to fix this for a few reasons:

  • The ship stats/controls aren’t calibrated at all. As long as I don’t at least roughly know, how the ships will steer in the end, there’s no sense in optimizing an AI for it.
  • Luckily, naval fights mainly consist of loads of water and the occasional “Arrrh!”. There simply will be near to no obstacles at all. At most a few ships and the rest is open space.
    If there are practically no obstacles, having problems with avoiding them might simply not matter. But to be sure, I’ll have to develop a simple naval battle AI first.

What if it matters after all?

I do have some ideas on how I could fix or at least lessen this problems:

  • Ships could slow down and try to rotate in a smaller arc if the amount they want to rotate is greater than a certain amount of degrees.
  • Ships could not rotate when too close to an object so they don’t crash into it, etc.
  • I could try to calculate paths from a spot a little in front of the ship to the desired destination and use that path if it contains fewer path segments than the currently calculated path.
  • etc.

Progress Report: August 2018

During August, I mainly worked on ship-to-ship combat.

Here’s a short video demonstrating the currently implemented features, namely:

  • Wind direction (black arrow) affecting ship speed.
  • Detection if enemy ship is within cannon range.
  • Shooting of cannons.
  • Reload time for cannons.
  • Health model for ships with different graphics reflecting current condition the ship is in.
  • Various (placeholder) graphical effects:
    • Smoke from cannons being fired.
    • Cannonball trails.
    • Explosion when a cannonball hit a ship.
    • Water splashes when a cannonball crashes into the ocean.

Code Snippets #2: Not Quiet So Simple Pooling Manager

A while back, I posted my simple pooling manager. Unfortunately, it turned out to be too simple for me.
It didn’t cover a common use case I have: requesting objects but not using them immediately. At the core of the problem was the fact that the pools relied upon if the object was active or not to determine if it was in use or could be handed out by the pool. When handing out the object, the pool then set the object to active so it wouldn’t be handed out twice incidentally.

This however presented a problem in a common use case like this:

  • A ship fires its cannons.
  • Since the ship has 20 cannons, I need 20 cannonballs.
  • To add some more realism, not all cannons are fired exactly at once.
  • However, it is way more effective to get all 20 cannonballs in one call to the cannonball pool and not make 20 separate calls for one ball each.
  • Since the pool needs to set objects to “active” when handing them out, the cannonballs immediately became visible. That was ok for those that were initialized and fired directly. But those that weren’t fired in the same frame as the cannonballs were requested, just spawned in the place they were at when they were when they were put back into the pool/disable the last time. They just floated there, motionless, until the frame they were fired in came up, then they were teleported to the correct spot and started moving/were shot.
  • To prevent that problem, I had to write a lot of code that was triggered on initialization and also when the objects were disabled (turning colliders, sprite renderers, etc. on and off). It was a lot of work, prone to errors and something that needed to be done separately for every kind of pooled object that wasn’t immediately used.

That’s why I wrote a new pooling system that doesn’t rely upon if an object is active or not to determine if it can be handed out or is currently in use. That way, objects can be handed out inactive by the pool.
Since there are major changes, I decided against silently updating the old post and to write this new one. That way, people interested in using a simpler pooling manager or comparing the two, will be able to do so.

Here’s my new version of the pooling system:

Class to manage multiple pools:

Class representing a pool:

Class that is attached to pooled objects by the pool. This meta info helps the pooling manager to return objects to the correct pool:


  • In my old pooling manager post, I mentioned that it was a lot more efficient to fetch n objects in one call than to fetch 1 object n times.
    While it’s still more effective to get all objects in one call, the differences in performance in this new pooling manager are a lot smaller
  • In some places the code looks a bit inelegant (using for instead of foreach, saving the amount of objects in a list to a variable instead of using Count(), etc.
    This design decisions are intentional. I did quite a bit of profiling and came to the conclusion that writing the code this way leads to much better performance when dealing with a lot of objects.

Video #0: In-Game Overview July 2018

When sitting together with a friend and talking about my project, we came onto the subject of a dilemma I am struggling with almost since the beginning of this project: I’m very unsure of what to present on my blog.

I’m no artist at all, which means that (for the moment at least) I’m relying on bad programmer art, assets from very old games and assets made freely available on the internet (thank you, kind souls!). Especially because of the latter two, I am very reluctant to show anything on my blog. I don’t want to adorn myself with borrowed plumes and I also don’t want to raise wrong expectations what the game will look like. That’s why I almost always decided against showing something visual in the past. But if I don’t show any of this graphics off, it’s hard to show anything tangible at all because 90% of what I produce is source code and that’s very hard to present in a visual way.

However, my friend made some compelling arguments for just putting everything I produce out there at this stage of the project. His points made a lot of sense, at least to someone who admittedly deep down always wanted to do this anyway but was simply too worried.
He convinced me and I thought to myself “Yeah! I’ll go home and start putting my stuff out there! No holding back anymore!” And that’s what I did! Well, almost. This conversation with my friend took place back in March or April, I think. But hey, no good project without some good, old-fashioned delays, right?

Without further ado, I hereby present the first result caused by this decision. A short video of some of the features that are already integrated in the game: