Get the latest Education e-news
 
  • What is a Game Engine?

    [04.29.08]
    - Jeff Ward

  •  Birth of a Game Engine
    For a long time, many game companies made their own game engines and kept that technology in house, iterating on it as computers improved and more advanced versions were needed. Engines like SCUMM by LucasArts and SCI by Sierra, for example, powered most of the adventure games that those companies released in the late 1980s and into the mid 1990s. More recently, engines like id Tech (the engine that powers the Quake series of games) and the Unreal Engine started as in-house technologies, though they have recently evolved into middleware technologies as well.

    Over the past several years, the cost of making an in-house engine has grown significantly, and more and more companies have begun to specialize in making either full game engines or game engine components to sell to other companies, rather than make games. We call these kinds of companies middleware providers. The middleware providers can offer these products at very reasonable prices, and, for most game development studios, this creates a very clear "build versus buy" decision. Why pay six programmers for a year to build an engine when you can buy 90 percent of the features you want from a proven technology for less money -- and have it immediately? As a result, almost all components of a game engine are purchasable at a variety of prices, or downloadable in the form of open source projects.

    Types of Game Engines
    Game engines come in many different flavors and at many levels of programming expertise. To get a feel for how different they can be, I'll explain three kinds of engines: the roll-your-own version, the mostly-ready version, and the point-and-click engine.

    Roll-your-own game engines (lowest level). Despite the cost, many mainstream companies (as well as indie game makers) will still attempt to roll their own engines. This means they use publicly available application interfaces, such as APIs like XNA, DirectX, OpenGL, the Windows and Linux APIs and SDL, to create their own engines. In addition, they may use other libraries, both commercial and open source, to help them along the way. These libraries might include physics libraries like Havok and ODE, scene graph libraries like OpenSceneGraph, and GUI libraries like AntTweakBar.

    I include XNA and SDL here because, although they make creating an engine much easier by abstracting away some of the more nasty platform implementation issues, they still require a lot of programming to get a game off the ground. They're not really engines so much as good starting points for creating your own engines.

    Generally, these home-rolled systems give programmers the greatest amount of flexibility, letting them pick and choose the components they want and integrating them exactly how they want. But they also take the longest amount of time to build. Additionally, programmers frequently will have to build the tool chain from scratch, since they can rarely rely on all these libraries to work together straight out of the box. This makes rolling your own engine less attractive to most game developers, even the professional ones.

    Mostly-ready game engines (mid level). I consider most game engines to be "mostly ready." These engines are ready for prime time right out of the box, with rendering, input, GUI, physics -- you name it. Many of them even have mature tool chains so you don't have to roll your own. Engines in this category include OGRE and Genesis3D, which are both open source, low priced engines like Torque, and even really high priced ones such as Unreal, id Tech, and Gamebryo.

    To varying degrees, all these engines still require a bit of programming to get them up and running into a complete game. They might call for some scripting or sometimes even low-level coding to get a real game working. Mostly-ready game engines are a bit more limiting than roll-your-own engines and are frequently optimized for the general case. That said, many of these engines are the product of dozens of people's work over hundreds of long hours, and will provide better performance with less effort than most roll-your-own engines, even if they don't do exactly what you want.

    Point-and-click engines (highest level). Point-and-click engines are becoming more and more common these days. They include a full tool chain that allows you to point and click your way to creating a game. These engines, which include GameMaker, Torque Game Builder, and Unity3D, are built to be as friendly as possible, and are made to require as little coding as possible. That's not to say knowing a little coding doesn't help, but it isn't really a necessity the way it is for the mostly-ready and roll-your-own engines.

    The problem with many point-and-click engines is that they can be extremely limiting. Many do one or two types or genres of game well, or one or two types of graphics modes. This is not to say they're useless. Even faced with the restrictions of these tools, it's possible to make highly creative games or even find creative ways around those restrictions. The best thing about these engines is that they allow you to work quickly, and play your games quickly, without too muck work. If you're just starting out in game design, you could do worse than these tools.

    For More Information
    There are many resources for finding game engines. Wikipedia is generally the best resource for engine information, and it lists all the known open source engines. The pages are frequently updated and frequently give feature comparisons:

    These pages also provide a list of games that use more common engines.

    Jeff Ward is a co-founder of and lead programmer at Orbus Gameworks, a provider of metrics and data-gathering tools for game developers.

Comments

comments powered by Disqus