Design Documentation
Author
I am unsure whether there is an easy answer already existing on this forum or website, so if there is I would be grateful if you could direct me.
I am a student, currently studying 'Games and Interactive Entertainment' at Queensland University of Technology. I'm taking a year off for personal reasons, but I still want to work on achieving my goal of designing games professionally at some point in the future. I have a number of game ideas in my head, which I believe would make quite good games. They're all reasonable and feasible ideas... if you're a Games Development company. They're (mostly) completely beyond my ability to produce on my own, or even with a team of volunteers. However, I feel it'd be good way to develop the skills I'll one day need, and hopefully show as work demonstrations at some point, if I fleshed them out in the form of documents. I think I could easily write hundreds of pages on a number of them in terms of setting, narrative/backstory, feel, general gameplay, specific menu designs, game-play design, algorithms, basically all the ideas involved. I would, of course, only be writing for the purposes of writing and improving myself.
However, here comes the question/problem. Having no experience in an actual development team, I'm not really capable of estimating costs and timelines and technical requirements. I know that MOST of them are achievable on today's technology, and I know how to write up cost estimates, hardware prices... but the details would all be guess-work. The question I wish to ask is firstly, would it be a good idea to write these documents, assuming I have the time? Secondly, how should I write them? Should I attempt a Concept Document, Game Proposal and then Game Design Document? Or should I, perhaps, combine a Concept Document and a Design Document minus most of the technical side?
Any advice would be appreciated. Thanks in advance.
Personally, I'd recommend you to get some hard skills. Developing small games or levels isn't too hard these days, with high-level scripting languages such as Python, or platforms such as Flash, or the modding tools that many AAA games come with nowadays.
I've got a fair list of ideas as well, but I've scaled down to smaller, more doable ideas over the years, because my motivation span doesn't allow for them: after 6-12 months, I need to be done with something or I'll probably never finish it.
I've also learned something else after 7 years of level-design: playtesting is an important aspect. Ideas can sound great, but more often than not, they're not really as fun as they sounded (while a random experiment may actually turn out quite fun). Some ideas just have to be dropped straight away, others can be made into fun games after a lot of tweaking. But paperwork isn't going to tell you that. At the very least, prototype your most interesting ideas to see how they work out. I think you'll learn a lot more from that than from writing hundreds of pages that nobody wants to read. Developers want the information they need to be easily accessible anyway, not buried in tons of paper.
I've got a fair list of ideas as well, but I've scaled down to smaller, more doable ideas over the years, because my motivation span doesn't allow for them: after 6-12 months, I need to be done with something or I'll probably never finish it.
I've also learned something else after 7 years of level-design: playtesting is an important aspect. Ideas can sound great, but more often than not, they're not really as fun as they sounded (while a random experiment may actually turn out quite fun). Some ideas just have to be dropped straight away, others can be made into fun games after a lot of tweaking. But paperwork isn't going to tell you that. At the very least, prototype your most interesting ideas to see how they work out. I think you'll learn a lot more from that than from writing hundreds of pages that nobody wants to read. Developers want the information they need to be easily accessible anyway, not buried in tons of paper.
Author
I am very much concentrating on developing my hard skills. As much as I would like to develop these ideas myself, to me they are just ideas I like. I don't possess the technical skills for them yet.
I have a number of small projects I'm developing myself. Unfortunately at the moment my computer for gaming/games development is fried. I need to wait a while before I can replace some parts. For now I lack a PC capable of doing that work.
I may eventually develop one of my idea as a modification for an already existing game. At this stage I was more looking at developing a detailed plan for said idea, before I even think of trying to realise it.
As for your valid point on tons of paper, I wasn't talking about going into unnecessary detail. I was speaking of a brief guide to every element of the game. As a design document should be.
I'm sorry if I didn't convey what I meant in the first post. These ideas are unlikely to be developed. It would be an exercise in the thinking/writing processes rather than the implementation. I have some smaller, less ambitious projects ongoing simultaneously.
I have a number of small projects I'm developing myself. Unfortunately at the moment my computer for gaming/games development is fried. I need to wait a while before I can replace some parts. For now I lack a PC capable of doing that work.
I may eventually develop one of my idea as a modification for an already existing game. At this stage I was more looking at developing a detailed plan for said idea, before I even think of trying to realise it.
As for your valid point on tons of paper, I wasn't talking about going into unnecessary detail. I was speaking of a brief guide to every element of the game. As a design document should be.
I'm sorry if I didn't convey what I meant in the first post. These ideas are unlikely to be developed. It would be an exercise in the thinking/writing processes rather than the implementation. I have some smaller, less ambitious projects ongoing simultaneously.
The game design process is pretty rigorous, especially if you're intent on creating something that people will actually enjoy (the goal of games). Begin by creating an overall "design document." While your first game project should not include every aspect of a professional design document, it's still a good idea to include many aspects to get the hang of things.
When you write up the specific documents, remember for whom you're writing them. Producers want to be impressed, developers want only what they can use to implement, writers only want the story, artists only want the visuals. Don't write too much to overwhelm the reader, but write enough to cover all your ideas.
Do so in the following steps:
1. Create a high concept. This is usually just one, two, or three sentences describing the overall feel to the game.
2. Create a scope document. This is your first working document. The idea is to expand upon the high concept to flesh out the main goals of the game without going into too much details. You should include things like the platform (PC/console), players (single/multi), genre (action/adventure/puzzle/etc), goals, special features.
3. Write up a game design. While that probably sounds pretty broad, it's quite specific and detail driven. This document includes things like game summary, outstanding aspects (what makes it unique?), game story, backstory, main players, characters (NPC or other players), weapons, buildings, structures, any other objects in the worlds, conflicts, resolutions, controls, and different game modes.
4. Set up your specific in game data. Using excel or some sort of spreadsheet (you can hand write it if you want), make sure you give specifications to any in game objects that require certain numbers to operate. For example, you'd keep track of how much health certain monsters and players would have, their damages, intelligence levels, and anything else you can think of.
5. Think of the technicalities. Up until this point, you shouldn't even think about the which code or algorithms to implement. This is where you begin to sit down and think about which technology you're going to use for certain parts of the game. Your developers will be reading this document, so keep it short and sweet. Primarily you should focus on:
- Rendering - 3D? 2D? Isometric?
- System Architecture - Windows specific? Linux specific? Platform independent?
- Scripting - Python? LUA? Either for interfaces? AI?
- Networking - LAN? Internet?
- Sound and Music - Establish mood and necessity of types of effects and music
- Artificial Intelligence - Just enough to convince? Pathfinding? Aiming?
- Animation/Characters - Sprites? 3D models?
- User Interface - Dependent on an interface or can do without one?
- World System - Static field of play? Scrolling 2D background? 3D immersion?
- Database System - How to store game data/resources, usernames for multiplayer stats, etc.
6. Finally, think of the player. Define a set of rules that the player must follow in all situations. Think of what happens when a player does X to Y. What happens if he does A and B simultaneously? How will the menus work when the player interacts?
Obviously, that's a lot on your plate for your first game, and most can probably be left out. The point of showing you all of this was that there's a lot involved and you should probably always take everything into consideration if you want to make it a good habit. You will thank yourself after you've established all of the above and have a solid working blueprint for your concept.
Reference reading: Game Design: A Practical Approach
When you write up the specific documents, remember for whom you're writing them. Producers want to be impressed, developers want only what they can use to implement, writers only want the story, artists only want the visuals. Don't write too much to overwhelm the reader, but write enough to cover all your ideas.
Do so in the following steps:
1. Create a high concept. This is usually just one, two, or three sentences describing the overall feel to the game.
2. Create a scope document. This is your first working document. The idea is to expand upon the high concept to flesh out the main goals of the game without going into too much details. You should include things like the platform (PC/console), players (single/multi), genre (action/adventure/puzzle/etc), goals, special features.
3. Write up a game design. While that probably sounds pretty broad, it's quite specific and detail driven. This document includes things like game summary, outstanding aspects (what makes it unique?), game story, backstory, main players, characters (NPC or other players), weapons, buildings, structures, any other objects in the worlds, conflicts, resolutions, controls, and different game modes.
4. Set up your specific in game data. Using excel or some sort of spreadsheet (you can hand write it if you want), make sure you give specifications to any in game objects that require certain numbers to operate. For example, you'd keep track of how much health certain monsters and players would have, their damages, intelligence levels, and anything else you can think of.
5. Think of the technicalities. Up until this point, you shouldn't even think about the which code or algorithms to implement. This is where you begin to sit down and think about which technology you're going to use for certain parts of the game. Your developers will be reading this document, so keep it short and sweet. Primarily you should focus on:
- Rendering - 3D? 2D? Isometric?
- System Architecture - Windows specific? Linux specific? Platform independent?
- Scripting - Python? LUA? Either for interfaces? AI?
- Networking - LAN? Internet?
- Sound and Music - Establish mood and necessity of types of effects and music
- Artificial Intelligence - Just enough to convince? Pathfinding? Aiming?
- Animation/Characters - Sprites? 3D models?
- User Interface - Dependent on an interface or can do without one?
- World System - Static field of play? Scrolling 2D background? 3D immersion?
- Database System - How to store game data/resources, usernames for multiplayer stats, etc.
6. Finally, think of the player. Define a set of rules that the player must follow in all situations. Think of what happens when a player does X to Y. What happens if he does A and B simultaneously? How will the menus work when the player interacts?
Obviously, that's a lot on your plate for your first game, and most can probably be left out. The point of showing you all of this was that there's a lot involved and you should probably always take everything into consideration if you want to make it a good habit. You will thank yourself after you've established all of the above and have a solid working blueprint for your concept.
Reference reading: Game Design: A Practical Approach
Nathan wrote (not necessarily in this order):
>how should I write them? Should I attempt a Concept Document, Game Proposal and then Game Design Document? Or should I, perhaps, combine a Concept Document and a Design Document minus most of the technical side?
It doesn't matter. You may not be able to show them to potential employers anyway, and you're doing it for the practice. Pick the five most promising game concepts. Write a 2-page concept document for each of them. Then pick one (any one) and start a GDD for it. If you find yourself losing momentum on that, put it aside and see if the 2-pager still holds validity, and rewrite it if necessary. Go to another of your concepts and write a 15-page treatment (limiting yourself strictly to 15 pages and not discussing the controls at all, unless it's a DS or Wii game).
>would it be a good idea to write these documents, assuming I have the time?
>I feel it'd be good way to develop the skills I'll one day need
The problem is that you're working off your "feelings" rather than your belief or opinion. I personally believe that it'd be a very good way to develop the skills you'll need. And I've said so many times before.
>I'm not really capable of estimating costs and timelines and technical requirements.
>I wasn't talking about going into unnecessary detail.
Costs and schedules and tech stuff is unnecessary detail. I assume you think you need them for "game proposals"? The heck with that. Just write 2-page concepts, 15-page treatments, and one or two GDDs. That's plenty of work right there.
>how should I write them? Should I attempt a Concept Document, Game Proposal and then Game Design Document? Or should I, perhaps, combine a Concept Document and a Design Document minus most of the technical side?
It doesn't matter. You may not be able to show them to potential employers anyway, and you're doing it for the practice. Pick the five most promising game concepts. Write a 2-page concept document for each of them. Then pick one (any one) and start a GDD for it. If you find yourself losing momentum on that, put it aside and see if the 2-pager still holds validity, and rewrite it if necessary. Go to another of your concepts and write a 15-page treatment (limiting yourself strictly to 15 pages and not discussing the controls at all, unless it's a DS or Wii game).
>would it be a good idea to write these documents, assuming I have the time?
>I feel it'd be good way to develop the skills I'll one day need
The problem is that you're working off your "feelings" rather than your belief or opinion. I personally believe that it'd be a very good way to develop the skills you'll need. And I've said so many times before.
>I'm not really capable of estimating costs and timelines and technical requirements.
>I wasn't talking about going into unnecessary detail.
Costs and schedules and tech stuff is unnecessary detail. I assume you think you need them for "game proposals"? The heck with that. Just write 2-page concepts, 15-page treatments, and one or two GDDs. That's plenty of work right there.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
