Engine Writing
by Mike Kuklinski · 12/20/2007 (10:28 pm) · 3 comments
So, the lot of you might have thought that I'd dropped off the face of the Earth for a while, maybe I was run over by a loose Vehicle* or something...
Nah, just been hit really hard by work, school, and writing my own Game Engine, or some combination of the before-stated.
Yeah, been working on it with another guy (I'm sure that he'll comment here on his own at some point) for about a month or so; a lot of the basic, basic stuff is in; memory management, reimplementation of stdlib, threading... and it's only getting better -- we have every intention of writing a Game Engine that supercedes everything so far, even Torque -wink-.
I really can't paste any screenshots yet, because we aren't anywhere near that stage and won't be for a while, but I thought I'd check up with the community and all that.
A few things I've learned:
1, Cut optimizations down. I wasted a lot of time optimizing bits of the memory manager that although may be meaningful in the end only slowed down overall development.
2, Abstraction, Abstraction, Abstracted. Abstracted code is golden; just write it in a way that does not kill performance.
3, Write your code not only to be easy for your users to read, but for you to read as well; it's more important that YOU can read your code than your users, it's THERE job to learn it, not yours to write it for them.
4, Comment! Put comments in your code lest you forget what-the-chewable-vitamin-c (yes, it was nearby) you were writing about.
5, Don't be afraid to ask questions... I'm in a C++ channel quite often asking questions, often I find that when you ask the question, the way you word it triggers your brain differently, causing you to find the solution yourself.
Nah, just been hit really hard by work, school, and writing my own Game Engine, or some combination of the before-stated.
Yeah, been working on it with another guy (I'm sure that he'll comment here on his own at some point) for about a month or so; a lot of the basic, basic stuff is in; memory management, reimplementation of stdlib, threading... and it's only getting better -- we have every intention of writing a Game Engine that supercedes everything so far, even Torque -wink-.
I really can't paste any screenshots yet, because we aren't anywhere near that stage and won't be for a while, but I thought I'd check up with the community and all that.
A few things I've learned:
1, Cut optimizations down. I wasted a lot of time optimizing bits of the memory manager that although may be meaningful in the end only slowed down overall development.
2, Abstraction, Abstraction, Abstracted. Abstracted code is golden; just write it in a way that does not kill performance.
3, Write your code not only to be easy for your users to read, but for you to read as well; it's more important that YOU can read your code than your users, it's THERE job to learn it, not yours to write it for them.
4, Comment! Put comments in your code lest you forget what-the-chewable-vitamin-c (yes, it was nearby) you were writing about.
5, Don't be afraid to ask questions... I'm in a C++ channel quite often asking questions, often I find that when you ask the question, the way you word it triggers your brain differently, causing you to find the solution yourself.
About the author
http://dev.stackheap.com/
#2
What kind of game engine are you writing? FPS, RTS, Generic?
Why are your writing your own rather then use/mod one of the many out there?
Sammual
12/21/2007 (7:30 am)
A few quick questions for you.What kind of game engine are you writing? FPS, RTS, Generic?
Why are your writing your own rather then use/mod one of the many out there?
Sammual
#3
One of the biggest complaints about torque was always lack of documentation make the code easy to follow with good docs to back it up and people will like it more.
I've started learning how to write an engine too, although I don't have plans of making an engine to sell I think it is necessary to know how to build at least a simple one to be able to effectively work with any other. If you don't know a lot of what goes into the engine and how to do it you won't be able to build a highly modified game out of any commercial engine. plus most of the commercial engines that an average hobbyist or true indie can afford are not very good
12/21/2007 (4:39 pm)
If you really are planning on making an engine to sell which to say the least is extremly tough, saying that it's up to the customer to figure it out is not a good way to go.One of the biggest complaints about torque was always lack of documentation make the code easy to follow with good docs to back it up and people will like it more.
I've started learning how to write an engine too, although I don't have plans of making an engine to sell I think it is necessary to know how to build at least a simple one to be able to effectively work with any other. If you don't know a lot of what goes into the engine and how to do it you won't be able to build a highly modified game out of any commercial engine. plus most of the commercial engines that an average hobbyist or true indie can afford are not very good
Torque 3D Owner Tony Richards
If you correctly use class factories, you can optimize individual factories later if required and you can still add debugging code that will help in finding memory leaks.
So often I've seen memory management implementations that do nothing more than create obfuscated implementations.
Disabling the Torque memory manager doesn't exhibit any performance hit or fragmentation problems.
Even after zoning (loading / unloading missions) several hundred times you might expect a bit of memory fragmentation, but both the MSVCRT and glibc memory management do such a great job now that it would take quite a bit of talent, skill and hard work for you to make something that is an improvement... plus, I'm sure you'd rather be putting your skills to good use doing the fun stuff, right? :D
I would have to agree with your thoughts on abstraction and code comments. Your users are your customers and if they see your code then that too is part of your product.
Also remember that documentation within the code, although very important, isn't enough.
This example of my code shows code with good internal documentation, but it's not near enough for anyone to understand the full picture.
UML as an after-the-fact design document is an excellent tool for this... especially since doxygen and visgraph do such great jobs at generating quite a bit of it for you. I just wish someone would take the time to add @sequence tag parsing in doxygen to help it create relevant sequence diagrams.
If you're seriously interested in creating a game engine I wish you would consider hanging out at IndieZen.org. I'm still putting the full team together, but the goal is to create a game engine framework and a toolchain framework and then create the plugins for piecing together different types of specialized game engines and toolchains.
The frameworks are open source and I've volunteered to do the bulk of the coding. Although I'm concentrating more on the framework and the tools, I would be more than happy to lend a hand where I can in helping you create your game engine.
The game engine plugins you create won't be bound by any particular license and they'll be yours to keep and do with as you please, so nothing would change in that respect.
The advantages are that you won't have to code all of it alone and when we're done you'll have a plethora of integrated components and tools at your disposal.