• Advertisement

Archived

This topic is now archived and is closed to further replies.

Game Engine Development

This topic is 5555 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

OK, I am a C++ programmer learning OpenGL and a bit of DirectX. I plan to start developing a 3D engine this summer with 4 of my friends. I''ve never ever coded an engine before, not even a simplistic one. My question: Does anybody know of any good online resources and/or books to get so that I would learn how top o'' the line 3D engines such as QuakeIII and Unreal are created, and architecture, programming, etc., etc. Put it this way: I want to learn as MUCH as I can about 3D Engine Development so that I would be able to start development of a pretty advanced third person RPG engine over the summer. I want it all...lol. Thanks a LOT in advance! -Sab

Share this post


Link to post
Share on other sites
Advertisement
well, unfortunately you have a lot to learn before you can just jump into a top of the line 3d engine. there's a reason so many game company's choose to buy an engine rather than spend a year developing one. not to discourage you, but you're not going to write an engine in a timely fashion if you set your goal that high. then, once your engine is done you'd have to work on your game content. I'm sure you've thought this out to some extent. there are plenty of tutorials, but none on, "How do I make Quake III". I would start from sqaure one, http://www.gamedev.net/hosted/3dgraphics/

good luck,
Joe

My Homepage
How many Microsoft employees does it take to screw in a light bulb?
None, they just declare drakness as a new standard.

[edited by - Julio on December 5, 2002 5:56:18 PM]

Share this post


Link to post
Share on other sites
ok ok let me correct myself..(clears throat) I would like to learn HOW they are made, and their architecture, pipeline, etc. LoL, i know, im going to suck real bad if i set my standards that high...but i was browsing through the bookstore a few weeks ago and found books that were titled like "Game Engine Development" and "Developing 3D Game Engines", and stuff like that. I just want to know how it's done, and what all the components and stuff are for an engine that's really good, that's all.

