Ok, I have a working prototype that is messy as all hell (can we say everything in a externed global ). After I got the basic prototype up and running, graphics and control only I started designing a shape for the game. From there I set the structure of the classes drew a bunch of pretty boxes with arrows etc and started coding. I quickly realised that doing it ''properly'' was a lot slower than just hacking it together... After reading GameDev.net''s Zero Defect Software article, I went back and started to recode a lot of what I did and got some advise \ opinions from more experienced coders (well 3 months isn''t hard to beat ) Problem is, it''s been over 2 months now since I worked on something that even looked like a game. I have a basic networking class running, direct input works, etc ... How do you guys stay motivated during those long stretches between being able to compile something that ''does something''. When I first wacked together the prototype I thought It''d only take a few months to get back to similar functionality if I coded it properly... time drags on.... I''m starting to look at game on the shelf rather than open up msdev... How do you guys cope? Many thanks gimp

How much experience do you have working with C++ & OOP software design? And the ''hail mary'' DirectX?

Me guess is if you decide to make a second game, it would take several orders of magnitude less time to develop.

It''s been almost two years since I wrote C++ code, and it''s been painful how much i''ve forgotten... I wrote more useful code this weekend than the last two weeks combined.

Basic(18years)
Visual Basic(6Years), COM, DCOM, MTS, MSMQ, ASP, VBSCRIPT...etc
C(6months)
C++(3months)

Initially classes looked a lot like COM object that I was used to in VB but recently the''ve started looking a lot deepter than that.

My main problem I suppose is a rash of technical problems recently has slowed development to a halt. Every week I learn a new technique that should replace a previous peice of code....

For example I''ve written the keyboard binding loader 3 times now and I''ve just learnt about map:: fstream:: that''ll cause me to rewrite it yet again...

Leave good enough alone - optimize latter
Get the design down first, otherwise you''ll waste time re-optimizing routines; i often use the simplest (hence easiest code to write & and often slowest code to run) first.

I agree. While it is useful to try to design your code neatly and without bugs (one way of interpreting the zero-defect method), continually improving one section of code is going to drive you nuts, and will never finish the project. Always revamping a section of code can be considered to be a slightly different form of "feature creep". So just work at it until it is fairly decent and is clean, then move on. You can come back later (after you have the whole thing going) and polish it.

But trying to use the best method for everything is an excercise in frustration...after all, 5 minutes after you finish this project, someone will have come up with a better way of doing something in your code...

Well, it''s like you said, Gimp, those long stretches between being able to really see progress are the problem. I try to organize things so that I can see progress more often.

For example, for my game''s terrain I have to:
(1) code a separate editor app that creates a height-map
(2) code functions that save and load the height-map from the editor to the game
(3) code a function that creates a set of triangle primitives to render the height-map (variable level-of-detail)
(4) code a function that renders the primitives

Instead of doing this all in order, here''s what I did first:
(1) entered a crappy height-map array directly into the game app
(2) created a crappy set of triangle primitives to render it
(3) coded the function that renders the primitives (step 4 above)

So I wasted a little time making a crappy height-map and a crappy triangle set, but that allowed me to get something on the screen faster.

Which is really what you want to do, in case that crappy height map turns out to be really crappy and needs a design spec change - balls, now I gotta change the editor too...

but not if you haven''t created it yet

I''m not using the STL either gimp

AAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!

I''ve spent the whole day trying to work out how to use map:: and all I''ve got is :

    #pragma warning(disable:4786)#include <iostream>#include <string>#include <map>using namespace std;typedef map<string, string > KEYPAIR;void main(){    KEYPAIR::iterator	CurrentItem;    string				Command = "QUIT";	KEYPAIR				Keypair;	Pair				Ret;	//Simulate the file loader with a few values...	Keypair.insert(KEYPAIR::value_type("QUIT","KEY_ESCAPE"));	Keypair.insert(KEYPAIR::value_type("FORWARD","KEY_UP"));	CurrentItem = Keypair.find(Command);	cout << (*CurrentItem).second << " ";    

This is the reason I keep away from ''other people code''. It takes me so long to work out silly things like return types that are datastructures. I made one error at one stage and got a 6 line error message... only one error.

I think all I really need to do is :

-Have a good clean simple design for the major components.
-Pay more attention to releasing memory, though even this isn''t important as I never free anything until I exit anyway...

Right now my code looks like C wrapped up in classes. The only reason I''m using classes is that it make the code ''feel'' neater. (I''m a VB COM programmer so it feels natural to section off code)

The gist of what I''m hearing is "Make a good structure (my classes) and optimise later if need be.". Is that about right?


Thanks guy''s I feel a bit better now...



Run gimpy Run!

___________________________________________
Sometimes you long for the days of old... Error 76 //

C:\Program Files\Microsoft Visual Studio\VC98\myprojects\Queue\Main.cpp(21) : error C2679: binary ''='' : no operator defined which takes a right-hand operand of type ''struct std::pairits,class std::allocator >,struct std::pair,class std::allocator > const ,class std::basic_string,class std::allocator > >,struct s
td::map,class std::allocator >,class std::basic_string,class std::allocator >,struct std::lessaits,class std::allocator > >,class std::allocator,class std::allocator > > >::_Kfn,struct std::less,class std::a
llocator > >,class std::allocator,class std::allocator > > >::iterator,bool>'' (or there is no acceptable conversion)

yes I find it very hard to read over my code after comming back to it months later. Then I have to relearn everything over again. Gets really annoying.
Basically nowdays, I take design ALOT more seriously. Just get pen and paper and start writing like crazy. Why you put something in, how you did such and such, what changes you had to make, maybe even some pseudo code if you can, a couple of test schedules.
I write with one idea in mind, if I were to give my design documents over to another person or another team, it should be so descriptive that they would be able to recreate my program from scratch.
Months later when I wonder how something works, I just pop open my design documents and everything is there. If you design properly progamming it become less than trivial.
I''m still surprised a how many people just jump straight into code with even a scrap of paper containing a general outline. I feel sorry those people, cause their the ones staying up day and night debugging code. Test have proven that the earlier you find a bug the less costly it will be for you in the long run.

Anyway I''m way off track Sorry I''m long winded sometimes.
what keep me motivated. Being able to look at a final piece of work and syaing "oh my god, I made that!"