If I have to rewrite a major portion of my engine one more time I''m going to BSP my computer out the window. a good chink into my little 3D project I realize that the reason none of my pointers work well is that my dynic array is deleting and reallocating all the objects, and... phhhwwww.. How are you suppoed to keep track of these details?! They always pop up AFTER you''ve finished coding something. You can just hear them, giggling behind you''re computer screen, waiting to pop out just when you think "I''m finished!" Then the little demons cackle and rip your program apart until you have know idea what any of it means anymore. It''s not through lack of planning-- I''ve got paper and index cards flying everywhere. But I never seem to plan for the right things. you trace through all the algortihms, but there''s always a stone you miss, and the whole thing comes tumbling down. Half rant, half "Does anyone have any advice?" --SH

here''s wut u need to do. buy another computer, and on your way home from the puter store, buy a shotgun. set your new puter next to your old one, and get buckshot happy on the old one until its just a smoldering pile of crud. this is just to let your new puter know wuts gonna happen to it if it duznt do wut u want it to. works like a charm

Short Answer:
Try to keep things simple, and encapsulated.

Long Answer:
The design process I''ve developed over time is as follows:

1-Do up a quick design of what ''you think'' your going to do.
2-Right away start coding, mainly building the shapes of classes(I call this skeleton code), what functions go where and do what, just don''t do any major algorithm''s instead use pseudo code or comments.
3-Pretty quickly you''ll find that the quick design is majorly flawed, if you can modify/fix some of the code and continue until a flaw so major pops up you cant continue.
4-Throw away all your design(really! deleted it!), return to setup 1 with a new understanding of what ''you think'' your going to do. Continue to return to step 1 until the the skeleton code you have seems like it might fit together in a reasonable manner.

After that I usualy have a design that has evolved to a point that it might be usuable in actual programming, with of course some more modification

Akins Law of spacecraft design #3
Design is an iterative process. The necessary number of iterations is one more than the number you have currently
done. This is true at any point in time.

It seems spacecraft''s have a great deal in common with programs.

Just because the church was wrong doesn't mean Galileo wasn't a heritic.
It just means he was a heritic who was right.

that''s why debugging always takes longer than creating the code itself. keep planning. keep drafting and designing. create several BINDERS full of your info, code, notes, drawings, etc. Have a binder for each aspect of the code: physics, networking, world design, player design, story design. Have whiteboards and easel pads set up to draft out the big picture.
(i''m just telling you what i do.) and most of all, be patient. that''s the only way to get through it. and if you really feel like the project is worth it, you''ll feel it, and you''ll learn more, and you''ll finish it. no matter how difficult it is.

a2k

I''m putting my 2 cents in because I am in the situation as you, but I''m not in 3D yet =(


Comment your code so you can understand what it is doing and construct your program ONE FUNCTION AT A TIME.. make sure it functions the way you want and move on to the next one.

Good luck

I always try to remember to think of the interfaces between the module of the project. Most of your code will end up being calls to interfaces of other modules, so make sure they are abstract(general), and well defined.

This allows you to completely change the implementation of a module without affecting any other code in the project. It''s the implementation part that''s important only in the later stages of a project, mainly for fixing bugs, adding features, and optimizing.

How is this different from simple encapsulation? Well you can encapsulate a module and still have a crappy interface into it. Make sure that interface exposes everything that module will be called on to do, and make sure it''s abstract. It it''s too specific to the implemenation behind it, then you''ll have problems down the road, if you have to change that implementation. The inter-module interfaces are the most important code you''ll write; make sure it''s solid.

Iterative design and development also rocks. Just don''t go too crazy. There is a point at which you''re wasting time. Not all code has to be completely ripped up: it can be refactored to fit into a new design. Remember this especially once you''re code has been tested. Throwing away tested code is the biggest waste of everybody''s time.

Well that''s enough talking about it, time to go work on it again.

Morbo

Thanks for writing, everyone! Good to know that some people have this sort of thing under a bit of control.

Fragmo, that sounds like a wonderful idea, but I wouldn't know what to do with the body. Generally, when people see a computer programmer up at midnight, digging a hole in the moonlight, they get suspicious.

Atavist wrote:

quote:
After that I usualy have a design that has evolved to a point that it might be usuable in actual programming, with of course some more modification

This is really a sensible idea, Atavist. I suppose the problem with the idea of a design is that a lot of people think it's something you do first, and then use that as a base. It's sort of unsettling to have your base shifting around, sometimes.

a2k wrote:

quote:
Have whiteboards and easel pads set up to draft out the big picture.

White boards are great-- there's something about writing big that brings out the creative side of people.

GoofProg:

quote:
Comment your code so you can understand what it is doing and construct your program ONE FUNCTION AT A TIME.. make sure it functions the way you want and move on to the next one.

One function at a time, should be engraved above a programmers desk... There's nothing more forboding thatn having coded four or five large functions at once, and then hitting the compile button...and it actually compiles. You know something is going to crash then.

quote:
It's the implementation part that's important only in the later stages of a project, mainly for fixing bugs, adding features, and optimizing.

Maybe I'm just designing badly, but that's my problem. I design these general interfaces "getPolygon", but when I go back to do the actual code implementation, i discover that that function has to go through several pointer indirections, and three function calls, just to get pointer. Which sends be back to Atavist's Steps to Perfect Design, step #4... I suppose I'll have to learn how to better balance abstract design with code that doesn't take a supercomputer to return a pointer

Happy coding everyone! SH

Edited by - SH on October 6, 2000 9:34:07 PM

But before I learn about software design, I''ll brush up on things like the difference between a slash and a backslash...

Sorry for the funny quotes-- SH