Adventure Game Studio

Community => Adventure Related Talk & Chat => Topic started by: abstauber on Tue 21/07/2009 10:10:00

Title: Adventure UML: Diagrams for puzzle design
Post by: abstauber on Tue 21/07/2009 10:10:00
Hey,
after reading Ghost's article about puzzle creation, I started to ask myself, how to make their design less confusing and more structured. Unfortunately most amateur games I've played recently are quite linear and the puzzles don't rely on each other.
And I also cought myself, making pretty linear puzzles myself. So why is that and how could it be changed...?

When designing software, you usually use some sort of diagrams (preferably UML charts) to visualize complex situations - isn't making a puzzle a complex thing too?

So I came up with a new diagram type, some kind of adventure UML ;D

It consists of an overview -  a simplified flow chart:
(http://shatten.sonores.de/wp-content/uploads/2009/07/dia_overview.PNG)

and a detailed view per puzzle
(http://shatten.sonores.de/wp-content/uploads/2009/07/dia_puzzle.PNG)
yes, this puzzle isn't too complex

Here are the stereotype for the problems
(http://shatten.sonores.de/wp-content/uploads/2009/07/dia_problems.PNG)

and here are the solutions
(http://shatten.sonores.de/wp-content/uploads/2009/07/dia_solutions.PNG)


I've done some puzzles with this method and I'm really starting to like it, since you can easily check if you're too linear or using one and the same stereotype over and over again.

What do you think? Maybe you guys are having an even better method to plan your puzzles...?



Btw: the probs and solutions are based on this article
http://einfall.blogspot.com/2006/04/adventure-game-design-patterns.html

Title: Re: Adventure UML: Diagrams for puzzle design
Post by: Layabout on Tue 21/07/2009 11:26:24
Yeah, basically what you are doing here is giving the illusion of non-linearity. Sorting puzzles into different problems and solutions is a really good way of doing things.

All games are linear. They follow the path the designer has preconcieved.
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: abstauber on Tue 21/07/2009 11:34:20
In that definition of the term of course ;)

Monkey Island e.g. leaves it up to you in which order you solve the three trials. But in the end you need to get off of Mêlée Islandâ,,¢.

So with non-linearity I sort of mean parallel puzzles.
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: Layabout on Tue 21/07/2009 13:17:27
I know :p

I'm just being nitpicky! :D
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: Mr Flibble on Tue 21/07/2009 21:01:40
Oooh, this is nice. I've been having trouble trying to diagram puzzles myself.

As for designing them what I've settled on is a list of "tasks" or "things the player could do". In isolation I'm fleshing each of these out, and then drawing links when I see them. For instance, I identify a puzzle that requires a knife so I make sure the player can acquire one in an earlier puzzle. Once I've fleshed the puzzles out I hope to link them in a logical order.

The game I'm writing is actually fairly non-linear and it's a bitch to plan.
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: Shane 'ProgZmax' Stevens on Wed 22/07/2009 06:33:29
I've been working on a game that is 60% sim like Little Computer People and 40% adventure game, which I've found very interesting and liberating so far.  Basically, while you have direct control via the arrow keys (or wasd) of the protagonist you also handle minor day-to-day issues like using the bathroom, eating, and making money, all the while interacting with your pet (you can feed and take it with you places) and indulging in adventures, either alone or with the protagonist's friends.  The way I approached the non-linear design was basically to pick a specific gameplay sequence that appealed and completely design it as a separate, self-contained 'adventure'.  For instance, there's a Halloween adventure in the game that you can unlock that is a complete adventure on its own, so I made a separate script file for it and designed it separately from the rest of the game, requiring NO items beforehand (although certain carried-over items can make things easier).

Someday I will complete this game! ._.
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: Mr Flibble on Wed 22/07/2009 07:42:06
An AGS version of LCP makes me all smiley in my happy place, good luck with that! :D
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: abstauber on Wed 22/07/2009 08:23:57
So you're working more puzzle driven than story driven?

@ProgZmax: LCP mixed with adventure aspects would be very cool indeed. Do you also use this cute cut-in-half house view?
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: Llama Val on Wed 22/07/2009 12:11:37
What program do you use for making these diagrams?
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: abstauber on Wed 22/07/2009 12:29:52
Just plain old PowerPoint. But OpenOffice Impress could do the job too - although Visio might be the best (which I don't have)
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: ThreeOhFour on Wed 22/07/2009 12:37:32
Quote from: ProgZmax on Wed 22/07/2009 06:33:29
I've been working on a game that is 60% sim like Little Computer People and 40% adventure game, which I've found very interesting and liberating so far.  Basically, while you have direct control via the arrow keys (or wasd) of the protagonist you also handle minor day-to-day issues like using the bathroom, eating, and making money, all the while interacting with your pet (you can feed and take it with you places) and indulging in adventures, either alone or with the protagonist's friends.  The way I approached the non-linear design was basically to pick a specific gameplay sequence that appealed and completely design it as a separate, self-contained 'adventure'.  For instance, there's a Halloween adventure in the game that you can unlock that is a complete adventure on its own, so I made a separate script file for it and designed it separately from the rest of the game, requiring NO items beforehand (although certain carried-over items can make things easier).

Someday I will complete this game! ._.

Hooray! Boyd quest!  :D ??? ;D
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: Llama Val on Wed 22/07/2009 12:44:45
Ah, thanks. I've never used Impress (don't have Powerpoint), now to figure out how to use this program. :)
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: on Wed 22/07/2009 13:09:10
Glad to see my fumbly bloggings have... effects ;)

For some very interesting reads on game flow and mechanics to get it rolling, see here:
http://www.squidi.net/three/ (http://www.squidi.net/three/)
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: Galen on Wed 22/07/2009 23:20:06
Funnily enough the idea to split my current project into three main tasks came to me about a week or two ago. I like the idea but at the same time I was concerned that I might end up overloading players with objectives. My current thought is to make the third and final task only achieveable once the first two tasks have been completed; hopefully that will help to give the game some flow and making controlling the pacing easier.
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: Shane 'ProgZmax' Stevens on Thu 23/07/2009 03:32:39
The game actually began with a full house design like LCP but I decided to break things up into more traditional backgrounds so I could have more interactions and such.  I still like the idea of a split view of a house so I'll probably factor it into the game at some point, even if only as an homage.
Title: Re: Adventure UML: Diagrams for puzzle design
Post by: Stupot on Sun 26/07/2009 20:47:55
The game I'm designing involves 3 phases, the 1st of which is the initial exploratory phase, the 3rd is the final boss sequence, and the 2nd is the main bulk of the game which is basically 16 puzzles split into 4 branches of 4.

In phase 1, there will be 4 items. Each will be required for the first puzzle of each of the 4 branches.  The 4 puzzles in each branch will have to be done in a linear fashion, with the solving of each puzzle unleashing an item that will be needed to solve the next.  But with 4 such branches going on at the same time the player will, at any given moment,  have a number of puzzles on the go at the same time, hopefully giving the impression of non-linearity, while retaining some structure to the game.

If that doesnt make sense, here's a little ascii demonstration:


   Phase 1
      |        [exploration]
/   /   \   \  [find 4 items]
 
   Phase 2
|   |   |   |  [use items to solve first four puzzles]

|   |   |   |  [each puzzle gives the player a new
                item with which to solve the next]
|   |   |   |
   
|   |   |   |  [the last puzzles will give the player
                four more items which he will need to
   Phase 3      solve the final "boss" puzzle
\   \   /   /
      |
   B O S S