We are proud to announce that our demo for Postbound! has been released! We encourage you to go check it out and send us your feedback. The full game release is slated for July 22, 2024. We put a lot of heart and soul into this game, and we hope you enjoy the demo.
Godot Engine
Our game is developed in Godot 4.2.2. We started in Godot 4.2.2, and finished in Godot 4.2.2. Overall, we had a very pleasant experience with using the engine. We found a few bugs and annoyances here and there, such as the inability to add space between TabContainer tabs, but nothing completely showstopping! We got it done, and now we are gearing up to finish the game and polish it up for its full release.
Issues
We did have one issue that does make us a bit wary of Godot, however. Not enough to stop using it, but just enough to look deeper and attempt to refine our development processes. It appears to be incredibly easy to “corrupt” scenes even when working purely in-editor with no major bells or whistles. Just 7 hours prior to our demo’s full release, several of our game’s most important scenes were seemingly corrupted, with no way to remedy the issue in-editor, and without making any changes to the project between a non-corrupt state and a corrupt state. This was completely shocking to us. Even using version control to revert the project back to a prior known-good state did not resolve the issue, which was incredibly panic-inducing right before a big release.
What made this issue incredibly difficult to debug is that despite having corrupt scenes according to the editor, the game ran both in-editor and after export perfectly fine, without issue. Even when inspecting the scenes manually (they are just text files, luckily!) we could not immediately pin down the issue, as everything looked structurally fine. After reverting back to a known-good state via version control, the Godot editor finally popped up a… blank error screen. It said there were errors and attempted to show them, but nothing was there in the error dialog. This persisted even after deleting our .godot folder and reloading, many many times.
So we went with the brute-force method: remove portions of the scene files in question until the errors go away. We eventually pinned the issue down to a scene we hadn’t edited since the near beginning of the project! We simply re-added the scene to the previously “corrupted” scene files and all was well again.
Potential Mitigations
What could be done differently by the Godot editor to prevent this?
- More detailed error messages: something more than just ‘Scene corrupted!’. There should be additional heuristics run by the editor to attempt to correct common scene corruption issues, such as regenerating scene IDs and fixing obvious syntax errors. These automatic fixes should be applied only when explicitly approved with a ‘Fix’ button or similar.
- Allow editing a structurally/syntactically correct scene, even if the scene/node IDs are no longer relevant. We should be able to remove and re-add these kinds of nodes in-editor. without having to resort to editing the scene file directly.
- More robust integration with version control systems to actually ensure known-good states return to known-good states. We were using the proper
.gitignoreconfiguration and weren’t uploading anything silly or autogenerated to our repository. We aren’t entirely sure how the autogenerated files work, but we suspect something about our corrupted scenes was causing Godot to autogenerate bad files.
Updated June 11, 2024
After posting this article on r/godot, we have been informed that Godot 4.3 makes some changes that address some of these issues, which we are very happy to hear! In particular, it addresses our first and second bullet points.
Our third bullet point may only be somewhat relevant, as if you know where Godot stores cached files (it’s not just the .godot folder!) then you should be able to avoid issues with version control not working as expected. Specifically, Godot stores additional settings and cached files in %appdata% on Windows, ~/.local/share on Linux, and ~/Library/Application Support on macOS. You can put a file with the name ._sc_ in the same directory as the Godot binary to tell Godot to use a self-contained mode, which will ignore the aforementioned metadata folders and create a new one in the same directory as the Godot binary. With this knowledge, investigating and addressing issues should be much easier if an issue occurs that isn’t addressed by version control.
End of update
Going forward, when we have the time, we are going to be putting more effort into enhancing Godot in ways that benefit our studio in the hopes that it also benefits other studios. What happened to us should not be possible to happen under regular circumstances: we weren’t doing any editing out-of-editor, we weren’t configuring files in weird ways, and we were only using two extremely popular add-ons available in the AssetLib (GodotSteam and DialogueManager).
Despite these issues, we still love Godot and we still plan to use it. However, because we have no idea what caused this issue, aside from a large hunch that it is related to scene/node IDs, and we are 100% certain that we did not make any modifications to the project between the non-corrupt and corrupt states, we recommend that you take extreme caution when using Godot for your project, even if you are using the latest version.
Further Updates
We will publish a full post-mortem a little while after the full release of Postbound! Keep an eye out for that if interested, and thanks for reading.