View Full Version : How to make a plan for game? Help Please.

06-01-2004, 07:47 PM
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.

06-01-2004, 08:54 PM
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.
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 (http://www.alistairkeys.co.uk/design_process.htm).

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.

07-01-2004, 08:56 PM
thanks for help alimonster

05-01-2007, 12:34 AM
This is pretty darn old but I would like to add to it regardless.

I'm not sure what standards most people follow but my way doesn't seem to be all that bad either lol.

I basically have an idea pop in my head and I start making it, I think about what will go into it (beside some basics) as I go, same with any software and games.

Like uhh, if I wanted to make the allmighty, overdone mp3 player, i'd think of the basic things to do, do them, then think up the rest and do them :P (well iv'e done it before so it seems to work for me lol).

Iv'e never gone for this "plan everything ahead" thing, don't have the time for it and i'd hate to waste all that time planning instead of programming and learning by actually doing something :P, cause in the end if I think about it too much It might not be worth it.

06-01-2007, 03:38 PM
I used to work in exactly that manner Chesso, in fact our PGD 2006 Competition Entry was created like that and it cost us first place ;-)

I jest, but, from someone who used to do everything in the exact manner you describe, my advice to anyone looking at writing software is to think ahead and plan. If you, as you suggest you might, lose interest during the planning phase, then I would ask myself whether I really wanted to write the thing in the first place.

Get yourself some tools like dotProject, Mantis bug tracker, a Wiki and a good old fashioned pencil and paper and plan the project before you get started. I think there is nothing more disheartening than getting a certain way into a project and then simply not knowing where to go next (that exact situation nearly killed our on-line game many times) and planning can help alleviate that problem.

You don't have to be specific... I ended up with just a list of things I had to do on a scrappy piece of paper blutacked to the wall in front of me... as I did them I crossed them off... theres a certain amount of satisfaction to the closure that provides... as your to-do list gets smaller you know you are getting closer to finishing the project. With little projects... the kind you can complete in a month or two its not so bad, but when you spend years working on the same thing... not seeing progress is a real killer.

Plus if you plan and think ahead, you can create a testing regime for the project (very important) and it can help you anticipate problems in the design (this is where I came unstuck with our competition entry... I dived in and created a complete mess that required a rewrite to fix... as a consequence we didn't meet the final stage goals).

You also said that you felt it was a waste of time because you weren't learning anything... in my career, I've noticed that my estimations of time scales for projects can sometimes (read usually, but just in case my boss is reading ;-) ) be so totally wrong its unbelievable. This has landed me in some serious situations... one or two of which have nearly cost me my job. If you plan your projects, you can learn and improve your planning skills using your own time where you're not going to fire your ass if you get it wrong. So instead of telling your boss it will take 3 weeks when what you actually should be telling him is say 6 months, you'll be able to give them reasonable time scales that you can stick to (or even better... you'll bring in the project ahead of schedule, although this can cause complications of its own).

This isn't meant as a lecture, just a bit of advice from someone who used to think exactly as you do :-)

06-01-2007, 04:15 PM
Luckily for me, time isn't a constraint, It's purely a hobby and I would most likely not do it as a profession (I prefer Pyshical labour to help counteract my somewhat anti-social and lazier hobbies aside from skateboarding).

I do plan, to a degree, but not far ahead or anything overboard, mostly jot down ideas in notepad or in the source itself.

If there's going to be anything added or changed along the way I usually think of it when I need to, if I waste alot of time too many features and things ahead, well alot of them more than likely won't happen for one reason or another lol.

The easiest way to figure out if an idea will actually go with what your doing, is to actually have something right infront of you, already up and running.

Maybe if I was doing this as a profession I might do things differently, but I prefer to keep it as a hobby.

08-01-2007, 03:05 PM
Well, I just had to respond to the thread when I saw it come back to life. I think I have started to cover off on why documentation is so important in my first article here on PGD (Foundations of Game Development: Project Design and Documentation (http://www.pascalgamedevelopment.com/viewarticle.php?a=67&p=1#article)). Of course, as the series goes on, I'll continue to talk about documentation and how it affects Marketing, future expansion design, backend development easement, and how it can help you go from wanna-be to professional.