Devlog - 11th November - Thoughts on Tech Update (Patreon)

===
DISCLAIMER: If you are not interested in coding you might want to skip this ... ;)
===

Hi,

I have been thinking a bit about which tech changes to implement into the SJX Game Engine to upgrade it for SJX 2. These are all changes that do not introduce "new" features but may be the basis to do so efficiently.

Here is a list and the motivation behind it.

a.) Renpy and Python Upgrade

b.) Static Data Management (Locations, Quests, Items, Active Elements, ...)

c.) GAME registry system

d.) Establish an Upgrade Compatibility "Safe Zone"

Item a.) is obviously necessary to catch up with Renpy development, get access to new pygame module (explosions, clock, ...) and also mandatory after I upgrade my OS I assume.

Item b.) has plagued me since Princess. In effect, when the game starts for the first time, it reads in items, locations, clickable elements, etc. This means they are no longer easily changeable (e.g. if I update the item list the new item will not show up in game as long as the Game isn't restarted from start).
I plan to change that so every night the static data is re-analyzed and if necessary each item selectively updated in game. New locations, items etc can thus be be added without losing save game compatibility.

Item c.) is related to b.) So far I lazily updated static data items (e.g. location dict records, ...) with status info ("place visited" etc.). If I want the freedom to update static data elements over night, I need to relocate such status info to a kind of GAME registry that documents states related to static data elements.

If I introduce a.) , b.) and c.) I can possibly work for longer on a "labeled" (aka save game compatible) codebase without nuking process flow consistency. In conjunction with d.), which would mean that at one time in-game the process flow ascends to call hierarchy top level (e.g. every night) before descending again that point could be used for "robust" game states that do not need to care about process flow so much and can be used as hook points for patches and data scrubbers, enabling bigger update packages without sacrificing save game compatibility.

As users will never read any caveats where and when to save to safely retain compatibility ;) and will flood me with error messages as result, I need to add some kind of vetting / game freeze if the "safe spot migration save" rule has been not observed when trying to migrate a save game across versions.

Inside a version saving anywhere and everywhere will remain possible as ususal, as this is a good feature imho.

Let me know what you think. Above approach is not guaranteed to work but at least will allow content only upgrades in a compatible way.

y.v.