The answer to the question “what is the best game engine?” isn’t simple. As I’ve said before, it all depends on what kind of project you’re building, what sort of resources you have to work with, and what kind of workflow you’re comfortable using. The best game engine, then, is the one you program yourself. In that situation, you define all of those things for yourself, in a way that is perfectly tailored to your project, your team, and your way of thinking.
The question you’ve inevitably got to ask yourself as you approach building your own game engine is “why would I do it if I have so many good options available?” It’s hard to justify re-inventing the wheel in a world where the likes of Unity3D, Game Maker, or UDK exist, or even when you consider the libraries available for this kind of thing in Flash. However, all of these options have shortcomings to take into account. Some of them are in terms of an engine’s power, some of them are in terms of organization or workflow, and some of them are deceptively a result of how broad the tools and scope of the engine are.
To really illustrate what I mean, I wish to use an art game I recently worked on with my friend, Marie Lazar. It’s called Reveal, you can find it here, and It was built in the Unreal Development Kit. In this game, players are tasked with escaping from a room, first by tearing magazines off the walls, then by tearing through wallpaper, then by smashing boards, pipes, and finally a layer of concrete. What I want to discuss specifically is the wallpaper layers.
What Marie intended was for each wallpaper to be a single plane spanning an entire wall, which could then dynamically tear into chunks and be ripped off when grabbed by the player. Cloth actors can be ripped and torn, but then how do you tell when every shred has been removed from the wall, IE when it’s been torn apart completely? Without being able to access the C++ code for cloth simulation, there simply is no way to do this. Additionally, the cloth simulation itself left something to be desired, as it could not be grabbed and manipulated by a physics handle. It could be if it were “anchored” to a skeletal mesh physics actor, but the cloth needed to be ripped free completely, and this has the effect of at least one portion of the cloth remaining stiff while the rest of it is limp. If you think of flags and banners, you know what I’m talking about. This is actually the intended use of cloth physics in Unreal and most engines; our use of it was strictly off-label in that it had to go completely limp.
In summary, the cloth physics were insufficient to perfectly capture Marie’s intent. We managed to get it “close enough” with a few work-arounds, like separating them into pre-torn strips, but it’ll never quite be “perfect.” Had we been coding the engine for this game ourselves, we’d have been able to program the cloth simulation to work to her exact specifications. We could keep a matrix of the vertices that were still in their proper places versus the ones that’re disconnected or “shredded.” We’d have been able to change the simulation’s parameters, including its collision and interaction with physics handles, however we wanted. Maybe most importantly, we could have eschewed a lot of unnecessary systems that Unreal has that we didn’t need, like certain aspects of Pawn physics, and diverted resources into the kinds of physics we wanted to have happen, resulting in a more focused performance from the game where it came to the extensive physics simulation with fewer hacky cheats.
High-level tools like Unrealscript, Kismet, or LUA, though they can be quite powerful, are really just a shortcut for what you’ve already laid groundwork for — or in this case, groundwork you’re trusting someone’s laid for you. In the case of Reveal, building our own engine was simply out of the question as it would have entailed months of R&D and low-level graphics, physics, and tools programming that frankly neither Marie nor I were prepared to do, which is why we settled for “good enough” rather than “perfect.”
“Good enough” got the job done, and should be thought of rightly as a relative term. The fact is that these pre-packaged deals save quite a lot of time in reinventing the wheel on some super-low-level systems, rendering and collision especially, and for most established types of games that can be “perfect,” especially if you can adapt and aren’t overwhelmingly picky about execution. Plus, they’re stable. Think about programming your engine and doing usability testing for that while your designers are also trying to get work done with it, it’s not pretty or very practical.
What I’d like to put into perspective, though, is that “perfect” execution of an idea is a perfectly attainable solution with a clear path, that being the low-level control that C or C++ provides access to. This is provided you’ve got time, of course, which nobody ever does these days, as well as no small amount of low-level programming resources and skill, but it’s still an attainable goal that there’s many good reasons to seek. As a few examples of what I mean, think of the terrain editing tools and global lighting in CryEngine; think of the massive, persistent world state in The Elder Scrolls, and how it saves every individual object you can pick up with almost no effort on the part of level designers, even as you cross miles of territory; think of the huge variety of enemies you fight in Kingdom Hearts, and the kind of editor you’d need to quickly add and tailor hitboxes to their numerous, hyper-kinetic attacks. If you’ve got the foresight to plan what kind of game you’re building ahead of time and the skill to code it from the ground up, you can tailor the entire design pipeline to your specifications and make developing your content exactly as easy and as streamlined as you would like it to be. And that, friends, is why the best game engine, inevitably, is the one that you build specially for your project.