Adventure game design

[Robert Maxwell]

Jadzia's got game design threads, so why not me?

As a gift for someone (shhh), I'm designing a web-based adventure game. It will use a cookie to store the game state, so it doesn't have to be kept on the server--also means no database, which is a plus.

It should be reminiscent of old games like Troll Cave for the Apple II, where you have a series of scenes and you move from scene to scene, picking up items and using them. You never see your character. Most games of this sort used a text parser where you typed in things like "go north" and whatnot. Sort of a half-step between pure text adventures and the graphical point-and-click adventures, you know?

So, I'm thinking I'll need the following types of game assets:

1. Scenes. These are locations you can go in the game.
2. Items. These are things you can add in your inventory and use.
3. Events. These are rule-driven occurrences in the game.

Rather than go down the text-parsing route, each scene would come with a list of possible destinations. You would also have your inventory and be able to click an item to use it. (No "use x with y" type situations, at least for now.) Each scene would also say what items can be found there, and which items can be used there.

Items should be pretty obvious. A graphic, a name, a long description, whether it is consumed when used (like food), and what events it triggers (if any.)

Events are where things get interesting and what I'm still trying to sort out. I'm thinking there would be 3 kinds of events: random events, one-time events, and permanent events. A random event is something that has a certain probability of occurring on each scene. A one-time event is what it sounds like: it can only happen once. A permanent event is one that changes a scene for the rest of the game, so every time you go back to that scene it will look how it did when you first triggered the event.

Events can have dependencies, so a certain event won't occur unless you've already triggered events a, b, and c. An event could also change your location and perhaps be designated an "ending" event, from which you can proceed no further.

Naturally, the features I'm thinking of are for the specific game I have in mind. Without going into a ton of detail, there are 7 ruined cities and 7 items, and what you have to do in the game is find the 7 items and bring each one to the right city. Upon using the item in the proper city, the city is rebuilt (a permanent event.) After rebuilding all 7 cities, an "endgame" event is triggered. Since you could rebuild the cities in any order, the dependency system seemed essential.

There will be other items that do other things, but there you go. That's the basic idea here.

What do you guys think? Is there anything obvious I may be missing? Any suggestions? I plan to give away the engine when I'm done, which could be used to make fairly simple web-based adventure games.

