game engine tutorials
Author
Does anyone know a good tutorial for designing a game engine. I was looking at the Enginuity tutorial and it sounds good but it's not finished. Does anyone know of a tutorial along those same line but finished. i tried searching on google but i couldn't find exactly what i wanted. Cause if i can't find a decent tutorial online i'll have to buy a book and i'm quite poor. thanks.
Here's another one, it's unfinished too though, but covers more ground than Enginuity has so far - Code on the Cob.
Maybe you should look more at class design, OOP etc
Making an engine is just putting code together to make a game, just organising the code is the hardpart.
Making an engine is just putting code together to make a game, just organising the code is the hardpart.
Quote:Original post by johnnyBravo
Maybe you should look more at class design, OOP etc
Making an engine is just putting code together to make a game, just organising the code is the hardpart.
Making a game engine is an *art*. A complete game engine can be as complex as an operating system. I suggest you look at open source code from functional engines, like Quake 2, and see how they were designed.
I'm making an actual engine and I'm not really a fan of the "enginuity" tutorials myself. If you look at real engine code, and try creatig an actual engine, you will see there is a large difference between the reality, and the theory... Which is sometimes completely irrelevant in the real world. As far as I know, the "enginuity" engine doesn't even run anything at this moment, and it doesn't focus on that either. I would personally wait until its complete and running a game before following its model.
Seriously, examine complete and working engines, even if you don't have the source. Next time you play a game, look at how the files are layed out, and try to figure out how it basically works, how the engine behaves in that game. You could even read John Carmack's .plan files, which reveal plenty of information about his development work at Id Software.
Sorry about that one guys, that was me testing :F
I'd like to say that Richard does have a working tetris game using enginuity. So dont bash the engine's ability to do something
I'd like to say that Richard does have a working tetris game using enginuity. So dont bash the engine's ability to do something
Btw I figured that since I'm here I might as well help out. I'm a firm believer that making a game engine is subtle art and exact science. It takes much planning and expiritiece in the field in order to create a good framework for building games. I also agree that making a complex engine can be very much like creating an operating system (albeit a scaled down version of one).
Some tips from me are: Read up on posts by simon o'connor. I made a thread or two which he dumped some good ideas into that really helped me out.
Read up on many different design patterns. You will have a much greater understanding of what can be done and what cannot be done effectively if you know what's out there.
Don't be afraid to rewrite a portion of the engine, or even the whole thing. When you rewrite you give yourself a fresh chance to apply what knowledge you may have learned from your mistakes.
Figure out before hand what your target platform and graphics apis will be. I know windows + linux + apple support and direct3d + opengl support sound fancy and nice, but is it necessary for what you are doing? Chances are no, but if you really want to explore those areas, even if just for learning purposes, go right ahead. You may find however that win32 and direct3d is all the support you would ever require and it could mean the difference between finishing your engine and...well..not.
Your ideas are not sacred, dont force yourself to not rewrite or scrap an idea. Everything can always be improved IMO
Test and test often. Always try to test out new portions of code you write and make sure everything is working properly. For god sakes keep that debugger at your fingertips.
Try to track what kind of memory leakage is going on. Using MMGR by paul nettle in your engine for a quick and painless way to track that stuff. You just insert the .cpp and .h file in your project and it does all the work for you (as far as tracking goes).
Decide whether you want your engine to be the .exe and the game code to be in a .dll, or whether you want the engine in a .dll and the game in the .exe. Or both, or neither. Those aren't the only two methods, they are just common.
Do your want your engine to be mostly scriptable? How tightly nit do you want scripting to interact with the internals of your engine? Is it a requirement that your game be made mostly of easy-to-edit-on-the-fly-and-test scripts?
Above all, don't over-engineer this thing. Keep it as simple as it *needs to be*. You don't want it too simple, and you dont want it too complex. Life is all about finding balances, and so it creating an engine.
Good luck and read up on whatever you can, it helps.
-neurokaotix
Some tips from me are: Read up on posts by simon o'connor. I made a thread or two which he dumped some good ideas into that really helped me out.
Read up on many different design patterns. You will have a much greater understanding of what can be done and what cannot be done effectively if you know what's out there.
Don't be afraid to rewrite a portion of the engine, or even the whole thing. When you rewrite you give yourself a fresh chance to apply what knowledge you may have learned from your mistakes.
Figure out before hand what your target platform and graphics apis will be. I know windows + linux + apple support and direct3d + opengl support sound fancy and nice, but is it necessary for what you are doing? Chances are no, but if you really want to explore those areas, even if just for learning purposes, go right ahead. You may find however that win32 and direct3d is all the support you would ever require and it could mean the difference between finishing your engine and...well..not.
Your ideas are not sacred, dont force yourself to not rewrite or scrap an idea. Everything can always be improved IMO
Test and test often. Always try to test out new portions of code you write and make sure everything is working properly. For god sakes keep that debugger at your fingertips.
Try to track what kind of memory leakage is going on. Using MMGR by paul nettle in your engine for a quick and painless way to track that stuff. You just insert the .cpp and .h file in your project and it does all the work for you (as far as tracking goes).
Decide whether you want your engine to be the .exe and the game code to be in a .dll, or whether you want the engine in a .dll and the game in the .exe. Or both, or neither. Those aren't the only two methods, they are just common.
Do your want your engine to be mostly scriptable? How tightly nit do you want scripting to interact with the internals of your engine? Is it a requirement that your game be made mostly of easy-to-edit-on-the-fly-and-test scripts?
Above all, don't over-engineer this thing. Keep it as simple as it *needs to be*. You don't want it too simple, and you dont want it too complex. Life is all about finding balances, and so it creating an engine.
Good luck and read up on whatever you can, it helps.
-neurokaotix
Author
Thanks for the help. I might read up some different design patterns since that's where i have the most trouble. I can never think of a good way to connect everything together.
Game Engine Anatomy 101 is quite useful. Check out Crystal Space, Irrlicht, OGRE and Enginuity for ideas as well. If you do buy a book Game Engine Programming is supposed to be more about the design and structure of an engine than Game Engine Design, ironically, which is pretty heavy on math related stuff.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
