Lucky Day
Daywatch
The talk about the save games in Shadowrun makes me pause now that I see what is involved technically in developing save games thanks to my own game. the techniques you can break down in three systems, two of them are related.
When I first began my development on Android I was hoping there was something in the system that just took a snapshot of its states and every value in memory and could save the "image". It would be a pig but it would make save games simple and automatic. There isn't.
What Shadowrun does is create save states and this is how I think it (and a lot of other console RPG's) do it:
Predefined Areas:
Area 1 Area 2 Area 3 Area 4 etc.
— — — —
objects stack objects stack objects stack objects stack
starting point starting point starting point starting point
with each are object having a 3 or four dimensional area variable to indicate where they are in the rooms (x, y, d or x, y, z, d)
Player Object
—-
Attributes
Inventory stack
State Variable
Using the state variable, you can indicate where the Player should be at any time and simply load the player into it. It should be obvious to anyone, you only have to save the values of the player in the save file. The state variable will take care of where it should be (ie - the Starting Point in each area) and you simply load the predefined room into it.
In order to have a "save anywhere" system there's two ways I can think of doing it
first is save everything
Player Object
—-
Attributes
Inventory stack
Area 1
Objects Stack
Area 2
Objects Stack
Area 3
Objects Stack
in order to do that you have to loop through everything and every object in each area. An NPC object for example would have a variable concerning their current opinion of the player. I mean, what if the player shot some random player in the room? You have to account for that in the save if you want to make it continue like you left off.
Each and every object and variable needs to be recorded in each and every object in the game (that the player can return to, assuming the game is not linear) and then be reversed back out from storage to make it seem like its continuing from where the player left off.
As you can see this can get pretty large. You can reduce some of it by only saving the areas Player has been to, make the game linear so you only have to save one area at a time, or make it hybrid-linear by dividing the game into chapters and closing certains areas to Player behind the,.
Another, similar way to do it is
Player Object
—-
Attributes
Inventory stack
State Variable
Predefined Areas:
Area 1 Area 2 Area 3 Area 4 etc.
— — — —
objects stack objects stack objects stack objects stack
starting point starting point starting point starting point
Area Stack
—
Stack of changes to first area
Player Object
—-
Attributes
Inventory stack
the upper end would be the same size but it does have the advantage of only saving the changes and therefore being smaller. Basically you would load the Predefined Areas everytime then load the changes behind them.
That sounds ideal but its more complicated algorithmically as, first, everything would need a state variable to say if they've changed or not and on each object that could add up as drilling down further and further. Doing it this way also makes it more susceptible to breaking. So what you make up for in cost of size you lose in cost of performance, and more importantly, complexity.
—
So you can see why its tempting to do it the first way. On a game as complex as Shadowrun with only a budget of two million, how much simpler was it to do it this way, compared to the constant need for QA the other ways.
When I first began my development on Android I was hoping there was something in the system that just took a snapshot of its states and every value in memory and could save the "image". It would be a pig but it would make save games simple and automatic. There isn't.
What Shadowrun does is create save states and this is how I think it (and a lot of other console RPG's) do it:
Predefined Areas:
Area 1 Area 2 Area 3 Area 4 etc.
— — — —
objects stack objects stack objects stack objects stack
starting point starting point starting point starting point
with each are object having a 3 or four dimensional area variable to indicate where they are in the rooms (x, y, d or x, y, z, d)
Player Object
—-
Attributes
Inventory stack
State Variable
Using the state variable, you can indicate where the Player should be at any time and simply load the player into it. It should be obvious to anyone, you only have to save the values of the player in the save file. The state variable will take care of where it should be (ie - the Starting Point in each area) and you simply load the predefined room into it.
In order to have a "save anywhere" system there's two ways I can think of doing it
first is save everything
Player Object
—-
Attributes
Inventory stack
Area 1
Objects Stack
Area 2
Objects Stack
Area 3
Objects Stack
in order to do that you have to loop through everything and every object in each area. An NPC object for example would have a variable concerning their current opinion of the player. I mean, what if the player shot some random player in the room? You have to account for that in the save if you want to make it continue like you left off.
Each and every object and variable needs to be recorded in each and every object in the game (that the player can return to, assuming the game is not linear) and then be reversed back out from storage to make it seem like its continuing from where the player left off.
As you can see this can get pretty large. You can reduce some of it by only saving the areas Player has been to, make the game linear so you only have to save one area at a time, or make it hybrid-linear by dividing the game into chapters and closing certains areas to Player behind the,.
Another, similar way to do it is
Player Object
—-
Attributes
Inventory stack
State Variable
Predefined Areas:
Area 1 Area 2 Area 3 Area 4 etc.
— — — —
objects stack objects stack objects stack objects stack
starting point starting point starting point starting point
Area Stack
—
Stack of changes to first area
Player Object
—-
Attributes
Inventory stack
the upper end would be the same size but it does have the advantage of only saving the changes and therefore being smaller. Basically you would load the Predefined Areas everytime then load the changes behind them.
That sounds ideal but its more complicated algorithmically as, first, everything would need a state variable to say if they've changed or not and on each object that could add up as drilling down further and further. Doing it this way also makes it more susceptible to breaking. So what you make up for in cost of size you lose in cost of performance, and more importantly, complexity.
—
So you can see why its tempting to do it the first way. On a game as complex as Shadowrun with only a budget of two million, how much simpler was it to do it this way, compared to the constant need for QA the other ways.