User:Snarglefoop/Games/Click link games

This section is Logical; it is meant to be so. Prepare to get bored!

Sensible Section

WARNING: Incoherent ramblings ahead! Put on your hard hat!

Dungeons and Rooms and Actions

I'm going to refer to the whole set of possible game states as a dungeon.

I'm going to refer to a possible player location as a room.

In general, in a web based click-link game, a "room" corresponds to a "web page" and moving from one room to another is done by clicking links.

In many situations, the word "room" sounds pretty stupid ("As you enter the room, you see an ocean, a thunderhead, a beach, and 300 seagulls. There is a dead whale in the room with you.") but I'm going to persist in using it anyway. Ditto "dungeon".

Games versus Interactive Stories

In interactive fiction, the author is telling a story, in little snippets, possibly with some plot variations depending on choices the user makes.

In a game, on the other hand, the user is actually challenged to solve one or more problems or puzzles of some sort in order to get to the end.

A game can be won, typically by finding a path through the game tree to the end, where most paths lead to blind alleys. In interactive fiction, it's not really meaningful to "win" since all paths lead to the end (or terminate in immediate blind alleys, from which the reader backs out of immediately, with little interruption to the story flow).

As we'll see, it's difficult to make a web based click-link thing into an actual game rather than a piece of interactive fiction.

Adventure games

We're not talking about point-and-shoot games here (ala Wolfenstein and its descendants) but rather Colossal Cave type games.

There are a couple varieties, but they function similarly.

In a text based adventure game, the user types a string of words which is interpreted by the program, which then types a response. There are objects in the game, and the objects, the rooms, and the players all have state associated with them.

In a point and click adventure game, there are (typically non-moving) graphics for the scenes, and you operate on things which are in the image, using the mouse. This is more limiting than the text-based games, with a smaller number of actions possible in each screen. Depending on how it's done, it can also be more annoying, in that it's easy to produce "busy" pictures in which it's very unclear what's going to be click able.

In a web-based click-link game (such as Rain of Dead Cats) each "room" consists of a description (just as in a text based adventure game) and a handful of links. Moving through the game consists of clicking the links.

Game Motion: Unidirectional versus Random

In a conventional adventure game, motion is random. If you start in front of the bank, you can enter the bank, come back out, walk north, walk south, walk south again, walk north again, and go back into the bank. Play proceeds randomly, with a path that goes where ever you want it to go.

In simple click-link games, you usually can't do that. You start in front of the bank, then you enter the bank, then you do something, and go out the back door ... you don't come back to your starting point. Play proceeds unidirectionally, along a path prescribed by the game designer. The path may split and then join again later but the progression is none the less unidirectional.

IMO this is the biggest impediment to making it into something that feels like a "game" rather than a story.

The Command Parser

In a text based game the command parser just parses the input text.

Adventure (ala Colossal Cave) had about the simplest practical parser. All commands were two words, and the order of the words didn't matter ("get axe" is the same as "axe get"). Even in that case, however, there may have been a dozen objects which could be referred to, and there were about as many verbs you could apply. That made for on the order of a hundred distinct commands.

Zork (and later games based on the same engine) added more sophisticated parsing, which, in particular, allowed for "verb object indirect-object" constructions. That increases the number of sentences by about an order of magnitude, giving us, perhaps, a thousand sensible commands.

Furthermore, it's worth noting that it's very rare for a command to get you killed. Consequently, you can execute nearly any command, and then continue the game from there.

This gives the game tree a branching factor of something on the order of 100, and makes exhaustive exploration of the game tree impossible.

In contrast to text-based adventure games, in a web-based click-link adventure game, there are fewer than a dozen possible actions in each room, and nearly all of them typically lead rapidly to dead ends. What's more, they're all right there in front of the user, in a list of links. Consequently, in most cases, exhaustive exploration of the game tree is straightforward. That makes putting challenging puzzles into the game more difficult.

