When planning to make a game, should I cover everything before actually starting?

Started by
6 comments, last by Slateboard 12 years, 3 months ago
I believe it's called Pre-Development. I've been putting down ideas, etc of what I want to do in my game. What I want to know is if I need to (or if it's preferrabe) to cover every detail in this stage, or should I focus on the major points?

For example, I've already outlined all of the actions my character can perform as well as how the environment of a level will accomodate it. Am I doing this 'correctly' or should I be taking it further somehow?

I'm aware that the development process is prone to involve changes at any time, so I basically don't want to overdo it only to end up having nothing to show for it.
Advertisement
I call it Pre-Production, and yes, the design should be written in Pre-Production, not after you start programming.
Then again there's Iterative Production, in which you start to produce the game, then try it on for size, then make alterations (you "iterate").

-- Tom Sloper -- sloperama.com

i am a beginning programmer but have somewhat more experience in managing web & web design projects.

with these last projects, i prefer the iterative method by far, because its impossible to predict everything beforehand.

My personal blog on game development!

Black Wolf Game Development

As it is For Beginners forum, I strongly recommend you start small.


Start with text-based Tic-Tac-Toe. Have you done it (or an equivalent) yet? That's a good one to experiment with logic and AI. The design documents for it are straightforward, and implementing a min-max AI is usually part of an 3rd-year university course.


After you can handle a few text-based games, move up to pong for a graphics game. Have you done it (or an equivalent) yet? That is a great introduction to graphics, animation, collision detection and response, audio, input, simple menus, keeping score, and much more. If you are feeling ambitious you can expand it to air hockey once the basic pong game is finished.


After that is often a Breakout clone, which gives all the same (graphics, animation, collision detection and response, audio, input, menus, scores, etc.) and also adds level design, map loading, and multiple levels. It can also add multiple types of blocks, which can add some novelty and increased game difficulty.



Choosing to start with a broad story-based RPG or similar character-based game is probably much too big for a For Beginner's post.
Well my current project is a Pong clone. I've been working on it off and on (I'm a College Student) so my main issue with that is consistency. Occasionally, I have little ideas that could work with a new/pre-existing game idea so I write it down somewhere.

Once I complete Pong (I've already got a list of what I want to accomplish with it), I plan to work on one of these ideas depending on the scope of them. Most are seemingly simple like top-down shooters or side-scrollers, and some I put aside because I lack the experience to make them what I want them to be.

Maybe I'm concerned that I'm not prepared enough for the development stage.
On my current project, pre-production ran for a couple of years (on and off) before I thought the idea was solid enough to begin work on it. In the year of development I've put into the project since I've run into plenty of issues I didn't foresee in my planning, as well as come up with countless new ideas that I only thought of due to implementing my ideas and make them concrete. What I mean by that last line is that when an idea is just an idea it doesn't have to pass strict tests for correctness, its given some leeway for the details to be "fleshed out later". But when you come to implement the idea, you can't hide from the details, they have to be done. I find this is a good test for how good the idea is, and you have to be prepared to throw away ideas that you love but can't get to work.

To sum up, unless you're writing something simple that's a clone of another game I would argue that you can't possibly think of everything before you start. I've read design documents for some of the big games that clearly took months to write, and though they do cover the vast majority of the final game's mechanics, there are always differences, where the original idea simply didn't work in practise.
[size="2"]Currently working on an open world survival RPG - For info check out my Development blog:[size="2"] ByteWrangler
Lost Garden author and successful game designer Daniel Cook recommends Game Design Logs rather than writing a long design document up front. Take a read for a good article on an alternative approach to writing your design document in pre-production that encourages and works well with an iterative approach to design whilst still creating some solid documentation of the project.

He also has an article on Post-it note design docs which outlines a process of quickly documenting your thought process using post-it notes, and one covering Common Game Prototyping Pitfalls which you may run into if you're not doing your design up-front.


A detailed design document is great for a software package (such as a word processor, database, whatever) that serves some particular well-defined need, but will probably not be the best choice for any non-trivial game where experimentation is often needed to "find the fun". Unless you're making a simple clone of an existing game, I would recommend only minimal design up-front; the exception is if you're planning to recruit others, when you will probably want some sort of pitch document outlining the idea and attracting people to join up.


Hope that helps! smile.png

- Jason Astle-Adams

I am so glad I made this topic. Everyone has provided me with such valuable information. I'm starting to see the path that will work best for me.

This topic is closed to new replies.

Advertisement