(Yes, I know there are things like AGS that could make much more complex games, which is why I'm not using that. I want to keep it pretty simple.)

 

[Jadzia]

Will there be a fixed number of items in the game, or is there an ability to generate items in play? That will determine if you use a single Item list, or both an ItemType (template) list and an Item (instance) list.

If the latter, your triggers would need to check ItemTypeId, rather than ItemId. This in turn affects how triggers will need to be programmed.

 

[Robert Maxwell]

Good question. For this game, I have a fixed number of items. However, I'm going to use XML to store my scene, item, and event definitions. So, there could be an arbitrary number of any, but for an item to appear more than once would be a new wrinkle. Could handle that by having a "unique" flag on items, as well as an inventory counter to track how many of each item you have.

I did not elaborate on how game state is done, but essentially I'm using an object which represents the game instance. It has your name, current location, inventory, completed events, etc. I serialize it out into a string and store that in a cookie, which is read back and replaced on every page load. Making the game itself stateless was an early design decision. Otherwise, I'd have gone AJAX or something.

 

[Jadzia]

I would probably approach it like this:

Have an array of states:

State[n]->Value
// 0, meaning unactivated
// T, meaning activated, and expiring in time T
// 255, meaning activated and permanent.

An array of items
Item[n]->ItemType
Item[n]->Location
Item[n]->Status
// 0 = at location
// 1 = in inventory
// 2 = is unavailable
Item[n]->ChargesRemaining
// 0 = means used up. 255 means infinite.

An array of item types
ItemType[n]->Name
ItemType[n]->Description
ItemType[n]->Graphic


Have an array of triggers:
Trigger[n]->EventType
// 0 = null event. can be called by other triggers
// 1 = arrive at location event
// 2 = use item event
// 3 = always run
// etc

Trigger[n]->EventData
//"X,Y,Z" or "ItemId" will be a string holding data for this event type. Parse it depending on the event type property.

Trigger[n]->ConditionString
//Condition string is given in postfix with operator symbols !not &and +or
//"S0013255" means return true if (state[0013]->value==255)
//"I0012002" means return true if (Item[0012]->Status==002)
//"!T0015007" means return true if NOT (Item[0015]->ItemType==007)


// If the logic passes true, we proceed with actions, which follow in this struct.

Trigger[n]->ActionText
// Stuff to write on screen when the event is triggered and the condition string returns true.

Trigger[n]->ActionString
// Several actions strings can be concatenated and maybe delimited by a special character #. The first byte in each substring will be the action type.
// L = move player to location
// I = change item status
// C = use one item charge.
// N = set item location
//The remainder of the substring will be data pertinent to this action type. eg
//"L030405#I00172#C0019" moves player to location (03,04,05), sets item 0017 status to 2(unavailable), and uses one charge on item 0019

Trigger[n]->ReTrigger?
// If True, rerun the trigger script when it's finished. You'll have to include a bail-out in case it gets stuck in a logic loop.

 

[Robert Maxwell]

I'll have to go over that with a fine-toothed comb although I think it overcomplicates what I'm doing.

I'm trying to think in terms of the game assets available. There are only locations, items, and events. The locations relevant to items would be a) where it can be found and b) where it can be used. Relevant to events would be the specific items and locations that can trigger it, as well as any required prior events.

I'm not thrilled with giving items any specific abilities other than the power to trigger events. Basically, if we start putting statistics into this it becomes more like an RPG than an adventure game. Nothing against RPGs, but this isn't one.

With the items used to rebuild the cities, they trigger permanent events but do not leave your inventory because you actually have to pick an item at the endgame to use. Otherwise, I'd make them "consumable" and have only a single use. By the mechanics I've conceived, since each item only triggers a permanent event in a specific location, it is effectively a one-time use, you just don't lose it after you lose it.

Know what I mean?

This will probably make more sense once I've got more coded. Right now, just the skeleton is there--the server process to handle the cookies and direct the code flow to display a scene, give you an item, use an item, trigger an event, etc. None of the asset files are even defined yet!

 

[Jadzia]

Okay, it sounds like this:

(1) One event can be triggered by more than one item.
(2) One item can trigger more than one event.
(3) Items are not used in synergy. You don't have to have item A in order to use item B.
(4) Moving to a location doesn't trigger an event by itself.

If (1) and (2) are true, then events are not functions of items, nor are items requirements of events.

Which means you'd be best taking that logic outside of both the items and events classes, and putting it into it's own little trigger class,

At a bare minimum, a trigger must then have test conditions and an action.

Trigger[n]->ItemUsed // ItemId
Trigger[n]->UsedAtLocation // Coordinates
Trigger[n]->RequiredStates // StateId listed in a string

Trigger[n]->StateToChange // StateId
Trigger[n]->StateValue

After each user driven event, we'd run through all triggers...

"If we use item ItemUsed at location UsedAtLocation, and if RequiredStates evaluates true, then let state StateToChange have value StateValue."

If either (3) or (4) is false, this bare minimum won't be enough, as you'll need more than one type of trigger, or something like I outlined in post 4.

 

[Robert Maxwell]

Let me clarify your assumptions.

1. One event can be triggered by more than one item--this is true.
2. One item can trigger more than one event--this is also true, but it cannot trigger multiple events at once.
3. Items are not used in synergy. Also correct.
4. Moving to a location doesn't trigger an event by itself. This is not true. Some events may be triggered simply by moving to a location, if it simply relies only on the occurrence of another event or is a "random" event with no prerequisites.

The way I'm looking at it, an event could be triggered a few ways:

1. Use an item, this directly triggers an event. Whether the item can be used will be governed by the item's location rules. If it can't be used here, the event won't be triggered. Likewise, if the event has prerequisites that haven't been met, using the item will produce no effect (trigger no event.)
2. Move to a location. When you reach a location, any events associated with that location will be checked. If you have met the prerequisites, the event will trigger immediately.
3. Random events, which can be triggered at any time when moving to an arbitrary location. As an example, I have two NPCs who will pop up and offer advice/taunts, and they will appear randomly through the game. Where they show up is not of particular importance. Each appearance is defined as a separate event and can have prereqs, so that way I can have a set order for what they say at each appearance, it's just that you never know where or when they will appear.
4. Permanent events. If a permanent event has been triggered (meaning recorded in the game state cookie as having occurred) then every time you go to the associated location, the results of that event will be visible.

All events can have images associated with them, which are superimposed over the current location image. They can also just be text. Permanent events really need the superimposed image, though, which would basically replace the original location image!

(This is pretty much how Troll Cave and similar games did things, though in a much less sophisticated way, obviously.)

Edit: DERP! The game I was thinking of was Troll's Tale. Silly me.

 

[Jadzia]

1-3 are triggers. 4 is a state check rather than a trigger.


Trigger[n]->ItemUsed
// 0 means no item required. (A move to location event)
// > 0 is the ItemId (A use item at location event)

Trigger[n]->UsedAtLocation
// 0 means this trigger not associated with any location.
// > 0 is the SceneId

Trigger[n]->Probability
// > 0 means do a (RND <= Probability) check.

Trigger[n]->RequiredStates // StateId listed in a string

Trigger[n]->StateToChange // StateId
Trigger[n]->StateValue
// 0 = inactive
// 1 = active once
// 2 = permanent
Trigger[n]->TextString

example 1:
Scene 5 has a locked door (state 12 has value 0). Use key (item 17) to permanently open door (state 12 given value 2).
Trigger[]->ItemUsed = 17
Trigger[]->UsedAtLocation = 5
Trigger[]->Probability = 1
Trigger[]->RequiredStates = "State12=0"
Trigger[]->StateToChange = 12
Trigger[]->StateValue = 2
Trigger[]->TextString = "The door unlocks."

example 2:
Player moves to scene 4 and sees Timmy. If wearing a scary mask (state 6 has value 2), you will scare Timmy causing him to drop his book. This is repeatable. (State 9 given value 1).
Trigger[]->ItemUsed = 0
Trigger[]->UsedAtLocation = 4
Trigger[]->Probability = 1
Trigger[]->RequiredStates = "State6=2"
Trigger[]->StateToChange = 9
Trigger[]->StateValue = 1
Trigger[]->TextString = "Upon seeing you in your scary mask, Timmy's eye's widen and he drops his book."

example 3:
Player moves to any location and Mischief Mary randomly appears with 10% probability. (State 23 given value 1)
Trigger[]->ItemUsed = 0
Trigger[]->UsedAtLocation = 0
Trigger[]->Probability = 0.1
Trigger[]->RequiredStates = ""
Trigger[]->StateToChange = 23
Trigger[]->StateValue = 1
Trigger[]->TextString = "Mischief Mary pops into view."

example 4:
This will require a separate database, of what to draw according to state values. But will use logic like this:
If (State[12]->Value==0) {
// Draw the locked door.
}
If (State[12]->Value==2) {
// Draw the unlocked door.
}

 

[Robert Maxwell]

Though I appreciate the effort, I was kind of looking for a more general discussion of adventure game mechanics. What you have above is, I think, much more complex than what I'm going for.

One thing to point out is that events in my system would have a set precedence based on what invoked them:

* Permanent events have highest precedence.
* Item-triggered events come second.
* Location-triggered events come third.
* Random events come last.

Since only one event can be triggered per game turn (remember, this is a web-based system), if multiple events would be triggered this turn then only the one with the highest precedence would occur. Any events skipped as a result of this would not be marked as having occurred in the game state, so they can still happen later.

One downside I see to this is that once a permanent event has occurred at a given location, no other events are possible there. However, I could have two states for a permanent event. When the permanent event is first triggered, no other events would be possible that turn. After that, though, the permanent event is really nothing but a superimposed image on that location, so I shouldn't prevent further events from just being superimposed on top, be they random or item-triggered. A practical implication of this is that the output web pages should have the original location image at the bottom of the z-index, then any permanent event image, then any other event image. This implies the potential for two images for each permanent event, as well: one upon its initiation (normal event image) and another for its permanent state.

I am just thinking "out loud" here.

 

[Owain Taggart]

Look into HTML TADS. You'll only have to think of the programming of the game, and not the engine, unless you do really want to program the game + engine.. It can do everything you're thinking of. Very versatile. The only thing it can't do is be played via a browser but any resources it uses can be embedded into the file. Other than that, the file structure is much the same as how you'd program HTML. It's essentially an Interactive Fiction game designer:

http://www.tads.org/tads3.htm

The other alternative you could take is go straight to using Z-Machine, the engine known for the Zork series of games and then use a web-based interpreter. I believe Google has one called Parchment.

http://code.google.com/p/parchment/

Here's an example of Parchment in action, running Zork!:

http://iplayif.com/?story=http://mirror.ifarchive.org/if-archive/games/glulx/ZorkI7.ulx

 

[Jadzia]

Though I appreciate the effort, I was kind of looking for a more general discussion of adventure game mechanics.

okay.

One of my favourite adventure games is Everyone's a Wally.

[yt]http://www.youtube.com/watch?v=fNoqq9Vfc0g[/yt]

The main mechanics are:
- item collection. Your inventory is small meaning you can only hold two things at once.
- Delivery. Items only perform a function in one specific location. Sometimes a delivery will create a new item, such as delivering the sand and water to the cement mixer produces a cement item.
- Characters. You can control 5 characters, but only one at a time. The other 4 will go into NPC mode, and wander the game world themselves. Crucially, items only perform their function when used by one specific character. Only Wilma can delivery books to the school.
- Maze. The game world is labyrinthine. You have to learn your way about, which is doable, and tends to be how players begin.
- Inaccessible areas. Some items make some part of the game world accessible. The gas mask allows you to enter the gas filled cave. It's impossible to survive this area without the gas mask.
- Secret areas. Some areas will be completely unknown until they are unlocked. The telephone boxes are actually portals to a secret virtual reality area, but you will only discover this if you have the screwdriver, to hack the phone lines.
- Obscurity. It's not always obvious what items are supposed to do, which adds a puzzle layer to the adventure game. Who would collect the football and immediately think that it should be used as a stepping stone to make a path across the pond?
- Logical order. Some deliveries need to happen before others. eg, the monkey nuts allow you to get past the monkeys to get monkey wrench. The monkey wrench is then used to fix the fountain. The empty bucket is used to collect water from the working fountain. The full bucket is taken to the cement mixer to make cement. The cement is taken to the broken wall to mend it... and so on.
-Simultaneous paths. There isn't just one logical path from start to finish. There are often three or more distinct sequences of actions that can be followed at any one time. There may be points of divergence, where a logical sequences branches into two independent ones. There may be points of convergence, where two independent logical sequences come together if a result depends on them both.
- Red Herrings. Some items are useless and don't play a logical role in the game. They are added to confuse.
- Randomness. Some random things change in the game to confuse you. As NPCs walk about they may collect and move objects from where you last saw them.
- Fatal moves. There is a way to fail the game. Not all situations are safe.

 

[Robert Maxwell]

Look into HTML TADS. You'll only have to think of the programming of the game, and not the engine, unless you do really want to program the game + engine.. It can do everything you're thinking of. Very versatile. The only thing it can't do is be played via a browser but any resources it uses can be embedded into the file. Other than that, the file structure is much the same as how you'd program HTML. It's essentially an Interactive Fiction game designer:

http://www.tads.org/tads3.htm

The other alternative you could take is go straight to using Z-Machine, the engine known for the Zork series of games and then use a web-based interpreter. I believe Google has one called Parchment.

http://code.google.com/p/parchment/

Here's an example of Parchment in action, running Zork!:

http://iplayif.com/?story=http://mirror.ifarchive.org/if-archive/games/glulx/ZorkI7.ulx

Yeah, I've used TADS before. A bit overkill for me. I remember one time I worked on a game in TADS and I added an "electricity" mechanic: some items had an "electrical" property and you could only use them if the room had "outlets", which were a room property. So, I remember it fondly as a very versatile system, just way too much for what I'm doing.

Though I appreciate the effort, I was kind of looking for a more general discussion of adventure game mechanics.

okay.

One of my favourite adventure games is Everyone's a Wally.

[yt]http://www.youtube.com/watch?v=fNoqq9Vfc0g[/yt]

The main mechanics are:
- item collection. Your inventory is small meaning you can only hold two things at once.
- Delivery. Items only perform a function in one specific location. Sometimes a delivery will create a new item, such as delivering the sand and water to the cement mixer produces a cement item.
- Characters. You can control 5 characters, but only one at a time. The other 4 will go into NPC mode, and wander the game world themselves. Crucially, items only perform their function when used by one specific character. Only Wilma can delivery books to the school.
- Maze. The game world is labyrinthine. You have to learn your way about, which is doable, and tends to be how players begin.
- Inaccessible areas. Some items make some part of the game world accessible. The gas mask allows you to enter the gas filled cave. It's impossible to survive this area without the gas mask.
- Secret areas. Some areas will be completely unknown until they are unlocked. The telephone boxes are actually portals to a secret virtual reality area, but you will only discover this if you have the screwdriver, to hack the phone lines.
- Obscurity. It's not always obvious what items are supposed to do, which adds a puzzle layer to the adventure game. Who would collect the football and immediately think that it should be used as a stepping stone to make a path across the pond?
- Logical order. Some deliveries need to happen before others. eg, the monkey nuts allow you to get past the monkeys to get monkey wrench. The monkey wrench is then used to fix the fountain. The empty bucket is used to collect water from the working fountain. The full bucket is taken to the cement mixer to make cement. The cement is taken to the broken wall to mend it... and so on.
-Simultaneous paths. There isn't just one logical path from start to finish. There are often three or more distinct sequences of actions that can be followed at any one time. There may be points of divergence, where a logical sequences branches into two independent ones. There may be points of convergence, where two independent logical sequences come together if a result depends on them both.
- Red Herrings. Some items are useless and don't play a logical role in the game. They are added to confuse.
- Randomness. Some random things change in the game to confuse you. As NPCs walk about they may collect and move objects from where you last saw them.
- Fatal moves. There is a way to fail the game. Not all situations are safe.

Interesting. Those are some good ideas. I was going to have some useless items, and indeed I do not tell you what any item in the game does. It has a name and a visual description but what you're supposed to do with it is not obvious as the game items are all heavily symbolic.

The event system I'm working on should allow you to do things in different orders, so long as you hold to the dependencies. So, there might be a set of events that all depend on you having completed a particular event, then one event that requires many events to have been completed beforehand--which then opens up other possible events. In this way, the game could proceed in distinct phases without requiring you to complete the tasks in a given a phase in any specific order.

One thing I need to do is draw out the game map and decide if I need secret/unlockable areas. Initially, I didn't think so, but maybe a few secret areas wouldn't hurt. There is one item (a box) that's meant to trigger a "secret" ending and I want it to be very hard to find, so that might be a candidate for this.

Constraining the inventory size might be a game option though I won't use it initially. I know I'm going to have some kind of INI file to control the basic game parameters.

I plan to work on a lot of this over the weekend so maybe I'll have a prototype to show for it by Tuesday.

 

[Kelthaz]

As long as you don't pull a classic Sierra "Fuck You" you really can't go wrong. There's so many types of Adventure games out there and they all have the potential to turn out a great game.

 

[Owain Taggart]

Yeah, I've used TADS before. A bit overkill for me. I remember one time I worked on a game in TADS and I added an "electricity" mechanic: some items had an "electrical" property and you could only use them if the room had "outlets", which were a room property. So, I remember it fondly as a very versatile system, just way too much for what I'm doing.

Heh, fair enough. I can understand that. Heck, I've explored it but I don't think I've ever done very much with it. It can be as simple or complex as you like it to be though, that's the beauty of it.

What about the Z-Machine and the web-based Parchment interpreter I posted in the same post?

 

[Robert Maxwell]

I do not want a text interpreter, at least not yet. So, as cool as those may be, they are beyond my needs.

 

[ALF]

As long as you don't pull a classic Sierra "Fuck You" you really can't go wrong. There's so many types of Adventure games out there and they all have the potential to turn out a great game.

Haha, I always loved that! In Police Quest I, you can die simply by typing 'take clothes off'.

Good luck Robert Maxwell. I love ambitious projects like these. My friend always says, "the smaller the audience, the better the project."

I'm working on something similar for a few close friends of mine, a flash throwback to Sierra style games set in our hometown when we were teenagers. It's all about collecting, buying and selling porn (one of my buddies had the market cornered back then)! I'm not great at programming but I know actionscript so that's why I'm using Flash.

Real life is stretching it out far longer than I thought, tho.

 

[Robert Maxwell]

I have until September to get this done, which is more time than I need. I plan to get most of the game code done this weekend and then the rest of my time will be spent building the assets.