making an engine, where to start..not a newbie..
Author
I know this sounds like the grand questions posted usually here:
"I am new to C/C++ and just learning it, i want to make a game engine what do i need?" but my question is more like:
"I have been using C/C++ and even VB for countless boring windoze applications, and I have made a few games using other engines from books i bought (like Tricks of the windows game programming gurus) but now I want to start investigating building my own engine from the ground up possibly in direct3d, where do I start, what features should I implement ..whats the most bare bones of the engine I should get up and running first."
The trick is ignoring all the books i have read that have ready-made engines so it is not to clout my mind as I sit down and try to tinker with my own.
I think for my first shot Id like an engine that just does some bare bones stuff (.md3 models and terrian i guess good start?) in 3d. Any suggestions where to start? then once the bare bones get done, whats a good thing to start on next... levels? bsp? octree? I have heard these buzz words, investigated them some, got the general concept down...just havent really dove into the code of them much.
Oh and heres a usually un-asked important question:
What helper classes/functions/structures do most engines use...ie.. say a good dynamic memory manager with linked lists etc... what else though? file functions im sure for reading and writing proprietery classes to file..but anything else?
Oh and what parts of a game engine are the most common:
the 3d renderer
ai?
what else?
Thanks,
-Shane
Well I''m not an expert on how to learn. But I wouldn''t start so complicated. A lot of people start with models and terrain. But in my opinion you should start with the actual game entity sort of stuff. Then actually make a simple game, with little graphics, then start to add other things. You''ll end up with a poorly structured engine, either way you start, unless you''re really up to speed on game engines. But at least you''ll succeed something, other than a terrain and model viewer.
Of course this is seen only from my view as someone who started from the HL SDK and only recently actually learned how to code, or should I say started to learn.
If my typing seems a little erratic it''s only because I''m trying to keep up with the fast bit of Telegraph Road by Dire Straits.
Of course this is seen only from my view as someone who started from the HL SDK and only recently actually learned how to code, or should I say started to learn.
If my typing seems a little erratic it''s only because I''m trying to keep up with the fast bit of Telegraph Road by Dire Straits.
I am doing what you mentioned.
I started with a demo that generates/renders 3d terrain.
After i was done with that demo (which was a school project) I decided to create an "engine" (which im still not clear what constitutes an engine). i added my terrain source there as a neat like module. I also started to add other modules such as Sound, Input, Collision, Phsics, CObject (the base class), CEntity, CModelManager, CProjectileSystem, CParticleSystem....all of which is more-or-less my first time around to seriously trying to do all this together. Many things such as the Sound manager are borrowed source code - modified only to my liking with what i need - and properly documented as well with the author''s credit.
But if it''s my own stuff, like physics, collision, particles, projectiles...etc...then it''s mostly basic stuff (no fancy per-polygon collision here) which are mostly created for my game purpose.
Having said all that, before I started my engine I had a game idea in my head. Of course, it has evolved a bit since my original idea - but the basic principle is still there.
So, i believe that an engine should start with a vision of what it should do and what kind of game you are planning to make. In my case, I have a specific game in mind - but I am making it flexible enough to start another game - possibly a different type if I wanted to.
And by no means do i expect my engine to be good even in the least bit. My source, however, it generally readable at first glance, unlike some other massively huge source out there (i.e. Half-life).
I started with a demo that generates/renders 3d terrain.
After i was done with that demo (which was a school project) I decided to create an "engine" (which im still not clear what constitutes an engine). i added my terrain source there as a neat like module. I also started to add other modules such as Sound, Input, Collision, Phsics, CObject (the base class), CEntity, CModelManager, CProjectileSystem, CParticleSystem....all of which is more-or-less my first time around to seriously trying to do all this together. Many things such as the Sound manager are borrowed source code - modified only to my liking with what i need - and properly documented as well with the author''s credit.
But if it''s my own stuff, like physics, collision, particles, projectiles...etc...then it''s mostly basic stuff (no fancy per-polygon collision here) which are mostly created for my game purpose.
Having said all that, before I started my engine I had a game idea in my head. Of course, it has evolved a bit since my original idea - but the basic principle is still there.
So, i believe that an engine should start with a vision of what it should do and what kind of game you are planning to make. In my case, I have a specific game in mind - but I am making it flexible enough to start another game - possibly a different type if I wanted to.
And by no means do i expect my engine to be good even in the least bit. My source, however, it generally readable at first glance, unlike some other massively huge source out there (i.e. Half-life).
Well, to me it sounds like you have done half the work already 
You have got the modules (your code or others, doesn''t matter) it''s not just a task of pouring it into a structured engine.
Try to envision your game. See what moduled it needs (terrain, sound, models, etcetera). Then see what you have already got. What modules will do? What modules need rewriting? Next, find out how these modules need to connect. What baseclasses they need, their dependancies, etcetera.
After this it''s a matter of restructuring the code you have, rewriting where nescessary and add them to your engine. Your an indy, you don''t have the time to build an engine from the ground up. Use the modules you have as much as possible. The hardest part will be to find out what modules you need and determining if your current modules will do.
What I haven''t seen in your list of modules: Vector class, Camera class, Plane class (can hold the frustum planes for culling), Texture manager, etcetera. Will your terrain module do? Probabely needs rewriting to support QuadTree frustum culling. Will your model class do? Probabely needs rewriting to have bounding boxes/spheres and a way of adding them to the terrain.
Good luck!
Sander Maréchal
[Lone Wolves GD][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]
You have got the modules (your code or others, doesn''t matter) it''s not just a task of pouring it into a structured engine.Try to envision your game. See what moduled it needs (terrain, sound, models, etcetera). Then see what you have already got. What modules will do? What modules need rewriting? Next, find out how these modules need to connect. What baseclasses they need, their dependancies, etcetera.
After this it''s a matter of restructuring the code you have, rewriting where nescessary and add them to your engine. Your an indy, you don''t have the time to build an engine from the ground up. Use the modules you have as much as possible. The hardest part will be to find out what modules you need and determining if your current modules will do.
What I haven''t seen in your list of modules: Vector class, Camera class, Plane class (can hold the frustum planes for culling), Texture manager, etcetera. Will your terrain module do? Probabely needs rewriting to support QuadTree frustum culling. Will your model class do? Probabely needs rewriting to have bounding boxes/spheres and a way of adding them to the terrain.
Good luck!
Sander Maréchal
[Lone Wolves GD][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]
You might find the first draft of my engine articles useful. The final version is being proofread and will be put up on this site soonish.
The one thing I''d stress above all else is: don''t fall into the trap of making a graphics engine, rather than a game engine.
Far too many people start with something that looks impressive, rather than something that has a rock-solid foundation. You find yourself using hacks and kludges to work in other things, such as a physics system or network support; as more and more high-level systems are written, it becomes harder to add low-level stuff, like a memory management system or runtime profiler.
Also, my golden saying: "A general-purpose engine is what you make when you''ve run out of ideas for games." With all of this, you should be keeping in mind the types of games you''re going to build on it at the end. Will it be an FPS engine? RTS? 3D or 2D? And so on. If you''re really sharp you can design it to allow switching between genres, but it''s more work.
Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
The one thing I''d stress above all else is: don''t fall into the trap of making a graphics engine, rather than a game engine.
Far too many people start with something that looks impressive, rather than something that has a rock-solid foundation. You find yourself using hacks and kludges to work in other things, such as a physics system or network support; as more and more high-level systems are written, it becomes harder to add low-level stuff, like a memory management system or runtime profiler.
Also, my golden saying: "A general-purpose engine is what you make when you''ve run out of ideas for games." With all of this, you should be keeping in mind the types of games you''re going to build on it at the end. Will it be an FPS engine? RTS? 3D or 2D? And so on. If you''re really sharp you can design it to allow switching between genres, but it''s more work.
Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
1) Think about how you'd like the final product to look like. (ideas)
2) Physically write on a peice of paper what is required from a programmer's point of view. (design)
3) Sort things out in terms of objects/wrappers (graphics wrapper, sound, input, etc).
4) Begin with your graphics wrapper (because when it's done, it will motivate you to move on), then do input, then sound, then other things like a text wrapper, etc.
NOTE: Try to keep OOP because it will make your work a lot easier.
[EDIT] Remember to keep things simple.
[EDIT2] Also remember that you are doing the, what I call, BACK engine, not the GAME engine. So keep things as general as possible until you start to actually make the GAME engine.
What I mean by "back" engine - Responsable for displaying graphics, playing sounds, loading data, input/output, all general things that could be applied to any genre of game.
What I am talking about when I say Game Engine - Responsable for the actual gameplay element of the game. How the game is played. This would make use of the "back" engine.
[EDIT3] heh, lots of edits. Once your done the basics of the "back" engine, try to do up a ping-pong game and see how it goes.
- Rob Loach
Current Project: Go Through Object-Oriented Programming in C++ by Robert Lafore
"Do or do not. There is no try."
- Yoda
[edited by - Rob Loach on May 6, 2003 9:03:40 PM]
[edited by - Rob Loach on May 6, 2003 9:08:04 PM]
[edited by - Rob Loach on May 6, 2003 9:09:46 PM]
2) Physically write on a peice of paper what is required from a programmer's point of view. (design)
3) Sort things out in terms of objects/wrappers (graphics wrapper, sound, input, etc).
4) Begin with your graphics wrapper (because when it's done, it will motivate you to move on), then do input, then sound, then other things like a text wrapper, etc.
NOTE: Try to keep OOP because it will make your work a lot easier.
[EDIT] Remember to keep things simple.
[EDIT2] Also remember that you are doing the, what I call, BACK engine, not the GAME engine. So keep things as general as possible until you start to actually make the GAME engine.
What I mean by "back" engine - Responsable for displaying graphics, playing sounds, loading data, input/output, all general things that could be applied to any genre of game.
What I am talking about when I say Game Engine - Responsable for the actual gameplay element of the game. How the game is played. This would make use of the "back" engine.
[EDIT3] heh, lots of edits. Once your done the basics of the "back" engine, try to do up a ping-pong game and see how it goes.
- Rob Loach
Current Project: Go Through Object-Oriented Programming in C++ by Robert Lafore
"Do or do not. There is no try."
- Yoda
[edited by - Rob Loach on May 6, 2003 9:03:40 PM]
[edited by - Rob Loach on May 6, 2003 9:08:04 PM]
[edited by - Rob Loach on May 6, 2003 9:09:46 PM]
its not easy designing a game engine if you dont know what sort of game you want to run on it.
game engines usually contain some of the following low level systems, which you build upon to get an actual game:
shed load of interface layers:
graphics
sound
system
input
resource manager:
textures
models
sounds
other game content stuff
math library:
all the real base stuff that everything else uses
its best to start here if you dont have a mathlib already
object stuff:
all the entities you will find in your game will be defined here probably
camera stuff as well
scene graph:
object relations
spatial partitioning
physics engine:
collision detection/response
object interaction etc
and a lot more other stuff i cant think of right now cos its 5:25am and i havent slept yet ;/
once youve got all that u can start using it to make a game
hope this clarifies it a bit
"We are what we repeatedly do. Excellence, then, is not an act, but a habit." - Aristotle
game engines usually contain some of the following low level systems, which you build upon to get an actual game:
shed load of interface layers:
graphics
sound
system
input
resource manager:
textures
models
sounds
other game content stuff
math library:
all the real base stuff that everything else uses
its best to start here if you dont have a mathlib already
object stuff:
all the entities you will find in your game will be defined here probably
camera stuff as well
scene graph:
object relations
spatial partitioning
physics engine:
collision detection/response
object interaction etc
and a lot more other stuff i cant think of right now cos its 5:25am and i havent slept yet ;/
once youve got all that u can start using it to make a game
hope this clarifies it a bit
"We are what we repeatedly do. Excellence, then, is not an act, but a habit." - Aristotle
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
