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]

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

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.

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?


RanBlade
"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]

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

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.

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.