I'm starting work on a text adventure game and am trying to figure out a good class structure. This is what I have so far:
class location
string name
string description
connection* listOfConnections //pointer to head of linked list
item* listOfItems
class connection
string direction
char shortcut
string description
location* destinationLocation //pointer to a location
class item
string name
string description
bool playerHas
bool inspectable
etc.
class inventory
item* listOfItems //pointer to head of linked list
So At this point I'm trying to figure out if this is a good class structure or if I need more or less classes.
How do I abstract the concept of an action or a relationship? Like using a key to open a door. Should I have an additional class for objects separate from items? (for doors)
Should the objects class have state bools or should I make another class for states and then have a pointer to a linked list of states in each instance of an object class.
Is there any point in having an inventory class if the item class already has a 'playerHas' bool? Or is the better question if there is any point in having the 'playerHas' bool if there is already a linked list of items that is the player's inventory.
It seems like concepts like actions "use key on door" and "press button" need to be abstracted and added to the class structure as well.
But I've never done anything like this so I'm not sure how best to proceed.
Class Structure for a Text Adventure Game
"bool playerHas"
You'll be back here asking how you have other characters carry things...
There are a couple of reasonable approaches. One is to have a true tree structure where objects can contain/consist or otherwise relate to other objects; rooms are objects which contain items and characters, characters can "hold" or "wear" objects, which in turn can contain other objects.
Lets you handle "examine gun in pocket of coat"
A simpler, but still useful mechanism, much used in games in the 8 and 16 bit eras is to give each object a "location" field which is an integer. If it's positive, the object is present in that numbered location. If it's negative, the object is being carried by character number abs(location). Location zero doesn't exist, so objects can be removed from the game world. Other location numbers can be "special" in various ways.
It then gets reasonably easy to implement "give" and "take" and then you can have puzzles where you need to stun the guard to take his sword (because when he's unconscious he doesn't attack you if you try to take objects off him) and use it to cut the rope...
"bool inspectable"
Just give each item a map of properties, string->string. When a player runs "Examine X", you can check X to see if it has a "examine" property. Otherwise it's "nothing special".
You can then encode several other useful things. If the item has "get_message" you can't get the item, but the string is the message to print instead. If the item has a "text" property, then "Read X" works on it... and so on.
That's how you make the door -- it has a "get_message". Now that the door is an object, handling "Use key on door" is easy. It's a special case of "Use X on Y"...
Back in the 8/16bit days, you'd have a single routine for each verb. The routine would check the objects. So first off you check if the objects are "present" (held by the player or in the current location) and then you do; if ob1 = key and ob2 = door then unlock_door()
Unlock_door() would clear the "blocked" bit in that link and swap the "locked door" object for the "opened door" object. (by swapping their locations).
These days, if your language supports them, you may want a set of maps which map tuples of (verb_number, object) -> function and (verbnumber, obj, preposition, obj) -> function
You'll be back here asking how you have other characters carry things...
There are a couple of reasonable approaches. One is to have a true tree structure where objects can contain/consist or otherwise relate to other objects; rooms are objects which contain items and characters, characters can "hold" or "wear" objects, which in turn can contain other objects.
Lets you handle "examine gun in pocket of coat"
A simpler, but still useful mechanism, much used in games in the 8 and 16 bit eras is to give each object a "location" field which is an integer. If it's positive, the object is present in that numbered location. If it's negative, the object is being carried by character number abs(location). Location zero doesn't exist, so objects can be removed from the game world. Other location numbers can be "special" in various ways.
It then gets reasonably easy to implement "give" and "take" and then you can have puzzles where you need to stun the guard to take his sword (because when he's unconscious he doesn't attack you if you try to take objects off him) and use it to cut the rope...
"bool inspectable"
Just give each item a map of properties, string->string. When a player runs "Examine X", you can check X to see if it has a "examine" property. Otherwise it's "nothing special".
You can then encode several other useful things. If the item has "get_message" you can't get the item, but the string is the message to print instead. If the item has a "text" property, then "Read X" works on it... and so on.
That's how you make the door -- it has a "get_message". Now that the door is an object, handling "Use key on door" is easy. It's a special case of "Use X on Y"...
Back in the 8/16bit days, you'd have a single routine for each verb. The routine would check the objects. So first off you check if the objects are "present" (held by the player or in the current location) and then you do; if ob1 = key and ob2 = door then unlock_door()
Unlock_door() would clear the "blocked" bit in that link and swap the "locked door" object for the "opened door" object. (by swapping their locations).
These days, if your language supports them, you may want a set of maps which map tuples of (verb_number, object) -> function and (verbnumber, obj, preposition, obj) -> function
Author
Definitely a lot of possibilities to consider. Lot of things I hadn't thought about yet. Thanks for your help!
Wouldn't each location either contain an inventory object or implement an inventory object's interface? Maybe door() would be a method of the connection class?
Probably not as big an issue now as it used to be but games can chug a bit if you get a particularly wild spin-up of objects going all at once. Make sure that room with 17 connections each implementing interfaces to 214 other objects gets de-allocated.
Probably not as big an issue now as it used to be but games can chug a bit if you get a particularly wild spin-up of objects going all at once. Make sure that room with 17 connections each implementing interfaces to 214 other objects gets de-allocated.
you'd be surprised at how complex a "simple" text adventure can get, especially if you want to implement a reasonably good parser, if you want to move around rooms, pick up and drop items, its relatively simple, when you add use x with y, check if x is with character or in room, check if y is with character or with room, is the item fixed of free, does it make a new final item or another item that can again be combined, does it generate a new exit...
Hi Sooner,
I made a post in another thread where I show an example of a simple text adventure structure. It basically defines Items, Rooms, and the Player, and you create the rooms and give it items. It's made to be updated, but it's a generic start.
BTW, in your code modules, it looks like you plan on using a linked list; why not use std::vector instead?
Good Luck!
I made a post in another thread where I show an example of a simple text adventure structure. It basically defines Items, Rooms, and the Player, and you create the rooms and give it items. It's made to be updated, but it's a generic start.
BTW, in your code modules, it looks like you plan on using a linked list; why not use std::vector instead?
Good Luck!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
