Building Browsergames

Getting your game to done: trimming your design

When most developers set out to build a browsergame, they tend to make big plans.

“It’ll all be real-time, and we’ll need at least six database servers just to handle the sheer amount of awesome!”

..The reality is, especially if it’s your first game, you won’t be able to build something quite that large(and most of the sites you visit on the internet don’t even use two database servers, anyway). However, that doesn’t mean that you can’t start taking the first steps, by getting something out there.

But what if you’re attached to your design, and that is what you want to build?

The simplest answer is trimming – take your entire design, and start stripping things away. Generally, I find that it’s helpful to make two lists – “things that have to be there”, and “things I want to have be there”. Then, you take all of your design notes and figure out what goes onto which list.

One of the easiest ways to do that is to start by putting everything onto the “things I want to have be there” list. Then, move pieces of your game over, one-by-one. Generally, things that are worth moving over are:

• Self-contained

  The feature shouldn’t rely on any other features to work. You’re getting your game up and running so that you can add more to it, not so that it will fulfill your design perfectly from day one.

• Small

  If one piece of your game will take two months to build, and each other piece averages a few days to a week, that feature isn’t a very good candidate(no matter how cool it is). Especially when you’re building your first game, motivating is hard – the more easy wins you have while you’re building it, the less likely you are to get discouraged and stop. One of the easiest ways to get easy wins is to focus on easy features in your first version.

• Low-resource

  Most of the developers that I have seen starting to build their own games have been working in a shared hosting environment, paying $5/month. And while your game is in it’s fledgling stages, that’s fine – but if a feature on your list calls for six database servers, you may want to keep it on the “I want” list instead of the “I need” list until you can actually justify the resources.

• Playable

  The last, and probably most important point, is that your feature needs to be playable. If that feature you’re considering moving over is really super-cool but isn’t something the players can interact with, it shouldn’t be in your first version. Building features that no one can see is a bit of a gamble even when your game is established; what are your players going to care if they can’t see it?

Once you’ve gone over your list and moved the bare minimum of features over to your “things that have to be there” list, you’re ready to start working on your game. Keep both lists somewhere that you’ll see them often, and while you’re building your game periodically review them – a lot of the time, features that you’ve built into your game will make it so that other features you wanted to have(but kept off your list) are now possible – and even easy.

Luke is the primary editor of Building Browsergames, and has written a large portion of the articles that you read here. He generally has no idea what to say when asked to write about himself in the third person.

Tags: design, features, release, trimming