• ### Announcements

#### Archived

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

# How much planning is recomended before you start to code?

## Recommended Posts

My current project is a pong clone written in OpenGL which I plan to use the code as a basis for more complex projects. One of the most boring parts of programing is the documentation. But I hear all you all you "experienced programers" saying that its necessary ... and I agree because as the code becomes larger its gets harder to manage and the docs help a little. The real question though is should you do flow charts / pseudo code and have algorithims all set out before you start to code like they taught you is basic CS? If you dont how will it come back to haunt you later? I tend to add to code as I need things for instance, in my texturemanager class I added code for loading raws recently which wasnt planned. I dont have a design document for my pong clone. All I know is that in version 2 it will have Net play and I want it to look "pretty". It is progressing fine and I hardly have to rewrite code. I guess I could sum it up as I like to see results quicly rather than to the paper work (algorithms and stuff). So what am I in for by not planning the whole project before hand?
"A security issue has been identified that could allow an attacker to remotely compromise a computer running Microsoft® Windows® and gain complete control over it. You can help protect your computer by installing this update from Microsoft." [edited by - try_catch_this on October 13, 2003 12:34:37 PM]

##### Share on other sites
I usually think about it for a while one night or somthing before i start. I probably dont plan enough but my projects arnt huge anyhow. If you dont plan much you code will probably be good and messy and you will have to spend a bit of time fixing it up along the way.

__________________________________________________________________________________________
"I am durk , so what=,ad some one pst porn for sn hour an nobody cred1'' LnodWiep "
" ''msinwe I amjust dcours? "
" i am dnk! bsiness meetng love you skll! mustsmdrd! MndWkpe "
The drunken words of mindwipe

##### Share on other sites
my latest project: a Baku Baku clone, i didnt plan at all..

1: i ended up rewriting a few functions again to integrate properly..

2: the code is basically unreadable by anyone but me now

3: i will plan the basic ''frame'' of everything next time.

##### Share on other sites
The urge to code is always strong, and your hatred of design docs will most likely never go away In your particular case, since you want to resuse your code for more games, lack of good planning will sting even for a small project like pong.

Aside from the likely mess you''ll end up with (spaghetti code as it''s called) you probably run into cases where what seemed like a good idea at the time you coded it turns out to be a bad idea later on. I don''t mean in terms of algos, but design decisions. By only looking at what''s in front of you it''s difficult to see the big picture.

Duplicated code is another thing. Without planning, it''s hard to see where it''s possible to share code. Class A is a great idea now, but later you see that Class B has some simialr functionality. Should they have extended the same base class? Should the functionality be split out into a Controller or Delegate? This sort of thing, when decided at design time, protects you from having to rewrite it later.

Lack of extensibility. This is something you need to think about if you want to reuse the code. Without planning, your objects could become so dependant upon each other that it becomes difficult to add new functionality. Objects will be tightly coupled, making it impossible to replace existing objects without rewriting several classes.

The dreaded dead-end. Without a plan, it is quite possible to code yourself into a corner with no way out except a complete rewrite. I have seen posts of that nature here more than once.

There are many other issues that could arise from not having a good design up front. You will still run into problems as you code, even with a design. But you''ll be able to see the big picture, so decisions on how to solve the problem become more obvious. If I change A here, then I need to add B here to support C later on. Without the design you most likey won''t think of adding B.

You don''t need flow charts, 50 page design docs, UML diagrams, yadda, yadda. Not unless you want them (or you have a boss telling you *he* wants them). I do most of my planning in a notbook I keep on my desk. A few pages describing the must-have features, would-like-to-have features, general game play, and a few notes on details (UI, specific game play poitns, game mechanics). Another couple of pages with a class outline, module dependancies, exposed interfaces, yadda, yadda. Get as detailed as you need to. More detail eases your pain later on, and helps keep you on track.

##### Share on other sites
Would it be ok to do this Doc or your planning in a Text editor on teh computer? I for one dont have the best hand writing and I type faster then I write so its easier for me that way. But do people feel you loose some creativity or detail by doing it on the text editor on your computer?

"Passion is what drives you to stay up until 4am fixing that bug that hardly anyone would notice...Passion is where great games come from, if you dont live and breathe games you shouldn''t be in the games industry." - Dave Pottinger, Ensemble Studios

[GameDev][C++ Page][Game Tutorials][FreeBSD][HawkNL(Hawk Network Library)][NeHe Productions][Mage Tower Ent-My Site]

##### Share on other sites
quote:
Would it be ok to do this Doc or your planning in a Text editor on teh computer? I for one dont have the best hand writing and I type faster then I write so its easier for me that way. But do people feel you loose some creativity or detail by doing it on the text editor on your computer?

sure, i ahvent used my hands to write in a decade...seriously.

##### Share on other sites
quote:
Original post by Anonymous Poster
sure, i ahvent used my hands to write in a decade...seriously.

Wait...you mean......I can make words without a keyboard?
Ha, you guys are crazy...

Lord Hen

[My retarded chatlogs(im rkinasz):1|2|3]

[edited by - Lord Hen on July 27, 2008 2:32:49 AM]

[edited by - Lord Hen on October 13, 2003 3:38:32 AM]

##### Share on other sites
Well, let''s see:

• A game design document - detailing how the game will behave, but not how it''ll actually be implemented

