I think the name "engine" is being overused a bit. Plenty of people seem to be using it when they are in fact talking about a basic framework or "skeleton" project type on which to build their program from. I'm presently learning Directx with the help of Rastertek online tutorials, and even he use the term "engine" and at other time "framework".

Framework don't necessarly include logics or loops, which most engine do. At least, this is how I understand engines.

Small advice. Buy a cheap "learn video game programming" book for c++ or c sharp. Start there and use the information to build your own projects. These books will teach you how to implement your graphics device either through DirectX or OpenGL which is very important. Additionally it will teach you proper game engine structuring for Object-Oriented design.

I'm presently learning Directx with the help of Rastertek online tutorials, and even he use the term "engine" and at other time "framework".

Personally, I will be creating things with distinction in the terms: game source code, game engine source code, higher level framework, and lower level framework. It is possible to architect clear boundries between these four areas in the same game development system. This begs the natural questions: What if I need to make major changes? Would it be better for future changes if I make orderly boundries between these major levels? For me, the answers would be a definate yes! If I form a team around me who uses my system, then could it be much more efficient and easier to understand if there are clear distinctions in the above mentioned four levels? Again, for me the answer is an obvious yes! From a purely coding perspective, would this be most efficient to organize these levels? My answer for me is yes!

The need for preparing our game development minds for future demands might cause us to desire a better use and understanding of words in this field.

Would I be better served by a "spaghetti" type of fully intergrated system with no clear boundries? In my case, I just say no! I'll have the spaghetti only for meal time, thank you very much! Would I be best served by doing and saying anything I feel in creating my game development system? I simply say no!


It is very feasible (though maybe not easy) for a game developer to have different uses for the terms: game source code, game engine source code, higher level framework, and lower level framework. I recommend seeking expert books and industry publications in print and through the internet to cut through much of the confusion out there. A lot can be learned by how corporations use these terms in describing their software. My opinion is that software industry and game development organizations lead us in establishing standards, including definitions. This would prevent much confusion caused by arbitrary use of terms by individuals, in my opinion.

All these are only suggestions, but I hope that people can get something here.

Clinton

[quote name='Inukai' timestamp='1351142460' post='4993685']
http://scientificnin...mes-not-engines

This is really bad advice.
[/quote]

It's actually pretty solid advice, but it's missing a few caveats.

You need to be disciplined enough to take the time to refactor and clean up your code. If you're writing a bunch of functions to handle sprites, combine those functions into a unit of some sort (class, namespace, etc.). And, combine functions into generic versions when possible.

And, you need to be able to admit that the current solution isn't working very well, and start over. If you're doing this all along, you should never have to throw out the entire code base but only rewrite a specific module. The longer a bad module is left in place, the harder it is to remove or repair.

The idea boils down to iterating on the existing code until you can complete the game; and not writing code before you need it. It also accounts for the fact that it incredibly hard to anticipate every bit of code you need to complete a game.