Dev Blog
Hi, this is the Stranded III development blog (see also Forum Thread, Comment Thread).
Entry 120 - January 25, 2026
My new Godot plushie welcomes you to 2026! I was really sad when I learned that there was a plushie and that I missed the opportunity to buy one. But they made a version 2 and of course I had to buy it. It now sits on my headphone holder and monitors my work on Stranded 3. 
It's great! You can get your own plushie at makeship! Buy it now to support Godot - and to have a cute plushie
Map Editor
I spent a lot of time working on the map editor in the past few weeks. It was the biggest part of the Unity version which I didn't convert to Godot yet. Now most of the essential things are implemented. The editor is now using 2 panels (left and right). The left side is the main panel with tool selection, options, loading, saving etc. and the right side is context aware stuff. E.g., if you select and entity, you'll see all of its properties there.
A red light entity in the map editor
I'm using Gizmo3D by chrisizeful for the runtime transform gizmo stuff. That guy translated the original Godot C++ code to GDScript and C#. Great work!
Terrain brushes are now also much more powerful. They support rotation and you have a pixel perfect preview on the 3D landscsape. You can also add your own brushes by simply dropping images into the right folder.
A funny terrain brush at night
Some other new editor things which were not yet implemented in the Unity version:
The mini map in the top right can now be scaled freely via drag&drop!
You can define multi language map loca in the editor and store it in the map file.
Custom map preview images can be set and stored in the map file.
Sorting for entities: Ascending and descending by name, definition Id, weight etc.
Blazing fast saving
Most modern games use a "trick" to save games really fast. Or at least to make it look fast without interrupting gameplay: There are two phases.
Phase 1: Collect all required data.
Phase 2: Write the data.
Phase 1 makes a snapshot of the current game state in memory. It often requires access to engine related data. So when using Godot most of the logic needs to run on the main thread. This also means that it potentially stalls the main thread and leads to noticeable stutters. Luckily in Stranded 3 collecting the data is quite fast and only takes a few milliseconds in my tests. So for most users it won't be noticeable - depending on hardware and map size of course.
Phase 2 is the much slower one compared to phase 1. It writes the collected data to a physical drive. This is the actual saving process. Even with a fast SSD this takes multiple times longer than collecting the data. The difference is even more significant if you're still using an HDD. So how do we prevent that this slow writing operation blocks game play and leads to lags? We do it on a thread! This means the game can keep running normally while the thread handles the slow writing operation in background.
I also ditched some overly complex compression logic that I talked about in earlier dev blogs. Instead all data is compressed with Brotli compression which is natively supported by C#.
Furthermore I now make heavy use of BinaryWriter.Write7BitEncodedInt. This is a pretty efficient way to save positive integers which makes it the perfect fit for saving counts and sizes/lengths. It uses a variable amount of bytes to save numbers. 7 bits per byte are used for the actual value and the remaining bit is used to tell if there is another byte or not. This way values up to 128 (2^7) are stored in a single byte, values up to 32,768 (2^15) in 2 bytes and so on (2^(bytes * 8 - 1)). C# also uses it internally when writing strings to store their length.
It's great! You can get your own plushie at makeship! Buy it now to support Godot - and to have a cute plushie
Map Editor
I spent a lot of time working on the map editor in the past few weeks. It was the biggest part of the Unity version which I didn't convert to Godot yet. Now most of the essential things are implemented. The editor is now using 2 panels (left and right). The left side is the main panel with tool selection, options, loading, saving etc. and the right side is context aware stuff. E.g., if you select and entity, you'll see all of its properties there.
A red light entity in the map editorI'm using Gizmo3D by chrisizeful for the runtime transform gizmo stuff. That guy translated the original Godot C++ code to GDScript and C#. Great work!
Terrain brushes are now also much more powerful. They support rotation and you have a pixel perfect preview on the 3D landscsape. You can also add your own brushes by simply dropping images into the right folder.
A funny terrain brush at nightSome other new editor things which were not yet implemented in the Unity version:
The mini map in the top right can now be scaled freely via drag&drop! You can define multi language map loca in the editor and store it in the map file. Custom map preview images can be set and stored in the map file. Sorting for entities: Ascending and descending by name, definition Id, weight etc.Blazing fast saving
Most modern games use a "trick" to save games really fast. Or at least to make it look fast without interrupting gameplay: There are two phases.
Phase 1: Collect all required data.
Phase 2: Write the data.
Phase 1 makes a snapshot of the current game state in memory. It often requires access to engine related data. So when using Godot most of the logic needs to run on the main thread. This also means that it potentially stalls the main thread and leads to noticeable stutters. Luckily in Stranded 3 collecting the data is quite fast and only takes a few milliseconds in my tests. So for most users it won't be noticeable - depending on hardware and map size of course.
Phase 2 is the much slower one compared to phase 1. It writes the collected data to a physical drive. This is the actual saving process. Even with a fast SSD this takes multiple times longer than collecting the data. The difference is even more significant if you're still using an HDD. So how do we prevent that this slow writing operation blocks game play and leads to lags? We do it on a thread! This means the game can keep running normally while the thread handles the slow writing operation in background.
I also ditched some overly complex compression logic that I talked about in earlier dev blogs. Instead all data is compressed with Brotli compression which is natively supported by C#.
Furthermore I now make heavy use of BinaryWriter.Write7BitEncodedInt. This is a pretty efficient way to save positive integers which makes it the perfect fit for saving counts and sizes/lengths. It uses a variable amount of bytes to save numbers. 7 bits per byte are used for the actual value and the remaining bit is used to tell if there is another byte or not. This way values up to 128 (2^7) are stored in a single byte, values up to 32,768 (2^15) in 2 bytes and so on (2^(bytes * 8 - 1)). C# also uses it internally when writing strings to store their length.