[edited by - sab3156 on December 5, 2002 6:01:32 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You have plenty of free open source 3D engines to start with.
As an example ,the Quake 1 and 2 engines source code is
available for you to download (Quake 3 will be next).
In these days it´s not worth starting an engine from scratch
unless you are writing your "tetris" clone and want to have
some "fun". You can have fun making your own outdated 3D engine
too, but it has no practical use. If you want to make use of the latest technology in a game your best bet is to rely on engines coded by people with more experience and use their codebase to build your game from there.

Share this post


Link to post
Share on other sites
I think I''m in the same boat as you. My team (were all university comp sci students), is looking at doing the same thing. We can program in C/C++, DirectX, and OpenGL. We also have a fair bit of experience with things like threads/forks, and network programming. We want to write an engine, because we believe were up to the challenge. We know were not going to beat Carmack to Doom 4, or Sony to the next Everquest. We are hoping to complete an engine and some simple demos showing it off in the next 2 - 3 years, In our spare time between classes and co-op sessions. Our problem is we want to make sure the architecture is designed properly. We want to build something that is flexible and extendable. Were just hoping someone can point us in the right direction for this layout.

Share this post


Link to post
Share on other sites
Well don''t listen to the utter rubbish above. You will learn far far more from writing your own engine than by looking at something like the quake source code.

The best advice i can give is to read and code a lot, thats it simple.

I went the OpenGL route and would reccomend the following texts :

OpenGL Blue Book
OpenGL Game Programming
Mathematics for 3D Game Programing.

I have to quote the above post,

"In these days it´s not worth starting an engine from scratch unless you are writing your "tetris" clone and want to have some fun" - Well i''d like to think that its more about learning than coding doom 7.

"You can have fun making your own outdated 3D engine too, but it has no practical use. " - Don''t you get better with experience? Yes you do and your engine then gets better and suddenly it hits you, your engine is pretty dam good.

"If you want to make use of the latest technology in a game your best bet is to rely on engines coded by people with more experience and use their codebase to build your game from there. " - I wonder how these people got their experience? They must have been born with it, the lucky sons of #*!@?''s.



Share this post


Link to post
Share on other sites
I''m actually on my 4th engine right now. Every year or so I write a new one, just to keep up with the times and what not (Hell, that''s what carmack used to do!)

Anyhow, the best advice I can give, is that an engine is broken into parts, all of which must work in harmony, but can be developed individaully. Here''s Roach''s 10 point check list for anyone wanting to put together a solid engine:

1. Reading In Geometry files (.3ds, .iwf, .ase, lightwave, etc)
2. Reading in Texture files (.jpg, .tga, .bmp, .raw)
3. Reading in text Files (for configs or .ini or whatever)
4. Creating a basic universal structure for your engine (Ie, every object uses the same definition of a polygon)
5. Make things extreamly portable. No doubt you''ll write 3 or 4 different versions of a given algorithm, it should be easy to pull in and out of your engine.
6. Creating a flowing user input system.
7. Reading in of sound files (.wav, .mp3)
8. Creation of a Scene Traversal Algorithm (octree etc)
9. Creation of a Scene Culling Algorithm (HOM, Frustum, etc)
10. A stable Debugging system (printing to the screen or logging to a .txt file on the HD)

These 10 things will start your understanding of how a Engine works, and how everything is put together. Although I don''t have alot of demos up, you can check out some features of my new "SarXos" engine (4th one in 5 years) at my website, under the "WorkBench" page.

Hope that helps!

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

Share this post


Link to post
Share on other sites
Are all of you going to be programming? There''s always an issue when you have multiple programmers on a project, and that''s organization. If you really want things to work, after you do all you''re research, you''re gonna have to sit down with your other programmers and figure out what each person''s job is going to be. You''re going to have to design the way each person''s code is going to "talk" with each other. Code interfaces are really important, and if you plan correctly, you''ll save yourself lots of debugging, because if the code doesn''t fit together, you''ll have a lot more work to do. Organization is the biggest problem with teams. If you think you''re going to have a problem with it, the best thing to do is program it alone. I think it''s always better to learn this way, because you can focus in on actually coding and less on management.

Look into software engineering books and do searches on Google

Miracle Man Studios

Domini
Rastagon 2 Engine

Share this post


Link to post
Share on other sites
In my team it''s all programmers. I just set up a CVS server on one of my computers. Two avoid version conflicts. I''ve already had two work terms in the real world, which gave me great insite to programmer organization. (We used source safe there). I was lucky enough to work with a company with about 15 programmers, and the organization was great, we hardly ever had conflicts. Were really tring to model our team after the one I worked for, because it worked so well.

Share this post


Link to post
Share on other sites
I usually tackle team problems by how the projects are assigned. Like i mentioned before, all aspects of our engines are exreamly portable. Our base classes are created by the head programmer, and everyone else must adhear to those standars. Any changes to the base classes have to first be passes by the lead programmer.

When you modulize all your code classes, you end up with huge systems which are simply called through 1 or 2 functions. So the entire guts of an algorithm can change on a programmer whim, just as long as those main function calls don''t deviate too much.

~Main

Share this post


Link to post
Share on other sites
I suggest buying a book, not just any book... This book, I''ve read it through a few times and its great. Also check out NeHe''s site, GameTutorials.com, both sites are very good.

---
Looking for a new gaming experience? Want something new that deals with everyday life. Ever wanted to be a thief, banker or a cop? Then come visit the newest thing in gaming today: Lejendz!
Other hosts turn you down? Need good tech support, excellent up time, and affordable prices? Come to cheapunixhosting.com/ to find a package right for YOU!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by jonbell
"In these days it´s not worth starting an engine from scratch unless you are writing your "tetris" clone and want to have some fun" - Well i''d like to think that its more about learning than coding doom 7.



Learn everything you want however life is too short :-(
and while working professionally you won´t have much time to make your own engine and make your game look as good as doom 7.
By the time you finish your product will look like pong vs doom 3.Perhaps you will learn more solving new problems using existing tools than wasting time reinventing the wheel and thus wasting your life. If you are a genius and can do something good in not much time then go ahead.

quote:

"You can have fun making your own outdated 3D engine too, but it has no practical use. " - Don''t you get better with experience? Yes you do and your engine then gets better and suddenly it hits you, your engine is pretty dam good.


If you want to get experience then code a good game.
Can you do it better than proffesional specialists who have been on the top coding the best engines for more than 20 years with your crappy and outdated amateur engine? Of course you
can learn and make fun games with your technology, but the
customers want the last of the last, and I bet any "point
and click" program user with imagination can make a funnier
and better looking game than you with your engine that took
you 1 year of your life (or more) to complete with even
not having anything to show, just a couple of poorly
rendered screens. You learnt a lot, who else cares?

quote:

"If you want to make use of the latest technology in a game your best bet is to rely on engines coded by people with more experience and use their codebase to build your game from there. " - I wonder how these people got their experience? They must have been born with it, the lucky sons of #*!@?''s.



These people want to use the best engines already available to make their games, and they need that you can work and know the
technology they use in their projects...the codebase. One way to get used with this technology is to code mods for their games. The same goes if i want to build a car, I want to be provided with stuff from the best manufacturers. They want current technology, not amateur engines imitating the ones that
powered those one century old cars. If you want to stay amateur
thats ok. Anyway coding an engine or 2 is good to get a grasp of
the basics, but don´t expect to make professional games with
that, unless you are pretty damn good or a genius, as i already
said.




Share this post


Link to post
Share on other sites
Agreed.

I don''t know about the rest of you, But i''m a broke ass college student, who''s currently freezing his ass off because when it comes down to money, you an either buy a jacket to stay warm, or eat for the next month.

Because of that, There''s no way in hell i''d ever have money for an engine, Espicially one that has been made by someone who''s been doing it "20 years."

On top of that, even if you had an engine, you couldn''t do anything with it, unless you knew what it was doing under the hood anyhow. And chances are, unless you understand those principles, you wouldn''t be able to use anything you could purchase anyhow.

Knowlage IS infact power. The more you learn, the better a programmer you become. And to simply disregard the concept of making your own engine, simply because you can''t compete with the big boys, well that''s just stupid. The fact is that you don''t have to compete graphicly. Talk to any independent developer, and they will all tell you that a game is about the "fun factor" because they know they can''t compete graphicly with the mainstream games. (Although i have to say most mainstream games aren''t that advanced right now)

Be fruitful and multiply. Make engines, be happy. Negativity in regards to programmming is a fault that does catch up.

~Main

Share this post


Link to post
Share on other sites
Interesting...lol this has become a heated debate rather than helpful solution to my problem! come on guys! ok listen: are there books SPECIFICALLY on engine development? i mean, kickass, high-performance 3D engines using OpenGL for graphics and DirectX for anything else. there doesn''t have to be code in the book...just architecture, design, flowcharts, analysis'', pitfalls, what''s good and what''s bad. that''s all...

Share this post


Link to post
Share on other sites
OpenGL Game Programming
Mathematics for 3D Game Programming & Computer Graphics.

Buy these books but don''t expect to create quake overnight.

Share this post


Link to post
Share on other sites
Don''t really listen to what everyone else has to say (Just kidding, keep an open mind in the world of game dev.!!), If you start to create your own game engine, you''ll develop a lot of skills that you couldn''t develop if you used, lets say, the Half-Life SDK. I''ll list a few

1.) Your own coding style, you wouldn''t believe how much faster you can program if you create your OWN instead of using someone else’s.

2.) Got a problem? Solve it yourself! This will help you in the long run, in pre-made engines that you edit (Or sdks that you "mod" games for.), most of the code is already there, you just change it or take stuff from other parts of it. Once you start getting really good at programming, there isn''t going to be much code for really advanced things... Just theories.

