Article about creating good puzzles, GUIs, stories, etc.

[seguso]

Hi there!  8)

I have written a guide full of hints to write better puzzles, user interfaces, stories and graphics. Download here:

http://onefinger.sf.net/What-makes-a-good-adventure-game---by-seguso---english-3.0.pdf


I would like any feedback about it---suggestions for additions, or even grammar corrections. Especially, I would like to know if some ideas in the document cannot be implemented with AGS.  For example, how suited AGS is for:
- animated backgrounds (e.g. moving branches of trees)
- animated, rotating palettes
- NPC schedules
- Dialogues where the inventory remains on-screen
- building a GUI with a dynamic verb list, as specified in the pictures?

Thanks for anything!

PS: The latest version can always be found via eDonkey (e.g. with aMule.). keywords: adventure, seguso.

[Radiant]

Hi there,

it is a good article and you have put some nice effort into it. However, I have to point out that it suffers from tunnel vision. While the ways you suggest are certainly A way to write an adventure game, they are by no means the only means. And, considering most of us are amateurs working in spare time here, some of your suggestions go way too far for most games written here.

For instance,
You should not write an adventure game as if it were a book (or movie script). This is because books and movies are by definition linear, whereas good adventure games are not. Also the several stages you suggest in writing your game should be combined far more. You should not create a list of rooms or items afterwards, you should do it simultaneously with writing the main plot, because the two should influence one another.

I'm afraid I have to disagree with you on the entire verb issue. Contrary to what you say, most people do not actually prefer text parser games to point 'n click games, as proven by sales figures. Also, every text parser game I've played, can be solved with a basic set of verbs, say two dozen max. If you have to guess a specific verb that is only relevant in one particular puzzle, I'd state that was a poorly designed puzzle.
So, while having a large selection of verbs is nice (at least larger than Sierra's standard look/touch/talk), overdoing it leads 1) to more work for the programmer, as you don't want standard responses everywhere, and 2) be confusing to the user, making the game less playable. For each verb you should consider if it's sufficiently different from the other verbs, and if it's not, drop it.

Note also that most of the verb list can be removed by allowing the 'use item on ...' approach. Early lucasfilm games had verbs for 'unlock door with key' and 'fix staircase with tools'... but these are obvious applications for the USE verb. Unlock only makes sense when done with a key - but using a key only makes sense if you're unlocking something with it. So USE isn't that bad after all, as many objects only have one purpose.
Turn on, turn off, fix, put on, take off - all can be replaced by use. Similarly, attack can be replaced by 'use sword on'. Pick lock can be done with 'use lockpick on'. Etc.
There aren't that many verbs that have been meaningfully used in adventure games, that aren't one of "walk, take, push, pull, open, close, look, give, show, use, speak, ask, attack, duck, cast spell, drop, throw"

Your text seems to imply that games with insufficient verbs are just too easy. But this is not, after all, the case. Most people get temporarily stuck in just about any game, and many have to resort to hints or walkthroughs.

Contrary to what you say in 3.5, it should in fact be easy to reach the inventory items. This has to do with user-friendliness, and accessibility of your game. Because you'll be using them a lot, burying them three menus deep (as I've seen in some games) only serves to aggravate the user. They should be at most one click away (pop up inv screen, select item)

Page 19, for the record, The Seventh Guest is not actually an adventure game, so whatever you're saying about adventure games doesn't apply there. How exactly are you suggesting that your lateral thinking example is a good puzzle? A man comes up to you and asks for a glass of water, and the player is supposed to figure out to click his gun on him instead? The key to lateral thinking puzzles (and I know of dozens of them) is to not give the player sufficient information. Adventure games don't quite work that way.
(most lateral thinking puzzles are word games where the player has to figure out what on earth was happening, e.g. "a man passes an apartment building, hears a phone, screams and dies". That is lateral thinking)

