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 .....
1
tips for a game design ....
Started by josejps84, Jul 21 2006 11:36 PM
2 replies to this topic
#2
-
- Members
-
- 459 posts
Senior Member
Posted 22 July 2006 - 01:16 AM
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.
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.
#3
-
- Moderators
-
- 1699 posts
Senior Member
- LocationThornhill, ON
Posted 22 July 2006 - 03:16 AM
As SamuraiCrow stated, document everything. A typical software life cycle includes:
1) Brainstorming
- Jot down ideas, short stories, and anything else on the mind
2) Researching
- 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, etc…
4) Requirements
- 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 you.
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.
6) Implementation
- “Follow the yellow brick road”. With 4) and 5), this part should be a breeze.
7) Testing
- 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 =)
1) Brainstorming
- Jot down ideas, short stories, and anything else on the mind
2) Researching
- 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, etc…
4) Requirements
- 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 you.
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.
6) Implementation
- “Follow the yellow brick road”. With 4) and 5), this part should be a breeze.
7) Testing
- 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 =)
http://www.nutty.ca - Being a nut has its advantages.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users