3.) You''ll learn the language a lot faster if you create something by scratch, you''ll have to solve new problems, some of which no one will be there to help with...

4.) Its fun! How many people can say they have programmed their own engine, and it actually being GOOD? Not many (At least in my town.)

-----
Anyways, just look through tutorials.... Old engines, new engines ( sourceforge.net is your friend, be sure to give credit and ask the author if you use their engine first. ), ask questions, read other posts, peoples problems, questions, ect..

---
Looking for a new gaming experience? Want something new that deals with everyday life. Ever wanted to be a thief, banker or a cop? Then come visit the newest thing in gaming today: Lejendz!
Other hosts turn you down? Need good tech support, excellent up time, and affordable prices? Come to cheapunixhosting.com/ to find a package right for YOU!

Share this post


Link to post
Share on other sites
OK. I have OpenGL Game Programming by PrimaTech...and I''m buying that math book. And I''m getting Physics for Game Developers by OReilly. What i need is a Game Engine book....

Share this post


Link to post
Share on other sites
The concept of an "Engine" is very ambigious.

You have to understand that an engine is actually a collection of classes for loading and displayign data. That''s about it. How you set up the backbone of your engine (tying everything together) is probally one of the only "engine" designed things. Other than that, it''s pluggin in different types of loading stuff.
There''s specificly some "game engine design" books out there (can''t remember them off the of my head) However they won''t do anything but probally confuse you. What you need to start with is loading files (like i mentioned in my 10 step list) you start to develop the programming interface and backbone used in engine development.

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave

Share this post


Link to post
Share on other sites
The problem with most books and websites right now is that they feature either API based graphics tutorials, or tutorials one specific subjects. Nothing really links all the tutorials together in order of the way someone would build an engine. I think the reason for this is that most of us that came into programming from a software engineering background already know how to fit multiple pieces together into the larger engine application, but people who are starting game programming from no large scale application building whatsoever have no idea how to do this.

I''m working on a website right now where I provide sort of a timeline for building an engine. This is more a case study of how I do thing than anything else, but that''s better than what we have right now. The major thing to remember is there is no end-all be-all engineering method for engines, everyone does it differently. The only right way is the way that gets the engine done.

I''ll be posting the URL of the engine tutorial once I get it written, it''ll probably be at http://www.numberporn.com/qengine/, which is where my current engine page resides. There''s not much there right now because I''m busy with finals and graduating college.

Share this post


Link to post
Share on other sites
I''m amazed this thread has gone this long without people mentioning two books(at least I think they haven''t been mentioned). They are:

Real-Time Rendering 2nd Edition
by Akenine-Moller & Haines

3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics
by Dave Eberly

Now, one thing to mention is that neither of these books are in written in a tutorial style. That is, they do not actually walk you through creating a game engine. What they cover is basically everything you need to know to create a decent game engine, and are API agnostic in doing so. Between the two, they cover things like:

Transforms: How Matrices, Quaternions, etc work, so you can create your own functions)
Graphics Pipeline: Cameras, Culling, Clipping, LOD, Shading, and Rasterizing.
Geometry Methods: Curves, primitives, triangle formats, sub-divs, patches, Terrain, etc
Scene Graphs: How to create and manage a tree of nodes
Intersection/Collision: Rays, Spheres, BBox''s, Ellipsoids, Capsules, etc
Animation: Keyframes, Inverse Kinematics, Skinning.
Rendering: Lighting, Texturing, BRDFs, Shadows, Global Illumination, DOF, etc

Now, what they don''t show you is how to set up your classes to hook up all those things up together and make them interact. Actually, I think Eberly''s book does come with an engine of some sort but I haven''t checked it out. That being said, I think how you go about hooking all that stuff up will differ depending on what type of game you''re doing. They also don''t show you anything regarding Input, Sound, AI, or Networking. So, you''ll have to glean that stuff from another source.

One thing you should be aware of is how these two books differ. Real-Time Rendering tells you how all these things work in theory, in a fairly easy to understand matter. All of the methods are explained with pictures and bits of pseudo-code, but no source code. Eberly''s book, OTOH, is VERY mathematical in it''s explanation of everything, but also provides nice source code showing how to do it. So, as I''ve been working through, I''ve found it works well to learn how it works with Real-Time rendering and then how to do it with 3D Game Engine Design. They seem to complement each other nicely.

At the end of the day, I think I''m in the same boat you''re in. I wish there was a good book that showed how to connect all the bits together. It seems like all of the books out there either represent very simple, heavily API reliant "engines", or they''re mostly reference books. But at least with these books you''ve got a fighting chance if you can think through how you want your engine to work.