Page 21. For contemporary games, I pose that 'getting stuck', aka dead ends, walking deads, or zombies, ARE an unnecessary evil, and the result of poor game design. It is frustrating for the player because the answer could be anywhere, and because they may have to replay a substantial part of the game.

Page 23. Graphics... I have never in fact seen a game in which 'every branch of a tree shakes in the wind'. While this would certainly immerse the player, it is far beyond the capacities of most programmers (and CPUs), and immersion can be achieved with considerably less than that. If 'every light is trembling', this might severely annoy the player.

Page 25, animating palettes... most contemporary games do not use palettes, but instead use 16-bit or higher color quality graphics

Page 27, games that teach you... educative software is really passe. This is also because there are very few eduware games that are actually worth it.

Finally, some other topics you may want to think of are
* full parser games, as opposed to 'type a verb and click on the item'
* pixel hunts
* word hunts (e.g. "put airsick bag in hair rejuvenator bottle")
* read the article on puzzle design on the AGS links page, it's very good
* puzzles that are too obscure
* commanding other characters (e.g. infocom games)

Good luck with it!

[GarageGothic]

Contrary to what you say, most people do not actually prefer text parser games to point 'n click games, as proven by sales figures.

I find it quite interesting actually, that the only reason Sierra gave up the parser interface was that there wasn't enough RAM available for it when also using VGA graphics. Although I agree that icon interfaces probably are more accesible and therefore more popular, I do miss the benefits of a well written text interface. The original QFG1 and its VGA remake is one of the better examples. For dialog in particular, a parser interface puts a lot more responsibility on the player, because you actually have to figure out the topics rather yourself rather than just going through the motions.
I don't think its an accident that the same games that introduced icon interfaces also introduced some of the weirdest puzzle solutions - because anything else would be too easy to solve randomly. Although Infocom also had some *ahem* "humorous" puzzle solutions in their text games, I really doubt they'd have had us hypnotize any monkeys to use as plumbing tools.

[seguso]

Hi Radiant, Thanks for your reply. Here is mine.

I'm afraid I have to disagree with you on the entire verb issue. Contrary to what you say, most people do not actually prefer text parser games to point 'n click games,

I never said that. 

Also, every text parser game I've played, can be solved with a basic set of verbs, say two dozen max. If you have to guess a specific verb that is only relevant in one particular puzzle, I'd state that was a poorly designed puzzle.

Wait. It's the opposite.  8) If a verb is used only once, it's because it's unusual. But good puzzles are those that make you do unusual things. So we should actually strive to find verbs that are needed only once.

In other words: a good puzzle often requires an action that is not common. Uncommon actions usually can only be expressed with uncommon verbs. (e.g. "shake bottle", "inspire balloon"). If you rule out uncommon verbs, you rule out some good puzzles.

Note also that most of the verb list can be removed by allowing the 'use item on ...' approach.

I dedicated a chapter to the problems of the "use" verb...

Early lucasfilm games had verbs for 'unlock door with key' and 'fix staircase with tools'... but these are obvious applications for the USE verb. Unlock only makes sense when done with a key - but using a key only makes sense if you're unlocking something with it. So USE isn't that bad after all, as many objects only have one purpose.

And good puzzles are about objects that must be used with a different purpose than the usual one...

Turn on, turn off, fix, put on, take off - all can be replaced by use.

...and the game plays itself... and the only puzzles that remain are mostly the illogical ones....

Your text seems to imply that games with insufficient verbs are just too easy. But this is not, after all, the case. Most people get temporarily stuck in just about any game, and many have to resort to hints or walkthroughs.

Very often, this happens because the puzzles were illogical. And why were they illogical? Because logical ones would have been too easy with that interface.

Contrary to what you say in 3.5, it should in fact be easy to reach the inventory items. This has to do with user-friendliness, and accessibility of your game. Because you'll be using them a lot,

You shouldn't. Why should you be encouraged to combine items before thinking?

How exactly are you suggesting that your lateral thinking example is a good puzzle?

I was trying to explain the principle. Of course, THAT puzzle wouldn't be useful in a game, but this is irrelevant...

