Hi Everyone, So I had a pretty general question for people. Lets say you wanted to make a standard adventure game. The kind where the user given a room(s) and they have choices to make. Such as "Look", "Get", "Examine", "Talk", or move to the next room and so on. Given this setup, what would be the best way to set about making a general engine for it? For example, I would think setting up a 2 dimensional array of structs for the rooms would be ok, with different parts of the structure being created for the attributes of the room. Like how many exits exist, how many items are found in each room, who is in each room, etc. But the problem with that approach is that I'm not sure how to make it flexible enough. Like, if any room contains (x) amount of items, how should that be stored in the structure? Or if an item, object, or person has multiple states... Like if you examine a table 3 times, a key is revealed, how would you store that kind of information in the room? At first I thought I would just give a room an attribute called "Item List" or something, and just put a list of items via index in it. And so, if the list contained item "3" then look up a different array to find out what kind of item it is and how to behave when you investigate it (As an example). Perhaps my method of tackling this issue is wrong to begin with? Sorry for the pretty messy description, but I'm hoping someone with experience kind of knows what I'm trying to figure out. (^_^);
I cant say myself cuz I've never ventured into adventure game programming, but maybe you could get some good design ideas from looking at the SCUMM engine?
A point-and-click game? You should check the Decay series (xbox indie game) http://vvgtv.com/2011/05/04/decay-part-4-xblig-vvg-indie-verse-review/ You can also try to contact the game's creator and ask those questions.
There are quite a few existing open source point and click engines out there as it is. Some of them quite powerful. I know that doesn't really answer your question but might be of some use.
Ah I remember the good old days of writing an adventure game in BASIC, defining lots of Arrays. You would have Room arrays which hold the description of the room, these could be 1D or 2D arrays so you could have different descriptions of the room. You would also have an array which would hold the links between the rooms, including directions to get between the rooms, you can also have lots of one way rooms too (for example if you jump out of a window then you might not be able to climb back up into the room). I remember having less then 64 rooms, so by adding binary bits to the room links I could add conditions, so you could mask off to find out if a condition needed to be set to enter the room, for example if the room was dark, needed a key, required you to have an object, etc. You would then have object arrays, items used with in the game. These would be everything from static objects, to food, animals and people. You then have lots of flag arrays which you use to link the items to conditions, status and to what room they were in. Item conditions would be single bit flags on whether the item can be picked up, eaten / drunk, thrown, used as a weapon, if the item can move on its own, if the item is a container, etc. Status arrays are things like weather of not item is used, number of times, if item is dead, condition of usage with other objects, if it contains other items, etc. You would also have a phraser, the later point and click games broke these down into a minimal set of words, where as in a text adventure game you would need to have more words, in a point and click it would be use match, but in a text adventure you would have use match, strike match, light match and probably some others too. So you would have long lists of words that would be aliases, but you might have to restrict some of the usages. At the end of the day an adventure game is basically lots of arrays that are linked to each other, with lots of flags allowing you to get through the game. The hardest part of any game is to write a story, then break it down into rooms, then work out what objects you need and how they will be used in the game and what flags you will need to catch everything. One thing about old text adventure games was the frequency of doing something that would kill you or more annoyingly using an object that you need to use somewhere else so you can not progress. For example lighting a match to light a lamp, which you need to pass through a dark cave, but only having one match and wasting it... I would suggest thinking small, maybe a adventure game with a couple of rooms and a few objects so you can work out how to use arrays and flags.
FYI, don't do standard arrays. Write some simple containment class then use STL List or Vectors to store your items in so you can change and move things around easily. Also work in c++. Like Jamtex said, Make a struct to define a room and in that struct have your stl list/vector of item structure and in the item structure have some form of a controllable state machine so you can change the current state of an item. for your items you can probably also use a base struct/class system so you can always add with out having to rewrite or make a really big struct/class to take into account all different ways an item can differ. //** Note, ignore bad code, I'm typing this in the text window and not writing in a IDE/Visual Studios first ** class BaseItem { public: enum EnumBaseItem = { eBaseItem_Base = 0, eBaseItem_Key, }; virutal EnumBaseItem GetItemType() { return eBaseItem_Base; }; virtual void OnInteract () {}; }; class ItemKey : public BaseItem { public: virutal EnumBaseItem GetItemType() { return eBaseItem_Key; }; virtual void OnInteract () { if( !bHasBenCollected ) { bHasBenCollected = true; } }; bool m_bHasBenCollected; }
Hrm... That sounds like a pretty good idea. Much better to use classes than to try and shoehorn everything in structs. (^_^);