Mission creep!

This may be a dumb and/or overly broad question, but …

… how do you clarify what your game is and is not going to be? When I start designing, I want to throw in everything that comes to mind. Eventually I work up an outline, and then it’s time to start coding.

And then I realize that the environment I’m simulating has a lot more locations than I thought. Which all need room descriptions, furniture, item descriptions, and a modicum of interactivity, because nothing annoys me more than an under-implemented game with nothing to look at or play with. Plus default responses need to be tweaked, for color and to let the player know if he’s on the right track. Plus if I’m lucky, there’s three or five different ways to implement a thing (if I’m not lucky I’ll be banging my head against the code for a couple of hours before I can get it to do things even one way!) … and that’s leaving out the time it takes me to come up with ideas, which can be a while.

And before you know it, I’m taking five times longer to finish the game than I’d planned. Ack.

Do you guys have some clever suggestions for how to curtail this problem? Or is it mostly a matter of practice?

It sounds like you’re taking a simulationist approach, envisioning an environment and trying to replicate it in a way that’s interesting. Whether this is a useful approach depends on the kind of game you want to make.

It might help you to focus on what the core locations need to be for the game to make sense, and then what additional locations and objects are required for puzzle chains. Extraneous locations and objects should be kept to a minimum.

I usually try to make sure each location has at least one puzzle element and some unique text that furthers the story or adds to the character of the game. I’ll have story specific reasons why the player isn’t allowed to go into places that exist in-fiction but haven’t been implemented.


This seems relevant to what you’re facing.

Hmm, maybe I need to change the default fail response from “You can’t see that here” to “That isn’t important.” Because if I enter, say, a bathroom and look for a sink, it would be ridiculous to say there isn’t one in there, but the player doesn’t need to interact with it.

For places like bathrooms or kitchens that have unimportant but essential furniture, I create a catch-all scenery item that accepts as a synonym all the unmentioned things that the player might think to look at. Then I make it clear in the description of the item that it’s not important.

This is a nicely sane option which I like. Can you give me a clearer example?


Here’s how I handled a (dream sequence) bedroom in Andromeda Dreaming:

[code]The Bedroom is a room.

The description of bedroom is “The pink light of two of the three suns paints your bedroom, but the morning scene is hard to appreciate as you’re covered in blood.”

The bed is scenery in the bedroom. Understand “door”, “chair”, “window”, “furniture”, “desk” as the bed. The bed is an enterable supporter. The description of the bed is “You suppose there must be furniture in your room but you can’t focus on that now.”[/code]

Play Ryan Veeder’s games for a lesson on implementation optimization.

Essentially it helps to avoid putting stuff in any room that you don’t want the player to bother with. Direct the players attention to the important interaction.

Zarf is also especially good, not so much in “not implementing what the player doesn’t need” but rather in “write it so that the player’s attention is naturally directed towards the stuff they do need to interact with”.

In a way they’re two sides of the same coin, really.

I found these articles helpful:

emshort.wordpress.com/2009/08/2 … mentation/

I like the through-line approach mentioned in the second article. That way you always have a game that can be played through from beginning to end–a game that could technically be released after some cleanup–regardless of whether you end up adding all the extras you’d originally planned.

Some people like to write an actual optimal transcript of a game as a guide document. If you imagine yourself playing the game and what you’d like to do and have happen at any given time, this might help you keep to the script.

I struggled with this when writing Last Day of Summer. Most of the game is set in a town, but there were only a couple locations in town that were important to the story, and I didn’t want to implement the rest of the town (partly due to time constraints when writing the game, but mostly because I didn’t want to distract the player with things that weren’t important to the story… and I didn’t want to expand the story to make the rest of the town interesting, because of said time constraints). So I ended up making the protagonist a child, who is in town alone for the first time, and going anywhere in town from the first important location results in him getting lost, ending up by chance in the other important location, and too intimidated/overwhelmed to go back out into town again.

In other words, I invented an in-story (“diegetic”) reason to prevent the player from exploring the rest of the town, rather than just having non-diegetic parser responses saying “you can’t do that” or “that’s not interesting”. However, I made the opposite choice for another part of the game: I didn’t want to implement a dialogue system, mostly due to time constraints again but also partly because I didn’t want this game to be the kind of game that is dialogue-focused; so, trying to talk to one of the two NPCs in the game results in a parser response “[You don’t need to use dialogue in this game.]”

Unfortunately, I got complaints related to both of these design decisions: people didn’t like that there was no indication of which way to go in town, and also that all directions effectively ended up in the same place; people also didn’t like being told they couldn’t use dialogue when it felt natural to want to talk to the NPCs. I think both of these complaints are probably valid. So maybe I don’t actually have useful advice! But I do think there are ways to make both of these approaches work, in ways that don’t annoy the player. Good luck figuring those ways out. :slight_smile:

Doug is right that diagetic reasons for limited scope of locations is way prefable than the IF equivalent of invisible walls. A custom message is preferable to just saying “You csntt go that way”.

Almost everything is preferable to “You csntt go that way”!

Sorry. Typo humour is cheap, but sometimes it’s still funny.


I do think there are ways to make non-diegetic limitations work. In other videogame genres, lack of affordances are well-accepted: no one thinks twice about the one-button interface in Canabalt or Flappy Bird. That’s an extreme example, since it’s clear that the entire game is built around that limitation, but it’s also not a big deal that you can’t jump in Doom and you can’t shoot in Super Mario. In the case of my game, it may just be that the lack of dialogue actions should have been announced at the beginning, rather than right after an NPC talks to you. But I don’t think it necessarily needs to be explained by the story.

Speaking of which, an interesting example of a diegetically-explained limitation is in the current IFComp game “Midnight. Swordfight.”, where you are given a “playscript” up front listing all the verbs you can use, and if you try to use any verb not on the list it simply says “That’s not in the playscript.” It’s a paper-thin conceit, really, but I think it works because other aspects of the game reinforce the acting-out-a-play metaphor.