How long to you spend planning?

Started by
14 comments, last by ysotuff 22 years, 4 months ago
I was just interested to know how much planning people do before they start a new programming project. Do you write up a design document? Set up a schedule? Figure out what sort of resources you''ll need? And if you try and figure out how long it will take to finish your project - how close are your estimates when you finish?
Advertisement
i think most of us try to set realistic goals... and then attempt to stick to them somewhat...
i believe jack hoxley wrote an article here somewhere on time managment in a project and how to stay on schedule.. it was a pretty informative read...
for the most part though, if you have a full time job or school or whatever like most of us do, you should really take all that into consideration when setting up a timeline.


-eldee
;another space monkey;
-eldee;another space monkey;[ Forced Evolution Studios ]
I''ve been planning on writing a game for about 20 years now, still haven''t started on it though
Keys to success: Ability, ambition and opportunity.
It depends on the complexity of the program.

If it is just simply input data, sort data, output data, there''s not much to do, so I just get to programming.

If it is an acutal game, I generally write a rough sketch of what I''m going to do in pseudocode, and think things through.

That''s what I do.
I think it is a good idea to do everything you said. Make your design document. In the document get as detailed as you can at the start. State things like, the graphics will be mxn bitmaps, there will be x number of frames for animation per sprite...etc

You can try to make an estimate before you put your design doc together, but it would probably be easier to nail down once you have it finished. The key to finishing is having a solid design doc, this keeps you from getting to frustrated by thinking up things as you go along or changing things because you didn''t plan for it.

Any time estimate you come up with you should take that number and double it and you will be pretty close to the real amount of time.

---
Make it work.
Make it right.
Make it fast.
"None of us learn in a vacuum; we all stand on the shoulders of giants such as Wirth and Knuth and thousands of others. Lend your shoulders to building the future!" - Michael Abrash[JavaGaming.org][The Java Tutorial][Slick][LWJGL][LWJGL Tutorials for NeHe][LWJGL Wiki][jMonkey Engine]
Before I design anything on paper (either digital or physical) I''ll almost always write a test implementation of my idea to insure that it is feasible. Afterwards I''ll either revise my ideas and try again or write down (normally in a fairly sketchy manner) the ideas I had. Then I''ll finally write a final implementation which is normally much cleaner than my first attempt. All of this is for larger projects, of course, for smaller ones I''ll just jump from demo to final without writing anything down .

[Resist Windows XP''s Invasive Production Activation Technology!]
The first thing I do is write upa Concept Document.

My Design Document is derived from the Concept Document, but everything is touched upon as much as possible. I usually spend a few days on a small design document.

Before I start programming, I open up Flash 4 and draw something that should be identical to the game in C++/ SDL/OpenGL ( thats what I use.. ). I don''t actually make the game in Flash, it is more like a screen shot. If the game looks like the screen shot, then I reached my goal.

Im in the proccess of doing that right now
------------------------------Put THAT in your smoke and pipe it
hell, i cant even write 1 paragraph without falling alseep

how do u ppl even manage to write 1 page of a design doc?

"Those who serve no purpose, have no purpose"
--------------------------------- "Those who serve no purpose, have no purpose."- SSC Oh the possibilities!!Edited By - SonShadowCat on Your Girlfriends Birthday

I love the design phase! My ideas are always pretty extreme... too extreme for a single person to implement... but I''ve found a good method for dealing with my over-zealous daydreaming =)

I''ll usually spend a couple of weeks building a huge concept. Then, I try to simplify things down to something realistic... this is important ''cause when something is too complex, you can''t truly envision it... but when you simplify it, you will surprise yourself with what you''ve created.

Next I begin writing up concept documents to nail down the idea and design documents to solidify the game rules and mechanics. One possible path is to drop the idea for a while and move onto something else. If you come back to it at a later time and say "WOW!" then it''s definitely worth the development effort.

Sometimes, I actually put the game into pen and paper to try to balance it. This is great for strategy games =)

The next part is very important... I always have to trim the idea. I have a huge game concept but there''s no way I can do it myself so I cut it up into a series with the first being something very feasable... something that will test out one or two aspects of the overall game... say... weapon balancing and physics. Perhaps a basic shooter?

Man... this is gettin'' long... Anyhoo, I start getting technical by writing up requirements and OOD docs to get an idea of just how far I can get into development. 3D graphics? Should I bother with textures... trim away everything that is gonna take up time and concentrate on creating the actual game.

Timeline? Hehe, I do this in my spare time... I couldn''t even contemplate a timeline! =)

I''ve always spent a lot of time designing... it really pays off! Most of my projects have been small but I''m now working on a major project... it''s an idea I''ve kicked around for 10 years... I''ve been documenting it for the past 2. I''ve got about 40 or more rather large documents detailing every aspect of the development. The game has been in development since August and it''s already fully playable... with the help of a lot of my old DOS code from back in the day =)



Many of the truths we cling to depend greatly on our own point of view

Get Tranced!
Quit screwin' around! - Brock Samson
My experience has shown me that every time I start a project without writing down a design document and without planning, I end up by taking twice the time for coding and by having a non rusable code.
The design document and the schedule help to separate the project in multiple easy tasks and help to avoid the creeping features disease. Ideas of new features that are not in the design document are studied, planned and developped after the game has been finished: I consider them as evolutions of the core game.

For an example of my schedules, here is the project I am on:
(length are standard 8 hours per day, 5 working days per week)

1 - study of win32 graphics engine (no DirectX or OpenGl here): 2 weeks.
2 - writing the design document of the graphics engine: 2 days. (depends on task 1)
3 - coding the graphics engine: 2 weeks. (depends on task 2)
4 - study of the game (simple 2D wargame with FSM AI all infos on screen): 5 weeks.
5 - Writing the design document of the game: 3 days. (depends on task 4 and 1)
6 - study of basic scripting engine: 1 week (depends on the task 5 and 1)
7 - writing the design document of the scripting engine: 1 day (depends on task 6)
8 - Art: 5 weeks (depends on task 4)
9 - implementing the game: 5 weeks (depends on task 3 and 5)
10 - implementing the scripting engine: 2 weeks (depends on task 3 and 7)
11 - balancing the game: 1 week (depends on task 10 and 9)

Critical path: 4 - 8 - 9 - 11. Total project length: 121 days.

When you look at it closely, the critical path is composed of only one programming task against three non programming tasks (game study, Art and game balancing). The graphics engine is not on the critical path: Please note that this schedule reflects only the way I am working, it is by no means a standard of the gaming industry.

When I finish my projects I am usually close to my planned estimates.

Note: the reason why the graphics engine is written in win32 is that the program is designed for the lowest common denominator (win 95, 98 and NT since not all the targeted computer have DirectX or OpenGL installed). No sound/music engine for the moment, it will be an evolution of the core game.

Hope that helps.
Red.

This topic is closed to new replies.

Advertisement