View Full Version : Save Feature
05-01-2006, 12:19 PM
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".
05-01-2006, 12:42 PM
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. :D
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.
05-01-2006, 01:18 PM
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.
05-01-2006, 01:28 PM
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:
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. :moreconf: 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.
05-01-2006, 05:42 PM
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.
05-01-2006, 06:22 PM
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.
05-01-2006, 09:37 PM
While I don't want to dampen your enthusiasm, I feel the effort needed to make an encrypted save would probably be better spent elsewhere. I put a lot of thought into this (a while back on another mod), and these are the conclusions I came to:
1. The save feature is something of an add-on to the engine. A basic version was put in to appease modders, but it's not very robust. Because of this, it's difficult to do much more with it than was intended.
2. Since I didn't have a license, all of my code had to be in UnrealScript. Therefore, the complete source would be available to anyone wishing to "hack" it. There's no way to prevent savvy users from figuring a way around the encryption, and they can easily "dumb it down" for the average user giving them step-by-step instructions on how to cheat.
3. Since the save would be used for SP, there's no real downside to the community for cheating. A cheater would simply be cheating himself out of the experience of the game. In the end, I didn't feel like it was worth the effort to prevent this.
These thoughts are what led me to develop the simplified system outlined above. I'm not trying to sway your decision, just trying to share my experience.
05-01-2006, 09:48 PM
These thoughts are what led me to develop the simplified system outlined above. I'm not trying to sway your decision, just trying to share my experience.I understand that. I appreciate your thoughts. I'm likewise sharing my (limited) experiences with implementing save features in games. I think having the knowledge of your groundwork is invaluable. We know that we will be able to put something like that in place if nothing else. :)
Since this is the earliest stages of this feature, I'm not discouraged in the least. As far as I'm concerned, all things are possible at the early stages of any design. I refine the design during this process to something more realistic, but I usually don't limit the scope at this time.
I think the important things to discuss at this time are what's needed and desired in this feature for this mod. This is a "wish list" phase. When I get some time to play with this, I'll start to get a better feel of the practical scope. But, I don't expect this feature to be implemented for another version or two at least. There's a little time to play yet.
vBulletin® v3.7.2, Copyright ©2000-2013, Jelsoft Enterprises Ltd.