#### Archived

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

# Staying motivated....

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

## Recommended Posts

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

##### Share on other sites
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.

##### Share on other sites
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...

##### Share on other sites
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.

##### Share on other sites
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...

##### Share on other sites
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.

##### Share on other sites
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

##### Share on other sites
I''m not using the STL either gimp

##### Share on other sites
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 #include #include using namespace std;typedef map 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)

##### Share on other sites
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!"

##### Share on other sites
Programming seems to equally divided into two parts: learning, and getting things done.

Do you know anything about thread synchronization? It''s very similar -- you have to be increasing your knowledge while working towards your goals. Juggling both at the same time requires care. But when you hit the right balance, things are very easy (at least that''s what I -think- happens ).

Anyway, you learn a little bit, and you code with what knowledge you have. Don''t start a big project and scrap the code half-way through so you can "code better". While you are learning, you are less experienced at that "better code" so you will end up just spinning your mental wheels. That''s great if you don''t care about creating software right now and just want to learn the language, but if you want some good goals then you must weigh your skill with the new method plus the time saved with the new method, against your skill with the old method plus the time lost with the old method.

To represent this mathematically, we''ll use two numbers to denote how efficient a particular method is for you.

int method_efficiency = 10;float your_skill = 0.75; // 75% of max (very good)

Now, when figuring out the benefit of a method to you, you just multiply those numbers. So, we get a net benefit of 7.5 from that method, which it not too bad.

But you learn a new method by reading an article, a book, talking to a friend, etc. This new method is much more efficient (a rating of 15), but your skill level is very low yet (.20). So the net benefit of that method is 3 (new method) - 7.5 (old method) = -4.5. That means that you will lose a lot of time by switching to the new method in the middle of a project.

Of course, your skill with the new method will pick up during development. It all depends on the size of the task, and how quickly you learn the new method. Eventually, when you reach a skill of .50, you will be coding just as efficiently as before, but you now have the capacity to learn to code even more efficiently later on.

So eventually the net benefit with reverse itself and you will be coding even better than before.

This takes time, though. Maybe days, weeks, months to get any net benefit from the new method. And then you still have to make up for all the time you spent learning the new method, when your efficiency was way down.

This is a long-winded way of saying that you should learn in spurts, and get your goals clear. It depends on what is more important -- getting the software out the door or learning. If you sit on the fence with which is more important, you will just flip-flop between learning new methods and writing code, but because you do not spend enough time on any one method you will never really make any progress.

So when you''re coding software, code to get the job done in the most efficient way you can (time vs. method_efficiency).

When you are learning, code only to learn and not to make progress (although if you make progress that''s fine).

If you have clear goals, you can be a very good programmer.

- null_pointer
Sabre Multimedia

##### Share on other sites
quote:
Original post by Silvanis

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...

PERFECT!!!!!!!! That''s the way I interpreted the "Zero-Defect..." article also. While you should STRIVE for Code that RUNS perfect (i.e. without bugs), you shouldn''t strive for PERFECT code. This doesn''t exist. You can then get the game running. Once that''s done, the upgrades in code can be introduced as new features in updates.

BeOS, "It's da bomb, baby"

##### Share on other sites
quote:
Original post by Devon
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.

Just a question. Does anyone know of some good URL''s for info on Design Documentation? Basically some examples of ones that people have used so I can get an idea. With VB I used a design layout, but with GUI creation handled by the IDE(not really one I guess), I focused more on the hard code I needed, or Database access. Now I find myself focusing on so many different aspects of the code with C/C++ that my old way of doing doesn''t suffice.

BeOS, "It's da bomb, baby"

##### Share on other sites
My way to start motivated (ive been working on my pong/breakout game for months now ) is to create a check list of things that still need to be completed and tick them off as you go, then go back and fix up the code. It really works as it give u a better idea of what needs to be done.

wrenhal: have u looked in the design section on gdnet?

-----------------------------
-cow_in_the_well

http://cowswell.gda.ods.org/

##### Share on other sites
Yes, checkboxes are very motivational. I use ''em all the time. (Seriously!)

lntakitopi@aol.com | http://geocities.com/guanajam/

##### Share on other sites
Here''s some of your original code...

//Simulate the file loader with a few values...Keypair.insert(KEYPAIR::value_type("QUIT","KEY_ESCAPE"));Keypair.insert(KEYPAIR::value_type("FORWARD","KEY_UP"));

Do you realise this can be simplified to:

Keypair["QUIT"] = "KEY_ESCAPE";
Keypair["FORWARD"] = "KEY_UP";

?

Looks nicer to me

As for the long errors, well, that''s the downside of templates I''m afraid. You have to really read the STL specifications well to see what they are telling you to do. Often they''re down to using an class in a container which doesn''t have all the operators that the container requires it to have.

##### Share on other sites
Ahhh, that looks much nicer.

I might go back and start looking at STL again... Every time I make a new linked list I think about using a slist or map, the code has always looked so much uglier then mine though.

I''ll give that another shot I think...

##### Share on other sites

