Using a pass code instead of saving to disk or tape?

Technical Development Development Systems
1

As some of you may know, many of the cross compilers that target 8-bit computers do not include an option to save data to tape or disk.

I was chatting to someone on a Discord channel for BASIC programmers earlier and they suggested using a pass code as some arcade games did on older machines.

My initial thought was that the code would have to be unfeasibly long to store the game state. Would it though?

Has anyone tried this for a parser based text adventure?

3 Likes
2

In general you’re right. A typical parser game stores the location of each movable object, plus any game-specific flags for each object. That’s probably a couple of characters per object even if you try to minimize it.

It might be feasible if your game is organized in chapters and you can mostly predict the state of every object at the start of a chapter. Say, if each chapter brings the player to a brand-new area and strips their inventory down to a fixed object list (“sword and lamp”). Then your password just encodes the chapter number.

(In Hadean Lands, I considered creating a password system that just encoded the list of spells you’d learned at one bit each! But there was just enough extra state information to make this not worthwhile.)

4 Likes
3

Alright, we’re talking about smaller games.

So;

“dropping” is overrated. Can’t drop anything in the game. waste of time anyway.

Then;

  1. < 128 locations (7 bits)
  2. <= 30 gettable objects (30 bits)
  3. 8 boolean flags (8 bits)

For (1) 7, bits store player location
for (2), 30 bits of whether the gettable is carried
For (3), spare 8 bits of story flag state

total = 45 bits.

Game generates an alphanumeric code of 10 characters. Each character

A-Z0-9 = 36 combinations. Drop to 32 by eliminating confusing 0/o, 1/l etc.
Each character encodes 5 bits.

So 9 chars is 45 bits needed, plus one extra as checksum/crc/hash to prevent cheating.

10 chars is not too long, can be increased eg 12 for more game states or even a variable length code. Perhaps up to a max of 16. which should still be ok to type in.

Edit: if you must keep drop, maybe add the good 'ol thief into the game :slight_smile:

4 Likes
4

Or add casing and a couple punctuation marks to get 6 bits per character, if you really trust your players’ handwriting to be able to clearly distinguish c from C and s from S and so on.

2 Likes
5

I use this save method in my games, but then I use a website/server to store game state as you play, then when you save, it just saves that state to a database and returns the unique reference to that record in the database (10 or 12 uppercase letters, depending on the game) that you can use alongside the LOAD command.

My games tend to track A LOT of data about the game to improve things like the CLUE command (which can help you find locations you have not yet visited, items you have not yet examined, etc.), so it would be infeasible to store all of that in a code without a database.

If the code itself was the game state, this could have unpredictable results if the player mis-types the load code. In the worst case, this could put the game in an unwinnable state without the player being aware (for example, accidentally placing an inventory item in a location beyond the place in which it’s needed).

2 Likes
6

Nice idea. Also regarding cheating/mis-typing, that’s why i figured to have a “check” digit. Really, it would probably need at least two to deter cheaters!p

1 Like
7

Thanks everyone.

You seem to have confirmed that even if I used a-z, A-Z, 0-9 and a couple of extra characters so base 64 (6 bits) could be used, it would only be helpful for games so small that RAMsave would be good enough anyway.

1 Like