I started to design the planet mechanics I have had in mind in a bit more detail. Mainly working with population growth and food mechanics and how to control the population on planets. People have to eat food to stay alive, but they will require more food to reproduce. Also, the growth rate is affected by the remaining free space on the planet. I feel this is quite realistic and simple. So the growth rate of the population on a planet is affected by the surplus of food and the size of the planet. As players can affect the growth rate by allocating work for farming, I find it convenient that the population’s work allocations can be set to meet desired goals. The goals are: sustain population size, max population growth and max food output (surplus can later be stored or sent to other planets). The allocation of workers then changes automatically once the requirements to meet these goals change. In addition, there is also a weight parameter assigned with the farming plan, which interpolates between these goals. With these tools the player can easily set the desired goals for the planets, hopefully reducing the amount of needed micromanagement.

After some (or all) of the workers have been allocated for farming (thematically all kinds of agricultural tasks, not just farming, whatever is required to get food on that planet) the rest of the workers are allocated to industry and research. There is another slider to set the ratio for this allocation.

All planets have base multipliers for food, industry and research output as well as a starting size. Now they are just randomized, but in the future there will be some kind of correlation between these numbers. Probably by having different types of planets and then using that base type as a starting point for some randomization.

Saving system

I have been thinking about and preparing how to make the saving system for the game right from the start. Now the individual pieces can finally be connected and tested. This system allows me to do the scene transitions seen in the previous post and the saving of the game seen in this video. In the video I set courses for the ships and make new blueprints and save to see that things are loaded correctly. For debugging purposes I save the state of the game into binary and JSON. JSON so that human can inspect it easily and binary because that’s what I’m going to really use in the end. Every time the game loads it loads both files and checks that everything matches.

I like to make only a few prefabs for the UI objects and then use them in different places and customize them via code instead of the inspector. This way only a small number of UI objects have to be maintained, it is not always fun to fiddle with those. For example the saving and loading panels are actually the same panel, but opening it up from different places assigns different functions for the save/load-panel and shows and hides different buttons.

Scene transitions

Fixed some issues with transitioning to combat and back and added transition to ship designing scene. Also added some UI things like a main menu panel and a fleet panel to show which ships the selected fleet contains. Next I will add some basic mechanism to colonize star systems and produce ships there. I still have to make some kind of basic enemy AI for the strategic part of the game and then a very simple version of the game can be “played”.


It was finally time to add some more efficient ways of finding ships based on their location. Things like finding closest ships to some location or all ships inside some radius around that location is needed in many places. For example when a ship wants to find the closest enemy or when some phenomenon affects all ships within some distance. So I implemented an octree to be used in the battle for this purpose. The benefits of the octree is that when looking for ships near some location, the algorithm can first iterate the bigger cubes and check if anything inside that can be close enough to the location. If not, every ship under that cube and its subcubes can be ignored, otherwise each subcube is again considered. Managing the octree of course takes some work, but with lots of ships the benefits greatly outweigh the costs.

In the video you can see visualization of the octrees and an example of its use. There are 200 ships per side, and for each frame and for each ship the closest ship from the enemy army is found. The closest ship is visualized with a blue line for the first army and with a red line for the second army. In a real case, the nearest ship search is done much more rarely, maybe closer to once per frame than 400 times per frame like here. Also, usually there should be some max distance in the search which also makes it a bit cheaper. This is not a real performance test since it is only run in the Unity editor, which makes this a bit slow for other reasons.

Unit groups

Giving commands one by one to huge numbers of ships is not very handy, not to mention all other problems like small ships getting lost in some corners of space. So I added some group controls to the combat UI. Now ships can form groups, like in many RTS-games, and there is also a button to choose all remaining ships. Groups can be selected by pushing the corresponding numeric button or by clicking near the midpoint of the group. I still keep the option of choosing ships freely, but I might change it later so that the groups are fixed like in Total War -games. That might be a much easier way to command the armies and probably wouldn’t restrict the combat too much. But will have to test and see if that is needed.

Also added a button which shows the command queue of all ship groups.

Scene transitions and basic combat AI

Worked on initializing the combat and star map scenes with correct starting information. Now if fleets meet at a star system, a combat scene is started and corresponding data is transferred to the combat scene. After the combat the star map is loaded and casualties are removed from the fleets. It is still handy to be able to test any scene you want by starting straight from that scene, and not having to navigate to that state of the game from the start. So each scene can also be started directly in which case it uses a test state for initialization which can be set from the Unity editor.

Also made a basic AI to control enemy ships in combat. Now they just queue to attack every opponent ship (player ships) one by one. I have done a coroutine based state machine for the individual ships and the same state machine could be used for the AI controlling the whole army. The state machine is very flexible and I feel that it will be enough for anything I need.


There will be four different mounting options for each weapon. Normal and right angle mounts are fixed to the direction they are pointing at. Then there are gimbal and turret mounts. Turrets are able to aim at targets in a semi sphere area. Turrets are more expensive, require more power, more space and they do suffer from a gimbal lock around the zenith, that is, they have some problems if the target is exactly above them. Gimbal mounts are like normal mounts, except they can rotate a bit left and right and up and down around the starting direction. They do not require a bigger mounting spot like turrets do but are more expensive than fixed mounts. They can only be mounted on forward mounts however, right angle mounts are always fixed to the direction they are pointing!

Gimbal mounts help less maneuverable ships to target faster ships and they also provide nice automatic gun harmonisation ( with adapting convergence point, which is needed against small targets. In the video the first corvette has beams with fixed mounts. The second corvette has gimbal mounts and it hits the small fighters much better.

Updated tracking

Updated all physics based direction tracking to be a bit smarter. Now they take all movements into account and still try to guide the turret/ship/gimbal to the correct direction the fastest way without overshooting. The following videos demonstrate the effects. The turrets try to optimally match the speed of the target, taking into account its own acceleration (and deceleration) and the movement of whatever it is mounted on. If the target comes to a sudden stop while the turret is correctly tracking, the turret will overshoot a bit. Similarly, if the ship the turret is mounted on rotates, and then comes to a sudden stop, the turret will overshoot. The result is satisfyingly realistic and accurate turrets.

Relative movement

Added possibility to give movement commands relative to some other ship. Should be useful when maneuvering bigger armies and ships of different speeds. In practice it means that the move commands can be set to follow another ship. In the fist video I have an overly complicated chain of ships following one another and in the second video lots of fighters following a destroyer.

Star map view

Finally starting the star map scene. Currently there are randomly distributed stars and fleets of different colors moving around. Changing the turn makes them do the set movement. There are lots of options on the rules of how to allow the movement between stars and how to restrict it. If ships are able to jump long distances it is hard to try to defend from attacks. It might be nice to have some kind of allowed paths between stars to have at least some kind of choke points. There also might be different kinds of propulsion systems which would enable different ways of moving around. I have some ideas but I have to test them a bit to see how they would work in reality.