Ahoy! Captain Filip here, welcome to our third Captain’s diary post. I would like to share the progress we are making as we are working full steam ahead on delivering the alpha build. So let’s jump into the updates!
Multiple settlements
As you might have noticed in the press build, there was just one large settlement where all the housing had to be joined into one big blob. That was tool limiting for obvious reasons. It did not allow to move the settlement somewhere else or to have multiple ones on the island. So we did a big rewrite and you can now build any number of settlements you want. You just need to make sure to connect each of these to all the resources. Maybe one day, settlements might have a limited reach on how large an area they can serve with workers, and extending that area would require public transport. So many options here!
Better upgrades
Previously, upgrades worked in the way that a machine scheduled for an upgrade was replaced with the upgraded one which was only finished after the required materials got delivered. That led to strange situations such as no ability to revert such an upgrade or the fact that the machine being upgraded was not able to work while materials were being delivered for the upgrade. That broke in cases like upgrading a shipyard that was the only one that had the products required for the upgrade so the upgrade was totally blocked :) And so we have redesigned this system. Now what happens is that a machine gets delivered all the materials needed before it upgrades itself. So the upgrade can never get stuck on missing resources and the machine can stay in action while materials are being collected. That’s neat!
More fun with seawater
We felt that our glass chain was a bit too simple. Just throwing sand into a furnace and here goes glass. We also realized that the player needs to get access to clean water earlier as the groundwater on the island can run out. So we took all these requirements together and did a little brainstorming and we ended up with a new product, salt! We are introducing a “new” thermal desalination facility (which is a reuse of our basic distiller). It boils seawater to create clean water and brine. Brine is a highly concentrated water solution of salt. The water can go to wherever needed, like farms or settlements. And brine can either go back to the ocean or it can go to the evaporation pond. The pond accepts brine and produces salt. And the salt goes to a glass mix which goes to a furnace to make glass. Having a new product like salt is exciting and we are looking forward to finding more use for it. Below is an overview of the new chain. The brine pond has a very cool animation but I will keep that for myself so you can experience it in alpha on your own!
Tutorials
We heard your feedback the last time. Tutorials are long and repetitive. So we heavily reduced the length and repetitiveness of tutorials and even recorded a few videos to make things more clear. We hope that the videos and changes we did will explain more things that sometimes took folks time to figure out. And we have also added a tutorial for the cargo ship. When doing that we have also prepared them for our community translations. So today you might see more strings for translations in our tool. And this is most likely the last significant push of string for translation. And speaking of translations, we now have 5 languages at 100% (before the new tutorials push), great job our community, you are amazing!
[Technical] Occupancy internals improvements
This is a little technical topic, but the conclusion is that we now support overlapping entities (you will learn why in the next update!), occupancy checking is faster and takes 5-10x less memory. Keep reading for more details.
We need to track precise occupancy to be able to compute collisions for building construction and for vehicle path-finding. This occupancy is done in 3D space since buildings like transports can go above each other, trucks need to be able to go below transports, etc.
Until now, we simply used a lookup table where the key was a 3D coordinate and the value was a reference to the occupying entity (some might know this data structure as a hash table). This means that for each occupied 3D coordinate we need to insert one entry. This works fine for smaller entities, but larger buildings such as farms have tens of thousands of occupied 3D coordinates, and storing each individual coordinate was becoming a problem.
Additionally, the old data structure could not represent overlapping entities because at every coordinate exactly one entity was recorded. We needed to relax this property and allow overlaps.
The solution was to change the representation from 3D to 2D. For each 2D coordinate we now save a range of occupied heights in format:
(EntityID, start height, total occupied height)For example, if height of a farm at coordinate [1, 8] is 4, we simply save
[1, 8] => ( [Farm#1, 2, 4] ) where the "2" is the terrain height. In the old representation we’d have to save:
( [1, 8, 2] => Farm#1,
[1, 8, 3] => Farm#1,
[1, 8, 4] => Farm#1,
[1, 8, 5] => Farm#1 )What are the savings? In the old data structure, a T3 farm stored 10k individual 3D coordinates that took ~100 kB of memory. Now, the farm has 2.5k 2D coordinates that take ~20 kB. We also no longer use a lookup table and store occupancy data directly in the terrain data structure. This brings faster access since the terrain is stored in a simple array.
Moreover, each 2D coordinate can now store multiple occupied-range records so overlapping entities are supported! As a side-effect, clearance testing in vehicle path-finding (whether a truck can drive below some obstacle) became more effective since we can now do a single check on a 2D coordinate instead of iterating over multiple 3D coordinates. The downside is that the code for testing occupancy became more complex (tests to the rescue!).
And this is all for now! Thank you for reading!
Comentarios