Making multi-part games on small systems

Technical Development
, ,
1

Many games structure themselves into several vignettes to avoid combinatorial explosion and also to make the game feel less daunting to play.

If you’re trying to make a really large game on Z3, you… have a few choices.

IIRC, at least one Scott Adams games had multiple parts, and the end of the first part gave you a password to “get into” the second part. That’s easy enough.

I was trying to think if there’s a way you can make a save game from one game be usable in the second part, but the only way that could fly is if their dynamic memory contents (which contain all the object names, for example) were identical, so I think that’s a nonstarter.

The next option is a dynamic password like 80’s Nintendo games had.

A string of letters and digits can obviously encode a reasonable amount of game state. This could encode which key objects you’re carrying, maybe the result of a few key choices you made in the first part, your final score, etc. You can include a checksum to keep people from guessing things.

The evil part of this of course is you could conceivably finish part one without the right “game state” to make part two winnable. That’s not very high on Zarf’s kindness scale.

I remember some ancient game I played on my Apple ][ clone where it simply chained to the next part of the game in a separate basic program. “Some of your items were lost as you crossed the raging river.” That meant they didn’t have to implement responses for all objects from the first part,

This would allow systems like a 48k spectrum (so no pageable VM) to conceivably play larger games?

Ultimately it’s a way to make a very large game playable on a very small system.

I can’t think of an example of anybody actually doing this, and there’s probably a reason for that.

-Dave

2 Likes
2

Z5 games can write arbitrary bytes to an external file and read them back in, which could be used to transfer any amount of game state between episodes. But of course, the systems where you’d really want this probably can’t handle Z5 in the first place.

The Scott Adams game you’re thinking of, Savage Island, specifically has two passwords you can get at the end of the first game: if I remember right, it’s 123 if you’re not carrying a specific item and 747 if you are. That item is the only thing you can carry with you to the endgame of part one, and it’s absolutely necessary for part two, which means you can softlock the game before you even start playing. Infocom’s Enchanter can be softlocked on turn one, and Suspended can be softlocked on turn zero, but only Savage Island can be softlocked before you even put in the disk!

The Zork and Enchanter games had various more-or-less plausible reasons why your inventory got reset in between episodes. At the end of Zork II you fall down a huge flight of stairs and drop everything you’re carrying. At the end of Enchanter your spellbook gets destroyed so you start Sorcerer with a new one (not containing all the powerful spells from last time). And so on.

Ferret, a huge mainframe game built in several distinct pieces, has inventory gates between each piece—only a small handful of useful objects (like the colored pins) can be carried between them. That could reduce the state to something small enough to fit in a password.

3 Likes
3

Do these systems have a debug “super-get” verb? Not sure what it might be called, but it’s usual for a debug verb to exist (in debug builds) that allows one to get an item from anywhere in the game.

In which case, could part 1 emit a text script which would be run by part 2 and thus super-get all the appropriate trans-game items?

1 Like
4

Passwords related to specific key item(s) password has negative sides, as noted, but I can’t underestimate the very positive side: lacking the item can unlock item-retrieval (or replacement-finding) sidequest, or even different sequencing, introducing the Arab Phoenix of IF: REPLAYABILITY

Yes, replayability: let’s say that there’s five or six key items (for the sake of keeping combinatiorial explosion to a reasonable minimum, 25 and 36 respectively), we can have not one, but twenty-five or thirty-six different walktru, instead of one.

Interesting idea is a understatement, I suppose…

Best regards from Italy,
dott. Piergiorgio.

2 Likes
5

That facility is hard-baked into the development systems I’ve used on 8-bit machines, such as the PAWS & DAAD. They allow you to create a save file which carries over information from one part of a game to another. All you need to do is maintain the same details (such as object numbers) for any information that is likely to carry over.

It’s really easy to create a multi-part game where objects and flags can be swapped back and forth. You can have distinct, sequential parts of a game or you can split the game world up into multiple sections that you can travel between, loading your player’s state from the previous part of the world.

The feature was rarely used, in our little community back in the day. Multi-part games were a lot of work. And it’s was a such a faff for the player, especially those using cassette tapes.

Passwords were more commonplace. Most often, as a simple way to act as a barrier to entry until the first part was completed. On some occasions, you’d get different passwords which would create different starting states in the next part. I used that technique myself thirty odd years ago but regret doing it now. Allowing players to soft-lock a game early on in part one and then carry over that state so that part two was unwinnable from the start was just extremely mean.

These days, I just don’t bother even adding a password. I’ve no problem with people getting stuck on one part of the game and loading up the next.

[Re. the whole “some of your items were lost when crossing the river” point… One of the most popular early system, The Quill, had very limited flags (booleans/variables) so authors regular manufactured points of no return, such as river crossings or collapsing cave roofs, so they could free up the flags that they’d used to track earlier actions and world states for reuse in the next section of the adventure. Like you point out, you can use those same narrative tricks to explain a player’s “reset” state at the start of a new part of a game (and indeed, authors did do this too back then).]

5 Likes
6

This is exactly the thing that’s at the centre of both the series that I’m currently picking at, and the Giant Ambitious SF Epic that’s currently on hold. The series is meant to have a metaplot that unfolds as you play it; the Giant Ambitious SF Epic is meant to be a five-act tragedy implemented in ten modules, and you play five of them, depending on your choices.

At the moment, the plan is to simply output a long string of hex digits (or encoded radix-32 characters), and have the player input them in the next game if they want to continue the overplot and not just play the next game’s default scenario. Having a mechanism in the Å-machine and/or z-machine to allow restarting with a different game file, with a bit of memory surviving the restart, would be extra spiffy for doing something like this.

A nice side effect would be that you could also use it to implement usefully big games on vintage machines with tape drives, if you divided the games into acts.

3 Likes
7

I definitely wouldn’t be opposed to a feature like that, but I’m afraid my 6502 assembly skills are definitely not up to the task of implementing file I/O from scratch. The most straightforward implementation would probably be writing a list of numbers and/or dictionary words, which are then parsed by the new game as per (get input $)—since different .aastory files can have different object numbers, dictionary words, and even character sets, that’s the only really safe way to transfer the data. Re-parsing words, or sticking exclusively to numbers.

…but at that point, that’s just a password system with extra steps.

2 Likes
8

I definitely wouldn’t be opposed to a feature like that, but I’m afraid my 6502 assembly skills are definitely not up to the task

Yeah, I’m figuring that most of my 6502 wish list is going to have to be things that I contribute. (This, REU support, C128 and dual monitor support, tape mode, et cetera.) First, to get to the point where I have a game close to release that actually calls for any of it…

2 Likes
9

You might want to look at the amazingly clever system developed for Ghostbusters on 8bit systems.
There is a surprising amount of game state data that can be stored in a password.
See this video. It might inspire you:

2 Likes
10

You may be able to pick up a few things from the Ozmoo source, like REU support.

2 Likes
11

Wait, what? Is there a special output stream? Any games actually use this?

1 Like
12

The standard allows the save opcode to specify a memory range to save.

I don’t think any games use it.

2 Likes
13

Beyond Zork uses it:

4 Likes
14

Ah, now I see why I didn’t bother implementing that… the wording made me think this was unofficial, but it’s no less unofficial than unicode support so…

[1.0] The extension also has (optional) parameters, which save a region of the save area, whose address and length are in bytes, and provides a suggested filename: name is a pointer to an array of ASCII characters giving this name (as usual preceded by a byte giving the number of characters). See S7.6. (Whether Infocom intended these options as part of Version 5 is doubtful, but it’s too useful a feature to exclude from this Standard.)

There are plenty of interpreters that support v5 on old machines, so if they support this extension it could be used as a password-free way to pass information to the next part.

Objects are 14 bytes instead of 9 on v5, and dictionary words are longer, but that’s partially offset by not requiring two bytes per routine parameter in every routine, and shorter call instructions are also available.

Of course, saving that state… to a cassette tape… is probably more of a pain in the ass than printing out a password that also encodes state. Base64 (uppercase, lowercase, digits, and two extra symbols) can encode 6 bits per letter. V5 also gives you access to the text input without requiring it be tokenized.

V5 also gives you access to the shift operators that can decode this much more efficiently!

15

I fear few do. I can say for sure that Ozmoo doesn’t support this.

On modern machines, you can write something to disk at any time without bothering the user. On 8-bit systems, you need to ask them to put in the right disk, or press record on tape etc. And there are things that can go wrong.

4 Likes