Archived

This topic is now archived and is closed to further replies.

How long to you spend planning?

This topic is 5843 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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;

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
Here''s my way to go about it. First, get come paper and pencil. At the top I write the name of the program. Right after that, I describe in a one line sentence what the goal is and main point. Then some simple graphic scenes after that so I don''t forget my graphical ideas. Then after that is controls and menus. Then the gameplay and strategy. Then the levels.

After writing that out, usually about a page double sided, I type it up and make some graphics in a 3d modeler or 2d modeler so I can get a feel of the graphics. Then I just type it up and orgranize it. After that, print it out and you have a good design. It usually takes about an hour or two and then you have the basics. Everytime you need to implement something not in your design, add it to your typed design. At the end, mine are usually about 5-10 pages.

If you are in school, thats great because in those boring history lessons, write out your design while pretending to take notes. It makes the teacher think your paying attention. :-)

Share this post


Link to post
Share on other sites
Well, it really does depend on the project but i normally spend about 1 or 2 hours designing the acctual structure. Then i''ll write some main code on a section (graphics, main body, class, ect) then i''ll go and write some more design about the specific thing i''m working on now that i have a better idea how things are working. I''ve tried doing an entire project at once but have failed so far.

Share this post


Link to post
Share on other sites
I began programming before I knew exactly what the words "design document" meant- I was 8 in the early 80''s, using a Commodore 64. Unfortunately, bad habits die hard and I still program like an 8-year-old. Since It''s always been for fun, I stuck to the two factors of programming I enjoyed the most: brainstorming and logic. I began with pencil and paper, laying out what kind of game I would like to make. No real "design document" structure there- just getting rough ideas out onto paper, and after a few pads worth I had a good "feel" for what I wanted to make. After defining the basic gameplay (knowing how I wanted it to turn out), I boiled it down to component parts: gamestates, data structures, control, graphics, sound. Then the programming, where I take the game step-by-step from the ground up, and work out the logic on how to implement all of the above. Usually along the way, I come up with "hey, this''ll be cool"... TONS of feature creep. Not really a bad thing, when all the fun to be had is in the creation.

-Tok.
~Feature Creep of the Family~

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
A lot of good ideas on this post...

Personally I like to write up a design document first. It''s all about abstraction, start with the basics then dive into the details a layer at a time. Start with the GDD, then work out the Technical Design Doc. From those you have a clean plate for planning your classes, once that''s done, work on the code for those classes. Then get into the nitty gritty with the actual game code using those classes. The beautiful thing about this method is that it saves so much time and keeps that feature creep out. You will know from the start what is possible and what isn''t and you''ll have much more time to figure out how everything will work together.

And Capt. Jester has it right on the money... Make it work, then make it right (fix the bugs), then make it fast (optimize). Oh ya!

D

Share this post


Link to post
Share on other sites
Well, my current method is something like this

  • Decide the type of game to make. This guides step 2.

  • Research engine design

  • Design engine

  • Implement engine, use stock materials where necessary for visuals

  • Design game to be used with engine

  • Implement game using unique intellectual property.



It''s going to be different for each person you ask. Just go with what works, and, above all, finish what you start.

Later,
ZE

Share this post


Link to post
Share on other sites