Some time ago i and my friend started creating a game. We were making it without any plan. And after some time didnt know what to do then. We thought the we have to make a plan before we star...But we dont know how. Does anyone know. If does could he help me.please. i'd like to know what it should consist and smth like this.
Big thanks.
Mathew
There is a specific design process to follow for software, although it's targeted at the more mundane aspects of the software business. I'll try to focus your mind on some of the thoughts you should be having about a new game, and then I'll cover a bit about ways to document what you're doing.

First and foremost, you need to decide some utterly basic things...

Do you want to create the game for fun or profit (choose one initially). You're unlikely to get much profit if you don't have a completed (good) game under your belt, so it's usual to prefer "fun" for the first few times. If you're confident about your coding abilities, you may decide to go for profit. At this point, you can consider whether to do a freeware "version 1" of your game, which can be released as freeware to build up some recognition, following up with a second version to leverage your experience, or whether to go full-throttle and create a for-pay version 1.

Next, another basic point: are you going to be working with other people? Do you know these people, and how do you plan to organise your team? Creating games by yourself is a quite different experience, although it can be easy to fall into a habit of time-wasting. Of course, you've answered this question in your post, so don't worry about it just now.

What sort of game are you planning to make (what genre, are there any other similar games, and so on).

The next point is quite fundamental: who is the target audience? Do you expect other people to play and enjoy it, or are you just creating the game because you like the idea and the process of making a game (not that there's anything wrong with that, of course!). Decide on a basic demographic and keep a focus on it. For example, if you're making a fast first-person-shooter, don't bog down the player with minutiae, like boring puzzles or having to traipse through barren maps you've seen before. Similarly, for a turn-based strategy, don't include elements that require fast reflexes. Of course, these are only guidelines, so feel free to go against the grain if it fits your game. At all times, though, think "will my target audience enjoy this aspect of the gameplay?"

The above may seem elementary, but it's all too easy to lose focus on the game and end up sitting idle. I know this because I do it a lot (I enjoy the process of making games and don't care if anyone else plays 'em ).

Now, the above can be consolidated into the design process method, which is documented on my site.

The very first task at hand when designing your game is a problem definition: what are you going to do? You want to make a space game, and stuff like that.

The feasibility study may be something that you'd skip for a "do it yourself" home-brewed game. This document intends to cover whether the given idea is feasible, noting stuff such as risks (legal and technical), constraints, ...basically, whether you can do the task at hand. However, in the context you've given (you and a friend working on a game), you're unlikely to come up with a "no" answer. The feasibility study is really intended for underlings to pass to higher up people, or to pass onto outside bodies if you're trying to get funding (or whatever). You don't care whether you can actually do the game, I guess, because you won't mind crashing and burning. Well, that's my assumption here anyway.

You can also do a project plan document. The project plan is exactly the sort of thing that nobody has the discipline to do in real life, but it is quite a useful document (if you're forced to write it for university coursework!). The project plan talks about the software that you're going to use, deliverables (solid documents you're going to write during the development), management stuff (identify possible development risks, such as lack of experience or dodgy tools, and what steps can be taken to minimize those risks, and other such stuff), how you're going to control quality, milestones (quite important dates -- like, when you plan to have an alpha version, or when you'll have prototypes for user testing). Here's a snippet of the work breakdown section from my project plan (probably old and incomplete because I didn't take my project seriously):

1. Project Management
a) plan the project phases
b) identify phase duration and their schedule
c) identify deliverables
d) identify resources required
e) perform a risk analysis
f) document project plan
g) review project plan
2. Initial requirements capture and design
a) perform a feasibility study to determine if the project is worth undertaking
b) identify typical users
c) identify requirements of the system
d) prioritise requirements (need and priority)
e) use priority to identify functions for build 1, and build 2
f) document requirements definition
g) requirements definition review
h) perform initial design
i) initial design review
j) revise project plan
3. Risk Analysis and Alpha Prototype Implementation
a) research major risk areas
b) identify different methods of implementing each
c) prototype each with preferred method
d) evaluate feasibility of preferred method
e) revise project plan
4. Requirements Capture and Design
a) refine initial requirements
b) document requirements specification
c) review requirements specification
d) distinguish between functional and non-functional requirements
e) refine initial design
f) perform detailed design
g) document detailed design
h) detailed design review
i) revise project plan
5. Beta Prototype Implementation and Testing
a) produce beta prototype
b) devise test plan
c) perform and implement unit tests
d) document test results
e) test review
f) devise and perform evaluations
g) review project plan
6. Final Implementation and Testing
a) produce final implementation
b) repeat unit testing
c) devise integration tests
d) perform and implement integration tests
e) code walkthrough
f) repeat evaluations
g) document test and evaluation results
h) produce user guide and installation guide
i) produce help files
7. Report
a) collate documentation
b) append references, contents, glossary
At this point, you've covered the basics of the process that you'll be following: what kinda game you want to make, the tools that will be used (compilers, art packages, word processors, etc.), whether you can actually do it, what risks may crop up, and other such stuff. But you've not actually discussed the game content.

The next section of the design process goes into detail about what you want to achieve.

The first document may well be a game design document. I have an example one for you, which is probably the best way to see this. Private Message me if you're interested. The game design document discusses the background story, the gameplay, the menu structure, attract modes (demos, high score tables, and so on), the gameplay itself (you blow up stuff or conquer planets), and basically talks about the entire game (the interesting stuff). You should also talk about assets you'll need (sound and artwork).

Anyway, this post is long enough. I'll finish it tomorrow sometime.