Mystery in London, and Incompetence as a Design Goal

Recently I tried Mystery in London, a search-for-lost-objects game. I’m not sure what possessed me to do this; possibly it was the pretty screen shots, or possibly it was curiosity about what this genre involved.

Less than an hour of the demo was plenty to convince me that I do not like search-for-lost-objects games at all. You’re confronted by a cluttered screen with many items too visually indistinct to recognize, and asked to pick out a handful of items fitting the list at the bottom of the panel. This experience has all the joy and charm of looking for a lost set of keys. The environments are often at least a bit interesting, but they don’t really make sense — all sorts of random nonsense has been put into them in order to spice up the object search, so that a fancy grocery store may turn out to contain a fire hydrant, a couple of lizards, a rose hanging from the ceiling, and a water mark on the plaster that looks exactly like Abraham Lincoln. Suffice it to say that interpreting the objects around into a coherently designed world is not the point of the exercise.

I’m sure that someone does enjoy all that, just as someone or other faithfully bought all the Where’s Waldo books. So I’m not here to kick someone else’s preferred form of entertainment. What interested me particularly about the form of Mystery in London was the use of minigames; specifically, at one point, an old man at a pub challenges the player to a game of Reversi.

Now, there are lots of computer implementations of Reversi in which the computer plays to win. But I’ve never seen a computer Reversi as unstintingly bad as this one, blithely giving away corner spots, making no effort to get strong positions at the edge of the board, etc. In one game I got the computer to the point where it had run out of moves through sheer incompetence; that one was called a draw and we had to play again. The second time, I won 46-18. So it’s obvious that the designers didn’t want to pose a really serious skill challenge to the player, since that might be out of keeping with the difficulty level of the rest of the game.

What I’ve been thinking about since is whether this is a reasonable way to create small skill challenges where you don’t want the minigame to become too dominant a part of the whole play experience — namely, give the player an opponent who is fairly weak. IF occasionally has minigames of skill that are hard to win unless you figure out a trick and disable your opponent, but I think I’ve less frequently seen them where the opponent is simply mediocre at playing. Perhaps as a way to represent, say, combat, where randomization is such a dissatisfying approach in IF?

This would wind up being a fairly stylized, puzzle-y, un-narrative-like kind of play, I imagine. But maybe interesting. Or are there examples already out there that I don’t know about?