(most lateral thinking puzzles are word games where the player has to figure out what on earth was happening, e.g. "a man passes an apartment building, hears a phone, screams and dies". That is lateral thinking)

Well, no. A lateral thinking puzzle is one that can only be solved by giving up some assumptions (that you make unconsciously).

Page 23. Graphics... I have never in fact seen a game in which 'every branch of a tree shakes in the wind'.

If you had seen one, I wouldn't have written the document.

While this would certainly immerse the player, it is far beyond the capacities of most programmers (and CPUs), and immersion can be achieved with considerably less than that. If 'every light is trembling', this might severely annoy the player.

Ok, but 1. Monkey2 does that, and it doesn't annoy the player. 2. I spoke about the dangers of animations being intrusive.

Page 25, animating palettes... most contemporary games do not use palettes, but instead use 16-bit or higher color quality graphics

That's why I wrote the document. In the hope of reminding them they were forgetting something important.

Finally, some other topics you may want to think of are
* full parser games, as opposed to 'type a verb and click on the item'
* pixel hunts
* word hunts (e.g. "put airsick bag in hair rejuvenator bottle")
* read the article on puzzle design on the AGS links page, it's very good
* puzzles that are too obscure
* commanding other characters (e.g. infocom games)

Some of these topics were discusses. thanks for the other ones!

Have a good time!

[Radiant]

Okay, let's agree to disagree here. I understood most of your points, I just would never take that approach when desiging a game. But then I'd never create a verb coin either, and some very good games have been made with that approach.
But one thing,

And good puzzles are about objects that must be used with a different purpose than the usual one...

They may be, but there are also other ways of creating good puzzles. Also, using objects in unexpected ways is certainly possible in a classic P&C interface: in MM, you haev to open a radio to get a battery. In KQ2+, you use a cloth to store gems. In Freddy Pharkas, you combine four different inv items to make a gas mask. And no verb guessing involved!

However to GarageGothic, you're showing an example from Monkey Island II, and that isn't nearly a game that invented point-n-click control. The first LucasFilm P&C game was Maniac Mansion, and actually the puzzle design is very good there. Also the MI2 puzzle you mention is logical if you consider the term Monkey Wrench (at least, it had me goind 'oh, of course!!!' when I solved it). If you're saying that P&C games were a large cause of poor puzzle design, then I strongly disagree. For instance, let me point out some poor puzzles from pre-P&C games... the yeti in KQ3, the flight serice ladies in Larry 2, and the loads of dead ends in Codename Iceman are all rather illogical and poorly designed puzzles.

[SSH]

Also the MI2 puzzle you mention is logical if you consider the term Monkey Wrench (at least, it had me goind 'oh, of course!!!' when I solved it

Yeah, but in the UK english version of Monkey Island II, you have to look for an "adjustable" instead of a monkey

[Iago]

seguso, in your article you mentioned some "book of puzzles"...

well, I'm very lazy for designing puzzles, so does anybody know a book/list of puzzles?

So I can just get through the list and implement some of these.

Sure, it is boring and I'm a poor copycat but I don't mind if my puzzles are original or not, they just must be good and there.

4 example I found this puzzle to be universal:

You are locked in a room, the key is stuck in the keyhole of the opposite side of the door.

I order to get out you take a poster of the wall/ a leaf of the plant/...  and slide it a bit under the door. Then you beat against the door, so the key falls on the leaf/poster and then you draw the leaf back into the room and have the key!

So do you know any puzzle compilation?

[Radiant]

That's easy, just download a bunch of walkthroughs for adventure games, and take puzzles from them. This won't win you any prizes in the originality department, of course.

[seguso]

So do you know any puzzle compilation?

If you are too lazy to invent puzzles and/or story, this means you only want to program the game engine and/or do the graphics. But then, isn't it better to find someone who wants to write puzzles and story? I am first!

To answer your question, I only know Raymond Smullyan's logic puzzle books and Paul Sloane's lateral thinking books. But only 5% of the puzzles in each book could be useful in a game.

[veryweirdguy]

So do you know any puzzle compilation?

I haven't read through the whole topic (I'll look at your article another time), but whenever someone mentions something like this, I feel as if I have to point them towards:

