Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm writing own game engine and want to look how other peoples implement game engine architecture. So any advices about well architected engines (even paid ones) are welcome.

share|improve this question

migrated from Jun 25 '11 at 3:11

This question came from our site for professional and enthusiast programmers.

Paid ones usually come with an NDA – Maik Semder Jun 25 '11 at 7:11

First, let's make sure we're on the same page here. If you're looking for something to let you render in 2D, I consider that separate from a 2D game engine.

A 2D game engine provides more than just low-level commands. It provides a place to hook AI behavior. It provides real structure that you can build on. So I'm going to talk about those kinds of things, not merely 2D drawing systems.

There really aren't a lot of 2D engines out there. The one I know off the top of my head is Torque Game Builder (aka: Torque2D).

But the real problem is that you asked for "well architected engines." Quite frankly, I'm not sure such a thing exists, whether 2D or 3D.

I've looked at the guts of Torque2D, and while the library looks reasonable from a high-level user perspective, if you actually read any of the code, it's like something out of MC Escher. I'm sure there was rhyme and reason to it at some point, but that was a long time ago.

I've seen quite a few other engines, and perhaps the most well-architected one I could say I've seen is maybe Quake. And that one has more C-isms in it than you can shake a stick at.

Game engines are notoriously hard to architect well, for a number of reasons. Most engines aren't built to be engines; they're built to be a game that is highly moddable. So they're built on a game development schedule, which accrues quick-fix hacks and other unpleasantness readily.

Another big reason is that everything may need to talk to everything else; system segregation is really hard to maintain. Animations need to cause sound playback. AI actions need to cause graphics to happen. Sound playing needs to notify the AI (so characters can "hear" sounds). The "tree" of calls in a game often turns into a nightmarish graph.

The bane of every game engine is the dreaded entity class. I've seen several entity classes in a few shipped games, and while some of them may have been OK, none of them were good. You have not seen a "fat interface" until you've seen a game's entity class. It makes sense; it needs to touch everything. It touches sound, rendering, animation, AI, networking, anything that actually matters in a game ultimately comes back to the entity class.

My advice: look at how some 3D engines handle it. There really isn't that much difference between a 2D game than a 3D one; it's mostly about the renderer.

share|improve this answer

I hate promoting my stuff here, but I'll just mention that my own C++ game engine for rapid prototyping is here:

It began life as a 2D vector graphic-based game engine (as prototypes happen faster, I've found, if you're not thinking about sprites), but has now being extended to support simple 3D graphics and textures as well, if desired.

But apart from its somewhat eccentric and manual style of rendering, it's reasonably full-featured, with its own memory manager (with leak/overwrite/etc checking), an integrated physics system (currently using Box2D), sound/music systems, keyboard/mouse/gamepad handling and remapping systems, its own maths code, etc. And it's compatible with Windows/Mac (and all but sound with iOS), and could be ported to Linux without much more work than simply writing a Makefile. Please do feel free to grab the source from the live subversion trunk and browse through it, copy bits of it into your own project, or whatever. I'm happy for folks to make use of any of that code in whatever ways they like.

It's still under active development (including some major restructuring right now, particularly in the rendering area), so the commenting/documentation isn't fantastic, and may occasionally be a little out of date. But the code is all there, and is reasonably under control and organised, and there are plenty of sample game implementations to compile, play, and browse the sample code from, to see how it all fits together.

share|improve this answer

The two engines (with available source) that I feel stand out in terms of C++ architecture are SFML and Ogre3D. Ogre3D is considered by many to be one of the best examples of object-oriented design, though it is a massive engine and therefore takes some effort to learn. SFML has a similar design, but is considerably smaller and geared specifically towards 2D, and you may find it more useful for the time being. Granted, neither is a full-fledged "game engine", but it is an excellent start.

Suggestions aside, I'd say take a look at lots of engines, whatever you can get your hands on. Not a one is perfect, and studying a wide variety can help you figure out what you like and what you don't like about each one, which in turn will help you design your engine to best suit your own needs.

share|improve this answer
I'm not sure how these will help him see what 2D game engine architecture should look like, since, as you point out, they're not game engines. Ogre3D is a renderer, and SFML is a multimedia library like Allegro. – Nicol Bolas Jun 25 '11 at 5:52
SFML is not an engine. It is a framework. – The Communist Duck Jun 25 '11 at 16:28
The Ogre forums house a variety projects, mostly games, with source and many times friendly authors. While Ogre itself is nothing but a renderer, the ecosystem around it is a great place to look for example architectures. – Patrick Hughes Jun 25 '11 at 16:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.