"Limited State" Adventure game design.

[Calin Leafshade]

I've been experimenting with something a little different for my new project Latency

In AGS we usually model our game progress by simply saving the whole state of the game. We save what music is playing, where the characters are, all the internal variables, which objects are visible. It's a snapshot in time that we resume later.

In Latency I'm attempting what I call a "Limited State". Essentially we only save the progress the player has made and we rebuild the game state from that information. This has a couple of advantages as far as I can tell.

1 - Complete decoupling from AGS's save state information. This means that, as long as you have logic to handle changes, save states can persist across versions of your game because you're saving *semantic* information about the game state rather than raw data.

2 - It's easy to recreate a game state from scratch for testing purposes. Most adventure games really have very few important events. It's not usually necessary to store everything the player has done, only what advances the game state in some way which often only amounts to a few actions. The terseness of some walkthroughs is a testament to this.

3 - Data in your game can persist across saves. Ever wanted to do some kind of transitions when loading an AGS game? This is possible but its a bit unwieldy since you can't persist timers and stuff between the old state and the new state. With this method you can.

4 - I'm not sure about this one but I *think* this method should be far less buggy because the game state is very explicit to you as a designer. You are forced to distil your design down to atomic events. You have a 100% clear idea on the game state because you set down those rules yourself.

What do you guys think? Food for thought at least, right?

EDIT: maybe Semantic State is a better name...

[Mandle]

As I understand it AGS does a complete memory dump on any saved game, much like it does when it prepares a TRS file.

This makes the system very robust and extremely fragile at the same time.

Robust in that there is absolutely nothing missing from the save game file. It's perfect...

Fragile in that a slight change to the game could break the template of data that the save game was supposed to plug back into...

So I can see your logic behind creating a simpler: "If Guybrush has gotten the shovel from the signpost then save as gamestate #345"

But: Won't this get incredibly complex over the course of a long, non-linear game? And won't this put the onus back onto the creator to define the crucial points of advancement within the game, as if their job was not already hard enough?

Hope I understood this thread properly and am not just raving...

[Calin Leafshade]

It doesn't seem to be more complex but I havent made a big game this way yet so I guess we'll see. I think, with good plannig, it should be *less* complicated.

[Snarky]

The idea sounds appealing, particularly the point about decoupling the innards of the engine from the save game format, but it does rather seem like it would be difficult in a complex game to decide what needs to be stored.

I mean, something like Heroine's Quest may be an extreme example, but you have all kinds of data: character stats, environment stats (weather, time of day, likelihood of creature encounters...) and all kinds of special sub-systems with their own state, dozens of NPCs who're walking around the world and have particular attitudes towards you, hundreds if not thousands of dialog topics that have a "freshness" flag, multiple inventories (items, spells, several chests)... If you're on the same screen as a monster when you save, you need to store pretty much all of that room state anyway. And that's not even getting into the state of the progress of the quests/puzzles themselves, of which there must be several hundred distinct events.

In almost any case I'd assume you'd want to save at least the current room state (where characters are standing/facing, state of animations, their walk-to points if currently moving, current cursor mode, etc.), in order to recreate exactly on load. But now there's going to be a mix of data that is stored "semantically" and data that is stored "bit-wise", simply by serializing the in-memory data structures. Won't that be confusing?

