I've been a developer for about 13 years. Never once in that time have I tried to make a game. When I finally did, I built a working prototype with a pretty good working AI based on the card game Dominion. That UI looked like this: Original Test Rig.

I tried to write a real version which spawned questions and then...

A few things happened:
I realized I don't know how to design games.
I realized I don't know anything about UML.

I spent a few hours today learning UML to write a design document for the game. I thought it might help, because there's not many game design documents out there. I thought maybe if I provided a decent design document , you might be willing to contribute some opinions/experiences/thoughts and we can dump a final document out there for future people to utilize.



This document is meant to describe a turn based game hosted within a client/server architecture with a predefined set of game rules:


Use Case Diagram:





Component Model (High Level):




Messaging Subsystem:




Client Subsystem:

Browser cut out most of the descriptions for the diagrams, I'll fix them tomorrow.

I can't tell if this is a Game Design post or a Your Announcements post or a Help Wanted post. Definitely not on-topic in For Beginners (a technical forum). Moving to Game Design.
Aer, if you are looking for help, you have to post in Help Wanted, using the required template.
You wrote:

there's not many game design documents out there.[/quote]
Not true. And they do not look like your collection of state diagrams. At the bottom of this page, you will find links to other places where there are GDDs you can look at. And I have two Shanghai Dynasty (SD) GDDs available in this folder on my site.

What you have there all belongs in a technical document, not a design document. A design document does not describe how to implement a game, it describes what the game will be. A design document uses normal language to describe in a way that can be understood equally by technical and non-technical staff (such as writers, artists, musicians) how a game is intended to play, the goals and philosophy of the design, and a design document may also contain appendices which list all the content which needs to be created for the game (characters, locations or levels, animations, pieces of music; documents like the game's complete script may also be appended).

<a href="http://home.comcast.net/~wickeddelite/XenallureDesignDoc.doc">Here is a link to my design document for the single player RPG Xenallure.</a> It is not complete, but the major sections are in place and in most cases it can be inferred what additional content was intended to be added. A single player RPG is largely irrelevant to a Dominion-like game, but the Xenallure document should serve to show what I mean by a document written in everyday language that describes what is in a game. A Dominion-like game would instead have descriptions of general card behavior, description of scoring, a list of all cards, etc.

Although a technical design is part of a game design document, it is only a part of it. The technical design is supposed to be how you are going to implement the game design.

As you are an experienced developer, you will know how before you write up a technical design for a system you first need documentation describing what the technical design is supposed to be for and what it is intended to achieve (a Specifications document). A Game Design Document is sort of like that, it is a non technical specification document that describes why you are making the technical document and what the technical document is supposed to be for.

This doesn't have to be long. For instance, when you made your Dominion game (and yes, Dominion is a great game ), you design document consisted of the dominion game rules and cards (ie: the card description sheet in the game rules) and your statement of: "I will make this game". All in all, less than 10 pages.

However, they can also be quite long consisting of hundreds of pages (or more) depending on the complexity of the game and the detail you think is necessary for someone to write the technical design and create the assets.

So as a quick game design document, you can just write out the game rules as if you were making a board game, and then write a description of each of the assets (game pieces) needed for the game.