After IMGJ27 and IMGJ29 this is now my 3rd time submitting 9 Dayz as an entry for the Improve My Game Jam series. IMGJs are a great motivation for me to work on my game, and as always I made quite some progress and was able to cross out some more points from my Todo list.

Looking back

In preparation for this article I was checking my last IMGJ Devlog which was about The In-Game Almanac. Was improving this guy some more since then, and added even more in-game information - showing up instantly when players hover certain items or actions. If you are interested, you can read more about that in the "What's new" Devlog.

My IMGJ31 Devlog (ongoing)

Which brings me to my latest changes which I did in the past week during the period of this Jam. I collected  most of them already in yet another "What's New" Devlog.

But I would like to use the chance to share some in-depth insights  for one of these  features I was  implementing in the past days:

Checkpoints - allowing players to save the game

The following insights are concentrating mainly on revealing the obstacles I was faced with and design choices, flavored with some tech talk here and there.

What needs to be saved - and how many?

What needs to be saved? The first candidate that came to mind was the inventory. It turned out that this was the simplest candidate. Around 50 objects and their amounts are already well packaged as a simple data object and can be easily saved and restored. Next, the character's properties - health, food, thirst and energy. Also a grateful candidate, as the data is very straightforward and easy to display in the UI.

But then it got tricky.

The next candidates: Day and time. Just two more values - easy, right?! Well, saving is super simple, sure. But in a game in which a constantly running in-game timer can be sped up and slowed down at any time and in which the environment reacts gradually to day and night times, restoring the correct state is suddenly no longer so easy. 

Screenshots: Morning > Day > Evening > Night. Not only colors, brightness and vignettes are changing. Also the shadows change their direction and shrink and grow throughout the day.

The Day-Night-Cycle in particular therefore took some time. I have adapted the code so that the change in the environment is no longer derived exclusively successively from a previous state (e.g. every evening hour, the environment gets a little darker, and shadows grow longer in relation to the previous one), but all environment properties can be specifically derived from a single, given time point. The result is not perfect, but it is good enough for now.

And the final candidate was the position of the player on the map at the time of saving. This one turned out to be easy, as I had already implemented dynamic repositioning as a feature in the game editor (a helper tool that supports me during development and is also available to you as a player via the corresponding button).

I have stopped at this point for now.

Unfortunately, the biggest chunks are still open:  Saving all the game world objects (buildings, places, trees, fields etc.) and their current states as well as the zombies and hostile animals. Uncovering all the parts of the map that have already been explored turns out to be difficult as well - although not as difficult as the first part. However, it is anything but impossible, as I have already completed all the important refactorings, which were aimed at reflecting all game objects and their changing properties via an internal data structure. Only the sheer volume and complexity of the data (and presumably the many side cases which will show up) make me hesitate to tackle this part right now.

Technical strategies and decisions

After some research I am faced with the following technical decisions. Upfront it looks like non of them will deliver an easy to implement and convinient solution.

The Browser Web Storage Option

At the moment I am converting all objects into a big JSON string and save it in the Local Storage of the users browser. Later I can retrieve the stored string from there to load the objects back into the game. It's an easy and straight forward solution which requires absolutely no additional action on the players side (except hitting the "Continue" button, of cause ;-)). Looking at the right side of my decision tree above, one can see how inconvient or even impossible other options would be when publishing games on itch.io.

The part that worries me without doing actual tests, is what is mentioned in the itch.io community posts Local Storage is lost at every update (unsovled technical issues, or lack of understanding on itch.io side) and How to save data (missing itch.io API).

Is Local Storage lost after game updates? - Doing my own tests

Regarding this community posts Local Storage is lost at every update there is an issue with changing CDN URLs after publishing game updates. This might sound awfully technical, the bottom line is: When the CDN URL (the "internal adress of the hosted game") changes, the former local storage can't be accessed any longer - hence, it is lost. But another user is stating, that this is not the case (any more). Time to check myself...

When saving my game for the first time, browser dev tools allow me to analyse this part (hit F12). In the following screenshot I highlighted the CDN URL (https://html-classic.itch.zone) as well as the first part of the stored data (one can even see what data it is, it was saved when I was reading the 1st signpost and some time data got saved - many more data is also included, but cut off).

Does it load after restarting the game? Yes, it does. But that was expected anyway, as the CDN URL is supposed to be changing only after publishing a game update. But I am optimistic here, as the CDN URL doesn't contain any dynamic parts. But let's check just to be sure...

Phew... all is good!

After publish a new version, and after making sure the game actually got updated, I was starting 9 Dayz again. And voila! The "Continue" button is still present - which means that game code can still access the Local Storage data. If this wouldn't have been the case, game would only offer the "New Game" button. Inspecting the stored data reveals exactly the same data as the screenshot above is showing. And after hitting "Continue" the game continues where it was saved before the update.

So. A solution is found and verified :-) I can keep this working Local Storage saving option. Will ignore the How to save data (missing itch.io API) part, as I can't do anything on this part.

How to load a save state - one feature, many (design) choices

This Devlog already got far too convolute. For this last topic I want to keep it really short. I will go for the left-side option in the concept below. Motivated by the idea of having different profiles later on.