I'm currently in the process of writing a design document before developing a game. Basically, my plan was to fully organize my ideas and properly structure the classes and project before starting development. First of all, I hate writing documents...really really hate writing documents, and drawing diagrams..ugh. But I realize their importance, and how much they contribute to actually finishing a project and communicating it to other people. I've hit a snag however. I kept telling myself not to go overboard, only use technologies I'm familiar with, and go for the shine (Charm, and clever design), rather than the vroom (Complicated algorithms that only technical people would ever care about, and which I can barely even visualize completely). But I've been a novice developer much longer than I've been a novice designer, and all novice developers get wild ideas with technologies they're not completely familiar with. So I've got this complicated feature I want to include in my game, and here are my two options: A. Get coding, prototype it, make sure it's anywhere near possible, and then include it in the document for further refinement. B. Write it down, place it at a later phase in the project, or mark it for release in another version--making sure that I've done as much as possible so that I can scale up to it. I should mention that the game I'm planning doesn't really need this feature, it adds very little to the gameplay (If anything at all), but a lot to the visuals and variety. Thing is, I can't think of anyone that has done anything like it, and if it were successful, it would make my game that much more innovative. Plus, and I know this is immature, it would be COOL!

Well... it depends a lot on what your motivation is. If you want to make a finished product and make some money, then stick to tried-and-true methods, and churn out something a bunch of people will like, but is technically as simple as possible.

If you're just doing it for fun/expand your skill, then just get coding... that's what I did. I would kind of start coming up with gameplay ideas as I went along with my coding, and now the game is mostly designed, without having to actually sit down and write a design document.

Sounds to me that you're mixing technical design with game design. They are very different things. Write your game design document first, at least a high level version of it. The evaluate the technical scope of the individual features you'll need. Refine and repeat. [wink] The game comes first ... schmanciness comes later.

I doubt I'll make money off this. I was planning to sell it for a dollar a copy, if I sell it at all. I'm doing this to expand my skills, have some fun, and maybe get a very humble popularity base (I'd be happy with just two people, as long as they're not my parents). Most important of all, I'd like to create a complete game, rather than just a few random features I get bored of and never expand on, which has happened before.

Quote:

Sounds to me that you're mixing technical design with game design. They are very different things. Write your game design document first, at least a high level version of it. The evaluate the technical scope of the individual features you'll need. Refine and repeat. The game comes first ... schmanciness comes later.

Stupid question...

Would a game design document include detailed information like weapons, items, walkthroughs, interface diagrams and level maps?

I'm pretty new at this, I'm mostly a business developer.

Quote:

Original post by WazzatMan Would a game design document include detailed information like weapons, items, walkthroughs, interface diagrams and level maps?

Yeah, except it doesn't have to be one single super honking huge document, though [wink]

Say for instance you are wanting to create a 2d platformer (for simplicity's sake). The GDD (game design document) would provide details (bulleted lists are good ... not lengthy paragraphs) on the various elements of the game. These elements would include types of characters, types of weapons, actions that characters can perform, what factors into combat, how power-ups work, how they can be obtained, etc. Putting tidbits of specific damage of a given weapon doesn't make sense, because that is an easily changed variable from play-testing. However, how that weapon interacts with a player's armor class, dodge score, whatever should be spelled out. You'll also want to flowchart out menu flow and bullet out the list of elements that each menu will contain.

Once you have this document you can sit down and figure out how to achieve this all in code. You could also start drawing out levels, which will also give you a better understanding of what you're going to need to do, technically.

Planning your gameplay features ahead of time instead of building a bunch of tech and then figuring out what do with it prevents you from having nearly as much code rework.

Makes sense, thanks.

I'd say it also depends on who your intended audience is when writing your documents.
Most design documents are meant to communicate your ideas to the team so that they can implement the systems as intended.
If you are the sole developer of a project then it is much easier to prototype things and design by trial-and-error.

Another reason to make a design doc is to get you to think the features and design through. It is easy to fix a doc before wasting time programming. The worst thing a colleague said to me once was "even if I code myself into a corner, at least I have all the code to re-use". The problem is time is money, and not all code is reusable.

Now, if you are just doing a small feature, as others have mentioned, you don't need a big document. If you do not need a legal specification that has to be signed off by a client, then that is another reason for not 'having' to do one.

However, even if it is a small feature, writing it out a bit, or making a small flow chart, will help expose any design flaws.

I'd recommend that you split your design doc into two sections.

1) Things you *know*, either because you're asserting them as invariants of your design, or because you've actually tested and played them and you know they work in your game. "It's an FPS" qualifies. "It's class-based" qualifies. "There are these 28 specific classes" probably doesn't. If any of these change (and they can!) it should be considered a significant redesign.

2) Ideas. This is where the list of the 28 classes go, and inventory lists, and... This is where you basically put stuff that you think might work or is interesting, but you haven't actually tested it yet.

One of the biggest dangers is putting things in category 1 when they're really in category 2. Doing the opposite is much, much less problematic in the long run. For things that you don't *know* yet, it's best to acknowledge that, and give yourself some room to change those decisions if necessary.

When looking at complicated features, the biggest thing to ask is how it's going to impact the player. If it doesn't impact the player any more than a simple system, then it's not really buying you anything :)

When writing a design document you should divide the feature in catogories like:
Must haves - Must be in the game to make it work
Should haves - Should be in the game to make it fun
Could haves - Could be in the game to make it a little better