Advanced concept of Saving and Loading in my game

Hello,

As it is my first post here, I’d like to say that my name is Maciej and I am very interested in developing games (well, at least one game) on Your platform.

This post will be about a game for my Master’s - so a quite advanced thing. Also information provided here would become crucial for other games, as these are merely concepts, not implementations.

I am using http://hub.jmonkeyengine.org/forum/topic/entitymonkey-a-simple-entity-system-for-jme/ EntityMonkey entity system.

I have divided the game systems (namely - persistence systems) into sections, and I’d like to hear from You about hidden flaws of these, or even what changes should I make in these. So, lets start with

FILE SECTION:

Files of Program:
.dat Files - There will be kept files in .dat extension (my own one, nothing particularly significant). Most of these will not be overwritten by any means in the application - quite static files. Contents of those would be, for example, in-game settings. (pun intended with dat files :stuck_out_tongue_winking_eye: )

.j3o model files - Another type of files would be traditional jme3 graphical model files, represented by spatials in app (.j3o). These will NOT contain ANY userData (like in setUserData method of spatial). In my current vision of application, these will ONLY serve as graphical models. One for each enemy visual representation, but NOT for each enemy (for example, an generic Orc will always have its look as an Orc, but NOT always have the same stats as an generic Orc).

Save Game Files:
.sav files -These will be overwritten on-demand. There will be kept files, that contain userData mentioned above (for ex. health). The catch in this is right here: This folder will ONLY keep userData that has CHANGED during gameplay. This data will be represented as CHANGED COMPONENTS of an Entity (or a whole entity, if this would become too much hassle).

And lets continue with

DATABASE SECTION:

This will contain all the userData (namely: filled components of each Entity) from in-game entities. An entity is for example an Orc, that has Attacking and Defense components, and Defense contains Health, so current Health of this particular Orc will be stored in the Database.
As I mentioned above, I want different stats for same model of a creature - and this will make this happen. Ill load records from DB, then make them into Components that I will inject into applications’ Entities. All done on-demand (for example, when a level loads). After doing this, ill associate those Entities with certain Models (spatials), for example by a Component that contains information about which Model file should I use for this Entity.
So after doing all those steps, ill have my desired list of Entities, defined as “Orcs” with “Orc.j3o” as a visual representation, and each of these will have different Defense and Attack Components - so stronger Orcs, weaker Orcs etc.
Doing all those things in Models files would make this to happen: each individual (with unique stats, components) orc declared in game would have his own file, which would be a little too much, considering a level with hundreds of orcs. Now there is only one model file for “Orc.j3o” and hundreds of Database rows, each for one individual “Orc”.

Don’t fret, dear reader, the end is near and it is called

SAVE GAME SECTION:

As You may have noticed, I store changed monster definitions in saved games as a FILES and default ones as a RECORDS in Database.

I have done this in favor of:

  1. user should have the ability to freely store his saved games. Files are perfect for that.
  2. Keeping everything in the database would make user unable to store his saved games wherever he wants.

In terms of a pseudo-implementation, the process of save method would be:

  • Save changed entities (or only their components) into file (and that is all).

In terms of a pseudo-implementation, the process of load method would be:

  • Load all saved entities/components (as I said before, I am not sure whether I would save whole entities or just changed components) into app memory
  • update the database with these changed entities/components
  • load the level, which involves reading the database as usual - now with changed components! So changes like “Monster’s current Health” will preserve!

The benefits of this saving system:

  • “continue playing” button is a normal loading of level, nothing special in it (as database will always have the changes from last Load method)
    The drawbacks of this saving system:
  • the “New Game” button is going to have to erase changes made by last Load method, so everything would be “default”.

The flaws of this saving system, that I see:

  • i bet ill have trouble with getting “default” values for New Game button, so it would change in that way: Saving the game means save the files. Load the game means, load needed part of DB and change loaded values according to changes in loaded savegame files - without updating the DB, so DB always stores the defaults.

Thanks for reading! I really appreciate any comments on this! If something is a bit confusing, I’ll edit that.

guys, sorry for double-post but…

how to edit my previous post? I see that I have omitted some bolding here and wrong title there.

EDIT.

It seems I can’t do it. Great…

Add /edit to the url.

1 Like
@normen said: Add /edit to the url.
Thank You! Now someone can delete those now-unnecessary posts :)

I have a Meta layer for this,
entity can have a template component,
now I have a template replicator, that creates a copy (and remaps entty references to the copyies)
-> it also adds a reference to the template.

In your logic

Monster123 Template has 100hp
Monster123 instance in save abc has 20hp

New game just kills all non templates and replicates all anew.
-> Bonus you can get all info from the templates in the monsters, eg to make a single one respawn just reset it to the template values.

@Empire Phoenix said: I have a Meta layer for this, entity can have a template component, now I have a template replicator, that creates a copy (and remaps entty references to the copyies) -> it also adds a reference to the template.

In your logic

Monster123 Template has 100hp
Monster123 instance in save abc has 20hp

New game just kills all non templates and replicates all anew.
-> Bonus you can get all info from the templates in the monsters, eg to make a single one respawn just reset it to the template values.

Thanks.
Now I see, that I have omitted something important - the abillity to spawn new monster as needed. In my previous thinking I didn’t realize that my game would simply make monsters from database appear, not generating entirely new ones from templates.
I’ll consider this meta layer.