Many asks me, "ikarius, how professional designs games ?" or "my project never gets done, because at some point, i am getting lost, what can I do to resolve this matter ?".
Creating a game can be done in two ways, the first one is being organised, the second one is improvisation. Improvisation is good in the matter you create a small game such as a Tetris/Breakout/Pacman/Bomberman Clone and do not intend to actually use high-techs or any stories. Basically, anything that doesn't require you to code for a long time is improvisation.
Although in some cases, improvisation is too big and you so need organisation. All of you are not professionals. So, I won't go in details how us, professionals, goes into this. Before getting started, note this...
Professionalism as I state is in the meaning you are working into the industry (technically I can work in the industry, I just lack of experience, but I am considered as a professional Game Developper/Designer/Programmer). The word "professional" means in this document simply that I am working in the industry but not "i am better than thou". This is a false statement as many professional works are not nearly as good as indie (homebrew) work.
First things comes first. As first, you can read this document without knowing programming and simply design/develop your game and get someone (or more people) to program it for you. As second, you can also program your own game, which is more time consuming, but gives more self-satisfaction nonetheless.
NOTE: For this document we'll take an example on one of my offline game called WRAITH.
STEP 1: BRAINSTORMING YOUR IDEA
Take a sheet of paper, notepad, whatever you feel like writing into and get your inspiration on it. Words, sentences, names of characters, technologies you'd wish to use... basically, everything. Who cares if it can be done or not, we just need ideas. As for "can it be done ?" we'll see that in the classification phase. For now, we just need to know what we want and how we want it.
Into a brainstorming, you don't need to have anything in order, just make sure you understand what you wrote and what exactly you wanted. No need to get in details here, and it's probably the easiest step of all this document. My suggestion, put yourself some soundtracks/ocremix/whatever music, and close your eyes and write what you see, what you feel. Those feelings MUST NOT be influenced by "will people like my game ?". Just let them flow and write whatever you see/dream/imagine.
On a side note, AND THIS IS IMPORTANT, you will ask me the question, or maybe ask yourself: "Will my game be popular ?" or "Will people like my game ?". Welcome on earth, and wake up call to reality: Everyone is different. Some will like your game, some will not. Some will be fans of your designs, some will hate them. In the haters, 60% of them are jealous, 20% of them are opinionated people, 10% of them gives constructive critism that are not really usefull, 5% of them will just dislike everything they see, 3% are just maybe too perfectionist, 2% of them have a good reason and will review your game with good and pertinent constructive critisms. So, don't start going angry at them, they are people among other people. Take the good comments, constructive critisms (even if some of them say your game isn't good), and leave the rest.
Best word of advice: Believe in yourself and in your ideas.
STEP 2: ORDERING UP / "WHAT CAN BE DONE ?" STEP
Now, we got a brainstorming. The size of it depends on your ideas and imagination. For Wraith, I had 2 pages full of ideas, but, for Tengoku: Kingdoms of Heavens (which is a MMORPG), I had about 30 pages full. It really depends on the project size and your ideas (and your font/handwritting size).
Time has come to order things up. Now, this is the time you have either to think by yourself, if you don't code your own game, to see a programmer (or a programmer you work with) about some of your ideas. Now, we'll strike the things that cannot be done, or what doesnt make sense. It's now time to create a first draft in order of our ideas.
In my own brainstorming I had for example: "STORY: Dennis falls in love with Lenneth" "STORY: Tyler gets a hand gun" "STORY: The villiant is presented as Kain" "TECH: Player get 100% freedom in the game"
First, what cannot be done... A player can't never really get 100% freedom in a game since the game is based upon rules (just like our own world). This was a stupid idea (not an idea nonetheless), although, it cannot be done. So I stroke it down.
Then, what doesn't make sense... Considering Wraith is a FPS Narrative game (see Farcry for xbox for somekind of example) into a scary/trailer atmosphere (see Indigo Prophecy (or Farenheit for Europeans) for an example of the atmosphere) a love scene doesn't make sense, so, I stroke it down.
Then, ordering up. It is good to order things up in chronological order (as they happen in the game), although, you cannot determine small details at this point (mainly because you dont yet have a game idea). Note that things can change through your development/designing phase, but can also change in the programming/beta phase. Somethings are hard to figure on the development if they (or not) make sense.
As you noticed, I wrote "STORY" or "TECH" beside my ideas. This is my personal drill of remembering what event/idea is associated with what. Indeed, in this one, it was obvious, but in some cases, it's not as obvious as it seems.
After you are done striking things and ordering, time to copy what you have, in order, on another sheet of paper (or another notepad document... or then if you use notepad, copy/paste is your bestfriend).
Once this is done, CONGRATULATION, you got the draft we need to start the development document.
STEP 3: DEVELOPPING THE GAME IDEA
Before designing a game, you need to develop your idea into a better state, something more understandable for the general people that will have access to your development document.
NOTE: Development documents are, yes, supported and copyrighted under your name for intellectual properties of your idea. Although, read below for more informations about how to make it valid, as it's not technically automatic.
So, we got a draft with reasonable ideas. Time for us to write a document. I suggest you do it clean on the computer with Microsoft Words or OpenOffice (which is a free alternative, but... it's maybe not as good as it seems). This document can be 2 pages, and can be 30 pages. All depends on your game size in ideas, really, but what is important to know: In this present document, you have to fly in a general matter. Which means, don't start doing the dialogues/narrations/drawings.
How do we do such a document ? No one has the same way of doing it. As you are not making big commercial games, no need of having a 300 pages document. 10~20 pages might suffice.
What you need to put:
SECTION I - General Description of the game (What console its gonna be on, who is your team, who does what, what the synposis of your story is, how will it work, how much player will there be)
SECTION II - Detailed Description (Go in depth inside of the story, describe chronological events, if you need actual history details do your research and put your details here, how will the battle system work, if its 3D, how do you manage to get an engine working, mainly all details go here)
SECTION III - Detailed Teammate Jobs (In this section your describe who will do what if you don't do everything by yourself. You have to put every details of every aspects of every jobs so everyone know what they are "hired" for.)
SECTION VI - Distribution Plans (How do you plan to distribute the game, will there be any legal issues to deal with, where will you advertise your game, will you give active news of the development and if so what details should and shouldn't be told within those reports)
This document is mainly to gather your "non-artistic" ideas together and put a general storyline. This document is available for everyone working with you so they know what they are working on. Its the first step in your game.
STEP 4: DESIGNING YOUR GAME
Now, time for us to be artists ! Now the time has come for us to develop the story to the max (this means all the story in all aspects, leaving no details behind). This is where your brainstorming comes in handy because you will need it to place all details of your story.
A designing document is splitted in 3 sections for this tutorial, although it might be more.
SECTION I - The story (in this you detail the story from the beginning of the game (the intro) to the final scene (the ending) You say who are your characters, you detail them in pretty much everything (hair color, eye color, behaviour, tone of voice if you plan to add voice actors, and any other details that will be usefull for the drawing of your characters) make sure you do a background story for them because they need a previous past and a future within your game.)
SECTION II - Dialogues (This section is optional if you don't plan to have characters or dialogues. Do not start minding about passive or active mode in this part of the development, reason simple, you are not professionals and you don't work in a big corporation with thousands of teammates... You will have your team with people you know and that can ask you questions. Make sure of one thing though, YOU MUST specify the emotional state the character is in when he spoke his line. Also, includes, like a movie scenario, what the scenery looks like, if the character is off-screen or on-screen, and what movements he does... the movement and camera description are mostly for 3D games, but nice detail to know nonetheless)
SECTION III - Designs and Drawings (Time for your sketching skills. You draw what your character looks like, what some levels would look like, and what you expect to add as drawings inside. No Sprites / modelling is used in this part, it's only basic artworks).
This document can easily be 50~100 pages. Don't be scared of putting as much details as you can for the story/dialogue part. It is very important as this document will be your bestfriend for the rest of the game creation process. It will include EVERYTHING you need to do when you (or the person in your team) will code the program to know where to go.
STEP 5: GATHERING THE RESOURCES
Now, we have a development and designing document. Your game is done over the designing part and we know what we need to do, what the atmosphere will be and how we will manage to create the things the programmers will need. Before attempting programming you need everything you will need through the game:
- Sprites (Google this or draw them yourself)
- Musics (ocremix.org is a good resource or modarchive.com for mods/xms)
- Sound Effects (flashkit.com is your new bestfriend)
- Background Images
- Misc Images for the Menus (Skinning)
- Models (If you do 3D game)
- Maps (Or get one of your programmer, or yourself, to create a map creation program mainly for 2D maps. For 3D maps (if you use C/C++) I'd recommend going with Quake 3 map engine to begin with).
- Voice Acting Files (If you plan to have any. If you need voice actors go to http://www.voiceacting.co.uk/ and see how you can do auditions. Warning: Those people have an over ego on that website, so, respect the rules and make sure to read the FAQs properly in order not to get ban on your first post).
This step is called "Gathering the Resources" as programmers (or yourself) won't have to deal with it in the future. Indeed, needs might come or modifications might need to be done, but at least the biggest part is already done.
STEP 6: GAME PROGRAMMING PLAN
So, you got the resources, the documents, and now the last step before programming the game ? The Programming Plan ! Programming plans are more like checklists in your case. For one, to know whatever which programmer is working on if you got more than one programmer.
What's important to know is the order of programming. You do your list however you want as long as its comprehensible. That plan allows you to identify the progress of your game too !
The order of programming ? What is that ? Most people will program like this:
"Scene 1, add sprites, do the events, and shove the story in", and after 5 scenes get losts. It's normal. Before programming story, you need to program an engine. For a simple 2D RPG, you'd need to program:
- Map Engine: Everything that deals with map files reading and displaying
- Sprite Engine: Everything that deals with the map engine for the sprite movements, attacks, and the limits of the maps (a character can't go through a tree)
- Battle System Engine: Everything that relates to the battle system (and sprites within it)
- Sound/Music Engine: Everything that deals with the music/sound effects/voice.
- Menu Engine: Everything that deals with the menus.
- Dialogue Engine: Everything that deals with text boxes.
- Monster Engine: Basically said: the AI.
Once all those engines are gathered into one, it's time to make it look good with story and stuff. So, you code your monsters in, your story, put your events. For an RPG, RPG Maker is the best example of what an engine looks like. Basically, every company creates a "RPG Maker" (or "Whatever Maker" of their game), to only have to care about the resources to add, rather than adding them one after another.
Big steps are the engines and there is side-steps that, again, you have to put in order. Let's take a Map Engine for example:
- Create a Map Editor
- Make the Engine load tile from files
- Make the Engine load tile definition from files
- Add Event Handling at Locations X and Y
- Make the map scrolling smoothly or create transitions
- Make sure the map respects the limits and that the limits of the maps are well done.
- Make a layer rendering for under-layering movements.
- Allow map animations
- Make sure the engine is easily usuable and the content will be added easily
This is how it's done for each steps you consider as important. Once all that is done, either you do everything yourself (which can seem big), either you work in teams. If your work in team, then, someone can do the map engine, someone can do the sprite engine, etc...
Once you attributed tasks and everything is written on a clean document, time to print and you have one more document, and now, you are ready to send it into production, this means: Programming ! The Dream will come true !
STEP 7: PROGRAMMING THE BETA GAME
All programmers should now have: Development Document, Design Document and Programming Plan as well as all resources you gathered. The choice of programming language will depend on the programmer skills (or into company, don't try to know... it's C++). Programmers needs the appropriate skills or the programming will go slowly (although for beginners its the best way to begin).
What you do when you program the game ? Thinking. You take your programming plan and go ONE STEP AFTER ANOTHER IN ORDER ! If you don't do it this way, you obviously will get lost.
So, when you take one step, you analyse what you should do, and how you should do it, and what would work and what wouldn't. Optimizations ? Not yet, we are only at the beta programming, we don't care more than having something that works. This is what beta are for, we only want it to work, and work fine. Smoothly is not in our dictionnary for now.
Then, your analyze is done... let's start programming !! WRONG !!!!!!!! This will make you lost track of your own codes, and you will get lost, AGAIN. No, the first step of programming is to create a PSEUDO-CODE. What is that weird name ? How can it be done ?
A pseudo-code is mainly writting in english what we'll translate with our programming language. Some people do it in another document, I personally do it in comments. The "how you do it" depends on you (or what the team/company requires you to do). The following example is a hello world in C, but you will get the idea of what a pseudo code is (with my own technique).
--[[ PSEUDO-CODE ]]--
// Create the Main Loop
int main(int argc, char * argv)
// Initialize the Variables
// Display Hello World on Screen
// Add 3 to variable x
// Return 0; End the Program
--[[ PROGRAMMED CODE ]]--
// Create the Main Loop
int main(int argc, char * argv)
// Initialize the Variables
int x = 2;
// Display Hello World on Screen
// Add 3 to variable x
x += 3;
// Return 0; End the Program
With the pseudo-code before programming, I was able to figure out:
1. What functions would I need to create ?
2. What API would I need to use ?
3. What do I need to create something ?
4. How should I create it ?
5. Is my function is done creating ?
6. What my own function is suppose to do or what does it do ?
Also it helps for:
1. Bug tracking
2. Another programmer reading the code to understand it
3. Understand your own code
4. Avoid getting lost in codes
This fits for any programming languages as long as it supports commenting (which 99% of them does).
So, once your pseudo-code is done (or at least a good part of things you are sure of needing for your engine), time for you to enjoy your programming which is the longest time consuming step.
STEP 8: BETA TESTING, DEBUGGING AND OPTIMIZATIONS
Now, get yourself some people on the internet to test your software and take their reviews and comments. This is the part where your program is done, and it's time to perfection it.
Perfection doesn't exist, so, don't think you program will be bug free, no program is bug free, but at least it will be nice, smooth and playable. Beta Testing allows you to see bugs that you don't see. It can be little things like typos, as much as it can be a big thing, such as a tree floating over the ground. It's things that doesn't necessarly catches our attention, but can be bad for reviews.
Also, this is the time where you optimize your code to make it as fast as you can and make everything run as smoothly as you want. In this phase you are already done with the beta testing, and you just add some personal touches to your code.
STEP 9 (OPTIONAL): DESIGNING BOXART AND DISTRIBUTION
Indeed, you can't do this step for console programming because you don't have any licenses to do it, but I thought it'd be nice to add for PC games where you can do whatever you want once you are done !
You can design a boxart, and distribute your game, but this cost a lot when you want to do it like big companies. I suggest you to go to http://www.cafepress.com where they can press your CD with your BoxArt and Distribute it on their website to make sure you get some money out of it. You can also make it a "free downloadable" game on the internet through your website. Really this only depends on your personal decision on the subject.
ANNEX I: LEGAL STATEMENT OF YOUR DOCUMENTS
Your documents are not fully copyrighted, that's normal, you don't have to get big time copyrights over them. Intellectual properties protects everything you do write, but you need to do one easy step.
First, get your document printed and get yourself a big enveloppe. Then, put all your documents (and a CD of your source code and resources) into the enveloppe and seal it. Put your own home address on the cover and send it to you.
The stamp of your post is your date proof of creation. All post offices are managed through your government, so, in front of a judge, this is perfectly viable as proof of the creation date.
IMPORTANT: DO NOT NEVER IN UNDER CIRCUMSTANCES OPEN YOUR ENVELOPPE ANYMORE AND PUT IT IN A SECURE PLACE. The only time you will need to open the enveloppe is in front of a judge. Make sure that at least one of the documents inside contains your signature.
You have to do this for stuff that: ARE NOT COPYRIGHTED BY ANYONE ELSE BUT YOU AND/OR YOUR TEAM ! Anything like sprites/musics/SFX that you dont create yourself (or are free to be used) are viable to this... if you use edited sprites or the same sprites as another game (same thing with any other resources included GPLed source code), is NOT valid and you lose your intellectual properties.
If those materials are required, put a note inside of the enveloppe that (and you have to say every file names, from which place, and copyrighted to who) those resources are copyrighted to their respected authors.
Overall, I hope this tutorial helps you and will make you enjoy game development and game designing and game programming much more. Organisation is a great thing to have and create good assets for any good games.
Personally, I am not a programmer anymore (I go it for my own pleasure and projects). I am professional game designer and game developper (search on wikipedia for the definition of both as they are long to describe properly) but not because i am "better than thou", but simply because I am related (in a far way still) to the industry.
No one is better than you, everyone has their own style.
On those words, enjoy making your game !