Application of Puzzle Theory
Written by Scarpia, (c) 2003
Good puzzles alone do not make a great adventure game. Essentially, it is all about plot consistency, puzzle integration, well-developed character personalities, and plenty of humour. But forget all that for a second, and Let's Talk PUZZLES!
Why this article?
I'm still fairly new to the independent game developer community, but adventure game puzzles have been a strong passion of mine ever since my 'first encounters' with them in Beneath A Steel Sky way back in '94. Anyways, after having lurked around in the community for a while, it has surprised me how little this topic is actually being discussed.
I went on to frantically Googling the web for "adventure game puzzles", "puzzle design", "puzzle theory" and the like, but -- to my astonishment -- the material available on the topic is limited to Esseb's old topic from the DOSUser boards, an article by Blake Speers from the AGDZine (which went 404 on me, too!) and one, ONE!, actual structured article from 1997 on the topic of puzzle design, by Bob Bates of Legend Entertainment.
Well - that's not entirely true. I did also find a short article by Johnathan Partington somewhere, and another one on GamaSutra, and a few more; but these are hardly worthwhile from a game designer's point of view.
Now, although there are literally dozens of amateur adventure games currently in the works, using engines like AGS, AGAST, WME or SLUDGE, the one thing amateur designers still aren't discussing, is how to make good puzzles.... which, in the eyes of someone like me, is a pity beyond belief.
Theory vs. Practice
I'm not here to re-invent the wheel, though. Go read Bob Bates' article on Puzzle Theory if you haven't already done so. C'mon, go there. Go! Now!
Good. Every adventure game developer should know the basics of puzzle theory. However, my intent is another. I want to dig in a little deeper, into the practice and application of puzzle theory. To me, at least, this calls for a different angle. When designing puzzles, I need to distinguish between different kinds (or 'implementations') of "sequence puzzles", for example, whereas it does not make sense to consider "ordinary use of an object in the way it was obviously designed" a puzzle, at least not by itself.
In a practical approach, we must categorize puzzles not by similar goals, but by the types of actions that a player must perform in order to solve them. To clarify: I wanted my classification of puzzle types to reflect that two subsequent puzzles of the same type will make the player feel like he's doing the same all over again, only in a different context. With two subsequent puzzles of different types, the player will get a more rewarding and diverse experience.
Applied Puzzle Types
Quid Pro Quo / Exchange Puzzles. The most basic of all puzzles, from an implementer's point of view. The objective is for the player to get a certain item, and in order to get it, he will have to give up something else, be it from his inventory, or something he must first acquire.
(Often, the item you need belongs to an NPC who will give you a clue as to what he is willing to trade it for. All there is to the switch itself, is then trading one object for another by finding the item he wants and giving it to him, and in return, he will give you the item you need.)
The other typical kind of QPQ puzzle is the Indiana Jones switch, in which you must use an object with the item you need, in effect switching the two, to get the item you need. Strictly speaking, the objects do not always 'switch', but after getting item B, you will no longer have item A in your inventory.
Be aware that badly-designed QPQ puzzles become boring in no time, and that many (if not most) amateur adventure games suffer from an excessive use of them. If half (or more, eek) of your puzzles are QPQ puzzles, your game play is likely to bore the players. To make a QPQ puzzle more interesting, a game designer can use a number of techniques:
- Make the clues from the NPC as vague as possible without spoiling the puzzle altogether. "Oh no, my dress is all torn up.." is vague, and opens up to a variety of solutions. In short, the obstacle is merely presented to the player. "My dress needs mending. Could you find me a pair of tailor's scissors?" not only reveals the complete obstacle, it also tells the player exactly how to complete the puzzle. The 'how' should always be left to the player, and this is accomplished by being vague. On the other hand, do not make your 'how'-clues too ambiguous, or you may lead the player completely and helplessly off track. Always leave good hints.
- When it comes to the items themselves, don't be too obvious either. If the NPC (vaguely) asks for an orange, don't just leave an orange lying around in the next room. You could instead (and I'm just brainstorming here) have a sarcastic bartender NPC, who, earlier in the game, had been refusing to serve anything but orange juice to a wimpy looking character in the corner of the inn, and make it possible (through subtle hints) for the player to recall this incident, go back to the inn, get the glass of orange juice, and complete the exchange.
- Use QPQ puzzles in combination with other puzzle types to make more unique puzzle structures. Don't make it too easy for the player to get the item for the exchange - use an additional puzzle here, or two, or five, or whatever - as long as you always remember to switch between different puzzle types.
Inventory / Combination Puzzles. Rarely a puzzle in itself, but it deserves mentioning nevertheless. It isn't easy for a game designer to pull off a good inventory puzzle, since the combination of items must be somehow logical without being too obvious (of the gun-bullet or flashlight-batteries type) or too arbitrary, which will throw the player into use-everything-with-everything hell. The balance is best achieved, I think, through good beta testing. Whenever a beta tester attempts a combination of objects, that should signify some kind of logic connection between those objects, even if the game designer didn't think of it.
If you know beforehand that the player is likely to try a certain combination which isn't the right one, the least you can do is reward him with some kind of witty comment when he does. After all, cracking that use-violin-with-bible combo takes a pretty awesome imagination.. Okay, so it may be completely and utterly wrong, but at least let him know you're *way* ahead of him..
The best way to balance your inventory puzzles is using the object descriptions to leave hints about their possible future use. Always do this.
Always reward the player
Solving a puzzle, especially a hard one, should always be rewarded!! But what can you give him? How about this:
These are exciting for the player to watch, and every time you reward him with one of these for solving a puzzle, he'll want to solve the next one more.
- A funny or surprising dialogue (very small reward)
- A unique character animation (small reward)
- Access to a new location (small/medium reward)
- Access to a new area of locations (medium/big reward)
- A cutscene (medium/big reward)
- Access to a new player character (big reward)
Dave Gilbert pointed out that a funny or surprising dialogue can also be used as a reward, and I agree completely. But unless the dialogue is wrapped in a cutscene, it is a very small reward compared to the others, even if it's really funny. When I break out a new amateur adventure game, I expect humour but hope for animations. Nuff said.
Timing Puzzles. Very possibly the most underestimated puzzle type of all. It is almost never seen in amateur adventure games, mostly because it takes some less-than-trivial scripting. To me, timing puzzles are often what makes an adventure game come to life.
My definition of a timing puzzle differs from that of "an action that will not yield an instant effect, but instead will cause something to happen at a particular point in the future", as formulated by Bob Bates. If you ask me, that definition would fit half the puzzles in Beneath a Steel Sky or Day of The Tentacle. If a puzzle is well integrated in the game plot, it will invariably trigger some kind of effect later on in the game, no matter what kind of puzzle it is. Instead, I define a timing puzzle as a puzzle that has an actual timer, like an invisible stopwatch, and in which the player must take specific action between time A and time B for his action to succeed.
Example [spoiler]: Monkey Island 1 & 2 had wonderful timing puzzles: Grabbing the cartographer's monocle at the right time; walking into the kitchen of the Scumm Bar when the cook was out of sight; the spitting contest puzzle (my favourite adventure game puzzle of all time) had no less than two great timing puzzles, etc. [/spoiler]
I could go on like this, but what's special about timing puzzles is that they can be amazingly simple and logical, all the while being surprisingly rewarding to solve. Ditch half a dozen QPQ puzzles for one or two timing puzzles, and watch that game come to life before your eyes.
Distract-n-Grab Puzzles. Another real classic, but this one is much more rewarding than the plain old QPQ puzzle. Sometimes the distraction part includes a timing element of some sort (kicking it up a notch), but lots of DnG puzzles keeps the NPC busy until the player has grabbed what he needs.
Too many DnG puzzles in one game might feel awkward, but so would an amateur adventure game without them ;)
Examples [spoiler]: the infamous "three-headed-monkey" trick; Getting rid of the 'Woodchuck' in Monkey Island II, the General and his secretary in Broken Sword II, or the mechanic in the beginning of Beneath a Steel Sky. [/spoiler]
Maze Puzzles. Mazes are so cliché. Fortunately, it is not terribly easy to create a maze puzzle, or I'm sure there'd be one in every amateur adventure game out there, one more heinous than the other. Poorly designed mazes are absolute game killers, whereas really good mazes are just slightly annoying. Okay, I'm sure there are lots of people who actually enjoy working through mazes, but unless your maze design is really good, even they will get frustrated long before they get it right.
Most mazes in commercial adventure games will provide good in-game hints, such as clues, maps, parrots, dancing lesson charts, ways of leaving a trail behind, etc. Why? Because walking into a maze blind is bound to get you stuck. That's the original idea of any maze, of course: to get you stuck so you won't find the secret on the other side! "But my maze isn't *that* hard", I hear you saying. But if it's really that easy, why is it there in the first place? Did the villains of your story think that only really dumb people would enter their labyrinth? Or are you basically just wasting the player's time? Is a maze really necessary? Does it make sense to even have a maze in the context of your game's plot? Think about it for a while, before you decide to script that maze.
To summarize: If you want to include a maze, fine. Just remember this: In-game hints. In-game hints! IN-GAME HINTS!
Aim to integrate puzzles and plot
Whenever the player acts in your world, the world should react to the change. Avoid having too many puzzles that don't affect anything other than the immediate state of an object / location. Instead, have the player's solutions affect other characters, the scenery, or (my favourite) the primary plot. This helps make the game seem much more non-linear.
Imagine that the solution to one puzzle later turns out to present an obstacle for the player, that is, another puzzle? E.g. the player needs to pass a huge boulder, so he pushes it over the cliff's edge. Later, at the bottom of the cliff, he finally arrives at the cave holding the big treasure, only to find the boulder from earlier landed exactly there, blocking the entrance.. You'll get the picture.
Great example: Beneath a Steel Sky does this a lot.
Escape Puzzles. Oh no - our hero is locked up in chains on the floor of a tiny prison cell, and the prison is engulfed in flames. All he has left is a dry bone, a hungry rat and five thousand rubber bands. Now what?
Escape puzzles are fun because we know the answer lies right in front of us, but we just can't see it. There is no risk of frustration due to walking between locations, talking to the same characters over again, etc., since the solution is obviously there in that one location. This basically allows for more difficult puzzles, e.g. in the form of intricate logic sequence or device puzzles. But don't overdo it - spending too long in the same room, stuck with an escape puzzle in the same room, trying different approaches in the same room, listening to the same music over and over again, in the same room!!!! - will eventually get tedious, or worse.
Again, it's all about being unconventional when supplying the player with inventory items. And remember - even prison cells have more exits than one. Make the player wonder whether he's supposed to dig his way out, bend the bars in the window, or reach the keys on the table beside the sleeping guard. Guards in movies and adventure games sure seem to sleep a lot on the job, don't they? ;)
Disguise Puzzles. Sometimes, you need to look different in order to get inside a certain place, and you will need a disguise. Some games take the easy way out and supply a costume shop, complete with wacky shopkeeper and everything, while others require you to make your own nose, wig or peg leg from the items you can find. Both approaches can be hilarious.
These are rarely seen in amateur adventure games, probably in part because they require additional character art, sometimes even extra animation. But animations are not merely superfluous, time-consuming eye candy, although I'm sure many amateur game designers wish they were. I believe lots of animations are necessary for an adventure game to be good. The graphics don't have to be great, but if there are no extra animations, the game will always have that 'static' feel to it that many amateur adventure games have.
Cryptogram Puzzles I hate these. In real life, I enjoy a challenging cryptogram as much as the next man, but in adventure games, cryptograms have always been pathetically, painfully, monumentally crappy. Probably because any half-decent cryptogram would throw off 60% of the core players then and there, and few game designers are willing to take that risk. I know I'm not.
With that rant out of my system, I can go on with the description. Cryptogram puzzles are basically just encoded text messages written with either letters or symbols / numbers that represent letters. Now, in order to decipher the cryptogram (thus making it readable), one needs some sort of 'key'. Most adventure games use trivial ciphers such as ROT13 (which 'rotates' the individual letters alphabetically by 13 places) in order to keep the difficulty level down, and, on top of that, they add in-game clues to make sure even the last 15% will get it right without too much frustration. I suggest you do the same if you choose to include a cryptogram puzzle in your game.
Epic plot structure
Game plots should follow the same basic rules of story-telling that movies or books do. These epic principles have been refined for centuries, and only fools do not abide by them:
- Use the first few puzzles mainly to introduce and establish characters, locations and the basic plot outline.
- Spend a lot of effort developing the core characters, and make sure the player sympathizes with and cares about the protagonist.
- Build up tension throughout the game, reaching a climax at the final endgame puzzle.
- If you are making a large game, try to divide the plot into a couple of logical "chapters", each following these epic principles.
Memory-based Sequence Puzzles. Most puzzles consist of a sequence of events leading up to the solution in one way or another. What distinguishes this category of puzzles, is that the puzzle basically relies on the player to remember and recreate a sequence of steps or actions. [spoiler] Like the safe combination in Monkey Island I: At one point, you watch the shop manager open the safe with a combination of push/pull actions, and when he leaves, you must perform the same sequence to open the safe. [/spoiler]
Memory-based sequence puzzles are quite satisfying, because they are naturally split in four separate, consistent parts:
- Observing the sequence (often this part is a small puzzle in itself)
- Figuring out you'll need this information, possibly checking the sequence again
- Memorizing the sequence (or writing it down)
- Recreating the sequence from memory
Logic Sequence / Device Puzzles. These are puzzles that constitute some sort of mechanical-causal relationship between the events leading up to the final solution. There are many different kinds of classic device puzzles, like the rig-a-trap puzzle, the excluded-middle / preparing-the-way puzzle as explained by Bob Bates, or the machine puzzle, in which the player must figure out how to operate a machine in order to complete the puzzle.
Logic sequence puzzles must be logical; the more steps you add to the sequence, the more difficult it gets; and this makes it crucial that each step is as unambiguous as possible to the player.
As a side-note, have you ever completed a logic sequence puzzle in a commercial adventure game, and not gotten a funny little animation when it finally worked out - and possibly even when it failed? I think not. Always reward the player with something after solving a hard puzzle, and not with 'money' or 'points'. Players don't care about points. They don't play the game for the points. They play to see all the fun stuff. So make sure you give 'em some.
I believe I read about this somewhere, and it is certainly worth looking into. Some games have "smart clues", that is, clues that automatically appear if and when the player needs them. Imagine a puzzle that you know is hard, and you have added 4 different hints near the puzzle location, one of which is kinda unambiguous about the solution. You know from beta testing that 6 out of 10 will solve it without the final clue (and they generally tell you that the fourth clue makes it too obvious). The rest, 4 out of 10, will not solve the puzzle without it.
To make this clue 'smart', write a script that checks the player's actions on this stage of the game: if he has found the three (more vague) hints, and still doesn't solve the puzzle within a certain time limit, the extra clue is placed where the player is likely to find it.
Now that's a smart clue.
Repeated-Action Puzzles. A simple yet highly adaptable puzzle type is the repeated-action puzzle. The Reality-on-the-Norm game Purity of the Surf uses this in a very humorous way: [spoiler] the main character being a surfer dude, walks around barefoot. When he enters the Italian restaurant, Chef Lucca comes out from the kitchen, yelling at him to get out. Entering again, the Chef once again comes running, this time yelling even more (and it is a different dialogue this time, hint hint..). After returning a few more times like this, you have finally made the Chef so angry that he tosses a fish at you, which you, conveniently, need for another puzzle. [/spoiler]
Oh, and as Esseb kindly reminded me, repeated-action puzzles will easily get players stuck, unless the player is likely to attempt the action again. Using the action of entering a location is fine, since you always walk everywhere when you're stuck, but interacting with a squirrel is hardly something you'd try if it failed the first time.
Dialogue Puzzles. With dialogue puzzles, you attempt to choose the right path through a conversation, saying the right things or asking the right questions, in order to accomplish something, get a piece of information, get a hint, etc. If you choose the wrong path, you can always just try again, but that will take a while.
If the puzzle is too complex, or the dialogue isn't humorous, the player will soon stop reading the dialogue and just click frantically through different choices until he's explored all the possible combinations of the dialogue tree. This kind of 'puzzle' should be avoided unless there is good reason to use it (I suppose certain types of detective stories would use them, for interrogation sequences etc.).
As the following examples show, a dialogue puzzle can actually be quite funny, provided that: 1) it shouldn't be too complex; 2) it should be obvious that there is a puzzle; and 3) there should not be a lot of these in one game. Pointed out to me by Creed Malay, here are a few good dialogue puzzles:
- Manny trying to talk the security girl into giving him her metal detector in Grim Fandango
- Guybrush convincing Elaine that he's in love with her in Monkey Island II
- The V.K. test in Blade Runner
- And perhaps the finest dialogue puzzle of all: Insult Sword Fighting, also Monkey Island II
Forced Dialogue Puzzles. Many game developers refrain from using these, because they tend to become a nuisance to the players (Bad Marketing Strategies 101). The basic idea is this: in order to get the response you need (and solve the puzzle), you must choose the right path through the conversation with one or more NPC's. If you get it wrong, you will have to restore a saved game or you're stuck.
Naturally, you may provide a forced dialogue puzzle merely as an alternative, allowing the puzzle to be solved in a different manner even if the dialogue puzzle fails. In my opinion, this is the best way to avoid frustrating the player unnecessarily by forcing him to go through Restore Game-purgatory every time he makes a wrong choice. Some games have an auto-restore function which allows you to automatically return to before you made the wrong choice, but that's for rare events like deaths. With frequent events like these, auto-restoring would become rather annoying too.
We all know we shouldn't do the same puzzle twice in a game. The player will find it tedious the second time around. However, in Monkey Island II, that's exactly what the designers did with the "Voodoo Doll" puzzle. [spoiler] The fortune teller woman handed you the recipe for the first doll, and later on in the game, you received subtle hints that you would need to make another voodoo doll. You then had to recall what items you needed for the doll and find them, only this time, some of the items from earlier were no longer available, so you had to improvise, which turned out to be a very amusing puzzle. [/spoiler]
Credits for this one to Cerulean
Riddles and Logic Puzzles. Bob Bates claims this is one of the least satisfying puzzle types, since "if the player doesn't get it, he just doesn't get it". This may be true to a point, but the same could easily be said for many other puzzle types. I believe riddles, when used with caution, can add greatly to the atmosphere of an adventure game, and certainly to the personality of the character presenting the riddle. Same goes for logic puzzles.
An example of a good logic puzzle is the 'how many fingers'-code on Phratt Island in Monkey Island II. If you didn't get it, you could keep trying until you got it right, or figure it out by yourself. I believe there was an in-game hint somewhere, too, but I don't remember exactly where.
With riddles as well as logic puzzles, always leave hints or provide alternative solutions. That way, chances are the player will - eventually - 'get it'.
GUI / Board Puzzles. Probably the most script-heavy puzzle type, and often, it is not worth the effort. There are thousands of classic board games, from chess to tic-tac-toe, all of which could be adapted as puzzles in an adventure game. This, however, is not always trivial, as you will likely need to create a new GUI for the game, as well as do some scripting for the 'game' to have a realistic look-and-feel.
Some puzzles, such as certain machine puzzles, cryptogram puzzles and others, often use separates GUIs as well, which certainly justifies their use, but board game puzzles are hard to fit into a plot in any reasonable way, and should be used only when there is a tight connection between that specific game and the main characters of your plot.
With that said, alternating interfaces can make a game look much more professional, given that their use is justified. A good example is in Pleurghburg: Dark Ages, in which several additional GUI's are nicely integrated into the story: a computer interface, a top-down view of a building, a wall-mounted elevator panel, etc. Sure, none of those are used as puzzles, but they add to the game play without seeming out-of-place, and that's what you'll want with your GUI puzzles as well.
Dead Ends, Red Herrings and Faux Puzzles. Dead ends are inevitable in adventure games, whether we as designers aim to put them there or not. Unless our puzzles are ridiculously easy, the player will get stuck in one or more of them. Sometimes, especially with poorly designed puzzles, the player will be clueless when faced with the obstacle, but most of the time, he will have several logical and / or obvious solutions to try out; then he will move on to a couple of more imaginative ones, before getting stuck trying out irrational combinations, more or less at random.
When this happens, the good adventure games don't abandon the player altogether. They supply parallel puzzles to be solved. While stuck in one puzzle, the player can move on with another puzzle elsewhere, instead of getting frustrated by the fact that he's stuck. Most amateur adventure games are very linear, leaving the player with only one puzzle to solve at any time, and are thus more prone to player frustration.
When non-linearity (parallel puzzles) is done elegantly, the player won't even notice that he was stuck; after all, "it could be part of the plot that you have to finish *these* two puzzles before you can move on with the other one." As long as you succeed in maintaining this illusion, the players won't mind being stuck in the first place.
Remember however, not to create side-stories which are separate from the main plot, or your game will fall apart. Two, or even three, simultaneous puzzles or 'goals' are fine, but if two of them are obstacles on your way to rescue a princess, and the third is stealing an egg from a bird's nest, then you better make damn sure the player knows exactly why he'll need that egg later on, or he simply won't bother (well, most players will, but only because they see the bird's nest and go "This is probably a puzzle. I should solve this and see what I get." -- which is just idiotic, if you ask me).
The "faux puzzle" is when you intentionally design a dead end, to let the players know they're on the wrong track (or just to mess with them a bit). Sometimes you'll want to create one after a beta-testing phase when several of the testers were stuck trying fruitlessly to solve a certain puzzle in the same - wrong - way. And at other times, you just want to be mean and place a hammer in a place where the player can't reach it, just when his current puzzle is to break something. Oh, don't do that; that's just cruel. Heh.
Actually, adding a faux puzzle can be an interesting twist to an otherwise dull puzzle. In the hammer example from before, allow the player to reach the hammer (with a little luck and perhaps a simple inventory combination), but then let the hammer turn out to be a useless rubber hammer, or make it break or something, indicating that the puzzle has to be solved differently.
Classics & Inspiration
- Multiple solutions to one puzzle increase realism. Like, cutting a rope can be accomplished both using a rusty sword, a shard of glass, or a pair of scissors.
- 'Caught in the dark' puzzles, where you wind up in a dark place and must find a way to shed some light. They take very little drawing / animating, and are a nice gimmick in any game. Don't put too many in one game, though.
- Partially deaf NPC's. If you want a character to come off especially annoying and cliché, make him / her partially deaf.
- Who decided that players could only Use, Pick Up, Talk To, etc.? Why not have a dog as player character: Eat, Smell, Bark At, Poop, Pee.. or a mean biker: Break, Hurt, Kick, Yell At..?
- Remember the ship's horn in Monkey Island II? Blowing it next to the blind lookout man would make the guy from the nearby spitting contest come running and talk to the old lookout geezer, which was pretty funny in itself. [spoiler] Later, you could use this knowledge in the "Spitting Contest" puzzle. [/spoiler] Making a funny dialogue sequence made sure the player would remember this effect.
Example of an applied puzzle structure
Let's have a look at a puzzle I was playing around with, set in Reality-on-the-Norm, the main characters being a mean little kid named Moe, and his nervous sidekick, Wilbur. The goal of the puzzle is getting inside the kitchen of Chef Lucca's Italian restaurant (to steal the birthday cake Lucca is making for his naked brother Guido), and an additional goal of gaining access to the hospital morgue. Here goes:
When the kids enter the restaurant, they see Chef Lucca walking around and occasionally entering the kitchen. He is busy decorating the restaurant and servicing a single customer who is eating some kind of pasta dish and complaining that it has no parmesan. Talking to Lucca, the kids learn that he is making a delicious birthday cake out back. If they try to enter the kitchen while Lucca is in the restaurant, he will yell at them to keep out of there. If they enter while he's in the kitchen, he will throw them out (but they will get a quick peek of the cake on the table).
If they enter the kitchen like that a few times, the chef gets more and more angry, and finally tosses a mortar (not a bomb; the kitchen kind) at them (small reward: snimation), which they pick up. (Repeated-Action)
While Lucca is in the kitchen, the kids can steal the hammer and scissors he's using for the decorating. (Timing Puzzle)
Not far from the restaurant is the hospital. If the kids enter there and ask if they can get inside the morgue, a guard will tell them to leave. Enter again, and he will get angry at them, wave his gun around (he's under a lot of stress) and tell them if anyone walks through those doors within the next two minutes, they'll be seeing the morgue sooner than they think - hint, hint.. (small reward: animation) If they DO enter again within 2 minutes despite the guard's warning, he will shoot them dead. If they enter after the two minutes have passed, he will merely throw them out and repeat his threat. (Repeated-Action and Timing)
Back in town square, there is a closed fast-food place called Dominatrix' Pizza (or at least we think it's a fast food place - nobody knows for sure). Behind the window is a pill jar (Larry 1 reference, heh). The kids must use the hammer to smash the window (the brats!) and take the jar of pills (small reward: animation), but to get away with it, they must distract a character who's standing nearby. (Distract-n-Grab)
The jar of pills has a label on it that indicates danger. If Moe eats the pills, he will drop dead (I kill my characters a lot. I know it's bad, I just can't help it). If he makes Wilbur eat a couple (which is quite likely since Moe's a real jerk), poor Wilbur will start to vomit and look very pale for the rest of the game. The mortar must be used with the jar to grind the pills into a powdery substance. (Inventory / Combination Puzzle)
In the restaurant, the kids can now use the jar with the pasta dish (small reward: animation). The customer will think what they're sprinkling over his food is parmesan, and thank them as he starts to eat. (I could have made a Quid Pro Quo puzzle here as well, but I chose not to)
As the kids leave the restaurant, there is a cutscene (medium reward) with a 911 call from the restaurant.
The kids should now go back to the hospital and enter again, piss the guard off, and then go wait outside. Within seconds (that is, less than two minutes), Lucca arrives, carrying the unconscious customer (small reward: animation), and enters through the hospital doors. Two loud shots are heard, and a lot of cursing. (the funny sequence earlier makes the player remember the effect of entering the hospital)
Another 911 call cutscene (medium reward), and this time the police are alerted. The kids decide to get the hell out of there before the police show up.
After this, the kids can return to the restaurant, enter the kitchen and get their hands on the cake - not! The restaurant doors are locked. When the police have sealed off the hospital and brought the guard back to headquarters, the kids can enter the hospital again (using the scissors to cut the 'Police Line Do Not Cross' tape) and get inside the morgue (final reward: new location). Also, they will find the chef's bloody apron on the floor, with the key to the restaurant in its pocket. Voilá.
As you have probably noticed, I include quite a few animations in the minor puzzles. This is key, I think, if you want to keep the players interested. Also, I try to use different types of puzzles so the player doesn't get bored having to do the same over and over again. And finally, the player can enter the hospital at any time to discover the guard's bad temper, which makes the puzzle a little bit less linear (and of course, there are other puzzles to solve at the same time: something to do with the mayor, bribes and a large genetic research corporation, heh, cliché is good).