That''s not HP''s STL, is it?
What the lastest flavor?

##### Share on other sites
I think most people either use the Dinkumware STL, or the SGI version, or the STLPort version. The first is the one that comes with Visual C++, and isn''t too atrocious I tried to use STLPort with VC5.0 but it gave me ''too many nested #ifdefs'' errors.

##### Share on other sites
I try to get something that looks like the final product up & running as fast as possible. Then you can just go back and replace the prototype features with final features like the article said.

http://www.geocities.com/guanajam

##### Share on other sites
I''m just using the MSVC built in STL. The doco is pretty crappy. Went out and bought "STL programming from the ground up" yesterday and already understand the concept behind all the bits. "Things that hold data" "things that manipulate data" and all the formats are standardized. Nice design, I''ve had glimmers of this thoery for a while as a VB COM programmer I''d never have developed the idea this far though.

What really made me pat attention was one poster who said that large portions of STL are in assembler. Previously I was under the impression that STL was going to be god awfully slow due to the kind of abstraction and inheritance that would be require to make this kind of thing work. Initially I thought that this was anoother one of the corperate reusablity over efficiency things.

I also like the performance guarantee''s. Not knowing the implemetation that was used behind certain feature used to make me distrustful of it''s speed. (how do I know that iterating through a vector isn''t just as slow as an linked list for example?).

Now I''m happily learning away

gimp

##### Share on other sites
quote:
Original post by gimp

I''m just using the MSVC built in STL. The doco is pretty crappy. Went out and bought "STL programming from the ground up" yesterday and already understand the concept behind all the bits. "Things that hold data" "things that manipulate data" and all the formats are standardized. Nice design, I''ve had glimmers of this thoery for a while as a VB COM programmer I''d never have developed the idea this far though.

What really made me pat attention was one poster who said that large portions of STL are in assembler. Previously I was under the impression that STL was going to be god awfully slow due to the kind of abstraction and inheritance that would be require to make this kind of thing work. Initially I thought that this was anoother one of the corperate reusablity over efficiency things.

I also like the performance guarantee''s. Not knowing the implemetation that was used behind certain feature used to make me distrustful of it''s speed. (how do I know that iterating through a vector isn''t just as slow as an linked list for example?).

Now I''m happily learning away

gimp

Do tell, what bought you back from the darkside? (VB to C++?)
In my experience with VB.... speed simply could not be a concern... It was given that is was going to be slow. For an excel add-in that I made I eneded up writting most of the code in a .dll & linking to it in vba (boy was that a painful learning experience) - ''Course you said COM...

##### Share on other sites
VB:
I did a security administration and mannaged remote execution system. I needed something that would perform an authenticated connection from a webserver where the commands were submitted for execution to a normal member server. I went with a html front end using asp, data stored in a sql database, the impersonation\security was carried out by a vb com object running in the contect of a netwoek wide administrator in an MTS package. A vb DCOM object on each machine would authenticate the call and excute the command \ return the output.

I essentially put it together over about 3 weeks with most of my time spent making the html netscape, ie3 amd ie4 friendly.

For things like this where as you said speed isn''t an issue VB + COM iss brilliant, in fact there ar only 2 things I use VB for now, COM and SQL. I''d even give a GUI a shot in VC.

What brought me back?
Events:
-gimp tries to use a few win32api''s and has to use some stupid memcpy thing... whatever the hell that is...
-gimp writes a MIME encoder for an SMTP COM component (so the system above can mail error to the developer(me)). The encoder take 1 min to encode 1 meg, a friend code a c++ one to do it in under a second)
-gimp starts writing a file parser to get all the textures used in a quake stype map file and copy them for another directory to help the release process for a mod he''s working on. sending everyone a msvbvm50.dll sound like a bad idea.
-gimp realises that all those unix boffin actually have a use after all teach me C! (On company time to boot!)
-gimp is tutored on C, gets the app running, the app executes at blistering speeds...gimp drools 5mb copied with getc() and putc() in one second. Not even using memory mapping...
-gimp get shits with is mod team for being so slow and finds gamedev, reads a cool tutorial on Cubic splines and gets pumped about writing a MP game
-gimp likes Battlezone and thinks something along similar lies would be a good goal (for a person who has only ever written a single file parser)
-gimp finds wildtanget engine to handle the outdoors terrain, grabs a copy of "Tricks of the game programming guru''s" and "Learn C++ in 21 days"[this was easter]

So there is the who story of how I went from a VB professional to a C++ minor league player. I''m currently reading 3 books, "Efficient C++", "Data structures and algorithms"(some uni book) and "STL from the ground up"(Herbert Schildt).

3 months ago I was a games don''t need OO and C is faster person, now my code bank is getting so large that I need pictures and classes to mentally keep track of everything.

The major factor was:
-VB could never used used to run games(well good ones anyway)
-VB makes it hard to call WIN32 API''s
-VB could never be ported to linux
-VB makes easy things easier and hard things harder.

Once I got used to using character arrays rather than string I was fine.

gimp