   the hardest thing about game programming
  Ok, mainly all my game programming has been done with engines that have everything taken care of for you, so that all you have to do is basically create your art and sounds, use the engine's loader and tell it what to do with what's been loaded.  However, it's my belief, as is with the rest of the community(I think), that one should have an understanding of the lower level stuff that goes into an engine to effectively use it.  This is what I have set out to do, but I am hitting a major snag.  I am currently learning DirectX and I go through all these tutorials, and I understand the concepts presented very well.  I can go through the code and understand everything that's going on.  But whenever I try to implement the techniques into my own projects, I really have trouble applying what I've learned.  Now I may be wrong here, but I think it just looks more difficult than it actually is.  This is because everything done in a tutorial is presented as engine code rather as game code and makes things seem more difficult that it actually is because you only have to write, for example, object loading code once then you can just use that code for any object.int main() {   //init   engineObject.load("world.x");   engineObject.render();   //clean up}The above would be using an engine.  Now if you were to do the same thing, except using your own code to load the file, it would look more like this:int main() {   //init   struct engineObject { //properties //vertices //other stuff   };   //A cubic ass ton of code to load and render the world.   //clean up}Now my question is this: Once I have a loader, a renderer, an animator etc. done I can go back to where I started and treat my code just like an engine, right?  I mean, obviously even after all that is done there will still be a great deal of work, but it won't seem AS insurmountable.  Is this a correct assumtion or am I missing something? Thanks for reading and I look forward to the replies.-AJ   
  The tutorials you're reading don't necessarily have 'engine code' but more likely 'reusable code.'  Since good engine code -is- reusable code, I can see where you get the two confused :)Fact is, if you just want to go and, you know, test some cool new Direct3D thing out, or mess with DirectSound, or whatever, you don't necessarily need an existing engine for it.  Just could very easily hack something up that'll allow you to do what you want to do.However, what you'll realize very quickly is that you do the same stuff over and over again in order to test something, and you'll identify great 'reusable code' candidates.  Those guys you'll put into such constructs as your 'Object.Load' and 'Object.Render' calls.Having reusable code is very nice, and will save you much headache in the future ;)  It does not maketh for an engine though.  But it will provide a clear starting point for you.So my answer to your question : Don't get too bogged down trying to write an extensive engine.  You'll end up like me writing tons and tons and tons of code doing all kinds of magnificent behind-the-scenes crap and end up with .. a bouncy ball (although, it is a very magnificently bouncy ball nonetheless ;)).  Instead, when going through tutorials write good, clean, solid -reusable- code that gets you to what you want to do.  This has three major benefits:(1)  You'll get to muck around with the tutorials quickly and easily(2)  You'll start learning good coding practices very early on.(3)  You'll have a good start to really understand what it means to make an engine, and if you're clever about it, a nice start to your own engine.Again, in your case: good, clean and reusable code should be your goal.  Making an awesometastic game engine will come later =)I hope that answers your question :)Graf   ;  Before you start an engine think about the data formats you want to use and if you can get content in these formatsThe next step is to think about how complex/advanced your engine shall be.Once you know what you really want, go on and collect information about the different parts you need to implementSome canditates for code reuse are:- image loader- config loader- virtual filesystems- 3d format loaders that convert to your engine internal formatThen think about how you want to connect all the part of your engine:e.g.:- game code to game dll- engine code to engine dll- network into a sperate thread for reading, writing and de-/compression of packets- content management systems, that keep track of the resources you have loaded for a level in order to release them on level change- consoles are a good addition to make debugging a little bit easier later on- GUI <-> game interaction- input control- render managementA renderer is more than  just a loop to send 3d data and texture ids to the GPU.In order to get decent results you need to consider a more complex shader implementation that gets associated with your 3d objects.These objects need to be culled at runtime and sorted by shader/texture.Sound and particle effects play another important role, however with particle effects I would be careful, since overuse of particle can make the scenery unclear and probably require too much attention by the playerCall of Duty 2 is a good example in my opinion although I respect opposing opinions.If you look for some reuseable code components, I have a little library here which is still in development and shall be for free for non commercial objects.Just pm me if you are interested   ;  Actually you want the bare essentials in tutorial code because you don't care to learn the framework when you care about gfx code for example. The framework is something to pursue once you're tired of writing zillion times the same code over and over. However a framework in not necessarily an engine. It's more like a small piece of the whole that allows you to write test cases faster. A game engine contains many more things that tutorials never implement into their frameworks because it's not needed. I suggest you take a look at real game code instead of tutorials to see what it entails.   