Hi everyone,

I am not all that experienced in game programming. I've made a few test games to help me learn, but I've never made a fully functional game.

I've just recently been reading up on something called a game design document. I guess companies in the gaming industry use these documents as a detailed "script" for the game. Either briefly outlining the storyline, gameplay, and player controls, or going into full detail about every aspect of the game.

I think this is a great way to keep everyone on your team on the same page and to give the creation process clear and precise goals.

I was wondering, do you create a game design document for your games? If so, what does your document look like? What does your design document include?

Ugh, I've been trying to squeeze one of these babies out of my team for ages! They are all just like "lolwut?" XD

Well, you could have certain fields for things like language, graphics (2D or 3D), credits, what button does what, character sheets (if applicable), a general outline of what the program does or how to work it, and of course an annotated script outline.

A script outline, like the one I was trying to design, could look like this:

Ch1 of storyline, XXX City fight scene:

Event 1:
-location:
-characters involved:
-monsters:
-bosses:
-music:
-required actions to move on:
-cutscene:
-items to be found:
-secrets:
-shops:
-etc

event 2:
....

Next big story line event:

event 1:
...

I don't do any formal documents for my projects (game or otherwise), but I do keep a list of details, mostly written up as bullet points, although most of them are complete sentences and a few turn into paragraphs. To provide a sense of scale, my current side-project game (started about two and a half weeks ago) has 750 lines/33,651 characters of notes; assuming a standard 250 words/page and 6 characters/word, that's a bit over 22 pages of plans (vs. 1338 lines of non-comment, non-whitespace code so far).

Of course, this is heavily influenced by the fact that I mostly work in a team of one. Clearer documentation is required when you need to keep a group of people working together in sync, but even then I'd advocate a more "agile"/"extreme" model of iterative design, especially for a game, where you're likely to be discovering more about what actually is or isn't fun in your game as you go. BDUF (Big Design Up Front) just doesn't normally work all that well in my experience.

Incidentally, the plans I'm working with are all feature and game system details; my interests bend sharply towards sandbox games and emergent story, so I don't do any scripted scenes or events, unlike the examples in NeoTifa's response. Even if it were to be a story-driven game, I'd be inclined to build the game mechanics and interface first, then write the story instead of the other way around.

At the moment I do a document for the game I am planning.
I might not follow the "rules" of making one but in it I describe

Scenery, enemies, locations (non-cities), people, items, cities, background story, controls, subsystems like "Quests", "Inventory" etc.

But do not over do it then it will be hard to keep to it, flexibility is key!
I use the document as a "this is what I want" but not a " I MUST have this ".

If you want tip on how write one here is some links
http://digitalworlds.wordpress.com/2008/04...esign-document/

I think the way you make the document if up to you, it's you and the team that need to understand it

For games I think it is good to write a design document. I feel that having a good plan is very important when creating a game, any large project for that matter. Hence this line in my signature: If you fail to plan, plan to fail..

This is a design document that I started to work on for a personal project I'm working on from time to time. It isn't finished but it has place holders for items that I have not added yet.

http://www.jtmbooks.com/crystalcaverns.pdf

It really depends on the complexity of the game. If you think you can keep everything straight in your head then don't worry about one. As you develop, the program may get to be to much to keep in your head so at that point you may want to take some notes. The only thing I would suggest is to comment your code extensively.

@NeoTifa
That is a great way of doing a story driven design... I never really thought about doing it that way.

@SixOfEleven and FrozenSnake
Thanks for the links.

Thanks everyone for the design ideas. It was a great help!



Oh yes, I agree. I sometimes over comment my code

You're welcome. I think of things that way. That way the game kinda writes itself!

There is actually a debate over writing readable code vs using comments. I like to blend the two of them. I don't always though, bad programmer, and I know I really should, especially when I'm writing code for tutorials. If you come back to code you've written a year ago, unless you have an eidetic memory, you may end up scratching your head saying WTF!

Mind If I chime in on this one?

I used to plan extensively and try to create design documents up front for my games. The design documents would cover GUI, architecture, story elements, a ton of stuff.

Now, what I do is generate a list of features, then iteratively implement features fleshing out the game into the final product. This embraces the agile methodology which is kind of like.. knowing ahead of time that the plan.. however perfectly constructed..is going to change. So we don't waste alot of time documenting it. I still plan.. just not with a big design document.

The features are the description of the game, without having everything locked down in a rigid document. So when a feature changes (And they will!), there is no rework on design docs.
The plan takes the form of identifying which features will be implemented, and which ones to do first.


As for the commenting in code. I'm all for it as long as it is why .. not what. In other words.. your code should be clear enough to tell what you are doing, comments restating that you are looping over an array to find a specific element, when you can see that in the code, are superflous. Comments as to why you are finding that element and what it is used for, are not.

This post has been edited by Aeternalis: 5 Nov, 2009 - 08:05 AM

I think that is great idea when you're working on a game by yourself, or with a small team. Revisioning a large document everytime something changes would be very time consuming.

But I feel for a larger team, that it is almost necissary to have a design document covering all the details of the game so that everyone is on the same track. Also if a team member forgets something or has a question, they can simply refer to the design document without bothering other team members.



I very much agree with this. I am now going to start commenting why instead of what the code is doing

Create different version for each change, or keep and update log? *shrug*

i thing that you should get a book about these things
there is an old book the Tricks of the Windows Game Programming Gurus that even if it is old it has great information about game design

Youve got it stated perfectly there. Agile is really designed to be for a small to mid sized team. Complex software that is being developed by large teams, or many teams from different groups needs to have documented requirements / analysis and design in order to keep everyone on the same page.

In smaller groups you can get away from the documentation because agile focuses on communication as key to the small teams success. Communication between the team members, the project manager, and the customer are essential.

If you want to learn more about agile design methods, check out www.scrumalliance.org

they have a ton of resources and information about how to use scrum and agile / extreme programming and much more.

Aet

Wow, I had no idea these design methods even existed

Well, once you've worked for the military, you'd understand the importance on crystal clear communication, and how long processes, especially involving paperwork, takes.

Military? Nice. What branch were you in?

Air Force

This post has been edited by NeoTifa: 6 Nov, 2009 - 11:14 AM