Adventure Gamers - Forums

You have to light a candle.

You try to use matches on it. “You can’t do that!” the game responds. The matches are apparently needed elsewhere.
You see a burning fireplace. Use candle on fireplace? “You can’t do that!” Oh well.
You happen to have a fireball spell ready. There we go, the candle lights up.

“It’s too windy in here, the match would be blown out instantly.” “You put the candle to the fire, but oddly enough it doesn’t light up, just glows a weird blue.”  That would’ve helped, it was a magical candle, apparently.

So - what’s the typical rule on hinting at a correct solution, or at least explaining why the attempted one was incorrect? When is too much too much? When, as a general rule, should players be nudged to correct their approach, and when should they be left to their own devices?

At this moment I’m thinking EVERY potential solution should ideally be commented on with some kind of “fail clue”: “that won’t work BECAUSE…”. I’ll gladly hear arguments supporting lack of those, though.

And what’s the proper gamescientific term for those? Surely there must be one…

Well, obviously the game should always explain why it’s rejecting a seemingly-valid solution. But more importantly it should accept all reasonably-sensible solutions. Arbitrarily rejecting logical solutions just because the game expects you to find the one thing the designer had in mind is awful design. If a designer can’t make a puzzle interesting and challenging without resorting to arbitrary, nonsensical restrictions, then maybe they should be doing something else.

Kurufinwe - 01 November 2013 08:37 AM

If a designer can’t make a puzzle interesting and challenging without resorting to arbitrary, nonsensical restrictions, then maybe they should be doing something else.

Nah, that much is obvious (riiiight…), I meant what if a puzzle DOES have its internal logic (in the example: we’re in a windy place and said candle is magical) and DOES have to have that one specific solution - I mean what about failed but theoretically reasonable attempts. Trying to push a key into a lock getting a “that is too big to fit in there” (double entendre not intended), that kind of deal. Should a player always be nudged towards the right solution (find a smaller key), or are there cases where that would be intentionally avoided?

(EDIT) Ah, right, you DID say “obviously, always” at the very beginning. My bad, I somehow missed that. So, no possible examples when that rule would intentionally NOT work?

I can’t think of an example when it’s a bad thing to explain why something won’t work.
You don’t have to hint at the right solution - just explain why the wrong one is wrong. “The match lights up and instantly blows out” just fairly describes what your character is seeing, without having the narrator tell you anything beyond that.
Personally one of the things I hate most is a non-informative “this doesn’t work”, especially if after figuring it out my solution was just as reasonable.

Bonus Strongbad link:

Yeah, I can’t think of a single case where it’s better to just say that it doesn’t work without saying why.

I mean, if the character doesn’t understand why it’s not working, it’s fine to say that, but he/she should acknowledge that it should work. For instance, in your candle example, if you try to use a match but the candle wick just refuses to catch fire (for some reason that the player has to figure out at some point), then the character should say something along the lines of “I don’t get it… Why is the wick not catching fire?!” But just throwing a canned “that doesn’t work” answer when the solution makes reasonable sense is never ok as far as I’m concerned.

It was pretty clear to me personally that either “every reasonable attempt should be explained” or even “should just work” is better than “doesn’t work”.

I was mainly wondering if there are any exceptions to that rule, before I go around waving my finger in front of professional game devs’ faces and calling them incompetent :> I’m feeling slightly more confident now ;P (And disappointed with quite a few titles…)

Also, repeating my question from the beginning - does a “failure clue” like that have a proper name/trope, or should “failure clue” or “failure explanation” be enough to convey it, so that I don’t have to use examples and pictures and a whole puppet theater when trying to explain the concept..?

Ailinon, the case against this is cost. You’d need someone to think through all the logical attempts, you’d need to write the script for the response and have the voice actors carry it out, you’d need to encode that extra dialog in the game binaries (less of a concern these days, but back then games had to fit a tight bit budget).

It also won’t address the case when the played intends “use X on Y” to mean one thing and the developer thinks it would mean something else.
Like let’s say I want to throw the clown nose to the juggling clown as an extra ball, but the developer thinks I mean to offer it to the character to wear - nothing short of natural language interface will be able to address that, and that’s impossible (sorry Jack. The underlying computational issues are a lot more difficult than you’d think).

Antrax - 02 November 2013 12:39 AM

Ailinon, the case against this is cost. You’d need someone to think through all the logical attempts, you’d need to write the script for the response and have the voice actors carry it out, you’d need to encode that extra dialog in the game binaries (less of a concern these days, but back then games had to fit a tight bit budget).

It also won’t address the case when the played intends “use X on Y” to mean one thing and the developer thinks it would mean something else.
Like let’s say I want to throw the clown nose to the juggling clown as an extra ball, but the developer thinks I mean to offer it to the character to wear - nothing short of natural language interface will be able to address that, and that’s impossible (sorry Jack. The underlying computational issues are a lot more difficult than you’d think).

That’s another argument for bringing back verbs (give, use, throw, taste) rather than the look/use we’re stuck with in most modern AGs. This also explains why “you can’t do that” seemed to be featured more predominantly in text adventures - having the most dynamic language means a lot more programming and it would have been impossible to account for every possible action the player could come up with. Which is also why I don’t think it’s such a great achievement for games like Edna & Harvey or Deponia to have a response for every click - there are far less possible actions than there were for Enchanter or Gateway or Space Quest IV.

How would you differentiate between the two using the standard verb interfaces? Which is “use” and which is “give”? Can you be sure all players will agree?

I think you would have to use smarter ways of getting around it. So taking the clown example, using the ball on the balls being juggled in the air would be “use” (throw) and using it on the clown himself would be “give”.

How would you differentiate throwing an object at someone and giving it to them? I don’t know if you can without more specific verbs. It’s one reason I don’t much like the system of pulling something out of your inventory and clicking it on things, I imagine myself as the game’s character pulling things out of my pocket and randomly shoving them into objects to see if anything happens. I know it’s often said that the dual “look/use” system offers streamlining and increased compatibility with consoles etc, but surely there’s a way to use the mouse and/or controller to give the player more control over HOW things are used? It would make inventory puzzles a LOT more interesting.

Zifnab - 02 November 2013 02:35 AM

I think you would have to use smarter ways of getting around it. So taking the clown example, using the ball on the balls being juggled in the air would be “use” (throw) and using it on the clown himself would be “give”.

This can be solved by offering verbs AFTER an item is somehow clicked on the object - or after the object itself is clicked, even. There’s no reason why a menu of verbs couldn’t show unique verbs for every occasion - “open/close” for a door, “push/pull” for a mandatory crate, “give/throw” for the clown’s nose used on the clown, “drink/stir/spill” on coffee, etc.

You mean like they did in Monkey Island 4? I can definitely see the benefit - give the player a choice of valid actions for interaction with each object, instead of a permanent set of verbs which might not work or lead to anything.

The disadvantage is the lazy thinking involved: you don’t have to do the narrowing down in your head. Can I push this box? Open it? That’s how it would work in real life, but a game eliminating those options, well, it takes out some of the fun/challenge. I like exploring my environment and even attempting to push a box and getting an “it doesn’t move” somehow adds something to my experience.