Save Feature

[Blitz]

I looked at the code that I had for the "save" feature in another SP mod. I thought I'd start a thread here explaining how it was done. I'll post code snippets if neeed, but I don't have them with me at the moment.

Step 1: The GameInfo class has a "SaveConfig" function. It writes any class variables with a "config" prefix to an ini file. The simplest use for this would be to declare an integer "checkpointnum" var. Each time the player advances to a new section of the SP environment, increment the variable and call SaveConfig

Step 2: Create Triggers and PlayerStarts that have checkpoints associated with them. When a map loads, the current checkpoint is read from the config and all triggers that are < this number are disabled. All playerstarts that are not exactly equal to this number are disabled as well.

Step 3: Mappers use checkpoints to divide their maps into "continuation" points. A special trigger is used to indicate that a new checkpoint has been reached.

Step 4: A menu option would be needed to allow players to "continue" or "start over". A more complicated mapname/checkpoint pair might be necessary for multiple SP maps or "ladders".

[SuperApe]

Originally Posted by Blitz

I looked at the code that I had for the "save" feature in another SP mod...
Step 1: ...The simplest use for this would be to declare an integer "checkpointnum" var. Each time the player advances to a new section of the SP environment, increment the variable and call SaveConfig

Step 2: Create Triggers and PlayerStarts that have checkpoints associated with them....

Step 3: Mappers use checkpoints to divide their maps into "continuation" points....

Step 4: A menu option would be needed to allow players to "continue" or "start over". A more complicated mapname/checkpoint pair might be necessary for multiple SP maps or "ladders".

Thanks.

1) I saw this. I guess it's used now for config saving, so you're settings for weaponsstay, etc. are saved for the next session of gaming. I think your suggestion would work well.

2) Already done: Objectives. Triggers, the OSMObjectiveManager and the TriggeredPlayerStarts are the elements to this method. This is how OSM is set up to work. Using the suggested variable to keep track of the last Objective reached should work fine.

3) Likewise, already in place. Special Triggers (OSMObjectiveTriggers) are already automatically used by the OSMObjectiveManager to allow non-linear Objective progression and ensure triggering only once. So behind the scenes: Trigger -> OSMObjectiveTrigger -> OSMObjectiveManager -> TriggeredPlayerStarts. We can just include the new property in OSMGame to keep track for saved games.

4) Right. Likewise, we need the Save option available in the HUD in game. The save would take the last Objective reached.

I'm pretty confident about the methodology here. What I don't know (or haven't used) is the code to save to a separate save file.

[Blitz]

Originally Posted by SuperApe

I'm pretty confident about the methodology here. What I don't know (or haven't used) is the code to save to a separate save file.

Here's how I think it works...

1. declare a var with the "config" option
2. SaveConfig() will write <variable>=<value> to the [ClassName] section of the <package>.int file in the System directory.

What I think will take a little work is writing an array of mapnames and checkpoints as config variables so you can save multiple states. This could probably be a structure stored in the class as a dynamic array. There's a nagging little thought in the back of my head that dynamic arrays might not work as config variables, but it's been more than a year since I've messed with the code. You might have to have a specific number of "save slots" in order to work around this.

[SuperApe]

Originally Posted by Blitz

What I think will take a little work is writing an array of mapnames and checkpoints as config variables so you can save multiple states.

Isn't there a separate INI for each map as well? It seems we could take advantage of that. If I read that correctly, you're talking about a [OSMSave] block in a <mapname>.INI file that has a property like:
SaveGame(0)="someencodedstringtojumptoObjectiveX"
That looks more like what we might need. It's close to what we're already talking about.

But to me, a SP save is only useful if it puts you back to where you were, with all the baddies, vehicles and NPCs where they were, and all your equipment. That's trickier. If need be, we can forget the Pawn placement within the map and let the Objective separation take care of that aspect. But the Invetory seems critical to me.

[Lord_Simeon]

This will be very, very cool.
Mine is going to be approv. 4 maps long, with multiple starts. I'd love a save feature, but i was combating it with the level load / new area scene.
Kind of like Duke Nukem with set stages that can be loaded if you only want to play through say OSM-Wangara-Mothership.

[SuperApe]

I've been thinking about this in my idle minutes today. More methodology design is desirable, I think. A scheme for saving your place in a map (which Objective you last completed), is totally possible. The scheme for saving your inventory, which weapons, how much ammo, shield and adrenaline, is harder, but I think it's possible. Saving the position and health of all Pawns (monsters, vehicles, NPCs, etc.) is harder still. Saving your place within a campaign, that is somewhere within a series of maps, could be harder still, but sounds possible. Now, the killer: making this saving scheme at least somewhat cheat-proof.

So far, we've been talking about just saving values or properties to an ASCII file. (Property=Value) But, the more successful saving schemes I've seen use some kind of compression, which also makes it hard to just go in and change NumObjectivesAchieved=all, for example.

This last idea isn't necessary, but I'm wondering if during the process of saving the other things that might become necessary we begin to compress the data, encode it. For example, instead of saving a series of properties like: "ShieldGun=true, AssaultRifle=true, BioRifle=false,...", we compress this to an encoded string that looks more like, "110...", not only saving space, but also making it a little harder to cheat. Now, imagine compressing the data as well. That may actually make it near impossible to fiddle with those values without messing up the save game completely, effectively working as an anti-cheating mechanism while saving on dataspace at the same time.

I've done schemes like this in completely different game designs in BASIC, saving whole levels, character profiles, etc. in small dataspaces while also making a save that isn't easy to fiddle with without breaking it.