• A system architecture document - detailing the subsystems within the game and how they interact

• A technical design document - giving details on each subsystem in the architecture document, suggestions for implementations, supported file formats, etc etc.

That''s probably all I''d go for. Don''t forget, design isn''t set in stone - there''s a rule (known as the ''eighty-twenty'' rule) which states that only 80% of the design work will actually have been done by the time you start coding; the remaining 20% will be done as you adjust the design to account for unforseen technical problems.

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4
ry. .ibu cy. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu

##### Share on other sites
Wow, I like planning out my programs It''s FUN to make design docs and such. I didn''t used to, but I''ve started doing it more. I''ll try and write out how different classes will interact, and some pseudocode to help get me thinking how to code difficult parts of the program. I''d definetly recommend planning it first.

I usually write psuedocode in notepad or something, but if I need to design a complicated algorithim, I might use a little *real* notepad. Sometimes it helps to draw diagrams, which isn''t as easy on a computer as it is the "traditional" way with paper and pencil.

##### Share on other sites
I find using a physical notebook for design ideas much more comfortable. If I want to step away from the computer for a while I can relax on the sofa and review/add to my design, or while I''m in bed and can''t sleep. Plus, it''s one less thing to back up when I have to do the regular Windows re-install.

##### Share on other sites
"Plans are useless, but planning is indispensable." -- Eisenhower

##### Share on other sites
I have been at both extremes...

Things where everything was planned out first - down to every routine in the code. Everything had pseudo-code, flowcharts, variable lists etc. This was quite difficult and took quite a while, also it''s almost impossible to consider all the issues until you have things up and running (or not, if you get it wrong!). I must say that coding the routines (this was in 68000 assembler) was really, really easy when working from the flow-charts, and most code worked 100% (probably just luck). Having said all of that, I would not recommend this approach, these days I feel it was all just a bit over the top.

At the other end of the extreme is no planning at all. We have all done this, and it''s never pretty! Things are hard to change, bugs are hard to find and fix, code is messy, and you end up scrapping everything and starting again.

These days I tend to fall somewhere in the middle, plan to a certain point where I feel I have a complete understanding of what I am trying to achieve, then start coding it. If something comes up which is hard to visualise, I will get the pen and paper out again. Added to this is a good dose of regular refactoring as I go. This is the approach that works best for me. But eveyone is different - I guess most people just do what feels most comfortable.

##### Share on other sites
Failing to plan, is planning to fail.

Planning to plan, is failing to fail.

Those who don''t plan, teach. Those who fail, teach gym.

##### Share on other sites
I didnt expect so many replies so soon. thanks all you guys were helpful

I have a window class which is abstract enough to create any window, main app window or child using system defined classes. I use this code to make an OpenGL window class. So the OpenGL window has an "is a" relationship to window. My small problem is that right now the OpenGL window can only be a main window. It would be trivial to redesign the class to make it be a child instead of a main window. So far this seems to be my "only" issue. Later on when I start to learn DirectX I can reuse the window class to create a DirectX window. I made sure I named the members with a prefix to avoid problems with name clashes as can occur when you are inherating.

Well I guess I asked what I am in for because all seems to be going well, but its better to be safe than sorry.

##### Share on other sites
Do some googling for "extreme programming" if you aren''t a fan of big up front design. Or even if you are :-)

Planning *requirements* is essential. How can you start building if you don''t know what you''re building? The benefits of doing a lot of upfront design, diagrams, documentation, etc. are debatable.

--
Dave Mikesell
d.mikesell@computer.org
http://davemikesell.com

##### Share on other sites
I start out with a design document (which, I almost never read once it''s done), then I make a technical document then I start coding. Although I REALLY REALLY REALLY REALLY want to start coding right now I''m not finished with my tech doc which is taking forever

##### Share on other sites
Could someone give a small example of a program documentation?

Close your eyes, and die in the dark...

##### Share on other sites
quote:
Original post by x3verge
Could someone give a small example of a program documentation?

Close your eyes, and die in the dark...

taken from stl_vector.h
/**   *  Returns a read/write iterator that points to the first element in the   *  vector.  Iteration is done in ordinary element order.  */  iterator begin() { return iterator (_M_start); }  /**   *  Returns a read-only (constant) iterator that points to the first element   *  in the vector.  Iteration is done in ordinary element order.  */  const_iterator begin() const    { return const_iterator (_M_start); }

In a header I think its every function/class should have a sescription of what it does.

This would be inline documentation.

##### Share on other sites
my general opinion on planning is that you can''t really plan things in detail unless you know exactly how they work, so learning things along the way isn''t really possible. to make a really detailed plan/design you have to know (or learn) how to do everything that will be in your game (or whatever) before you can consider everything. for that reason i tend to just have a general idea of what things will do and not care about how until it comes to writing them. sometimes this plan goes wrong where you find something you thought was really easy is actually impossible causing you to rethink/rewrite a few things, but that''s all part of learning. unless you have loads of experience you can''t plan for everything, so my designing consists of thinking about different parts and what they do, and then when it comes to actually writing them i think for a few days/hours/minutes about how to actually do it and integrate it with the rest of my program. basically the "jump off that bridge when i get to it" approach.

• ### Forum Statistics

• Total Topics
627704
• Total Posts
2978716

• 21
• 14
• 12
• 10
• 12