Hi, I’m newer in game developing, I’m in the design phase and I just
want some help, tips, advices, links, anything from experimented people
for don’t make so much mistakes and learn faster about game design ….
Thanx for your help and your time …..
Please log in or register to post a reply.
Plan everything out ahead of time. Put some stuff on paper. Get as many
kinks worked out ahead of time before you start coding the game. Maybe
experiment a little bit with short programs before you try anything big.
Plan to take time at it.
If you really need a shortcut then get familiar with an existing game
engine or graphics engine instead of writing your own. That makes things
easier in the end.
As SamuraiCrow stated, document everything. A typical software life
- Jot down ideas, short stories, and anything else on the mind
- See if anyone has done it before. Look at other projects and see what
you can extract and use from them. There’s no sense in reinventing the
wheel, so take advantage of this.
- Append any interesting findings to your initial brainstorm list.
3) Game Design Document
- The purpose of this document is to collect all your thoughts and
organize it into a document for reference. It is not meant to go into
specifics, but after reading it someone should be able to understand
everything about your game, who it’s targeted for, the plot, features,
- This is the stage where you get into specifics. Programming
languages, engines, APIs, a comprehensive list of features and specific
details, environments (build, test, etc…) and so on.
- Once you complete this document, there’s no turning back. You cannot
have any “maybes”, everything listed herein is 100%, straight to the
end. It’s designed so that you follow it religiously. If done properly,
your development time cuts down considerably and you’ll find it very
easy to move from one milestone to the next. Everything’s laid out for
5) Design Document
- The requirements document listed high level problems and solutions.
The design document gets into programming related issues from the
requirements document. Things like how components will work together,
the structure of your code, database design and schemas, and so on.
- This document is used primarily by programmers. They need only look
at the diagrams and implement what they see.
- “Follow the yellow brick road”. With 4) and 5), this part should be a
- Most people forgo this, so it’s up to you. Ideally you create a test
plan which documents how you’re going to test your software. What
approaches will you take and what tools you will use.
- Following the test plan, you write down several thousand test cases
and later verify each one. If all test cases pass, your software will be
the first to ever achieve such a status =)