Jump to content
  • Advertisement

Archived

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

sab3156

Game Engine Development

This topic is 5648 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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!