Even in a more traditional adventure game, it seems like any time you code some fancy feature (whether it's something basic like the Tween module or footsteps-in-snow, or a full-fledged mini-game), the only way to be safe is to save and restore all associated state information. Otherwise you risk all kinds of weird bugs when you save/restore your game. Possibly it's easier if you're making a completely conventional adventure game that is completely static except in responding to user input, but for any data that isn't "semantic" as such (something that isn't directly meaningful to the player, but is necessary to control some aspect of the game logic internally) it sounds far more complicated, or just more limited.

I mean, it's an interesting problem, how to save and restore game state, and particularly how to do it so you don't break compatibility if the game logic changes (which of course is not always going to be possible, depending on the changes). I won't pretend I can think of a better way.

[ThreeOhFour]

One thing to think about is if a condition you're checking is an object's frame or graphic then that's another thing to store. If it's something's position, same thing. This means either adding this to your "stuff saved" list every time you add one (annoying) or setting variables instead of checking against specific object states (double handling).

[Khris]

It is indeed an appealing idea, and I was wondering about this myself from time to time, though not necessarily with regard to AGS.

It depends very much on the game; I would think it is completely possible to do this if the game is built around this concept. Take a very linear game for example; those often don't have save states at all, just checkpoints.

Years and years ago I was playing a choose your own adventure book about Sherlock Holmes, and the "save state" would have been just a list of booleans (clues from A-Z you'd check off during the game) and the current page, if you will.

Traditional adventure games have lots of flags that could be omitted without seriously detracting from the experience. Looking at something twice and getting a different message after the first time is pretty standard, but this flag doesn't really have to be part of a save game, I guess.

[Snarky]

Traditional adventure games have lots of flags that could be omitted without seriously detracting from the experience. Looking at something twice and getting a different message after the first time is pretty standard, but this flag doesn't really have to be part of a save game, I guess.

Personally I think omitting this kind of thing does significantly detract from the experience. If I talk to a character, and then the next time I talk to the character it's as if we never spoke before, that tends to really break my suspension of disbelief, and make me feel as if I'm playing some cheap-o Flash game.

I'm big on persistent state in general. I think it helps make the world feel real and consistent. So if there's a TV in a room that you can turn on or off, it shouldn't turn itself off just because you leave the room for a second. And if you have, let's say, a chess puzzle minigame, then each time you look at the board the pieces should (ideally) remain where you last left them.

(This reminds me of that 5-minute warning game that's been demoed at Mittens for the last few years, which is all about interacting with a consistent environment in real-time... I want to say it's by some combination of AGA, Creed and maybe Matt?)

[Calin Leafshade]

It's certainly not for every type of game. Heroines Quest is a good counter example for the reasons you mentioned.

Also, I do save some state information because I consider it to be semantic and very easy to store. For instance I save whether or not dialog options have been chosen but I *dont't* save whether or not they are active.
I'm using the custom dialog system demoed in my Lua thread and each dialog option has essentially a function that returns whether or not the option should be visible. Like this:



This is all saved in a lua file and then the condition is compiled dynamically and tested every time I want to process any particular node of the dialog tree. It seems to work very nicely and it's very convenient.

With regards to saving tweens and animations and stuff, I get around this mostly by limiting when the player can save the game. I don't think the player should be able to save the game "mid-event" and so only allow them to save in open play, basically when the game isn't blocked. This eliminates most of the very immediate stuff.

[Stacy Davidson]

There are two ways I have gone about keeping track of progress in my games. One is setting a bunch of flags like "sawDonkey" or "TalkedToFred", and the other is a floating point progress meter. With this, there may be, say, twelve "puzzles" in the game and each one may have a bunch of mini-steps. These could be as simple as talking to someone or looking at a tree. So if I'm 5 steps into puzzle 6 and I advance each ministep by 5 points, I'd be at state 6.25. That would make it easier to implement this kind of save system, between your progress state and your inventory, you'd probably have most of what you'd need. It would be tougher to do a non-linear game this way, but you could actually create contingency branches for everything.

[Snarky]

It's certainly not for every type of game. Heroines Quest is a good counter example for the reasons you mentioned.

Yes, and on the other hand that's the kind of game where the benefits of a system like this would really come in handy!

What you're talking about is in many ways like some of the AGS debug features and recommended ways to use them, wouldn't you say?

With regards to saving tweens and animations and stuff, I get around this mostly by limiting when the player can save the game. I don't think the player should be able to save the game "mid-event" and so only allow them to save in open play, basically when the game isn't blocked. This eliminates most of the very immediate stuff.

Mmmyes, but what if you have background characters that are always doing something (birds fluttering about, or e.g. a librarian who's stacking books on different shelves)? I've on occasion used Tweens to have clouds drifting across the sky. Oh, and the other day I watched the "Tim Schafer plays Grim Fandango" video, and he talked about a system he coded for essentially complex idle animations (with the example a secretary who would go between filing her nails, typing, and other activities). OK, so if the clouds or background birds or secretary didn't get returned to exactly the same position upon restore it probably wouldn't be that big of a deal, but you could easily imagine a timing puzzle based on the librarian's current action, and it would be annoying if it jumped back to a default or random state every time you reloaded (and unreasonable not to mention meta-spoilery if you couldn't save in this situation).

Of course, if it's that important you could always designate the librarian's current state as something to store as part of the savegame, right? (But again, very slight metaspoilers by restoring that accurately and not other background animations.)

[Calin Leafshade]

Mmmyes, but what if you have background characters that are always doing something (birds fluttering about, or e.g. a librarian who's stacking books on different shelves)?

I think this is likely to be the exception in 99% of cases and so you could make some kind of exceptional logic to deal with them. But I also think that this kind of example highlights exactly *why* my system is a good idea. I shouldnt have to save the location of the birds in the sky. From a semantic, gameplay perspective it's enough to know that there are birds in the sky. More than that is not fully related to the players progress and their experience.

[Snarky]

I think this is likely to be the exception in 99% of cases and so you could make some kind of exceptional logic to deal with them. But I also think that this kind of example highlights exactly *why* my system is a good idea. I shouldnt have to save the location of the birds in the sky.

Well, "you" the player or the game programmer doesn't have to save it: the engine does that for you.

From a semantic, gameplay perspective it's enough to know that there are birds in the sky. More than that is not fully related to the players progress and their experience.

From a gameplay perspective you could replace all the graphics with single-colored blocks and it wouldn't make a difference really. But looking at a player's experience, of the game representing a "real world" of some kind, surely one part of that is "when I saved the birds were over there, but when I reloaded they were over there."

It's perhaps a philosophical difference: when as a player I restore a saved game, I am not simply looking to access a game state where the puzzles are in an equivalent state to when I saved. I am going back to take up again the thread of events in the main character's life. So even if I'm replaying a part I already know, I usually won't just jump straight to the actions necessary to solve the puzzle: I'll look at things before I pick them up, I'll click on background hotspots I figure the character would want to check out, I'll make sure to pick the dialogue options that establish my character's motivation before I go ahead and perform the action... Because the playthrough, even though separated by saves and backtracking, should make sense within the world of the game, or otherwise I don't feel satisfied with the experience as a coherent whole. (That's also why I can never be happy with getting around a game bug by loading a savegame provided by the developer. It's not my playthrough, even though it might be functionally 100% equivalent!)

So any discontinuity between the game as saved and the game as restored offends against my philosophy as a player.

I know this all sounds a bit neurotic and, well... peculiar, and I don't mean to suggest that minor continuity errors would completely ruin my enjoyment, but it definitely would bother me, a little. Like I said, it makes me think of Flash games, which often have very rudimentary save systems (e.g. they won't remember where your character was on the screen).