Another major difference is that the "back" button in the browser is equivalent to the "undo" command in a text-based adventure game -- but most adventure games have no undo command. Consequently, exploring the game tree would be faster and easier in a click-link game than a text adventure game, even if the number of options and game complexity were the same.

In a point-and-click adventure game (such as Myst), the more limited set of options in each scene constrains the game tree branching factor quite a bit. There are typically only a few actions that can be taken in a particular scene. To make up for this, there tends to be a lot of state kept in the game (more on this later).

In "Return to Zork" the designers compromised, with a point-and-click interface using a grid of "nouns" on the screen, and a selection of verbs you could pick from after you chose a noun. That put them back somewhere near the 100 possible actions per room that Adventure had.

Game State

Game state generally includes:

• Player state
  • Player location
  • Inventory
  • Health, hunger
• Room state (is the door open or closed?)
• Object state
  • Object location (for text based adventure games)
  • Object internal state (open/closed, etc)

In a text based adventure you can generally pick up an object, move it to another room, and drop it, and it'll stay there until you move it again. In the point-and-click adventures I've played this was far more limited, with objects being droppable only in certain places.

Let's figure out how many distinct game states there are in an adventure game.

In a text based adventure the player location and state and the object states are independent, save that anything in the player's inventory must share their location.

In a dungeon with 100 rooms, the user can have 100 locations, corresponding to 100 state values.

If there are 10 "gettable" objects, and the user can pick them up individually, then there are 2^10 ~ 1000 possible inventory lists. Multiplying by the 100 possible player locations, that makes 10,000 possible state values so far.

Each dropped object can be in any of the 100 rooms, and so, for each object the player does not have in his/her inventory, we need to multiply the number of game states by another factor of 100. We haven't looked at internal object state here; that's going to result in some additional large factors going into the result. (As an example of an over the top object, in ZorkZero (or Beyond Zork or anyway Zork something or other) there's a game of Chinese checkers which you must play out. How many states are there in a Chinese checkers game? Dunno -- a lot, though. A nicer example, since it's saner and more relevant to the game, is the educational toy in Riven which teaches you the numbering system. It's got a major chunk of internal state, though not as much as the Chinese checkers game, I'm sure.)

Figuring out a precise number would be difficult, but we've gone far enough to see that there are well over a million possible game states, and a million might as well be infinity.

In a browser based click-link adventure, each distinct state value corresponds to a separate room (or separate web page). So, to build a conventional adventure game using click-link browser based technology, you would need over a million rooms. That's not practical. Consequently, there must be tight limits put on the game in order to fit it into the click-link paradigm. (A cookie-based game using javascript could get around a lot of this. But if you're going that route why not just write the whole thing in php? In any case it's not something we can do in a wiki page.)

More on State and Game Motion

The lack of state is what forces unidirectional game play on click-link games. The entire state is the player's location. Consequently, if you allow the player to return to an earlier location, the game state necessarily returns to its earlier value, which is obviously wrong.

To relax this constraint, it's necessary to make multiple copies of each room where the game could be in more than one state. If I can start on the boardwalk, then walk down to the beach, pick up a shell, and walk back to the boardwalk, I need to have two copies of the boardwalk: One for the state where the shell is lying on the beach, and a second copy for the state in which I am carrying the shell.

The two copies of the room may look identical to the user, with the same description and the same labels on the outbound links, but under the covers, the outbound links will all be different in the two states, because they'll link to rooms which also exist in multiple versions to represent the two separate inventory states "have-seashell" and "don't-have-seashell".

This gets very tedious very fast if you're building all the rooms by hand. That's why I wrote a Perl script to do the room-cloning and link-adjusting to maintain the states.

This approach makes it possible to have random motion and it allows a certain flexibility in terms of states, but it still doesn't make it possible to let the user pick up and drop arbitrary objects in arbitrary rooms, because that leads to a combinatorial state explosion. A lot of other actions remain infeasible too; one must constantly be aware of the impact any change or additional feature will have on the number of states.

Puzzles in the Game

