Making/Building 3D Game Engines

[LUkLy60M]

Hello everyone! Let's get straight to it.

Making/Building 3D Game Engines, Do I need to know anything related to ART or graphics in order to make them ? I mean, I do know that having a know how about vectors is VERY important, But I am no good at art, I suck. I have thought of getting a separate guy to do the art, as I'm more interested in writing code and then implementing it making use of the art that has been made, I'm just worried if I need to or not need to know anything about sketching or art in order to write a 3D Game engine ?

Thank you.

[LB]

You need no knowledge of art. You can easily find and hire a graphics designer. Additionally, if you want the in-game environments to affect people in specific ways, people in marketing are good with that.

Really, as with any game, you need lots and lots of math. The engine itself will mostly be just plain math and interaction with whatever graphics library you use, it's going to be brutally anything but art. In fact, you'll probably find yourself trying to line things up to make your code visually pleasing to read (art!) ;)

[cnoeval]

There's no art involved, just LOTS of advanced math and physics that require HIGHLY optimized algorithms. Good luck. I would just use one of the fantastic, free engines available and spend my time working on the games themselves.

[LUkLy60M]

ahahahahah that is good to hear! :P
I do not want anything to do with art, Atleast not when I am coding ! I want it to be purely syntax and math related.

I am just starting out on C++ and have almost gotten the grasp of all the basic/advanced concepts of it, I will be done with Inheritance/Polymorphism soon, At the moment I'm playing games with an analytic sense rather than when I used to play them.

Could you also tell me what topics in math I should study and relate to more in order to make me better at coding ? Other than Arithmetic and Algebra.

[LUkLy60M]

@cnoveal

Yes, I am currently using blender/unity/torque to make some prototypes, but they are only to see how engines work and how they interact with objects, I am more interested in making my own engine, even if it takes a long amount of time, Once I do have it down, I can use it over and over again to make different types of games.

[LB]

Study lots of physics and trigonometry. Calculus also helps, but it's mostly he trig and physics. Optimizing your algorithms is more important than optimizing your actual code in most cases, so you should study into algorithms and optimization too.

Making a game engine is brutal even if it is as simple as Minecraft. Good luck!

[NGen]

You're free to ignore the artist's process, but if you do you're likely to make a program that's great for programmers but terrible for artists and/or game designers (the two tend to be one in the same.) And more often than not, the programmer is spending more time in the code of the engine than in the engine itself. If you want it to actually be usable by anyone other than a programmer, remember that the end-product is something that helps a team make a game, not something for you to program. Design for how the end-product is going to be used, not for whatever interests you at the moment.

Then again, you're free to take the immediate programmer's approach and just program as you feel like it. Since this is your first time working on anything like this, acknowledge that this is a learning experience rather than a practical one. Try to combine the two and, I promise, you will fail miserably. Trying to design when you don't know what you're designing for/against tends to go badly unless you have guidance. Study other engines as much as you like, but you're only looking at the API, not the architecture. An engine where you can get a feel for the architecture through the API is not an engine that should be studied.

In terms of mathematics, I highly recommend 3D Math Primer for Graphics and Game Development by Fletcher Dunn/Ian Parberry. It covers a LOT of required mathematics in linear algebra for multiple coordinate systems and also provides wonderful explanations and diagrams for an explanation.
(Note that I have the second edition, which is linked below. I can't comment on the first edition.)
http://www.amazon.com/Math-Primer-Graphics-Game-Development/dp/1568817231

Another suggested read would be Game Engine Architecture, by Jason Gregory. Note that this is more of a book of guidelines than a comprehensive walkthrough, but despite that it still packs a lot of content. Definitely indicative of how much a full engine can have. It'll let you know what you might need and how you might go about handling it. It does not, however, explicitly go over systems interaction and the architecture as a whole. Ironic, but this seems to be the case. Take that note with a grain of salt, though, since I don't have the book right in front of me to reference. (Currently being borrowed by a friend.)
http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

[Ogoyant]

I'd also recommend:

Mathematics for 3D Game Programming & Computer Graphics by Eric Lengyel
http://www.amazon.com/Mathematics-Programming-Computer-Graphics-Development/dp/1584500379

Real-Time Collision Detection by Christer Ericson
http://www.amazon.com/Real-Time-Collision-Detection-Interactive-Technology/dp/1558607323/ref=sr_1_1?s=books&ie=UTF8&qid=1358979857&sr=1-1&keywords=real+time+collision+detection


also, it's interesting to see 3D Game Engine Architecture by David H. Eberly, and the accompanying website http://www.geometrictools.com/ . The engine he discusses in his book is open-source and downloadable from his website, and can be compiled in Mac, Linux and Windows. Interesting material.

[MrHutch]

The only art related concern I can think of is the parsing of 3D models.

You probably want to make sure that your engine supports at least one of the favoured 3D model formats (.obj, .fbx, etc.). That way, model formats commonly exported by 3D artists should be loaded into your program without much hassle.

An alternative, and something I used on a project recently, is to have your own model format with a separate parser that turns a common format into your desired format. So you'd have an artist export a common format, run it through your parser to turn it into your engine's format, then have your engine load it up. The advantage of this is that you can trim a lot of the unnecessary bulk that comes with common formats, reducing game assets size and increasing model load times.

Hope this helps.