Ramblings about hobbyist game development
– Add a timestamp to save games
– Keep the scenario name in the game state so that it can be applied to save games
Resolves #99
Hello! I’m trying to go for smaller, but more frequent commits again. So just in that spirit, this commit once again does exactly as it says:
Obviously still missing and also the next topic is actually taking screenshot and using them as thumbnails. So until that is done, byeee!
Store both the wall and portal data in save files
Resolves #98
Hi! So, once again, this is exactly as described in the commit message. Probably the most interesting (and satisfying) thing for me while working on this was seeing the progression from “no walls at all” to “both walls and portals are rendered” correctly:
As can be seen there, now we’re seeing the exact same thing as before saving the game. 🙂 Next up will be fleshing out the actual save menu.. or maybe adding timestamp support to the save files, whichever will seem more appealing when it comes to actually working on it. Byeee!
– Implement storing objects in save files
– Implement storing tile type data in save files
– Fix value for ObjectCategory::All
Relates to #98
Hello! This commit basically comes exactly as described, it implements storing the current object and tile state in the save games. Still lacking however are both walls and portal state, which leaves us with the following situation:
So the obvious next two steps are supporting walls and portals. 🙂
– Activate the “Save Game” button in the in-game menu
– Determine a name for the new .zip file to be stored
– Provide enough basic information into the new newly created snapshot to make it load from the menu
Relates to #98
Hi! As I had had previously hoped, self-motivation is a much smaller problem when there is less debugging and more actual development.
This commit actually contains much of the meat of the whole save game milestone: it creates the actual save file (.zip), makes sure its name is in the correct format and finally writes data from the current game state into it.
As for now, this is weird up directly to the “save game” button in the in-game menu. There isn’t much in term of user feedback happening, but an astute observer looking at the log will see something like
These files are “good enough” to be actually loaded already, however for now the snap shots basically only contain the very basic necessary information for that.
To keep things interesting there are some caveats:
So the next few tasks are basically already cut out for me, I will put a special emphasis on adding the missing fields to the save games. Anyway, it was good to be back to actually creating, nut just debugging Code.
Byeee! 🙂
– Add support for loading save games from the main menu
– Add support for loading save fames from within a running simulation
– Add support to the SnapShotManager to load save games
– Fix locking issues
Resolves #89, #88
Hello! This commit took quite some time as I was stuck with a weird UI synchronisation problem which turned out to be.. me missing a function call to synchronise things.
As I had encountered similar problems before (and fixed them) I was hunting for yet another bug, unfortunately in this case that was wrong in hindsight, I simply had to manually force-synchronise the UI state and all these warnings (and the occasional crash) went away.
On the happier side of things, it is now possible to load save game files from both the main menu and the in-game menu, albeit they have to be manually generated.
As you can see, visually there is not much of a difference to the scenario selection, but it is quite nice to see three out of the four options to be clickable now.
Next up will probably preliminary support for actually saving games, which will hopefully go quicker, it comes with a variety of sub-tasks. But it is certainly going to be a lot more motivating and exciting than drawn out bug hunting. 🙂 Byeee!