Messages

(duplicate)

Hi,

1) I like puzzles where some character has a routine that you need to disrupt. Maybe he depends on some object to do this routine. You can tamper with the object to disrupt his routine so he makes a mistake.

2) I like puzzles where you first have to talk with a character, but this does not solve a puzzle by itself: this only changes his mood, or his pose. And THEN you need to do something to him. (Indy4: talk to sophia to make her consider being the assisant of the knife thrower, then push her)


Cheers!

[abuse]

Hey Snarky,

First, I am glad to announce that I am opening a sourceforge project to build a free (GPL) engine and editor for 2d games. Like AGS, with some additional features:

- dynamic lighting algoritms for 2d scenes in hicolor modes.
- the verb-based interface I described in the docs
- works on linux too.

Second, version 3.0 of the document is out:
http://onefinger.sf.net/What-makes-a-good-adventure-game---by-seguso---english-3.0.pdf

I think seguso's document is interesting. It is not the final word on the matter by any stretch, but that may not be a bad thing. Some things he's right about, some things he's probably wrong about. When he is right, that's great. When he is wrong, others will point out the correct answer, and that's great too.

In any case, it is just one point of view, one way of doing things (or at least thinking about doing things). Yeah, I agree that the tone comes across as arrogant and pontificating, but that may be a language/cultural thing. My Italian friends are the same way. 

Please tell me where I sound pontificating. I also asked Radiant but he didn't reply.
The fact is, when you are not mother tongue, you tend not to see rude forms. You tend to oversimplify, write "must" instead of "had better", etc.

Hopefully, this too may serve a purpose, if it motivates others to articulate their alternative perspectives.

That's why I think it's so unfortunate that this discussion is starting to descend into a flamewar.

There hasn't been a lot of innovation in adventure game interfaces lately, and I for one am happy to see any fresh ideas. And to be honest, I think the proposed interface isn't half bad as an updated parser UI. It doesn't really do much to resolve the deeper problems with text interfaces, though, as highlighted by the hilarious statement: "there are usually only a few ways to express an action". 

It's true it's poorly phrased and superficial. I should have said "there are usually only a few verbs to express an action". Do you still not agree?

Still, I'd quite like to see a game that used this interface. (Or should I say another game? Anyone played LSL7?)

Some of the disagreements I had with the document...

Most of the reasoning is based on the assumption that players should approach the game as if it was real life, and that anything else is "cheating". To me, this is as absurd as insisting that people should be forced to play chess as if it was a real war.

True.
I modified the meta-reasoning part to better express why I believe this is cheating.
I also moved it to the beginning of the doc.

Adventure games are games, and they're meant to be fun. What's right for an adventure game is what makes it more entertaining and more interesting. Meta-reasoning is only bad when it leads to tedious try-everything-with-everything attempts to solve a puzzle, or makes everything just too easy.

The idea that games should be fun, which I'll call the Fun Principle (TM pending) also leads me to criticize the whole direction of the argument. Adventure game puzzles shouldn't be more like lateral thinking puzzles, because lateral thinking puzzles aren't fun.

That's because you are using a definition of "lateral thinking" that is not the official one. A lateral thinking puzzle is one you can only solve by giving up some assumptions. Not one where "the music stops, and the man dies".
Maybe I should state that more clearly in the doc...

OK, a small minority of enthusiasts think they're a great hoot, but for most people something like "The music stops, and a woman dies" is not a fun puzzle.

To the idea that animated backgrounds lead to increased immersion, which presumably leads to more FUN, I have to ask: Doesn't this imply that live-action movies should be more immersive than animated movies?

Not in my opinion. I only believe that there is a number X such that, if the animations in your game are less than X, immersion is prevented. I have no opinions over movies or games that have many animations. It may be that, after Y animations, there is no improvement.

After all, animated movies look fake, while live-action movies look very real (with shimmering lights and all). Yet I found The Lion King more immersive than, oh say The League of Extraordinary Gentlemen.

Also, the claim that by acknowledging that the game isn't real, players will be less involved in the game is pretty bold. Someone like Shakespeare filled his plays with sly references to the fact that they were mere theatre ("All the world's a stage..." etc.), and he's generally pretty well regarded. On the other hand, he put jokes into his tragedies, which clearly makes them LESS SAD, so what did he know?

I was warning against the abuse of such practice... I have changed the docs to better specify that. Thanks.

But I ramble... Let me conclude with this: Fitts's Law does not state that "buttons that are often used should be either very large, or located along the edge of the screen." It merely gives a formula for the time it takes to point at a target in terms of its size and distance. Specifically, MT = a + b log2(2A/W).

Another oversimplification I tend to do when writing in a hurry. Thanks.

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.

I hope the irony in that passage is not lost on you

There is no irony. Only someone who ignores someone else's arguments and tries to put him in riducule, providing no counter-arguments at all.

I now believe you are not looking for the truth, but only for some kind of personal satisfaction.

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.

Well, you may not have meant it that way, but your article does imply that your 'type-a-word-once' GUI is the one and only best way to create an adventure game.

Please tell me where. I am curious.

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.

Neither are puzzles born to justify the story, good puzzles.

1. Not necessarily, but least you have a chance. The other way your chances are way smaller.

2. I stated clearly that there are exceptions---another thing you ignore.

I would say that puzzles and story are two concurrent processes, rather than one iterative (which in this context is a synonym of sequential, by the way).

Radiant, your conscious attention can only focus on one task at once. You either think about the story, or about the puzzles. Not both at once. Therefore the word "iterative" it much more appropriate than "concurrent". (Of course I know your objection was only a provocation)

Your document has a clear outline of steps, one of which is story design, another of which is puzzles. That part of the document implies that you should do one after the other. If that's not what you meant, you should consider fixing it.

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

Not true. You can get a better flicker in true animation, because it's more versatile, and you can get better fire effects using particle engines. Try the fire plugin.

In the document I discuss color animation as a technique to create 2d backgrounds with animated, trembling lights (e.g. a still room with a couple of candles). In this context, your suggestion of creating an animation is completely inappropriate: the only things that need to change over time are the intensities and shades of the pixel colors.

Once again, I am not confusing anything.  I am proposing a very simple thing: since current cards cannot simulate palette animation in hicolor modes,

What you propose is nothing new, but you do have your terms mixed up

I never said it was new.
Also, I appreciate noticing that what you called "bogus" has now become "correct but not new".  Well, at least it's something!

Radiant, the only question here is: with whom are you fighting? And why?

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.

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

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.

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!  :

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.

I only know Paul Sloane's lateral thinking puzzle books, and Smullyan's pure logic puzzles books. Both are very amusing, however only 5% of the puzzles from each book would be usable in a game.

[because]

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!

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.