14 thoughts on “Mystery in London, and Incompetence as a Design Goal

  1. This sounds very similar to the “I Spy” games that my kids adore playing. I don’t have the patience for the games myself, but they enthrall my kids for hours…

  2. I suspect that such mini-games would quickly get very boring, especially if they come up often. If no skill is involved, they will feel like a gratuitous pacing device.

    There surely is an option between figuring out a trick to disable your opponent and playing against an opponent who doesn’t play well: play against an opponent who is competent. This will make the mini-game fun in its own right.

    Obviously, you will need some way of integrating the mini-game into the bigger game concept (either intra- or extra-diegetically); but you need to do that anyway if you don’t wish the mini-game to feel entirely gratuitous.

    (By the way, I do not see the tension between combat as a skill-based mini-game and randomised combat. Many skill-based games involve randomisation, and fictionalised combat–from Dungeon & Dragons to Axis & Allies–is no exception.)

  3. I don’t propose that they entail no skill, only that they not require a lot — maybe they look for the player to understand the basics of a skill game but not to have mastered it.

    My problem with randomized combat is not that it’s incompatible with skill-based games, but that it is terrible in IF, where the discrete move model and the ability to UNDO render it pointless or else force the author to resort to other tricks that annoy the player (turning off UNDO completely or selectively, or rigging the random number generator to be not quite truly random).

  4. I am reminded (embarrassingly enough) of a scene in ‘Blue Adept’ where Stile finds himself at a carnival set up by the evil Red Adept. He tosses a ball at a target, deliberately intending to miss… but hits the bulls-eye and wins a prize anyway. The trick, of course, is that the prize he wins is a booby trap.

    Done well, that could be a nice twist on the mini-game genre.

  5. Couldn’t the random number generator could be run ahead of when it was needed and the result stored for later use, rendering UNDO useless for rerolling the dice?

  6. Couldn’t the random number generator could be run ahead of when it was needed and the result stored for later use, rendering UNDO useless for rerolling the dice?

    That’s the kind of thing I meant by “rigging the random number generator”.

    Personally, I suspect I’d still find this kind of thing frustrating to play, even if it were done without crippling UNDO; at any rate, I can’t think of many IF games that I thought made a successful use of randomized combat.

  7. My problem with randomized combat is not that it’s incompatible with skill-based games, but that it is terrible in IF, where the discrete move model and the ability to UNDO render it pointless or else force the author to resort to other tricks that annoy the player (turning off UNDO completely or selectively, or rigging the random number generator to be not quite truly random).

    This is very interesting to me, since I’m working on a game that largely relies on random combat–although I would prefer to say that it relies on tactical combat which makes use of random number generation. (If you just speak of ‘random combat’, it might give the idea that the player has little or no influence over the outcome. Unfortunately, when combat was used in IF, it often has been this way; The Reliques of Tolti-Aph comes to mind.)

    It seems to me that both the discrete move model and the inability to undo are not peculiar to IF, but are instead features of a vast number of highly successful games built around combat. I already mentioned a pen & paper RPG, Dungeons and Dragon, and a tactical board game, Axis and Allies; I could as easily have mentioned computer games such as Baldur’s Gate. I see no real difference between these and IF as far as the possibility and desirability of combat with randomisation is concerned.

  8. Hm. Well, I’d be happy to be proven wrong about this, but so far I have yet to see such a thing done well. A greater tactical element would certainly help.

    I do think, though, that one important distinction between pen and paper RPGs and IF (re. inability to UNDO) is that with a human GM there’s less risk that you will inadvertently try something you didn’t mean to try. I’ve never really “accidentally” done an action in an RPG; if I mis-speak, which is relatively rare, there’s still a moment in which to take it back. In IF, though, I frequently mistype things, head east when I meant to go west, etc.; so there are cases where I want to UNDO not because I want to take back the random results of something but because the original command was never what I intended in the first place.

    It’s impossible for the parser to distinguish these two reasons for wanting to UNDO, so in IF stripping out UNDO means forcing the player to stick with any mistakes of guidance.

    This is of course something that also happens plenty in other computer games, but that doesn’t make it a good thing. One of my chief irritations with the otherwise excellent game Ayiti is that it frequently pops up dialogue boxes with the buttons overlapping important parts of the screen — so I’ll be trying to click somewhere, the box will suddenly appear, and I’ll wind up picking an option from the box that I didn’t mean to select at all. And there’s no way to take it back. This is maddening.

    Anyway, like I said, my judgment so far is largely based on the fact that all the attempts I’ve seen have been largely unsuccessful, in my opinion. I enjoyed Reliques, but it was a weird kind of enjoyment predicated on the knowledge that it was going to be completely unfair from start to finish… But I’ll be curious to see what you come up with.

  9. The mistyping thing is interesting; I hadn’t come up with it yet. I would think that the occasions where it would matter are relatively rare: (1) it almost have to be one-letter verbs, for it’s hard to mistype “take” as “look”; (2) the effect of the command typed is irreversible; (3) the effect of the command typed is non-trivially negative. These three will probably now happen together that often.

    But, this discussion allowed me to realise that I do not have to disable UNDO at all, for exactly the same reasons that I have not disabled SAVE. What is important, for both me and the player, is that Save/Restore and Undo are not the player’s best tactical options, for if they are, combat will become an incredibly boring exercise in waiting until the dice fall the right way up. Now, there are two ways to accomplish that: either you disable Save/Restore and Undo (altogether or in certain situations), or you associate a tactical cost with using them.

    I had already chosen the second option where it concerns Save. You can Save the game at any point, but it will cost you a certain amount of an in-game resource called Zeal. This resource is also used up by the player’s tactical skills (and is replenished by winning fights and by completing certain objectives). All I have to do as game designer is make sure that in general, using Save is not a better tactical option than using your other skills. This leaves it up to the player to decide on which particular occasions it is a better option–before doing something very dangerous, probably, or after accomplishing something that is very hard.

    I’ll probably do the same with Undo. If you can Undo whenever you wish, but it costs you a certain amount of Zeal, this means that (1) you cannot use it as the standard way to win combats, and therefore you do not have to use it that way, and therefore combat remains challenging and fun, but (2) whenever you really want to because something really bad happened, you can Undo anyway.

    By the way, do you know of any IF that has seriously tried to implement a tactical combat system?

    One of the reasons this is so exciting to me is that it allows me to have ‘gamey’ stuff in my IF without locking myself into the “puzzles that you have to solve in order to advance” paradigm. I hate puzzles like that. A tactical combat system both allows me to have, well, fun with tactics, but it also gives a whole new reward system unavailable to the regular IF author, which allows me to design puzzles that are optional and yet relevant for the game-aspect of the work.

    Let me try to explain that in a bit more detail. In most IF, there are only two kinds of rewards: advancement and final outcome. If I solve a puzzle, the author can either reward me by allowing me to advance further, giving me new possibilities of explorations and puzzle solving; or by changing the final state of the game, if I manage to solve it (the “optimal ending” thing). Both of these have drawbacks. The first gives you puzzles that MUST be solved, otherwise the player gets stuck. That’s fine for some, but I don’t really like it. The second makes a difference only at the end of the game, and its hard to implement many of them.

    But once I introduce tactical situations into my game, there is suddenly the possibility to award the player by tactical advantages. So, if he manages to solve the “let the iron grating fall down”-puzzle, he gets a tactical advantage in the fight against the robber baron, because it takes five turns for his guards to get through the grating. The player doesn’t have to solve the puzzle; it just makes it easier for him if he does. That’s how I love puzzles: you’re not stuck if you can’t solve them, but you do have a good “gamey” for trying.

    Anyway, lots of words, but its the results that count. ;)

  10. I’m not sure I’ve ever seen anything that implements combat in as much depth as you’re suggesting, and I am certainly curious to see what you’re doing with it. The idea of Zeal does sound like it could be a really cool mechanic.

    Re. mistyping: I bring it up because it happened to me *repeatedly* while I was testing Reliques. I very frequently swap east and west when navigating an IF map — most easily swapping E and W, but sometimes I even type them wrong in full, or swap northeast and northwest, or whatever. (I never have this problem with north and south. You’re welcome to supply your own cognitive explanation here.)

    Anyway, in Reliques it was possible to walk into a fight you weren’t ready for by doing this, or set off a trap even when you knew it was there, and this happened to me enough when I was testing the first part of the game for it to have made a Strong Impression.

  11. I have the exact same problem with east and west. Also, I often realise I’ve been mentally mapping east as left and west as right, rather than the normal (other) way around. I suppose up and down are simply more natural than left and right.

    Anyway, thanks to listening to what gradually turned into a description of my own WIP. :)

  12. Depending on how you implement your AI, it ought to be fairly easy to adjust the difficulty, such as by limiting the depth of an A* search, or by assigning higher weights to moves that you know are not worth it (for example, putting a higher weight on taking a pawn in chess, or weighting the taking of all pieces equally). I prefer the latter method when possible, for two reasons: it allows for characterization as part of the AI (ie: a child who just likes taking pieces), and lets you advise the player on strategies that often work.

  13. Pingback: It’s Not All Chocolate | Emily Short's Interactive Storytelling

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s