Facts of IF: Design Points

A while ago, I was going over the data I pulled from the Comp 09 scores and survey results.  I was interrupted in that — I moved, and then a lot of stuff happened — and I’m not sure when I’ll get back to it.

However, I will be creating a Comp 10 survey, which ought to close the holes in this one, and which I’ll have open from the beginning of the Comp.  It will be broken down by game, so judges can give targeted feedback on games as they play the Comp, if they want to.

Meantime, here are the overall conclusions I have so far drawn from the data:

  • Players like having the opportunity to fail. They don’t want to fail accidentally, but they want to be able to play the game “wrong” and to get the “bad” ending, as opposed to not being allowed to progress unless they do things right, and then be railroaded to the good ending.
  • Players who like a game like having an alternative ending. Making more than two ‘good’ endings is probably overkill.  Most players won’t see them, so it’s wasted development effort.
  • Players like having the opportunity to *escape* the game. This isn’t discussed much, but you’ll remember that Yon Astounding Castle had a “win” command. That was a little jokey, but as a game mechanic it was brilliant, because it allowed bored players to zip on through, get a minimally-acceptable ending (it closed what there was of the narrative), and therefore they didn’t resent the game.

— In my opinion, what’s happening is that the alternative ending and the escape mechanism allow the player to *pace* their involvement in the game. If they want to play longer, they can do that; if they want to stop, they can do that.

Please note that I’m *not* saying your game should include a “win” command.  There are many ways to do this, without going meta-.  For example, in Alabaster, you have the option to end the game by making The Big Decision at any time.  What keeps you from doing that is your desire to understand the situation — which is to say, to play the game.

  • Gauntlet structures are fine for most players (although I’m not wild about them), if the player has interesting things to explore within each node, and some latitude about what his next move will be.
  • Most players don’t like puzzles they can’t solve.  Every game has its own level of difficulty.  My general suggestion would be to make one killer-difficult puzzle with an easy alternative, and tie it in to one of the alternate endings.
  • The first thing your game should do is introduce the conflict (and hence the narrative). Give the player a narrative problem — a story that could end badly — immediately, and a little interactively, and then follow it with character, setting, all that good stuff.

I will add:  This is interpretive — I’m telling you my conclusions about what kind of game design does well in Comps.

(I was going to build up my case for each of these points, post by post, and leave everyone awed at my analytical ability; but instead, and especially since I have other priorities, I figured I’d get this out there for any of you who are designing games and looking for ideas.)

Published in: on January 13, 2010 at 6:34 pm  Comments (3)  
Tags: , ,

The URI to TrackBack this entry is: https://onewetsneaker.wordpress.com/2010/01/13/facts-of-if-design-points/trackback/

RSS feed for comments on this post.

3 CommentsLeave a comment

  1. This is all interesting stuff, but my anecdotal experience suggests that different players sometimes like very different things, so that any generalizations about what players like need to be read with that in mind. Even a generalization like “Most players don’t like puzzles they can’t solve”, plausible though it looks, skates over the problem that players can often have very different perceptions of the difficulty of the same puzzle.

    You may also need to take into account that what players like or dislike may depend on the kind of game they’re playing. What’s acceptable in an ingenious puzzlefest may be quite out of place in a game focused principally on story, for example.

    Still, I’ll be interested to see what conclusions you draw from the 2010 Comp data.

    — Eric

  2. A very good point about setting the context and managing player expectations.

    ‘Even a generalization like “Most players don’t like puzzles they can’t solve”, plausible though it looks, skates over the problem that players can often have very different perceptions of the difficulty of the same puzzle.’

    Well, it deliberately skates over that issue. I’m looking for generalizations, and that sometimes means altering the degree of generality. I’m not going for fortune cookie wisdom here: it really does look like, in general, people dislike games when they can’t solve the puzzles.

    Other things can offset that, but it still appears to impact the score.

    As you say, different players will experience the same puzzle as being of different difficulties. I might be able to find a puzzle that the vast majority of people consider to be of average difficulty. (Similarly, judges rated the game _PK Girl_ several Comps ago at a 5, with very little variation in score. So the game was useful to me personally as a reference point for a median score.) I hadn’t thought of doing that for puzzles until now.

    As a consequence of that pattern, earlier I recommended making games with easy puzzles. Difficult puzzles are simply not rewarded by high scores. But now I’ve revised that advice:

    Now I say, use puzzle difficulty as a gating mechanism to sort out your puzzle-players from your story-players. Unlock the magic sword with a killer riddle, but allow the player to make do with a club. That way, the poor puzzle solver walks away happy and doesn’t punish your game with a low score.

    As for what *exactly* constitutes puzzle difficulty, that’s not something I’m prepared to address now: but we can say, functionally, a puzzle really is difficult when the majority of players report that it is difficult.

  3. “Unlock the magic sword with a killer riddle, but allow the player to make do with a club. That way, the poor puzzle solver walks away happy and doesn’t punish your game with a low score.”

    With one caveat: make the player aware of the choice. I’m a puzzle-player (I like Zork, found multiple endings in Bad Machine, etc.) but often I just skim past optional puzzles because I never even notice them (e.g. in Resonance). Another danger is that the player will get stuck and think the optional puzzle is necessary to progress, and get frustrated (this has also happened to me sometimes, though usually not in IF). A third difficulty is that if there are indefinite ‘better paths’, the player will feel unsatisfied after winning just one of them, but be at a loss to find the others (since it’s hard enough to solve a puzzle even if you know it’s there). All of these can be avoided by making the choice obvious or even explicit.

    Blue Lacuna does this well. The whole introductory portion can be finished as briefly or as carefully as one wishes, but the game monitors what you do and, depending on whether you work out every detail yourself or let the game handle such things, suggests either story or puzzle mode. In addition, it explicitly asks which you prefer, so you aren’t unknowingly locked into one. And the line of the story is the same either way: you’re not ‘missing out’ on anything if you take one way or the other.

    Worlds Apart also has (at least one) optional puzzle, which, if I recall correctly, is clearly broadcast as optional. However, I don’t believe there’s any reward for completing it, and certainly no gating mechanism, so that’s a slightly different case.

    Yes, I’d rather like more games to work this way.


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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s