THIS

and

THIS

[seguso]

So do you know any puzzle compilation?

I haven't read through the whole topic (I'll look at your article another time), but whenever someone mentions something like this, I feel as if I have to point them towards:

THIS

and

THIS

That's very very interesting. Thanks heap!  :

[Iago]

Thanks for all the replies. 

Seguso, I would appreciate it if somebody would help me with the puzzles! I already have an overall theme and a bit of story for the game and some graphics. Here is a sample:

http://space.arcor.de/willydumaz/

Since I am making it for art class I need to have finished the game in the middle of january. So there is some kind of time pressure.
But if you are still motivated to help me, then you are welcome! 

(I only have to ask my teacher if he accepts that kind of teamwork) 

[big brother]

I found the document interesting, though I am a bit confused as to its purpose. How can you write a guide to making adventure games if you have never made one yourself? I believe it's more typical to establish credibility in a field before you write rules about it.

[Rui 'Trovatore' Pires]

My 2 cents after having read - I'd just like to support Radiant in that what you suggest is A way, not THE way. You give several examples of no-nos that have been sucessfully used in some games, and yes-yes that can be quite frustrating. For instance, can you imagine Phantasmagoria with a 20% of INV being red herrings?

It seems to me you have tried to do something similar to Arostoteles' Poetic - look at 'em all, see what makes 'em tick, present a guide with your findings. I don't have a gripe with that, not at all, but there are a couple of problems:

1 - Artistoteles made a *guide*, not a rulebook, despite what later generations read in him. And it was extremely subjective. He thought hard about it until he found out what, in the existing tragedies, made the ultimate, the perfect tragedy, and presented his own findings, and he never said "This is THE way to do them"(because he was aware of the subjectiveness of his opinions).

2 - Such guides are possible only within a very limited set. What I mean is, he could do it sucessfully because there was only one gender in theater back then - tragedy. And it's true that there's only one genre called "adventure", but look at how different the games can be, have been and will be! From IF to KQ1 to KQ4 to KQ5 to Phantasmagoria to MM to MI1, 3 and 4, to Black Dahlia... it's simply not possible to make such definitive comments as the ones you make in your guide. There's too many kind of games out there, and there's *several* tried and true formulas, plus interfaces that worked well in a game but wouldn't work in another.

On the whole, though, it's an impressive looking document with an obvious amount of effort and dedication and hard thought put into it. Here's a suggestion though - it seems to me from your previous posts that you are determined to make your points and defend them against what other people think, if you can do so argumentatively. That's a great attitude, but it won't help your document, as such divergences of opinion prove that your document is right *for you*. If other people disagree... ok, so you can't please everyone, agreed, but if ENOUGH people disagree, your effort becomes nothing more than YOUR view on the subject, unlikely to help anyone. You should get other people's opinions, and edit your file from their opinions after giving them CAREFUL considerations (after wall, you're making a guide, not a survey! I know! ).

Ok, so it turned out to be more like my 10 cents, but what the hey, I'm feeling generous.

EDIT - One more example. You talked about lines such as "If this game creator weren't lazy", and such meta-game issues. I'll quote something from a review of Discworld 2.

The game is not entirely serious, and Rincewind has always funny comments like, "They can't kill me yet, the game has barely started," or, "What, no pointless puzzles and quests?" I like this kind of game much better than the type that pretends to be dead serious even if it's still only a game. Games should be fun!

Just to say that there's many, many different opinions, and nothing should be invalidated because everything has potential if well done.

[seguso]

I found the document interesting, though I am a bit confused as to its purpose. How can you write a guide to making adventure games if you have never made one yourself? I believe it's more typical to establish credibility in a field before you write rules about it.

This is going to sound rude, but it's not my intention. 8)

1. I prefer to judge people from what they say, not from who they are.


2. I haven't created an adventure game, but I have written stories and that's what I am giving suggestions about (mostly).

3. Even if I hadn't, I may still have a brain to point out what's wrong in some adventure games.

[Radiant]

Well, of course you are fully entitled to your own opinion, but BB does have a valid point that you don't seem to be writing from your own experience. It would presumably improve the effectiveness of the document if you were. You now state that you're actually talking (mostly) about stories, but your initial post and the document itself are about "better puzzles, user interfaces, stories and graphics."

Anyway. As to what AGS can do, which you asked about,
- animated backgrounds (e.g. moving branches of trees)
Easily done by either setting an object to animate in said location, or by creating multiple background frames (currently limited to five)

- animated, rotating palettes
Yes, there's a function to do just that, but do remember that palette rotation is a 256-color feature, and most contemporary games use 16-bit color.

- NPC schedules
Not entirely sure what you mean with that, but you can code just about anything in the scripting language, and there's a character control plug-in as well.

- Dialogues where the inventory remains on-screen
The standard dialog system doesn't support it (well, it could be on-screen, but you can't use it). However it is very feasible to create your own dialog system that does allow this

