This article is part 1 in a series; continue to part 2.
Ten years ago I watched a presentation (possibly this one?) by Ron Gilbert about his first point-and-click adventure game Maniac Mansion, where he mentioned that because of the many different paths that the player can take throughout the game, using different combinations of characters with different abilities, the authors were not able to avoid dead ends—for instance, an item needed to complete the game could be “wasted” earlier without the player knowing it. Although the game, like the text adventures of Infocom or the (still parser-based) graphic adventures of Sierra, is implemented in a high-level domain-specific language (the charmingly named SCUMM), the rules of the game are still buried deep inside imperative code, and figuring out how to reach the end of the game for any combination of characters or finding dead ends required poring over complex dependency charts and a lot of playtesting. But what if the rules were expressed declaratively; surely, this would not only make generating these charts automatic, but also static analysis could be employed to find out what paths exist to the goal, and especially eliminate dead ends.
I believe that PuzzleScript had also come out around that time. Putting two and two together, I made a small prototype for a rule-based language called Golem for adventure games that I presented at a Picotachi night at Pico Pico Café. Spoiler alert: I did not crack the static analysis part (...yet!) but had a lot of fun. I also put this project aside until I was reminded of it recently and decided to give it another go.
Golem games are rendered in the browser and played with a very simple interface. Players move their avatar through various locations and pick up and use items together until the end goal is reached and the game is won. Items are represented by images that can be clicked or tapped to show a description, and can be dragged on top of one another to make them interact: dragging a key on top of a locked door will unlock the door, then dragging the player avatar onto that door will move to a new location on the other side of that door. Below is a sample four-location game implemented with a couple dozen rules; give it a try before going any further!
Here is the complete set of rules that implement the game above:
Golem manipulates very few concepts: there are locations, items, and tags. A location may contain items; items may
be qualified by tags, which represent different states of the same item, or give them specific properties. The player
avatar is just an item that has the special tag +You
; in this game, this is the item called Alice
.
Locations are actually items marked with the tag +Loc
.
A Golem game is a set of rules. Rules are versatile and can describe locations, items, and interactions between items. The general form of a rule is:
Subject, Object; Context: Effects, Description.
There must always be an object and either effects or description for a rule to be valid, but the other parts are optional. The first rule in the game above describes a location:
Cave+Loc [Alice+You, stone, hole]: "A mysterious cave."
The object here is Cave+Loc [Alice+You, stone, hole]
, and the description is "A mysterious
cave."
The Cave
item is marked with the +Loc
tag so it is a location; in brackets are the three
items that it contains: Alice+You
(i.e., the player character, as it has the +You
tag), stone
and hole
. The following rules describe these items. The interpretation of description rules depends
on the kind of object: if it is a location, then the description will be shown the player enters the location and
its name will be displayed above images for the items it contains (in this simple prototype, filenames of images are
derived from the item name and tags); otherwise, clicking or tapping on the item will show its description. Below is
an action rule:
stone, +You: +You [stone].
Action rules describe the result of using the subject item with the object item; in the graphical interface above,
dragging the subject on top of the object. The two items are replaced by whatever is on the right-hand side of the
rule. In this rule the subject is the stone
and the object the player character; these two items are replaced
with the same player character with the stone
as part of the item’s contents (i.e., in the player inventory).
Another way to interpret this rule is that the stone can be picked up by the player. Effects can create or destroy
items, or add or remove tags from items; they can also involve other items that must be present in the current location
or the inventory as in this more complex example:
stone+Glowing, cavity; door: cavity+Glowing, door+Open, "The door opens slowly with a thunderous
sound!"
This rule has everything! Subject (a glowing stone
), object (a cavity
), context (this rules only
applies in the context of a door
being present in the current location), effects, and description. If the stone
has the +Glowing
tag and is dragged onto the cavity
, then it is removed from the
location (since it does not appear on the right-hand side of the rule); the cavity
gets a +Glowing
tag, while the door gets an +Open
tag. We also get some imaginary audio to go with the application of that
rule.
We have seen how items can be examined, picked up, or used together. One last important feature that rules need to cover is movement between locations. Here is an example:
+You, hole: hole, Tunnel [+You], "There’s no way you’re going back up!"
When the player goes through the hole
, the hole
stays where it was (in the Cave
), but
the player becomes an item of the Tunnel
location. The current location of the game is then updated (it is,
by definition, the location that contains the player character) and is displayed following the rule that describes
it:
Tunnel+Loc [cavity, door, opening]: "A dark tunnel."
The player is now in “a dark tunnel” and can see a cavity
, a door
and an opening
, which
all have a description rule. The opening
leads to the Chamber
, and the door
leads to the Treasure Room
; however, that room is not accessible to the player at this time, as the rule
+You, door+Open: door+Open, Treasure\ room [+You].
requires that door
has the +Open
tag for it to apply, which it does not have initially (the \
escapes the space character in the name of the treasure room as it is normally a separator). We have seen
a rule above that opens the door when the glowing stone is placed in the cavity; playing the game is just a succession
of rule applications driven by the player, until
treasure, +You: +You+Win [treasure], "The idol is now yours. You win!"
can be applied; by taking the treasure
, the player item also gets the +Win
tag, indicating that
the game has reached a succesfull end state (the influence of Baba is You, another
rule-based game, is not anachronistic since some revisions were made to the initial prototype when reviving it).
This game is terrible. If you have played it or read the rules, you probably figured out that it is very easy to
end up in an unwinnable state: omitting to take the stone at the beginning, or putting it in the cavity before
dipping it into the fountain will make it impossible to reach the treasure room. You can also die: this happens when
you drink from the fountain, which removes +You
from the game and is therefore another dead end, in addition
to being unfair (the game tells you that the water looks refreshing, and it makes the stone glow). This is of course
by design in order to be able to test whether such conclusions can be reached automatically by analysing the rules,
a topic that will be covered in a later installment (and which is very much a work in progress!)
There is a lot more work in progress around this language. Right now, this is just a prototype, and writing a
more fully fleshed game is necessary to really understand what this rule system can and cannot do, and if it is really
suitable for a genuinely interesting game. Some features of classic adventure games are missing, such as multiple
player characters or a dialogue system; can the language be extended to accomodate those gracefully? The interface
shown above is very crude and does the bare minimum; this is really a rule engine that should be integrated into a
larger system, with sound, animation, a better user interface... or maybe the opposite: a text-only interface where
the player inputs commands to be parsed and matched to the rules of the game (“take the stone”, “go down the hole”).
In order to make this more interesting, a natural extension to the rule syntax is to add a Verb
component, so
that you can open a door, drink from the fountain, &c. Verbs could even become part of a graphical user
interface, which brings us back right where we started: to Maniac Mansion. ⚁⚁