Archived

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

My head

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I’ve got this problem when coming to do my own game engine. I’ve read game programming all in one all the way through and read the DirectX graphics part a few time (I understand it more each time). Using the engine that the book guides you through I''ve made a few games (3). Now I want to go and make my own engine to make an iso tile engine. First thing I do is create a reusable window class (with a little help from the book) then I create a singleton class for the screen (again using even more help from the book. Now I think ill need a raw RGBA image class, a surface class, and a texture class etc. These are all classes that are used in the books engine. But when i''m doing these classes I keep looking back over the book a lot. That’s my main problem, I can’t seem to do this from my head, I’ve heard that you only need to no where to look for information and not remember it all but this seems to be taking the piss. There’s a few complex pieces of code in there that I don’t think ill ever remember. I’ve only been doing real programming for a year. But I’m worried that if I go for a job doing games programming that I just won’t get it because I don’t know enough. I read that people use these books to start and then make the books engine better; I don’t even know how to do that. Don’t get me wrong I actually understand everything that’s going on (or almost all the time) I just don’t know how to use it really, I''ve never seen other engines that are written good (quake looks way to hard). Anyway if anyone actually read this thanks, could u give me some advice.

Share this post


Link to post
Share on other sites
What you describe is exactly what I would expect from someone who has only been programming for a year.

Don''t try to sit down and memorise huge blocks of code. Chances are you will never need that specific piece of code again and you will have wasted your time. The important thing is to understand why the code you are using does what it does.

The only advice I can really offer is keep programming. There is no other way to learn to program than to sit down and code. Dont worry that you are refering to a book or the help files, the more you use which ever language you use, the more of it you will remember.

Alan

Share this post


Link to post
Share on other sites
Trying to memorize how to rewrite a particular piece of code is USUALLY silly and a waste of time. While you should eventually be able to do all the common things off the top of your head, the key here is "common" things ... which implies stuff you do a lot, like managing dynamic memory, writting constructors and functions, inheritance, creating a templated class, etc ... the GENERAL PURPOSE stuff. You will never need to memorize how to code a linear congruential random number generator, because those things are stuff you write and then USE ... not write again. And they are stuff you look up in books, and keep references around for.

The key is to learn how to solve SIMILAR problems by breaking them down in SIMILAR ways to programs you''ve already seen and written ... this is what experience is ... but unlike in high school, as an engineer you are ALWAYS allowed to use all of your reference books, and your previously written code as reference material (cheat sheets). The more reference material you can draw from quickly and correctly, the better programmer you will be (more efficient and flexible) ... whereas memorizing how to retype comething again just turns you into an overpaid dos/unix command (cp fileone.cpp filetwo.cpp).

So concentrate on the REASONS and TRADEOFFS in the code you are learning and writting ... and the memorization of the common stuff happens automatically behind the scenes (the 50th time you create a 2 dimentional array, you could WRITE a book on the syntax, you don''t need to read it - but you never had to TRY to remember it ... just look it up each time, till you don''t have to anymore).

And this prevents you from wasting time on the wrong stuff ... because if you don''t ever force yourself to remember all the little details, then only the ones you actually use much (ie the important ones) will become permanent knowledge stored in your brain.

And another thing .. the stuff you learn that way, over constent casual repitition, will still be in your head 5 years after you quit writting C code at all ... whereas the stuff you used once and studied will have long since become confussed or lost to you).

Good Luck, and keep at it.

Share this post


Link to post
Share on other sites
Thanks for the advice.
One thing though when a team is starting an engine from scratch after releasing a big game, are they really starting from scratch because im sure they could use their old windows code, bitmap loading, and maybey the input code etc, if this stays pretty much the same, is there any point of them rewriting it?

Share this post


Link to post
Share on other sites
I they were smart, they wrote clean ''general-purpose'' functions to achieve these tasks, and put them in separate files, away from the game-specific code. This is what code reuse is all about.

Cédric

Share this post


Link to post
Share on other sites
the ONLY time intelligent developers really start from scratch is when legal reason force them to (like your old boss owns all your code, and wants any excuse to sue) ...

when they SAY they wrote it from scratch ... what they really mean is the framework, and all the messy cool stuff ...

nobody bothers to write their bitmap loader from scratch .. cause they just copied that code strait off the internet in the first place ...

what starting from scratch means to me (for me only) is this: If i''m working on an old system .. I keep it working .. and leave everything that works right alone ... trying not to shake the Jello ... when I''m starting from scratch it means, everything is suspect .. I create a clean sheet of paper ... and NOTHING gets included in the new project until we look at it and see if that''s the way we want to do it this time .. if so, we copy, if not we change it, change the documentation, write some new tests, and move on ...

the main difference is mental .. when starting over, everything has to earn its keep again ... no lines of code get in just cause they were already there and noone understands them ...

but that''s just me

Share this post


Link to post
Share on other sites