- building a GUI with a dynamic verb list, as specified in the pictures?
Tricky but possible. I would like to point out that you are unlikely to convince me (nor several other people on the forums here) about this issue until you create a (small) game that demonstrates this system.

The short answer to just about any question along the lines of "is foo possible in AGS" would be "yes".

I'm curious if you actually think that (most) adventure games are too easy, because that seems to be implied by your document.

[seguso]

For who is interested, I posted version 2.6 of the article, adding some more hints about puzzles, and fixing some logical mistake pointed out by readers.

http://onefinger.sf.net/What-makes-a-good-adventure-game---by-seguso---english-2.6.5.pdf


I would like to thank everyone for the useful feeback I received. Now it's time to actually do the game

[Radiant]

Well, I'd hate to be rude, but it seems to me that you ignored most of the feedback given to you by people in this thread. I believe that if you were to make a game as you explain in the text, people would critique on its lack of user-friendliness in the GUI department, on the cliches that you suggest as must-haves for a good story, and the strange gameplay that is created when you first write a story, then add puzzles, then add rooms and then add items, as you suggested.

As a long-time graphics programmer, I feel I must comment on the passage below, quoted from your text, because you really don't know what you're talking about.

Palette animation is even more important than ordinary animation. Imagine Monkey Island 2 (e.g. the woodsmith's cabin) or Indiana Jones 4, or even Ultima 7, without animated palettes: everything would seem “fake” and still. Palette animation is a must, at least for lights and water. Modern games don't use this technique anymore, because hicolor modes make it difficult for 2d games to dynamically change the color of objects in a non-uniform way; this is, in my humble opinion, a big deficiency that should be solved at any costâ€"even if this requires using the CPU for blitting sprites, instead of the hardware blitting capabilities of graphic cards.

First, 'true' animation (e.g. crashing waves) always looks better than 'palette' animation (i.e. rotating the colors of the sea). Ultima 7 actually does use crashing waves in true animation.
Second, what you say about hicolor modes is bogus, the fact of the matter is that a 16-bit (or more) color game does not have a palette, and therefore by definition can't cycle its palette.
Third, what you say about using the CPU for blitting sprites is more bogus. Blitting is just moving pixels around, and a graphics card can handle that, that's what it's there for. You seem to be confusing blitting with hardware-vs-software rendered polygons.
And finally, blitting has absolutely nothing to do with palette cycling. Palette cycling was used in older games to save on processor cycles, instead of using true animation. With comtemporary high-performance computers, true animation is the way to go, and luminescence could be used as an added bonus. Not the other way around.

[seguso]

Thank you Radiant. I don't mind the rudeness at all. I only care about concepts.

Well, I'd hate to be rude, but it seems to me that you ignored most of the feedback given to you by people in this thread. I believe that if you were to make a game as you explain in the text, people would critique on its lack of user-friendliness in the GUI department,

Indeed they would, but people don't always understand what's best for them, or why they don't like something. There are unexpected details that impress the subconscious only.  For example, they may not feel absorbed by the game but not realize the reason is that the lights are not animated.

Also, the interface I proposed is meant to be used as a last resort, only if you can't afford to renounce to some puzzles. And I stated that clearly. A thing you keep ignoring.

on the cliches that you suggest as must-haves for a good story,

Not at all. Please don't put things in my mouth I haven't said. Or cite a passage where I say they are must-have.

and the strange gameplay that is created when you first write a story, then add puzzles, then add rooms and then add items, as you suggested.

You keep ignoring it, but I clearly states that adding puzzles to a story is an iterative process, not sequential, in which you should start with the story, because stories that are born to justify puzzles rarely make good games.

As a long-time graphics programmer, I feel I must comment on the passage below, quoted from your text, because you really don't know what you're talking about.

Palette animation is even more important than ordinary animation. Imagine Monkey Island 2 (e.g. the woodsmith's cabin) or Indiana Jones 4, or even Ultima 7, without animated palettes: everything would seem “fake” and still. Palette animation is a must, at least for lights and water. Modern games don't use this technique anymore, because hicolor modes make it difficult for 2d games to dynamically change the color of objects in a non-uniform way; this is, in my humble opinion, a big deficiency that should be solved at any costâ€"even if this requires using the CPU for blitting sprites, instead of the hardware blitting capabilities of graphic cards.

First, 'true' animation (e.g. crashing waves) always looks better than 'palette' animation (i.e. rotating the colors of the sea).

Untrue. Color animation is the only way to animate lights.

Second, what you say about hicolor modes is bogus, the fact of the matter is that a 16-bit (or more) color game does not have a palette, and therefore by definition can't cycle its palette.

The only problem is that you can't read between the lines. When I say "palette animation" I mean "color animation", which doesn't imply a palettized graphic mode at all.

This is a slight imprecision (not an error) that I did unconsciously, so thanks for pointing it out. However, it was completely obvious what I meant, so your objection is only apparently appropriate. 

Third, what you say about using the CPU for blitting sprites is more bogus. Blitting is just moving pixels around, and a graphics card can handle that, that's what it's there for. You seem to be confusing blitting with hardware-vs-software rendered polygons.

Once again, I am not confusing anything.  I am proposing a very simple thing: since current cards cannot simulate palette animation in hicolor modes, write a software blitting procedure, which takes as input a sprite and a map of color multipliers, and then, while blitting the sprite, multiplies each pixel's color by the correspondent entry in the map. Voila', we get animated "palettes" in hicolor modes. And, of course, the slowdown of blitting 2d sprites via code is negligible with current computers.

And finally, blitting has absolutely nothing to do with palette cycling. Palette cycling was used in older games to save on processor cycles, instead of using true animation. With comtemporary high-performance computers, true animation is the way to go, and luminescence could be used as an added bonus. Not the other way around.

Blitting has to do with palette cycling. Since you cannot do palette cycling in hicolor modes, you have to rewrite the blitting function to simulate palette cycling. What's so difficult to understand here?

Again, thanks a lot. I appreciated your comments.

[big brother]

Don't get me worng, I think your article is good. I reacted more because I felt it took a very superior air. It seemed to criticize other games, while pushing forward a "right" way to do things.

I think it's fairly easy to generalize about how to design an adventure game, but the real challenge is when you put your own pen to the paper. You have to constantly make compromises between the story and the puzzles. As a result, some puzzles will be weaker than others, and may seem contrived. You can even find examples of that in the classic adventure games we all look up to.

If you do end up making your own full-length game, I think it will be interesting to see how the experience changes your opinion about the "guide" you wrote. Not to be overly harsh, but right now, you sound like a virgin giving advice on good sex.