I’ve read this question and several others like it, however they don’t address exacty what I’m looking for here. Apologize in advance if this is a duplicate question (if it is, please feel free to point me in the right direction!).
I’m trying to implement a “persistent pause” feature, whereby the user can pause the game and even quit the game (kill the PID) but resume exactly where they were when they paused. That is, resume everything in the scenegraph to the state it was in prior to hitting pause.
To me, it seems this could be accomplished by persisting the scenegraph to disk. So I searched these forums and consulted the Google Gods, but could not find a good explanation for how to do this.
Ideally, jME3 would have a Utils-type class tucked away somewhere that I could use:
SceneGraphUtils.persist(rootNode, new File("path/to/my-scenegraph.bin"));
etc. If that doesn’t exist (either as part of core jME3 or any 3rd party OSS libs that anyone knows about), then I’ll have to implement my own. Once I have an object, I can handle the serialization/deserialization to/from binary format (or XML, JSON, YAML, etc.). I guess in this case, I would just need to know what actually constitutes “the scenegraph”.
I assume I could implement a SceneGraphVisitor and traverse all the Spatials under the root node. And, for each spatial, my visitor would implement my custom persist/serialize behavior. But I’m guessing there’s more to a scenegraph than just the tree of spatials underneath the root node. So any guesses as to what objects/relationships I’d need to persist in order to say that I’ve “saved the entire scenegraph to disk”?
But really, saving the scene graph is not really what you want probably… since if you’ve designed your game properly then that wouldn’t save the actual game objects. Unless you’ve followed the short-cut antipattern of treating spatials like game objects.
pspeed can give you more thorough answer most likely. But a common MVC pattern is what usually you are supposed to be doing (or anything else, but not use the visual objects as real objects). Scene graph is just the view, and as you develop the game anything visual is most likely going to change along with behavior. But game objects are most likely quite persistent, or easy to convert from “older saves” to new by assuming default values. This assures longevity with you save games. But that is just one reason, the lesser reason
Well, let’s say you are making a game about pigs. So you have a Pig class. It has a position and all the nice things that a pig in your game will need. You have some simulation loop that moves the pig into the mud, over to the trough, etc… all of the nice things a pig will want to do.
All of those pigs running around do so independently of any sort of “view”. To display your farm to the players, you pull a bunch of things together, loading assets for the barn, the trough, a mud pit, etc… and some pig assets. Every frame you make sure the pig Spatials represent the location, orientation, animation state, and so on that matches the state of your Pig game objects.
When you save the game, you are just saving the pig objects. The scene will reconstruct itself from the loaded state of all of those pigs.
Otherwise, if today you decide you want minecraft style block pigs with basic lighting and tomorrow you get AAA style, 15000 polygon pigs with PBR textures, animated breathing, etc… the player won’t care. They can still load games just like they always did but now they get hi-def pigs with new shaders.
1000 different things can change about your spatials due to your game evolving or JME fixing things, etc. that have nothing to do with where your pigs are and what they were thinking. So it would be a shame to ruin your player’s save games every time you decide to change something. Where as the state of your pigs is probably a more durable thing to save.
