Saturday, May 14, 2011

3D Game and Graphics Engines

One thing that I get asked about a lot is whether you should use a game or graphics engine instead of learning OpenGL ES. Often, these emails are prefaced by a statement about how hard graphics programming. I've had to answer this question enough times now that it seems like a good topic for a blog post.

Honestly, I find it kind of hard to answer, because I don't see the "using an engine" and "learning graphics programming" as being distinct or mutually exclusive approaches. While a good game or graphics engine will handle a lot of the more gnarly programming tasks for you and shorten your development time, you still need to understand the underlying concepts to build anything of any complexity.

All of these engines are built on top of OpenGL (and/or DirectX if they support Windows), and are subject to the same limitations and strengths. Not understanding, at least at some level, how these lower-level graphics libraries work and the basic maths of 3D programming will eventually hold you back.

But… that doesn't necessarily mean you need to learn OpenGL before you can start using these tools effectively. You don't. It's just that some of the difficult, sticky math and concepts that might be scaring you away from OpenGL are still there (though better hidden), and you may well still have to deal with them at some point if you're doing the coding on the game (as opposed to just creating assets or doing level design).

Here's kind of a simple nutshell rule:

If you love graphics programming or are fascinated by it, then study OpenGL ES and the underlying maths and forget about using the engines at first (though studying their source is a great way to learn). There's always going to be work for good graphics programmers and you can't put a price tag on doing what you love.

If, on the other hand, your goal is to make a game or other graphics-heavy application, and graphics programming is just a means to that end, then use an engine, because it will shorten the amount of work you have to do tremendously, which inherently increases your chances of making money because time is money and there's never enough of it.

So, when shouldn't you use an existing engine if your goal is to make a game and not to try and be the next John Carmack? Almost never. Rolling your own game engine should be a labor of love. It's got to be an itch you can't scratch; the kind of desire that I probably couldn't talk you out of anyway. Otherwise, it's just a waste of your time.

What about when there just isn't an engine that works for what you want to do?

Honestly, that's not all that likely in this day and age, but even if it is, you're far better off starting with an existing engine and then modifying it to meet your needs.

From a business and financial perspective, it's almost never better to start from scratch. Even many of the AAA commercial game engines are derivatives of other engines. To give an example: Valve's Source Engine, is derived from their older Goldsource Engine, which itself was forked from the Quake Engine back around 1996.

Though there are quite a few game engines around, a very large percentage of high-end commercial games, both console and PC, are based on either the Unreal engine or the Quake engine or one of their derivatives. If you throw in a handful of other engines, like the CryEngine, you've probably covered all but a few outliers.

If it's not cost effective for large, multi-person development teams with multi-million dollar budgets to develop their own game engines, it's probably not the best choice for individual indie developers or small shops.

So, don't reinvent the wheel. Use an engine and stand on the shoulders of John Carmack and others like him. Don't spend your time trying to solve problems that are long-solved. Just be aware that using an engine can't completely eliminate the need to learn a little math or to understand the underlying concepts.

Engines

It just so happens that for a number of proposals I've done lately, I've been looking at game engines in some depth. I'm not going to do "reviews" per se, but over the next few weeks, I will try and post my thoughts about several of the engines available for iOS, including Unity3D, Sio2, Ogre3D, and Cocos3D.

I won't be discussing the UDK, even though it's a phenomenal engine, because it requires using Windows for many tasks, and I don't want to spend time in Windows. If you've got both a Mac and a Windows machine, however, and don't mind splitting time between OS X and Windows, you might want to check it out. A lot of time and brainpower has gone into getting the UDK to have incredible performance on iOS and the license terms have been changed to be much more friendly to small indie shops ($99 plus 25% of royalties after the first $50,000).



8 comments:

K. A. Barber said...

I tend to agree with everything you've said in this post. I spent enough time early in my career implementing boiler plate graphics code to know that if you are going to write a game you can't also be writing an engine, unless you have team large enough to have some people dedicated to it.

honkj said...

I just finished 4 months on a custom 3D engine from scratch* for the iPad, because the others did not have what i wanted to do... my brain hurts. i would not wish it on anyone else :0)

now i'm working on actual environments now, i need one of those DVI outs for my iPad2, i am aching to show it.

*scratch is of course relative, i started from this post of yours right here: (and years of CAD experience)

http://iphonedevelopment.blogspot.com/2009/04/opengl-es-from-ground-up-part-2-look-at.html

everything i learned, i learned in 2nd grade... no i learned from Jeff Lamarche openGL blogs.

honkj said...

i've got a related question, I had put in the Bullet physics engine, just to check it out, it is an amazing piece of work that is very cool to watch, but it basically brings a processor to it's knees if you want to work in real time and an iOS device.

has anyone seen an app using Bullet in 3D that is some what complex and is not (lack of a better word) slow?

do your proposals need 3D physics in them?

synchromesh said...

Thanks Jeff for the great post! Also for the UDK reference - I hadn't seen that.

What are your thoughts on Oolong? Will you be covering that in your short series of reviews?

Jeff LaMarche said...

honkj:

I haven't had problems with Bullet, but I haven't really had to do anything super complex. Are you using the same rendering meshes for your physics calculations? If so, that may be your problem. It's usually better to have a simplified physics model. A high vertex count physics model can very easily bring a physics engine to its knees on a mobile device.

synchromesh:

Honestly, I had forgotten all about oolong. If I have time, I'll take a look at it, but it's too late for me to consider it for my current projects, so it's going to be hard to find time to look at it in any depth.

synchromesh said...

Fair enough too. I mentioned it because it seems like a middle ground between writing one's own engine and using some cross-platform C++ framework. And because it's the one I'm looking at using myself, of course.

Heber said...

Jeff, Thanks for your thoughts on this. I've been really interested in 3D computer graphics since college, and am looking forward to your thoughts on different approaches.
Thanks again for your blog and activity in the dev community

mindgenies said...

I truly like to reading your post. Thank you so much for taking the time to share such a nice information. I'll definitely add this great post in my article section.
Web Development Company