CRPG Saved Games

[+adamantyr]

Hi all,

 

So I'm slaving away writing up as much CRPG code as I can... I want to try and get at least an implementation of ALL the game logic done so I can debug and fix and start really focusing on completing the game's story and dungeons and actually try and GET THIS DONE ten years after I started!

 

I have a small problem though to fix...

 

So I have a saved game file, which contains the basic party and character data. However, this isn't enough to preserve the whole game. There are "mob files" associated with each set of maps, which need to be altered ON DISK during play. This will let me make sure treasure chests stay empty, people say different things after you've stopped the bad guy, and so forth.

 

I'm doing this because the one major complaint I've heard with a lot of vintage CRPG's is the total lack of persistence in the world. This is understandable with the older technology, but I'd like to have mine be a much more dynamic experience than that.

 

The problem though, is how to handle saved games. Most gamers are used to being able to just restore from the last save if they don't like what happened in the game, and get a do-over. Allowing for this, though, is going to be a huge strain on the game. In particular, I'll have to actually copy and create WORKING copies of each mob file (4k each) every time you load a saved game, only modify those, and then copy ALL of those records back to the main game files if you actually save the game. (Also, yeah, you'll need to have master copies of the files.)

 

In assembly, this will be significant work. Effectively, I'm using a disk file to act as long-term memory storage. (And before you ask, no, I don't have space for this in CPU RAM anywhere.) So at start-up, it would need to load up the entire mob file and save each record back into the saved mob file. Each mob file is 2048 2-byte records, so it will take awhile to do this. I'd feel better about this if I could treat length-2 records as length 128 for reading/writing purposes, but I suspect this won't work at level 3 access. (I'll have to write some prototype code to test this out.)

 

Then I started thinking... what if you COULDN'T restore a prior save? What if, too bad, you are going to just have to deal with things, no do-overs? So in this case, every time you did something that altered mob records, it auto-saves the game for you, and that's your new restore point. Would this work, or would players hate it?

 

So I'm polling and seeing what people think about saved games in CRPG's! Looking forward to everyone's opinion on the subject!

[+InsaneMultitasker]

In assembly, this will be significant work. Effectively, I'm using a disk file to act as long-term memory storage. (And before you ask, no, I don't have space for this in CPU RAM anywhere.) So at start-up, it would need to load up the entire mob file and save each record back into the saved mob file. Each mob file is 2048 2-byte records, so it will take awhile to do this. I'd feel better about this if I could treat length-2 records as length 128 for reading/writing purposes, but I suspect this won't work at level 3 access. (I'll have to write some prototype code to test this out.)

Just a few quick thoughts about the file IO as I finish some lunch...

 

I'm not entirely clear what you mean by treating length-2 records as length-128; however, file routines are fairly flexible. If you expand the record size you would need to have a larger record buffer and presumably you would need to calculate both a record offset and the bytes within the record, versus simply reading/writing the 2-byte record directly.

 

From an efficiency perspective, you may gain speed by using a longer record length. As an example, try reading the 4096 byte file first as 2048 2-byte records then as 32 128-byte records. If you are only reading/writing a few records, it isn't as noticeable.

 

Finally, if you are looking to read the entire MOB file at one time yet retain the record IO at a 2-byte level, you could use DSR level 2 IO to read the file directly. This hybrid approach has its own set of pros and cons depending on how you use the mob files.

 

To partly answer your 'poll' I think a game save option is very helpful.

[+adamantyr]

Just a few quick thoughts about the file IO as I finish some lunch...

 

I'm not entirely clear what you mean by treating length-2 records as length-128; however, file routines are fairly flexible. If you expand the record size you would need to have a larger record buffer and presumably you would need to calculate both a record offset and the bytes within the record, versus simply reading/writing the 2-byte record directly.

 

From an efficiency perspective, you may gain speed by using a longer record length. As an example, try reading the 4096 byte file first as 2048 2-byte records then as 32 128-byte records. If you are only reading/writing a few records, it isn't as noticeable.

 

Finally, if you are looking to read the entire MOB file at one time yet retain the record IO at a 2-byte level, you could use DSR level 2 IO to read the file directly. This hybrid approach has its own set of pros and cons depending on how you use the mob files.

 

To partly answer your 'poll' I think a game save option is very helpful.

 

I set up poll questions but they didn't appear... Hrmph.

 

Yeah, I'm wondering if Level 3 is flexible enough that IF I opened a file buffer and said "no no, this is length 128, not 2" would it choke because the file's header says it's only length 2? Or would it say "Sure" and let me manipulate things that way?

 

Yeah, I was looking over reading/writing by sector... You're quite right, if I could read in 128-byte length segments and just write those back out, it would be a much faster process.

 

Part of me doesn't want to be lazy and wants that "undo" option. There are auto-save points; I've split all the maps and places into four distinct file groups, so there are points where you'd cross over a threshold and be told "you have to save the game now."

Edited February 27, 2015 by adamantyr

[+adamantyr]

Come to think of it... what I'm basically looking for here is a Copy File routine in assembly language. Anyone have a basic routine already written I can make use of?

 

Updates to the file as you do stuff in game would just happen on a single 2-byte record basis. So that won't need anything extraordinary.

[+adamantyr]

So here's what I decided...

 

Every time you transition to a new map, it will auto-save all changes to the file. And after significant events (Mainly events that actually alter a record that is NOT even associated with the map you're on) it will also auto-save. That means that your actions will NOT be reversible, unless you want to make copies of the saved files yourself.

 

This should be interesting... a CRPG that forces you to live with your mistakes.

[+Vorticon]

Oh noooooo! You mean just like real life??? I play games to get away from real life!

By the way, the fact that you picked up the CRPG development again kind of makes me feel guilty of neglecting Ultimate Planet. It will 10 years next year since I started the project, but I refuse to completely drop it

Guilt is not fun, so I hate you...

[Bill Loguidice]

So here's what I decided...

 

Every time you transition to a new map, it will auto-save all changes to the file. And after significant events (Mainly events that actually alter a record that is NOT even associated with the map you're on) it will also auto-save. That means that your actions will NOT be reversible, unless you want to make copies of the saved files yourself.

 

This should be interesting... a CRPG that forces you to live with your mistakes.

 

It's your game of course, but I don't think it's particularly good design to punish players. You're not making a Rogue-like game here, but a CRPG, and one common theme with most CRPGs is the ability to go back to a previous save after either intentionally or unintentionally getting into a fight (or some other scenario) you can't possibly win at present and/or that might take multiple tries. Or am I misinterpreting what you're stating here?

[+adamantyr]

 

It's your game of course, but I don't think it's particularly good design to punish players. You're not making a Rogue-like game here, but a CRPG, and one common theme with most CRPGs is the ability to go back to a previous save after either intentionally or unintentionally getting into a fight (or some other scenario) you can't possibly win at present and/or that might take multiple tries. Or am I misinterpreting what you're stating here?

Thank you Bill for asking a good question!

 

No, combat results will not be saved. In fact, if the whole party dies, you can restore from the last save.

 

The only time it would auto save is if you move to a different map. This means enemies you defeated stay defeated. And if you have a fight with a tough opponent and win, you can save the game immediately so you don't have to fight it again.

 

The only time the game does a full save without asking if if you do something in a transaction that has wide reaching impact, like, for example, breaking a dam that causes a valley to flood. None of these actions will make the game unwinnable or unplayable.

[Bill Loguidice]

In that case, obviously, it makes perfect sense.

[Opry99er]

Adam, from a player's perspective, I fully see your dilemma. Not knowing how "free-form" your exploration through the world(s) will be, it is difficult to fully answer the question.

 

Once a new map is entered, can the party re-enter a previous map? If there was an important (non-crucial, but not trivial) item that the player forgot to get or a big stash of gold he missed, can the player go back to retrieve it?

 

I know that sometimes when playing RPGs, I am so.focused on the quest that I neglect to fully explore the world. If I reached an auto-save point and learned there was something I missed, could I go back to get it?

Again, it is a game-structure question here, certainly not a criticism.