How do adventure game engines work?
Author
Hey all...
OK I was recently playing one of my favorite games that I haven''t played in ages (Monkey Island 2) and now I am totally confused as to how the game engine works.I think LucasArts calls it the SCUMM story system or something.
My question is,how does it work? How does the game link all and keep track of the events that occure in the game? How is it all organised? How does it know what sentences to give your character in certain events? How...blah blah blah...
Any ideas or does anyone have a good link to a site that explains all this?
Thanx in advance!
Well, you could check out several freeware engines, as I''m pretty sure the basic concepts are the same. I''m currently using Adventure Game Studio, but there are others, that I can''t think of off the top of my head.
Ut
Ut
The best game in the world ever, and still my favourite genre!
Gecko, think DATABASE. I''ve worked (dabbled) with a system for games like this and it basically boiled down to a database. Using objects together had the ability to create other objects, or using objects in a scene had the ability to change the state of a scene.
Each object (inevtory item or part of a scene) has a unique ID, cross-matching their interactions will either yeild a positive result, or a standard "I can''t do that" response. It may even cause a change to the scene, like opening a door, so compare the state of the scene AND the object interactions to find the appropriate reaction.
Saving games becomes easy too, simply dump the entire database into the save file!
I still want to write a game like this, so if you are thinking of starting one, I''ll gladly help out.
Cheers
Matt
Gecko, think DATABASE. I''ve worked (dabbled) with a system for games like this and it basically boiled down to a database. Using objects together had the ability to create other objects, or using objects in a scene had the ability to change the state of a scene.
Each object (inevtory item or part of a scene) has a unique ID, cross-matching their interactions will either yeild a positive result, or a standard "I can''t do that" response. It may even cause a change to the scene, like opening a door, so compare the state of the scene AND the object interactions to find the appropriate reaction.
Saving games becomes easy too, simply dump the entire database into the save file!
I still want to write a game like this, so if you are thinking of starting one, I''ll gladly help out.
Cheers
Matt
thats what i like to hear, people still interested in adventure games. i like a lot of different genres of games, but these are by far my favorites. if you are interested in making an adventure game, i would definetly be interested in helping too.
Author
Thanx for all the quick responses guys!
Good thinking with that database thing! I''ll actually take a look at that!
What I''m planning on doing is a 3D adventure game but it will all be cartoon rendered.Something like Monkey Island but full 3D.It was just a though that came to me while playing monkey island 2.I''m not sure of the story but those who are interested,drop me an email at thegecko@tbaytel.net so I can have your email adresses handy
You guys do know that Monkey Island 4 will be out in a week or so, right?
Good thinking with that database thing! I''ll actually take a look at that!
What I''m planning on doing is a 3D adventure game but it will all be cartoon rendered.Something like Monkey Island but full 3D.It was just a though that came to me while playing monkey island 2.I''m not sure of the story but those who are interested,drop me an email at thegecko@tbaytel.net so I can have your email adresses handy
You guys do know that Monkey Island 4 will be out in a week or so, right?
Woohoo, someone talking about adventure games!
I'm actually making a 3d adventure game right now (just me and a friend, but we're aiming for pro quality!), and i can tell you it's WAY different from programming action games. This thing is more complicated than monkey island's interaction--there's a ton of message passing going on since everything needs to be passive (like Windows elements). Everything's gotta be passive, and flexible (we want a system that doesn't restrict ANYTHING that objects can do)
I use a different system rather than a database, because of both the passive requirement as well as the enormous changes that interaction must inflict on not just the status of other objects, but the process of the game itself (mini games!). All the interaction centers around one queue of "events", which are basic units that embody all of the possible connections between "entities" and the world. They are flexible, mutable types, so i can always add new types of events. Some tell the text controller to put out some text for x amount of time, some give a choice of "things to say", some are conditional branches, some just stall the execution of the queue, etc.
The "entity" is composed of the graphic portion of the object (i still have yet to complete this) and the "operand", which tells what it "does" when you act on it. To "do" something to an "operand", an "operation" is performed on it. so the operand basically holds a group of operations, which are just sequences of events to slap into the queue.
pretty oddball, huh?
I'm actually pretty far on it. I've finished with the building blocks (loading models, skeletons, animations, and the the base of the operand/operation/event system- active components as well as I/O), have completed significant portions of the interface, and im just now working on tying everything together in the "level"... after that, there's the significant task of entering in the data and making the graphics.
But the level is the big problem- what structures will i use to affect the functioning of the world? how will they act on one another? how will the events mutate the level, and at a higher level, the game proceedings themselves? i've only answered a few of those questions. (im not asking anyone, im just reflecting)
added in edit-
Oh yeah, the big problem with MI4 is the interface- it sucks. We already have the essence of a mouse-driven interface... i've written the code for the the object selection and the character navigation (haven't tested it yet because the level ain't completed). Trying to figure out navigation was pretty fun... i came up first of all with a pathfinding thing, and while walking, the individual steps are precisely tracked. it'll be cool when i construct the level and make the animations. walk differently up stairs? you bet. change direction in the middle of walking? you'll have a turning radius (albeit a small one).
now another problem we have to face is where will you stand and look to act on something. our best idea was to have an "action zone" designated for each object in the level editor.
and we do have a story-- a magnificent one at that!
also, here's a link with some outdated info http://www.jps.net/~xenocide. Check out future projects.
Edited by - Hauser on November 3, 2000 3:36:40 AM
I'm actually making a 3d adventure game right now (just me and a friend, but we're aiming for pro quality!), and i can tell you it's WAY different from programming action games. This thing is more complicated than monkey island's interaction--there's a ton of message passing going on since everything needs to be passive (like Windows elements). Everything's gotta be passive, and flexible (we want a system that doesn't restrict ANYTHING that objects can do)
I use a different system rather than a database, because of both the passive requirement as well as the enormous changes that interaction must inflict on not just the status of other objects, but the process of the game itself (mini games!). All the interaction centers around one queue of "events", which are basic units that embody all of the possible connections between "entities" and the world. They are flexible, mutable types, so i can always add new types of events. Some tell the text controller to put out some text for x amount of time, some give a choice of "things to say", some are conditional branches, some just stall the execution of the queue, etc.
The "entity" is composed of the graphic portion of the object (i still have yet to complete this) and the "operand", which tells what it "does" when you act on it. To "do" something to an "operand", an "operation" is performed on it. so the operand basically holds a group of operations, which are just sequences of events to slap into the queue.
pretty oddball, huh?
I'm actually pretty far on it. I've finished with the building blocks (loading models, skeletons, animations, and the the base of the operand/operation/event system- active components as well as I/O), have completed significant portions of the interface, and im just now working on tying everything together in the "level"... after that, there's the significant task of entering in the data and making the graphics.
But the level is the big problem- what structures will i use to affect the functioning of the world? how will they act on one another? how will the events mutate the level, and at a higher level, the game proceedings themselves? i've only answered a few of those questions. (im not asking anyone, im just reflecting)
added in edit-
Oh yeah, the big problem with MI4 is the interface- it sucks. We already have the essence of a mouse-driven interface... i've written the code for the the object selection and the character navigation (haven't tested it yet because the level ain't completed). Trying to figure out navigation was pretty fun... i came up first of all with a pathfinding thing, and while walking, the individual steps are precisely tracked. it'll be cool when i construct the level and make the animations. walk differently up stairs? you bet. change direction in the middle of walking? you'll have a turning radius (albeit a small one).
now another problem we have to face is where will you stand and look to act on something. our best idea was to have an "action zone" designated for each object in the level editor.
and we do have a story-- a magnificent one at that!
also, here's a link with some outdated info http://www.jps.net/~xenocide. Check out future projects.
Edited by - Hauser on November 3, 2000 3:36:40 AM
Well, the database idea certainly makes sense, but I''m currently working on an adventure game, (It has a bit of action to it though.) and I decided on the nice ''simple'' techneque - write a complete C style scripting language:-) This adds tons of flexability and power, as well as no editors need to be made, though I still have some database style stuff - ie for conversations. (If you e-mail me, or anyone else, I''ll send you my conversation editor - it''s very flexible and outputs to a really simple plain text file format, allowing access to external game states and the whole design is managed by a colour coded tree - anyone could use it.)
-Lethe
-Lethe
I''m also writing an adventure game - for Windows using DX. I''m going beyond how normal adventure games are, focusing a lot of detail into non-playing characters for the game. I''m trying to make the game real in a fact where there are weight limits on the inventory.
Here is my basic design for now:
- Every player in the game (be it the main character or the NPCs) is stored in a class. Under this class it contains information such as the persons health, current mood (a feature used for NPCs), and current inventory.
- I keep track of game events through a flag array. This I might change later. A flag is either true or false. When the player wants to do something, test for certain flags. If they want to open a locked door, test for flag[24] which would be the flag that determines if the door is locked or not.
Now, I am trying to develop some sort of system that will restrict player movements on the screen or in a room. Sierra and Lucas Arts use a system of priority lines. Every room has two screens. One is the graphical screen we see and the other is a blank screen with lines designating the outline of where on the screen the player can walk. Lines would be different colors and areas could be filled in. The engine would know that a black line meant a border, blue line meant water, and a yellow line meant next room. This is, in my opinion, one of the hardest aspects of the engine. I''d like to hear some opinions about this.
BTW, my adventure game (currently called Testament) will be open source. We''ll have a webpage up in a few weeks and I''ll let everyone here know about it.
Here is my basic design for now:
- Every player in the game (be it the main character or the NPCs) is stored in a class. Under this class it contains information such as the persons health, current mood (a feature used for NPCs), and current inventory.
- I keep track of game events through a flag array. This I might change later. A flag is either true or false. When the player wants to do something, test for certain flags. If they want to open a locked door, test for flag[24] which would be the flag that determines if the door is locked or not.
Now, I am trying to develop some sort of system that will restrict player movements on the screen or in a room. Sierra and Lucas Arts use a system of priority lines. Every room has two screens. One is the graphical screen we see and the other is a blank screen with lines designating the outline of where on the screen the player can walk. Lines would be different colors and areas could be filled in. The engine would know that a black line meant a border, blue line meant water, and a yellow line meant next room. This is, in my opinion, one of the hardest aspects of the engine. I''d like to hear some opinions about this.
BTW, my adventure game (currently called Testament) will be open source. We''ll have a webpage up in a few weeks and I''ll let everyone here know about it.
Symbolic processing people...
You don''t want data structures that have a canned definition. This will cause you problems in the end.
Don''t do this:
struct object {
int weight;
int openable;
int open_or_closed;
int shootable;
int projectile_type;
...
};
Do this:
item -> hasAttribute -> value
Where [item] is a symbol with possible multiple [hasAttributes] which are in turn symbols. [value] is a also a symbol which in turn has attrributes pointing to values.
You then can do queries like:
(x open_or_closed)? fill in slot with right answer (yes os no).
(x projectile_type bullet)? answer yes or no.
(x projectile_type)? fill in the slot with right answer (bullet).
(x angry)? fill in slot with right answer (yes or no)?
(x carrying)? fill in slot with multiple items which x is carrying.
(x carrying knife)? answer yes or no.
You don''t want data structures that have a canned definition. This will cause you problems in the end.
Don''t do this:
struct object {
int weight;
int openable;
int open_or_closed;
int shootable;
int projectile_type;
...
};
Do this:
item -> hasAttribute -> value
Where [item] is a symbol with possible multiple [hasAttributes] which are in turn symbols. [value] is a also a symbol which in turn has attrributes pointing to values.
You then can do queries like:
(x open_or_closed)? fill in slot with right answer (yes os no).
(x projectile_type bullet)? answer yes or no.
(x projectile_type)? fill in the slot with right answer (bullet).
(x angry)? fill in slot with right answer (yes or no)?
(x carrying)? fill in slot with multiple items which x is carrying.
(x carrying knife)? answer yes or no.
Author
WOW! It''s great seeing that there are still lots of people interested in making adventure games! I''m really proud Keep those ideas coming! I''m beggining to "see the light"!
Hauser: tell us more.I''m also really interested about your skeletal animation system.This is one of those BIG things that are sort of stopping me from proceeding along and actually programming my game.I have no clue how single-mesh skeletal animation works and would REALLY appreciate it if you could point me to a good site or white paper about the subject.
Are you going to be using cartoon rendering eventually?
I won''t start programming my game until January,so in the mean time I''m writing the whole story for the next 2 months and looking around for 3D artists as well as working on the building blocks.I plan to have like MI4 (3D characters and the backgrounds are 2D hand drawn or pre-rendered cartoon images) I''ve got a really good idea of what my story is going to be and how things will interact,but I still have 2 big issues to resolve.First,figuring out ho my story engine is going to work and second,creating a skeletal animation system.That''s going to be the hardest part.I will,of course,keep all of you posted on my progress.But until I do actually start to program the game I would still like to hear more about what everyone is doing and any advice any of you can give me that might make my programming life easier
Keep em coming!
Keep those ideas coming! I''m beggining to "see the light"!Hauser: tell us more.I''m also really interested about your skeletal animation system.This is one of those BIG things that are sort of stopping me from proceeding along and actually programming my game.I have no clue how single-mesh skeletal animation works and would REALLY appreciate it if you could point me to a good site or white paper about the subject.
Are you going to be using cartoon rendering eventually?
I won''t start programming my game until January,so in the mean time I''m writing the whole story for the next 2 months and looking around for 3D artists as well as working on the building blocks.I plan to have like MI4 (3D characters and the backgrounds are 2D hand drawn or pre-rendered cartoon images) I''ve got a really good idea of what my story is going to be and how things will interact,but I still have 2 big issues to resolve.First,figuring out ho my story engine is going to work and second,creating a skeletal animation system.That''s going to be the hardest part.I will,of course,keep all of you posted on my progress.But until I do actually start to program the game I would still like to hear more about what everyone is doing and any advice any of you can give me that might make my programming life easier
Keep em coming!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
