Unity to Godot Part 12: Input and Serialization
Porting work continues this week. Some of the things done:
- Wrote here a retrospective for 2023 and outlook for 2024 for the game
- Added ambient sounds for mines and cities. Ambience needs some normalization and tinkering.
- Tweaked overworld fog of war look, to make it darker, not the drab cement grey.
- Added instant teleport support for debugging
- Added press-and-hold actions for the overworld: minimap, fast path (Ctrl shows best apparent path to hovered tile, click moves quickly there), creature and object overlays. These were all implemented previously and now handled through the input systems
- Added a few coroutines that I had using a MEC port
- Chopped quite a bit of old code that's not used anymore due to refactoring or being Unity-specific
- Refactored some cache texture builders, e.g. visibility texture, light texture, etc
- Got an issue with deep copying, as the library that I now use (DeepCopy) failed for some reason throwing exceptions, so I reverted to a codepath using BinaryFormatter, got some issues there too but I fixed them. But this highlighted the ticking bomb that is BinaryFormatter.
- Got quicksave/quickload to work fine in the overworld
Serialization: the next frontier
Currently, at loading time, I do more work than I used to, and it got me thinking about saving/loading. I really hope that's not going to be the "unplanned time sink of the year" this time, but I need to think hard and forward about it. At the moment my saves (BinaryFormatter dumps, with LZ4 applied) are not robust at all - if ANY data structure changes, my entire savefile is obsolete. That's an issue of course, and I need something more robust. Also quicksave/load need to be quick, so savefiles and save data need to contain some hash info to compare to avoid reload/rewrite. Finally, BinaryFormatter, that I'm using, needs to be refactored out anyway, so I need to do it at some point... Next week's work (and probably more) will be devoted to serialization.