If you've ever played any of the "Monkey Island" tri- (or is it quad) -logy, or if you've played any of the numerous other adventure games like (many of them set in mazes, but the better ones weren't IMHO), while you may (like me) have enjoyed them very much they tend not to replay very well. It's kind of like a mystery novel: you have to wait until you forget it to read it again (at least I do...). That may be a while. Which brings me to what I'd like to see...
I would like to create an adventure game in the style of "Monkey Island," but I would also like to be able to enjoy playing it even though I created it (oh sure, the gamer would get a benefit from this too, but who cares right? ).
So how do you make a game that by its very nature is centered around puzzles and ingenuity on the part of the player a dynamic experience where there isn't just one solution, there are thousands or even millions of possibilities with varying degrees of success?
Well clearly you don't want to design each potential solution explicitly, unless you happen to like writing dictionaries in your spare time. This is where the dynamic part comes in.
[IF YOU ARE ABOUT TO REPLY WITH FLAMES, TAKE A DEEP BREATH AND KEEP READING. I WILL ADDRESS THE ISSUE THAT IS BUGGING YOU. REALLY.]
I (having been around here for a while now) am aware that a fair number of posts have been...um...posted about dynamic worlds, NPC communication (there's one in this forum now), etc. The discussion I'm initiating is geared toward implementing such a system in an adventure game and getting something that is fun to play. Hopefully that has saved me from being scorched.
Anyway, back to the gist...
My seed of an idea right now (again in and of itself not original) is to assign properties to each object you create. For the sake of lessening tedium, I would suggest using various features of OOP such as inheretance. In fact why not go ahead and make an OOP language for describing objects? Anyway, the objects have properties (and methods I guess...).
Then you define certain goals based on puzzles. What does this problem require, basically. For example, suppose you are trapped in a dark room. You need to get some light. The goal: Ambient light > 10%. You have a match, there's a candle in the corner (you bumped into it), there is a rug that is probably flamable, etc. What do you do? Well certainly the choice is yours. You could light the match which in this case say doesn't provide sufficient light. However if that was your only match you're in trouble when it goes out. Or you could light the match and use it to light the candle which would satisfy the goal. Or you could light the rug, but that would probably result in your fiery demise. Object descriptions could look like this:
Anyway the above is a very scant example. It really doesn't do justice to the concept, but I have eye strain because I type all day at work.
One of the issues with such a system is ensuring that the game can still be won. If you don't know what the user will do, is it possible to ensure that the game is winnable? Does that matter? I don't think so. Let the player invent and reward them if they are smart; if they're not, they can go back to a previous save...
[PUTS ON ASBESTOS SUIT...] I know the savegame thing is a hot issue, but that is my opinion in this case. It in no way reflects my opinion in all cases, nor should it ...
Expect more posts on this. I simply don't have time to list all ideas in this one, plus if it gets much longer no one will read it (I know I wouldn't). [edited by - bob_the_third on August 5, 2003 11:53:00 PM]
Hey great post. I just recently added something veeeeery similar to your example to my game. All the items are stored in a text file, where each definition basically lists the properties of that item. And of course there is inheritance Although as for what those properties mean currently it''s pretty much "hard" coded. I think this is a good idea, however, one of the things that makes the lucas arts style of puzzles so great is how well they tie in to the storyline, and how zany the puzzle solotions can be at times.
A functional method of creating items and problems that you hint at wont be able to recreate the same quality feel of puzzles in those games. Still, I have nothing against games that have very dynamic problems to solve and give you limitless options with which to solve them. I still have a big place in my heart though for a hardcoded mostly linear prewritten, story based puzzle adventure game
But for instance, Deus Ex succeeded very well with that method of keeping things modular and letting object oriented emergence take its course, although much of it was still predetermined. I think games are definately headed to areas where players are more likely to solve problems in a way that the designers DIDN''T imagine rather than the way the designers decided them to solve it.
And one of the keys to emergence is, in my opinion, to as you say take a bottom-up approach. The game of LIFE with the cells expanding, or the flocking algoithms show that with a few good simple rules there can emerge an extremely complex system.
The only problem I see is that an adventure game almost requires a really good story to tie things together, and the puzzles need to fit. If you can find a way to make an adventure game that''s fairly dynamic, with unscripted puzzles that still fit into the storyline (hardcoded or dynamically generated), and it still has a good story and is fun to play, you will have created a great leap forward! I''m not sure if it will be as easy as I make it sound though lol.
I think that as games progress, players will be able to have more say in their performance rather than being basically fed cues and acting on them. But I''m not sure if that''s a good thing or a bad thing, because the experience of acting out a good storyline, even if you are mostly acting as was intended, is as much a part of gaming for me as being able to play around and do your own thing.
Just want to add, I don''t think all the technology or designing in the world will find a way to blend follow-the-lead-designer style gaming and follow-your-own-lead style gaming into one game, and keep the essence of both.
The difficulty in creating a dynamic adventure game is the fact that most adventures games have static puzzles and solutions by nature. For instance your example of being trapped in a dark room, if you always have a candle, match and rug. Then the puzzle is static and always the same. You know from the last time you played that you need to light the candle to escape.
In order to make a traditonal sierra style adventure game to have extensive replay ability then you need to make it dynamic so that each time you play things are diffrent. To this you''d have to create a large number of nodes and elements, and then allow the game to assemble these nodes into winable game each time.
For instance let say you 4 diffrent fire generating elements, a match, a ligher, a flint arrow head, and a strip of pottassim. Now depending on which nodes the program has joined together to form this version of the game. The player will have one or more of these when they reach the dark room assuming the dark room is in that version of the game. The player now has to get light into the room put how they do will be slightly diffrent depending which nodes the game posses. You could furthur increase replay ability by randomizing the contents of the nodes. For instance the dark contains map to buryed gold. You could set it up so that the map is painted on the wall, sown into the rug or carved into the candle. That way if the player lights rug on fire, they may do so only to discover they have destroyed the very map they wanted to retrive.
However there is still a static nature to the game since the puzzle have finite preprogrammed solutions.
----------------------------------------------------- Writer, Programer, Cook, I''m a Jack of all Trades Current Design project Chaos Factor Design Document
If it were just about a sequence of seperated rooms, each with a puzzle like this it wouldn''t be too bad.
But once you start letting the player do things like, say, blow up buildings and distrupting the entire city around him, you open up a can of worms as to how to model everything he''s capable of doing.
You could restrict what the world lets him do, but that inevitably brings it down to the level of interaction we already have.
So the only real solution is to invent a world and situations that you can feasably design a system to handle with the dynamic range you''re interested in. One way to do this could be to reduce the level of technology(and therefore potential world situations) available until you reach a level that''s doable. The modern world has so many distinct *things* in it; that''s why it''s so hard to recreate in exacting detail. Go back to the Stone Age, and you have a bunch of people, creatures, a few simple possessions, and the landscape. That wouldn''t be too hard to make a game from.
Another way would be to give the player very few real choices. Like a "Robinson Crusoe" game where the player has to build shelter and hunt to survive on a desert island. The only buildings the player gets to knock down are the ones he makes. There aren''t other people around to make stupid AI errors and destroy the sense of reality, either. (Well, if you followed the book exactly there would be, later on, but the earliest parts are what interest people the most anyway.)
And we already engage in a lot of both of these things in existing games. For example, we never see a military FPS game where between your combat missions you get to wander around the local town doing whatever, because it would be too hard to include both the entire off-duty segment and the combat too. So instead it''s simply one fight after the next.
Straying from the dynamics, if the point is to be able to "discover" your own game, you could have different people you know design different chapters.
For example, your whole team pitches in for the first chapter, which can be as long or as short as you want it to be, and designs the engine and starts off the story, basically getting the game on its feet, then different members of the team, or fans of the game, could take turns using the engine to develop their own chapters with their own puzzles and plot twists if allowed. what do you think?
quote:bob_the_third : My seed of an idea right now (again in and of itself not original) is to assign properties to each object you create.
The problem I see is: because of the way words are selected in languages (whether you believe it is to categorize or to differentiate), attributes tend to be both ill-defined and numerous.
You had three properties that determine the "flammability" of those three objects. Probably you could create some base classes for the objects that burn readily, can be burnt, are damaged by fire, and are invulnerable. (and these classes would have several properties that enumerate this "flammable" attribute).
Now you move on to, say, "movable". Again, there are a few basic properties (required strength, leverage, maybe something for attached items). More base classes (multiple inheritance).
Now move on to the next attribute... and the next. Once you have fourty or fifty attributes (and a hundred or two quantifiable properties), you can probably handle the simple -- simple -- interactions between a hundred or so objects.
You have a quest where you have to poke something through a keyhole to knock loose the key. You need a property for that (just size doesn''t work as not everything is rectilinear). You have a quest where you need to get past a bull. Might need weapon properties, possibly color+capelike properties.
The problem is that we''re taught to see things in hierarchies. Indeed, much time is taken creating taxonomies of creatures, objects, etc. But in general the hierarchy is just resolving one property at each level of depth -- one view of reality. You really need hundreds of hierarchies minimally.
Plus, consider interactions. A match has properties. A flame does. Combine the two, you have a "lit match". Okay, this could be a flag -- but what if the match is combined with water? It acts differently. What if it''s soaked in gasoline? Very different picture.
I don''t want to discourage you, though. That''s how I picture reality. It''s just been a problem I''ve been tossing around in my head since... well, a long time. Finding a solution for a limited set of items is doable. But if you want reality modelling, there''s just a whole slew of deatil -- and every time you create an object you have to look at all possible interactions, and compare it to all quest types. It starts to get daunting.
This is neat thinking, imo, and I wish I were more technically skilled to be able to address the problem in a clearer way, so I hope what I am saying makes sense; it's been a long two days, and IT maintenance weekend is looming starting Friday.
The design side of me is telling me to say to you that the solution lies not in the type of dynamicism you assign to object, it properties or attributes, or a puzzle design, but in how the story is designed that dictates limitations of the dynamicism you seek in the range of solutions that are realistic and comprehensible in playtime terms to the player to choose from quickly.
Having tried not to make that sound like I was puking all over the screen in metaphores, let me give you an example from my adventure game.
In my game design, the world and the levels have a finite array of natural physics and material attributes (gravity, wind, current; densities of objects like wood, water, air, stone, metal). So the levels have a topography and geology pretty normal looking.
The features I design as superior technology and/or supernaturalism supercede in certain cases the preset params for physics and material, giving the player a range of responses in their inventory or ability at that time and place in the game.
The piece of the story that I am designing the level for has a reasonable range of approaches (as solutions to puzzles or escape from traps or inventions/constructions/manipulation of objects/environment/NPCs/opponents/foos) to the complications I compose.
Your assertion that thousands or millions of solutions with varying degress of success, imo may not matter as much as an array of solutions the player can create in a fairly short period of time while engaged in play action. This is based on the assumption that if time is important to satisfaction factors in user play (as percieved as entertainment value by the player), then a zillion solutions are over design, even if perfect or amazingly high standards design.
Put another way, if I were on a fairly complex level, and I had to put together a lot of solution factors in my head while I was running around the level avoiding, combatting or compensating for objects or world attributes while figuring out the solution to the primary or secondary challenge the level contains, at a certain point of complexity or chaos, fun in gameplay becomes a factor of diminishing returns. I hate sitting on a level with a bunch of dead things around me thinking, "HTF do I get out of here, or open this thing, or make this new foo work?"
Am I just amazingly intellectually lazy, or do I want to play in a game, and thinking is something I do for a job or for my girlfriend?
This is based entirely on my naive assumption that in game design, you are going to make your best game if it is the game that you want to play.
So I put myself in the shoes of a player, and realize from my experiences as a game player before I ever started my game design, that super complex levels and majorly intricate puzzles were not much more fun than the fun I was already having trying to discover the larger world mystery driving the adventure to begin with, and what the changes in complexity were really for was the variety of challenge necessary to keep players engaged.
This is the story design process I am talking about as the guide. I don't tell my player everything up front, like in an intro cinematic showing the reason I am going to be playing for the rest of the game, e.g., this is the quest for the treasure of so and so. Rather I'd like to keep them guessing, with hints and glimpses of the larger mystery to discover, and keep their engagement and involvement levels really high.
Maybe I am just speaking with blinders, since I can only see this technique as usable in my type of design, the epic mystery adventure, and am not really seeing a larger game design issue. Fatigue and tunnel vision can cause this, and I am sure you will point out where I'm missing something.
Many game design books point to how in each level you design, there is (without being so formulaic that individual outstanding creative originality is ruled out by strictly interpreted and applied design criteria; for in some cases I have levels that take a few minutes or less to complete, but in other cases, I have levels that are going to take you a significant amout of time, perhaps hours over a few days, to complete. But I give you rewards worthy to the effort so you take away the value of the payoff and still have fun) only so much difficulty or complexity you want in any level, and also many game design books indicate after a pretty intense or intricate/complex level, you want to provide an easier, "cooling off" level afterwards for the benefit of giving the player some mental rest.
So, how much fun in terms of what makes the player play, or makes the player keep going or makes the player rave to their friends is a thousand or more possible solutions? Aren't a reasonable amount of logically (problems solving faculties being engaged by the player in gametime) configurable solutions to any given complications design, whether trick, trap, puzzle or clue solving pretty much all you need to satisfy the vast majority of players?
Are there really so many players of your game, as a percentage of the total number of players who bought your title, going to sit around and say, "It was no fun because I couldn't solve it this way", when in playtesting, that array of solutions design players create during play went through vetting and/or redesign/repurposing for the elusive fun factor improvement process anyway, and you got the best your level could give you?
Will all those innumerable solutions make all players happy all the time?
Am I just completely exhausted after two 15 hour days, making no sense whatsoever, and perfectly entitling myself to flamage, or does this make any sense to the question you asked, or bear any resemblance to even addressing the issue?
Proceed Johnny Torch..
Adventuredesign
[edited by - adventuredesign on August 7, 2003 5:44:31 AM]
Always without desire we must be found, If its deep mystery we would sound; But if desire always within us be, Its outer fringe is all that we shall see. - The Tao
Very interesting questions you raise bob. I have also been tinkering with a similar idea, but instead of focusing on objects and their properties I have been dealing with human interaction and NPCs (that is a topic of its own).
Your idea all sounds good on paper, but as Merle points out, surely you would soon reach a point where the number of properties and actions just got so huge that it wouldn''t be fun anymore to try designing the world.
Take the example of trying to light a match. How would you define the striking surface (of a matchbox)? Would it be hardcoded that the match could light only on the matchbox? Would you define a property for the surface that enabled it to light matches?
But enough pessimism! I consider myself an optimst, so I belive it could be done. But you would need to think long and hard of what properties and actions should be available in the game.
Your original question was if it would be possible to design an an adventure/puzzle game that suprised yourself everytime you generated a new quest. One idea would be to have your players/fanbase submit new objects. This could create a huge array of objects and many potentials and fun/suprising combiniations.
As for creating a "winnable game" I think that too would be possible. Just let the computer use an A*-algorithm for finding the best solution.
I''m going to be honest up front. I haven''t completely read all the responses, but I did skim them to get a general feel. I will respond in part here with some more of my thoughts and then more fully later when I''m not rushed.
Everyone: Agreed. It''s a tough problem, and having too many potential solutions could very well decrease the fun factor.
The thing that I want is to be rewarded for my creativity, not for trying a bunch of stuff till I find out what the designer wants me to do. What I liked about the MI series was the humor and fun-ness of the story and the feel of the game. What I didn''t like was the gameplay that went like this:
"Well I tried the cheetos. Hmm. Is that a monkey in the corner. Don''t know what good it would do, but let''s try every command on it...Well I''ll be, that was it!" I feel like a person trying to brute-force a combination lock. Ick!
Instead it would be great if I could say, "Well I need to get out of this room...let''s try the axe. Yeah, that worked but somebody heard me. I wonder if there was a better way. Won''t know till it''s over, and maybe not even then."
I really hated it when Guybrush would say, "I''m not picking that up." or "No." or just not do stuff. It all seemed very arbitrary because it was statically designed.
So what I''m thinking is this:
You define the objectives, scenes, and objects. Using genetic algorithms, a software tool suggests object selection (but not necessarily placement) for each room that meets the requirements you set.
quote:bob_the_third: You define the objectives, scenes, and objects. Using genetic algorithms, a software tool suggests object selection (but not necessarily placement) for each room that meets the requirements you set.
I think it works for a simplified situation like that, where the player is wandering through rooms, and each room contains the items needed to get to the next. For one puzzle, the model holds up, but I''m worried about what happens in a non-linear game.
The trick comes when there are many different areas, a number of barriers, and items scattered around. You have to scatter them so that you can get past each barrier, preferably in several ways (otherwise why have such a complex model?). And the system has to predict usage and compensate.
For example, in the starting area you have axe, match, tinder. First blockade is a door. In the second area, candle, and the blockade is "generate enough light". If the player uses the axe on the door, everything works out, but if they use match+tinder to burn the door down, there won''t be a way to light the candle (unless you unrealistically leave the door burning).
Of course you can remedy the system by just dumping in lots of objects, but I don''t think the game would be much fun then...
).
So how do you make a game that by its very nature is centered around puzzles and ingenuity on the part of the player a dynamic experience where there isn't just one solution, there are thousands or even millions of possibilities with varying degrees of success?
Well clearly you don't want to design each potential solution explicitly, unless you happen to like writing dictionaries in your spare time. This is where the dynamic part comes in.
[IF YOU ARE ABOUT TO REPLY WITH FLAMES, TAKE A DEEP BREATH AND KEEP READING. I WILL ADDRESS THE ISSUE THAT IS BUGGING YOU. REALLY.]
I (having been around here for a while now) am aware that a fair number of posts have been...um...posted about dynamic worlds, NPC communication (there's one in this forum now), etc. The discussion I'm initiating is geared toward implementing such a system in an adventure game and getting something that is fun to play. Hopefully that has saved me from being scorched. 
Anyway, back to the gist...
My seed of an idea right now (again in and of itself not original) is to assign properties to each object you create. For the sake of lessening tedium, I would suggest using various features of OOP such as inheretance. In fact why not go ahead and make an OOP language for describing objects? Anyway, the objects have properties (and methods I guess...).
Then you define certain goals based on puzzles. What does this problem require, basically. For example, suppose you are trapped in a dark room. You need to get some light. The goal: Ambient light > 10%. You have a match, there's a candle in the corner (you bumped into it), there is a rug that is probably flamable, etc. What do you do? Well certainly the choice is yours. You could light the match which in this case say doesn't provide sufficient light. However if that was your only match you're in trouble when it goes out. Or you could light the match and use it to light the candle which would satisfy the goal. Or you could light the rug, but that would probably result in your fiery demise. Object descriptions could look like this:
One of the issues with such a system is ensuring that the game can still be won. If you don't know what the user will do, is it possible to ensure that the game is winnable? Does that matter? I don't think so. Let the player invent and reward them if they are smart; if they're not, they can go back to a previous save...
[PUTS ON ASBESTOS SUIT...] I know the savegame thing is a hot issue, but that is my opinion in this case. It in no way reflects my opinion in all cases, nor should it ...
Expect more posts on this. I simply don't have time to list all ideas in this one, plus if it gets much longer no one will read it (I know I wouldn't). 
