How handle that a Game-Over needs to restart game

[Arnaud]

Hi,
in my game the map is modified while playing and i have not enough memory (in 64kB) to keep the original data (even compressed)
Then i case of game-Over i can't restore game in initial state (nor reload it).

I was thinking about two ways :

• Infinite loop in game-Over waiting for player to reload game : player will certainly give-up
• Resurrect player in first room keeping inventory : game will lost part of interest

What do you think is the best solution ?

[awergh]

If it is option one you probably need to make it clear that you expect them to reload to start again.
Having to reload again isn't an unprecedented idea as that is what happens in multi load tape games.
Although multi loading isn't much fun, but I don't think it is against the spirit of the cpcretrodev rules to require you to reload to start again)
If it is a necessary evil it isn't so bad as most people load from disk but it still works if loading from tape.

For option two I think it depends on the sort of game it is.
Is finding all the items what makes the experience unique or are they the same every time?
If they go back to the start will they be replaying from the beginning or continue where they left off because they already have the items?

How about a different question, is it necessary to die in your game? If the player doesn't die then they don't need to restart (of course this might not make any sense depending on the genre).

Ultimately I think if resurrecting the player with partial progress compromises the game experience stick with forcing the player to restart.
Besides it's not like it's going to take as long to load as Sultan's Maze does.

[GUNHED]

After the lives are used up you could load a simple loader, this loader then can do the rest. A simple loader can maybe only load one sector from disc or start the RSX command !CPM.


Or even better: Use 128 KB RAM as a prerequisite. 

[Sykobee (Briggsy)]

So yeah, you can do various things.


1) Detect extra RAM - use that to store the initial map / game state to reset from - should be pretty easy.


2) Never die - instead you lose experience/money/points


3) Reload upon game start - okay on Disk, horrible on Cassette.
3b) Cartridge version - will always have the initial map state available, just like having extra RAM.


4) Spend a long time rethinking the game map memory layout to free up enough to store the initial game state (compressed) - might mean that parts of the live map are recompressed during gameplay and only the area/zone you are in at the moment is decompressed. Depends on the compressibility of the map data. Also consider if there are ways to reduce the map size, at the cost of some flexibility or variety, if acceptable.


5) How *big* are the changes? Can you store the changes separately to the map data? I.e., the map data is always initial state, and you have a list of 'active changes' you apply during the game.


It shows why so many games back then never had permanent map changes, and why enemies reappeared when you returned to an area/screen, and so on.

[reidrac]

My advice would be: don't do it.

Change your data structures to have an init state and track the modifications.

In my games I handle persistence with 1 bit per entity. Not saying you can do the same, but think about it and you may find a solution.

[awergh]

Another option to consider (maybe not too seriously though as it is a bit of a compromise) is to split you game in half into two episodes or acts.
Then you would hopefully have the extra memory for what you want assuming you can section off the game so that some parts of the map only feature in a single episode.
Passing state across episodes isn't super practical either, maybe a level code that you got at the of the previous episode might work.
Most adventure games I have played will adjust your inventory on a new act so you could go that way easily enough and just design the game to facilitate what you need in the second act.

[roudoudou]

Hi,
in my game the map is modified while playing and i have not enough memory (in 64kB) to keep the original data (even compressed)
Then i case of game-Over i can't restore game in initial state (nor reload it).

Where is the alpha footage preview work in progress video? 

[Axelay]

I was thinking about two ways :

   
• Infinite loop in game-Over waiting for player to reload game : player will certainly give-up
• Resurrect player in first room keeping inventory : game will lost part of interest

What do you think is the best solution ?

Neither of those two options sounds particularly desirable, especially if as a 64k game you want it to be 464/tape compatible.


Don't know that I can add much to what's already been said, but you mention the player restarting with the same inventory, which makes me wonder how extensive those changes to the map are and, as has already been said, could you just store a change/reset list, if that's not what you were already thinking of?  Depending on your room drawing system, maybe you could even get away with not changing the map data and simply check for any item being in the inventory before you draw that item on entering a room?


Other than that, I'd guess it depends on whether it's a competition entry that needs to be a single load?  If not you could split the game or make it multiload as already suggested, or perhaps you might be able to use that trick I think one of the retrodev entries used in previous years, where you only got the menu once at the start of the game to make your option selections, and then on death the game just restarted without the menu.  So maybe you could reclaim memory by storing any menu selection logic/presentation/music in temporary memory that is discarded after the first play to make room for your map restoring data?

[Arnaud]

For option two I think it depends on the sort of game it is.

It's an adventure game with exploration and if there's no danger in entering a new room i'm afraid of losing interest while playing.

Where is the alpha footage preview work in progress video? 

The game is far to be finished and i already have no more memory left 

@reidrac, @GUNHED, @Sykobee (Briggsy), @Axelay
As you suggested, i split my data structure in two parts, static and dynamic. And i also optimized the dynamic part (no need to have map of objects in rooms that could not have objects) and compressed it.
And now i'm trying to use a loader to remove all code needed for loading and i hope to find enough memory to store the compressed dynamic data.

So maybe you could reclaim memory by storing any menu selection logic/presentation/music in temporary memory that is discarded after the first play to make room for your map restoring data?

I used this trick in my last entry of the retrodev previous years, maybe you are speaking of my game ? 

[GUNHED]

Good luck with your game - I'm sure it will be great (again). 

[Arnaud]

Another option to consider (maybe not too seriously though as it is a bit of a compromise) is to split you game in half into two episodes or acts.
Then you would hopefully have the extra memory for what you want assuming you can section off the game so that some parts of the map only feature in a single episode.
Passing state across episodes isn't super practical either, maybe a level code that you got at the of the previous episode might work.
Most adventure games I have played will adjust your inventory on a new act so you could go that way easily enough and just design the game to facilitate what you need in the second act.

You are right and it's a good idea, i could split the rooms in several independant area, because some area are purely "static" and and do not require to be "saved".

[awergh]

You are right and it's a good idea, i could split the rooms in several independant area, because some area are purely "static" and and do not require to be "saved".

I had been thinking of a much harder split between two acts but having dynamic and static areas is a good way to do this.


Reading about you working on your game makes me want to start planing my game for this year  .

[Arnaud]

Reading about you working on your game makes me want to start planing my game for this year  .

Nice !
This year maybe another "Fitzroy and ..."

[goksteroo]

Interesting problem - one that all game designers face at one time or another. Some more info would be helpful - like, ASM or Basic or ASM called by a Basic loader, data structure for the map and value ranges for the data, what map data is changed during the game, how much (or little??) memory do you have available....

[Arnaud]

Finally it works, and i mix all your suggestions :

• Separate static part and dynamic part from the data model.
• Optimize a little the dynamic part.
• Compress the dynamic part.
• Use a loader mixing basic / assembly in order to load and move data at the right place and remove all code for loading in main program (thanks to @Kukulcan for providing the loader)

And now when i die i can start a new game.

But as usual no more memory left  and the game is not finished.
Bref, je ne suis pas sorti de l'auberge...

[awergh]

Nice !
This year maybe another "Fitzroy and ..."

Thats the plan, I have an idea. I hope the gesture can slot into the idea but we will see.
I will probably formally decide what ... is in about four months time  .

But as usual no more memory left  and the game is not finished.

The never ending battle with finding more memory, but at least you have a few months to find some more instead of running out of memory just after you have implemented that fantastic must have feature and there is now only a few days or hours left to submit the game.