The puzzles in the game generally take several forms:

• Object state based puzzles. "Light the candle", "Turn on the lamp", "Open the box"
• Using objects on the landscape. "Unlock the door with the key"
• Finding hidden things.

A great deal of the game tends to be oriented around opening doors which are tricky or hidden. An example of this is the hot air balloon in Zork, which you must inflate and then control in order to get to several rooms.

Another example of a door which is hard to open is the door to the endgame, also in Zork, where there's a sequence of actions you need to perform: light the candles, read the book, and ring the bell (I think that's the sequence), and doing those things elsewhere or earlier in the game or in the wrong sequence doesn't get you anywhere.

The puzzles which appear in such games can be roughly divided into a few categories.

Hidden Command Puzzles

With a text-based adventure game, "hidden command" puzzles are extremely common. Perhaps the most famous example is the ending to Adventure, in which the user must somehow guess that the magic word which is needed is "blast".

The most horrible example of a "hidden command" which comes to mind is from an Infocom instruction booklet. As a hint on playing the games, they say you should "try everything", and as an example to illustrate that, they give "Throw the monkey at the vegetable vendor." As far as I know that sentence doesn't actually appear in any game (except The Stench) but in a text-based adventure game, I can't imagine how you'd ever guess you needed to say that. (It's easy in The Stench, since it's one of the links, of course.)

For better or worse, hidden command puzzles are impossible in a click-link game.

Hidden Room Puzzles

Like the guess-the-command puzzles, these are based on hidden commands. To get into the world of Zork you need to guess that you should move the rug -- the door is not visible otherwise.

Since they depend on hidden commands, these are mostly impossible in a click-link game.

Mazes

Unlike the other puzzles discussed here, mazes are extremely easy to construct using click-link technology. What's more, by throwing in some random links (see the template TheStenchChoose for one easy approach) one can make the mazes rather difficult to solve.

Actually the hazard with mazes in a click-link game is that it's all too easy to make them too hard. In a maze it's common to make every room appear identical to every other room, so the user can't easily map it. In text based adventure game, a common technique for solving a maze is to drop objects in the various rooms in order to make them different (if you enter a room and a red ball is on the floor, you say "Aha! This is the room where I dropped the red ball!" and so mark that connection on the map). In a click-link adventure, you can't drop arbitrary objects in arbitrary rooms, due to the combinatorial state explosion which would result. So, mapping a complex maze would be quite difficult, and if there are random links in it, it could be well nigh impossible.

Not everyone finds solving mazes particularly interesting, though, so they're something which should be used in limited quantities.

Object Application Puzzles

Put the key in the lock and turn it...

This is really not practical in a click-link game since all the possible actions are right there, and it's easy to click them, one after the other, using the 'back' button to revert moves that don't do the right thing.

Pure State Based Puzzles

In their simplest form, these take the form of a collection of switches which must be set correctly. In a conventional adventure game the number of switches can easily be made large enough that the player must deduce or guess the correct combination; exhaustive search won't be possible.

Since the number of states corresponds directly to the number of rooms, state based puzzles in a click-link game must use a severely constrained set of switches. That means a patient user will always be able to use exhaustive search to find the solution, but that's OK.

The actions needed to achieve the desired final state can be put in separate rooms, which can add to the difficulty of the puzzle without apparently expanding the number of needed states. However, if separate state values need to be carried through a series of rooms, it's worth keeping in mind that every room through which they must go must have one instance for each of the possible state values. Consequently, spatially separating the rooms in a state-based puzzle will increase the total number of rooms needed in the dungeon.

Sequence Puzzles

This is a specific form of a state-based puzzle. You must perform several actions in a particular order to get the desired result.

Due to the rapid state explosion in keeping track of this sort of thing, in a click-link game we'd typically be limiting this to two or three actions. It's also possible to reduce the state space by forcing the order using choke points which the user can't pass without having done the prerequisite action. However, that removes a lot of the challenge of a sequence puzzle.