- Jesse Barksdale
Creating a 3d game engine
Author
Hello there,
I have been learning OpenGL recently and playing around with it a lot. Once I make a couple little games and become familiar with it I want to make my own SIMPLE LITTLE engine. I am the only programmer on the job, my friend is an artist. I am wondering if it is possible for me to make a simple little engine that is capable of creating the games I want to make. I am talking very simple at the beginning. I just want the most basic support for OpenGL graphics, light, etc. I can expand later. I am wondering how long it would take a single person to make a simple game engine capable of this if it is possible. Also your suggestions on any reading material etc that might help me.
Thanks a bunch
- Jesse Barksdale
- Jesse Barksdale
Author
I am using VC++6 and have a firm grasp of both C and C++.... just thought I would throw that in there in case it matters
- Jesse Barksdale
- Jesse Barksdale
You say you want basic support for opengl graphics, light... How do you mean then? If you just want opengl support, that won''t take long... I''m not sure what kind of engine you want to do, it sounds like you just want to box the opengl base code, that doesn''t take long at all... But if you want to create your own light objects that displays light in other ways then opengl vertex lighting (lightmap, per-pixel lighting etc) that''s more tricky.
You should feel confident before creating your engine, you should know how to go about it...
/G
You should feel confident before creating your engine, you should know how to go about it...
/G
Ofcourse, there are a lot of more or less game specific things in a 3D rendering engine.
But some things are quite universal, like the rendering order code (wich takes care of in wich order the objects should be rendered, for optimized visual quality and speed).
Other things, like basic meshes and maybe simple basic models should also (in my opinion) be in the basic re-usable code.
Collision code, light managing code (dynamic vertex lights, that is) should (or could) also be in the basics.
What you should start out doing first, is to find out what software you will use for 3D modelling: Maya, 3DSMAX, trueSpace or whatever.
Then, find out what your model format will be looking like, then make an exporter for easy model conversion (maybe also a small conversion utillity).
You may think, that all such things are "high end" stuff, but exporters, converters and tools in general are the heart of your engine. If it´s very difficult to make content for your engine, then it really doés´nt matter how cool the renderer is. So tools should be a primary concern.
The second is engine usability and design.
You would help yourself knowing how to make singlton classes. They are invaluable. Instead of passing a manager pointer through 2, 3, 4 or even 5 classes, then just acces the manager directly.
Another things: Keep your functions as small as ever possible. And name them in a logical way, or just in a consistent way.
I use member function prefixes, like S_Setup() or R_Render.
S_ means that the function is setup only (that it should not be run every frame), and R_ that it´s a runtime only function.
And I have functions starting with RS_, wich means, that it´s a function that can be used both at setup and at runtime.
You would maybe find your own way or naming functions. But it´s a must.
Last: Don´t make your functions too big. I try to keep a maximum of 40-50 lines. Anything bigger than that will be harder to maintain, and therefore also more buggy. So don´t make too big functions.
But some things are quite universal, like the rendering order code (wich takes care of in wich order the objects should be rendered, for optimized visual quality and speed).
Other things, like basic meshes and maybe simple basic models should also (in my opinion) be in the basic re-usable code.
Collision code, light managing code (dynamic vertex lights, that is) should (or could) also be in the basics.
What you should start out doing first, is to find out what software you will use for 3D modelling: Maya, 3DSMAX, trueSpace or whatever.
Then, find out what your model format will be looking like, then make an exporter for easy model conversion (maybe also a small conversion utillity).
You may think, that all such things are "high end" stuff, but exporters, converters and tools in general are the heart of your engine. If it´s very difficult to make content for your engine, then it really doés´nt matter how cool the renderer is. So tools should be a primary concern.
The second is engine usability and design.
You would help yourself knowing how to make singlton classes. They are invaluable. Instead of passing a manager pointer through 2, 3, 4 or even 5 classes, then just acces the manager directly.
Another things: Keep your functions as small as ever possible. And name them in a logical way, or just in a consistent way.
I use member function prefixes, like S_Setup() or R_Render.
S_ means that the function is setup only (that it should not be run every frame), and R_ that it´s a runtime only function.
And I have functions starting with RS_, wich means, that it´s a function that can be used both at setup and at runtime.
You would maybe find your own way or naming functions. But it´s a must.
Last: Don´t make your functions too big. I try to keep a maximum of 40-50 lines. Anything bigger than that will be harder to maintain, and therefore also more buggy. So don´t make too big functions.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