Also, just as an aside, you might want to hold off on picking up "Physics for Game Developers" for the moment, and use your money instead on these two books. I have that book too, and while it''s OK for reference it didn''t blow me away. But more than that, with all of the other engine stuff to contend with, it might be a while until you get to implementing physics for whatever type of game you''re doing

Well, I hope that helped!

-John

Share this post


Link to post
Share on other sites
Here is my advice:
1. Think about making a small game, just think.
2. You will start to discover that making a small game requires you to do certain things in preparation, such as loading texture, loading models, reading input, etc.
3. Plan. Design the architecture of those things (loading texture, etc).
4. Once you have figured this out, code it, and call it an engine.
5. Done coding, you should think if your engine also works in a larger game. If so, you have done perfectly well. If not, you should redesign it.
6. Make sure your engine is project-independent. Suppose you are thinking "I want my next RPG game to have 5 stats, Strength, Intelligence, Endurance, Personality, and Charm." Don''t include such stats in your engine. What happens if in any case, you decide to have 6 stats, or 7? Make the engine generic as possible as you can.

Making a good engine requires practice and experience. There is no way you can code a good engine just by reading a book. A good book just shows you the way, you are the person doing it.


My compiler generates one error message: "does not compile."

Share this post


Link to post
Share on other sites
Well, from the looks of everything most people seem to equate "game engine" with "graphics subsystem"! There''s a LOT more to a game engine than just shoving geometry around, if all you want to develop is a fancy renderer then you''re in good shape with all the recommendations so far!

The first thing to do is sit down and generate a list of desired features. Divide the features into logically grouped categories, something like "AI", "Networking", "Geometry Database", "Renderer", "Audio", "User Interface" and such. You''ll find a lot of dependencies between subsystems this way as well. After enough passes, you should have a decent idea of the number of subsystems you''ll be implementing and their interactions. Then you can pick a technology for implementation: Language (C/C++/Java/whatever) and component communication (COM, message-passing, etc).

The general concept is: decide WHAT you want to make. Then decide HOW you''re going to make it. And there''s nothing wrong with reverse-engineering someone elses code, learn from others mistakes - it''s more fun to make your own (lol do I know that one)! Strangely enough, I don''t think there''s actually a good book on "game engine design" that covers ALL the bases (graphics/AI/database/audio/physics/networking), everyone tends to focus on the "hot topic" which is mostly visuals - the most obvious part of the engine - and leaves out the "dirty little details" that make up the other 90% of the code.. ugh.

As to the clueless llama saying don''t do it: I''m sure this is from someone that''s still coming to terms with QuickBASIC. The only real way to learn something is to try and do it yourself, and that''s what I think the idea is here - learning how. Ignore this person, obviously Mom forgot to give them their Prozac before they went online.

Share this post


Link to post
Share on other sites
You will learn alot more by starting with a 2d game engine. I would probably opt to do it in DirectX. Don''t bother with Directdraw though. It is probably better to just do it in 3d. At least, it is alot easier, and what you learn can be applied to full 3d game engines.

As for what the guy above said, he is definately right. A game engine is a whole lot more than just pretty visuals. It would probably be a good idea to put alot of focus on AI, networking, and other things that make up a game engine. The fact is, there are too many "graphics" programmers in the games industry. If you are not the best, then you are unemployed. It would be better to concentrate on things that not a whole lot of people concentrate on. As previous posters have indicated, game companies are beginning to mainly purchase 3d party graphics engines. The main task to be done is usually adding in the game elements.

Unless you are a mathematical genius, I would stay away from the 3d graphics programming side of things. Instead, learn how to implement different file formats into projects, create realistic AI, do good networking code, how to write plugins for software used in game developement, make scripting engines, make editors and tools, and whatever else you might think would be fun.

Share this post


Link to post
Share on other sites
Have a look at the Ogre engine. Its free and available at sourceforge. You can use it as a reference when you need help.

Share this post


Link to post
Share on other sites

  • Advertisement