[size="7"]TOPIC CLOSED
Hey Guys,
I have created a GDD (I have called it a Design Report) which I am going to submit to a programmer to implement and code a basic version.
I was wandering if there were any Game Designers out there that have a few minutes to go through the document and decide whether they can start creating the game from the information it contains. I believe it is of good standard however I have never desgined a game before.
Any criticism is welcome but please give a helpful comment about how the document could be improved along with it.
Thankyou for your time,
Thomas
Design Report needs Criticism from Game Designers
I have created a Design Report which I am going to submit to a programmer.
Hi Thomas,
What is a "Design Report"? It's not a school project? Is it a GDD (Game Design Document), is that what you're saying (is that why you're "submitting it to a programmer")?
If it's a GDD, does it include the necessary GDD elements outlined here?
Author
[quote name='bored-student' timestamp='1302982517' post='4799227']I have created a Design Report which I am going to submit to a programmer.
Hi Thomas,
What is a "Design Report"? It's not a school project? Is it a GDD (Game Design Document), is that what you're saying (is that why you're "submitting it to a programmer")?
If it's a GDD, does it include the necessary GDD elements outlined here?
[/quote]
Yes by Design Report I mean a GDD. Sorry about the confusion, it is based on a report i had to write for my university degree about developing a mobile application.
Thankyou for the link, i will go through my GDD and highlight/correct it to fit your otuline more closley.
I can't download it... I either get partial downloads or a connection error.
I'm not sure that's through any fault of mine as i seem to be able to download without a problem. Sorry.
I think it suffers from confusion of purpose: it's trying to be a game design document, a technical design document and a kind of hire contract all at the same time.
Don't write your game design document as a specific set of instructions for a programmer - this is a horribly unscalable approach, as you'll end up having to write different documents for each member of the team. Not only is this a massive waste of your time, but it will inevitably lead to issues as the design changes (which it will) and the different versions go out if sync.
In my experience, there are three different 'design documents' that need to exist.
The first is the game design document (GDD) which deals with the mechanics and flow of the game, and what the game actually is.
Then there is the technical design document, (TDD) which deals with how the game is actually implemented. This document is generally written by the most experienced programmer on the team, which usually isn't the designer.
Then there is the media design document (MDD) which deals with the artistic side of things, and is written by an appointed 'vision holder' who maintains the artistic vision for the game. This could be a designer, or it could be an artist.
There is also another document: the 'pitch' which is a short document intended to explain the basic game idea as concisely and excitingly as possible. The purpose of this document is to basically build interest in the project, to motivate people to invest their time, money, or whatever into helping it become a reality.
Decide which if those documents you are qualified to write, and write them as separate documents. I would say that you probably are qualified to write the GDD and possibly the MDD (although be aware that artistic direction is not as easy in practice as it might sound) but as a programmer your technical sections seem a little naive - you might be better off letting your programmer handle the technical design.
As for all the stuff about deliverables and what a programmer is or is not expected to do, that stuff doesn't really belong in there at all, let alone twice - that belongs in whatever contract you draw up between you and the programmer you choose to employ.
Don't write your game design document as a specific set of instructions for a programmer - this is a horribly unscalable approach, as you'll end up having to write different documents for each member of the team. Not only is this a massive waste of your time, but it will inevitably lead to issues as the design changes (which it will) and the different versions go out if sync.
In my experience, there are three different 'design documents' that need to exist.
The first is the game design document (GDD) which deals with the mechanics and flow of the game, and what the game actually is.
Then there is the technical design document, (TDD) which deals with how the game is actually implemented. This document is generally written by the most experienced programmer on the team, which usually isn't the designer.
Then there is the media design document (MDD) which deals with the artistic side of things, and is written by an appointed 'vision holder' who maintains the artistic vision for the game. This could be a designer, or it could be an artist.
There is also another document: the 'pitch' which is a short document intended to explain the basic game idea as concisely and excitingly as possible. The purpose of this document is to basically build interest in the project, to motivate people to invest their time, money, or whatever into helping it become a reality.
Decide which if those documents you are qualified to write, and write them as separate documents. I would say that you probably are qualified to write the GDD and possibly the MDD (although be aware that artistic direction is not as easy in practice as it might sound) but as a programmer your technical sections seem a little naive - you might be better off letting your programmer handle the technical design.
As for all the stuff about deliverables and what a programmer is or is not expected to do, that stuff doesn't really belong in there at all, let alone twice - that belongs in whatever contract you draw up between you and the programmer you choose to employ.
Author
Thankyou for the feedback, I will break the document up and re-design it
Thomas
Thomas
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
