Design doc vs prototype

[xDan]

Howdy!

For my next game I was thinking of writing a really detailed design doc. As I keep starting projects then losing direction after getting the intitial engine and game play mechanics working. Not having thought out decent level designs or puzzles.

Anyway so far I've thought up and wrote down some stuff: including a somewhat unique puzzle mechanic. Which in my mind seems like it could be some fun.

But I just wondered what you guys would do now. Would you continue and completely finish planning levels etc and hope that when you actually make it it is as good as you imagined. Or would you make a prototype before going any further?

Or is it all personal preference and should I bugger off and learn to make my own decisions? ;)

[bignobody]

I think it depends on the size of your team. If you are working more or less by yourself (like I do) I don't see a lot of value is going into a lot of detail in the design documents if the concept doesn't really need to be put across to other people to implement. It's more of a flexible guide for you to get your ideas out of your head and to work with over time until you have a fun prototype working that you can show to others. Then (this is the hard part, as you seem to already know) you polish it until it is good enough to sell.

Also, don't make a lot of levels until you are very happy with your prototype, as chances are your level file format will change at some point and you'll have to throw them all away.

Once you have a fun prototype, making the levels should be a lot more fun too.

Good luck, and stick with it!

[Popcorn Boy]

Howdy!

But I just wondered what you guys would do now. Would you continue and completely finish planning levels etc and hope that when you actually make it it is as good as you imagined. Or would you make a prototype before going any further?

Why don't you do something in the middle. Create a rough synopsis of all the levels but don't go into too much detail. Have a plan for how you want it to all work out, but don't dig down too deep until you verify through your prototype that this is something you want to pursue to the end.

[oNyx]

>[...]including a somewhat unique puzzle mechanic. Which in my mind seems
>like it could be some fun.

Most things which sound great in theory (or on paper) don't actually work that great. If something doesn't work you have to find that out as quick as possible and the only way to do that (if it's something new) is prototyping.

For me the breakdown is typically like this: From 10 "great" ideas 5 are crap after some thinking (eg they require too much content or they are somehow fundamentally flawed), 3 fail early in the prototyping phase, and if I'm lucky 1 of the remaining 2 is somewhat usable.

There are simply too many things which can go wrong. Some details are covered by personal experience and can be quickly discarded/changed (eg I know a specific set of cam/target/moving schemes which simply don't work in reality). With other things - especially new things - you simply don't know all implications and side effects. You just have to try it out.

Design documents can be either used as a kind of project outline for yourself or as a tool to synchronize the vision of the game with your team. If it's supposed to be used for the latter it needs frequent updates - otherwise it's useless.

Personally I don't think they are all that useful for small teams, but give it a try regardless. You can also try a wiki; some people are using one for that kind of thing.

You can also try the radically different prototype/cut down approach. In a nutshell: you prototype ideas until you find something interesting, then you experiment a bit with different ideas, write stuff down, try things, and finally you cut all optional things away. Everything which isn't 100% essential for the game has to go. All of it.

After that you should have a semi functional prototype and a list of things to do. This is your first milestone. Set yourself a time limit and run for it. Once you reach it you can flesh out the details for milestone#2 (you can recycle some ideas from the first step). Repeat if necessary.

The benefits of this approach are very little overhead, a quick start, quick progress, quick feedback (if you like), and a high chance to finish the project. It's a bit chaotic, which disqualifies it for bigger projects, but for small games (web games in particular) it's probably the best thing to do.

[OremLK]

For me, this is very much the same as writing fiction; how much do you plan, if at all? I really think it depends on your personality and individual circumstances. If you're doing most or all of the work yourself, I don't really think there's a "right" answer to this question.

Going back to the fiction writing analogy, Stephen King says you shouldn't plan at all, and you're being dishonest as an author if you do; Orson Scott Card says that you should plan things out as much as you can, or you'll rob your work of depth and originality. Who's right? Both. Neither.

Some people work best seeing immediate results, and then changing things over and over again until it's perfect. Others want to plan everything ahead of time and deviate from the plan not even a little. I suspect most of us fall somewhere in between.

I apologize if that sounds like a long way of saying very little. In summary, I think it's best to just experiment with different approaches towards planning until you find something that works best for you.

[jhanson]

Personally, I'm an outliner. I like to make an outline of all the basic features and items I hope to include in a game. When it comes time to start working on one of those features or items, if it's something somewhat complex that might require some extra thought, I'll make an outline of its components. This cycle can continue until I have it down to something that's workable for me.

The benefit here is that not only do I get a chance to think things through before I start coding, but I end up with a nice checklist against which I can chart my progress.

[Coyote]

I consider the design doc to be the "paper prototype." Once features are implemented, that section of the doc becomes obsolete and the game itself becomes the design document in stages.

This varies by style of game. Your design doc might still have several important sections even when the core gameplay section is obsolete - things like planned levels, characters, etc.

[tentons]

I start with a broad design doc to get the big picture down, and maybe some of the main features that I think will work. Then build something, test, revise, and keep writing your doc as you go so you can communicate the ideas to your team (even if it's small). Basically plan right before you are going to implement. And you have to know what you're trying to do. So a doc is useful for multiple reasons.

I've also been forced (by funders of the past) to write a very detailed doc before implementation. Unless you are cloning something, it's not very useful to write in detail at that point unless it's to please someone that's giving you money. :) The details simply evolve too much to try and capture them all before you've even begun coding.

So, get the big points down, be brief, and find the vision. Then make small choices as you build, continually iterating the ideas and the code.

[Arex]

I suggest putting the most important things to paper and prototyping.

[xDan]

I'm working by myself so it's only for my benefit, to help me focus.

It's very interesting to hear what everyone does. Thanks!

I'll start on a prototype before I do much detailed planning.

[Laz-Roc]

In my opinion design documents are very useful tools indeed - even if you are the only developer - and makes a prototype only a companion to it, if at all.

It's a good thing to work out a vision before starting anything, and pen & paper gives a lot more flexibility, and is less time consuming than coding (at least for me). Writing down the ideas, and detailing them, helps me a lot to get familiar with the game. It helps me to visualize the game before actual development starts, as well as spotting loose or redundant ideas.

The design docs are a very useful leadership tool, especially in later development phases when everything gets complex, and you run the risk of loosing direction, getting bogged down on secondary tasks, or whatsoever. All in all, it helps to focus on what's important, makes this vision clear to you and everybody in your team, and serves as masterplan and blueprint during development.

I am also convinced that it's universally a bad habit to rush into development, as the creation of anything consists of two phases: psychic first, then physical. You simply can't adjust bad leadership (psychic) with good management (physical) - that's a law of nature.

[Nikos Beck]

In terms of using a design document as a "leadership" tool, I prefer a task list. As parts of the game start to come together, there can be a thousand tasks left. The designer chooses the highest priority tasks, adding details as needed. It keeps the team focused on the most important tasks. Tasks can be added to the list but unless they're a priority, there not touched. It's also useful when features need to be cut.

I use the design document as a vision statement and explanation of how things will work.