SUBSIM Radio Room Forums - View Single Post - Saved won't load

MarkShot · 01-28-08, 06:19 PM

I used to play SH2/PA. Like GWX, PA was an amazing piece of work. The PA Team took a linear campaign and turned it into a dynamic campaign. However, ultimately there was one thing which killed it for me. You could save and reload. I could not get whole patrol played in one sitting. So, I gave up on it.

Granted I can back track here, but I want to simply be able to pick up a game where I left off. It is really not too much to ask for.

---

Save/reload is not that hard. You simply need two representations of data area:

Game Representation: This is what most programmers think of as variables, arrays, stacks, etc ... They are your subs, ships, map, crew, ...

Storage Representation & Threads: This is simply a pointer to start of all game data locations and the length of allocated data. Additional, as part of preamble it the list of active tasks and current execution points.

Save: You dump the SRT structure to a disk file. In this forms, it is just a long string of bytes.

Load: You read the SRT structure back into memory. Reset the active tasks and transfer control from a systems image process to the application handling. Thus, it becomes simply a game once again.

---

The beauty of doing the save/load as a systems function is that you can add new variables, buffers, and data structures. None of this has any impact on save/reload, since to those basic functions it is just one long string of serialized bytes. Once you have it working, it should continue working for all new patches and builds of the game. Not only is it maintenance free, but it is the fastest on saving and loading. Why? Because there is no need to traverse or rebuild complex data structures, it is just a big block of bytes. Only when control is transfered back to application handling, the game, does it begin to have a more sophisticated meaning.

If you fail to use the above approach, they you must make sure to capture each every bit of data about every simulated object in any given state and capture it to disk. Then, later you must rebuild the a very complex state of execution from little pieces of data captured on disk. If you neglect even one thing, then you get glitches. Any time, you make the smallest change to the code, you have to go back in and work on the save/reload functionality.

---

I know I just wasted my time, but maybe someone is reading this who aspires to be a game developer one day. Maybe they just discovered the right way to do save/reload. I can only hope.

01-28-08, 06:19 PM	#5
MarkShot Ace of the Deep Join Date: Jul 2002 Posts: 1,134 Downloads: 93 Uploads: 0	I used to play SH2/PA. Like GWX, PA was an amazing piece of work. The PA Team took a linear campaign and turned it into a dynamic campaign. However, ultimately there was one thing which killed it for me. You could save and reload. I could not get whole patrol played in one sitting. So, I gave up on it. Granted I can back track here, but I want to simply be able to pick up a game where I left off. It is really not too much to ask for. --- Save/reload is not that hard. You simply need two representations of data area: Game Representation: This is what most programmers think of as variables, arrays, stacks, etc ... They are your subs, ships, map, crew, ... Storage Representation & Threads: This is simply a pointer to start of all game data locations and the length of allocated data. Additional, as part of preamble it the list of active tasks and current execution points. Save: You dump the SRT structure to a disk file. In this forms, it is just a long string of bytes. Load: You read the SRT structure back into memory. Reset the active tasks and transfer control from a systems image process to the application handling. Thus, it becomes simply a game once again. --- The beauty of doing the save/load as a systems function is that you can add new variables, buffers, and data structures. None of this has any impact on save/reload, since to those basic functions it is just one long string of serialized bytes. Once you have it working, it should continue working for all new patches and builds of the game. Not only is it maintenance free, but it is the fastest on saving and loading. Why? Because there is no need to traverse or rebuild complex data structures, it is just a big block of bytes. Only when control is transfered back to application handling, the game, does it begin to have a more sophisticated meaning. If you fail to use the above approach, they you must make sure to capture each every bit of data about every simulated object in any given state and capture it to disk. Then, later you must rebuild the a very complex state of execution from little pieces of data captured on disk. If you neglect even one thing, then you get glitches. Any time, you make the smallest change to the code, you have to go back in and work on the save/reload functionality. --- I know I just wasted my time, but maybe someone is reading this who aspires to be a game developer one day. Maybe they just discovered the right way to do save/reload. I can only hope. __________________ War games, not wars! --- Only a small few profit from war (that should not stand)!