0
\$\begingroup\$

I wonder how do I implement data persistence in 2d game. I am not using any engine, just pure Kotlin and OpenGL for rendering, so it is more of a software architecture question. The case:

Character travels on the tile map and after crossing the edge of it proceeds to the next level (or next map). Let's assume I want to store the character and its attributes, update actions (which are being performed in "update" method of the game), .

  1. Of course I can store the character entity in some kind of an object, that will be passed from one "scene" to another. Possible cons: unnecessary additional code to store and pass object.

  2. Using a file. Cons: This leads to parsing the file, opening streams to read data and etc.

  3. Declaring entities as static objects. Cons: I am afraid this can cause memory leaks, I am not sure how I am going to dispose static objects.

  4. Declare static object, which will hold the collection of data objects. Share it between all scenes. This seems like an optimal solution so far, even though I still will be referencing the object, I will have the ability to dispose certain entities.

I am not sure if some of the cons I mentioned are really making difference and will be significant. I want to know how this kind of logic is usually implemented.

\$\endgroup\$
1
  • 3
    \$\begingroup\$ It sounds like you've already surveyed the available options and identified the one that best meets the criteria you've set. What specific problem with your "optimal solution" would you like help solving? \$\endgroup\$
    – DMGregory
    Commented Apr 26, 2023 at 16:47

1 Answer 1

2
\$\begingroup\$

It largely depends on a game, but generally, it seems like you have a classic RPG/FPS/Arcade composition, where you have:

  • a Game instance (roughly speaking, this is your launched executable),
  • Game creates Sessions instances, one at a time (e.g. starting a new playthrough, loading a save, restarting, etc),
  • Session has a single Character instance and several instances of different Maps(Levels) he walks through. Maps(Levels) being instantiated on demand, existing one at a time.

Now you can see, that Characters lifetime spans over several Maps(Levels) and is equeal or just a bit shorter than the Session.

This is just the general direction, it can change to your game specifics. For example, in simulation-heavy games, it may be simpler to create new Character object for each Map(Level) from scratch, using just a small stored data (3-4 vars) and store it back on completion. Some games might deny Character progress unless Map(Level) is won, in that case you create a Character and only write back the results to the Character on completing. Other games could have very complex Characters (think RPGs), or ones that can even persist over Session in meta-gameplay.

How exactly do you store the Character instance in Session on serialization to savegame it up to you (heck, some games don't even do saves, they use level-codes), but generally you would store just the "persistent" bits (Level, Inventory, Skill-tree, etc).

\$\endgroup\$
2
  • \$\begingroup\$ It is actually the approach that is similar to the one I was using. However the Session creating was not implemented, so I surely gained some useful info from that. Thanks for the answer! \$\endgroup\$
    – Steyrix
    Commented Apr 27, 2023 at 16:32
  • 1
    \$\begingroup\$ @Steyrix It is "turtles all the way down" once you see it )) \$\endgroup\$
    – Kromster
    Commented Apr 27, 2023 at 18:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .