What's in a Game: The Color of Game Engines

by Noxon 09.12.14

Game engines have a unique, substantial, and inexorable influence on the games made with them. I call this influence “color,” and it’s a form of distortion. Not withstanding myriad other factors, distortion is the reason why games with identically designed starting points, but built in different engines, would turn out wildly different from each other.

The idea of color was first brought to my attention upon realizing how easy it was for me, in general, to pick Unity games from a lineup. Telltale signs of Unity include frivolous 3D graphics, violent shader abuse, shit gameplay, and of course, the dead giveaway, UnityGUI. Even barring the more obvious colorations afforded by an engine’s official featureset, like graphical capabilities or overreaching platform support, distortion also permeates the products of an engine in less conspicuous ways.

In practice, games are designed more or less on the fly by the people who code them. Even in a shop with a clear vision of a project and design documents galore, the gameplay programmers are ultimately responsible for developing designs on paper into tangible mechanics. As a result, the technical environment and headspace furnished by the engine are the prime grounds where design decisions are truly forged. Ergo, the engine plays an integral role in the creative process, and so colors a game’s design considerably.

I'm going to break down Super Murderwolf, our latest game, to highlight the ways, some remote and some direct, in which my choice of game engine, Flambe, influenced the final product.

I never would have done the sliding transition from the menu to the game if it weren’t for the way Flambe manages scenes, and includes a collection of sliding transitions by default. In another engine I would have done a fade, but the slide is superior and complemented the impending gameplay perfectly.

Most numerical variables in Flambe are trivially animatable. This made it easy for me to make things bounce and accelerate in tasteful ways without much work. So I was able to juice things that I otherwise wouldn’t have had time for, like the bouncing logo on the title screen and the zooming “Try Harder” text that appears when you crash.

Everything is moving on the title screen before sliding straight into the gameplay.

Flambe is sparsely featured and somewhat buggy; this contributes a lot to its character. There is no straightforward way to load frame by frame bitmap animations, there is no support for Flash embedded assets in the mainline, and performance at the default 60 fps is pretty inconsistent, to name but a few of the issues I encountered. I was able to fix most of these problems for my purposes. Some of the fixes, including embedded asset loading, are available in my fork, but time wasted patching the engine could have been better spent improving the game.

Flambe lacks the concept of a camera in the renderer, so there are no means to view world coordinates outside the range of the screen. In order to make it look like the player was constantly advancing upwards while keeping them visible, I had to have the ground and mountains move toward the player character, whose world position was clamped to stay on screen. I would have preferred to move the player character towards the obstacles.

The player appears to move, but is vertically stationary.

Though I always planned to implement beat-synced obstacles, its one of the last things I did because I expected it to be impossible. In many engines it would be. However, even though I got it to work, the way audio is handled in Flambe means that beat-sync will never be perfect, and it’s still particularly bad on Linux. If Flambe didn’t support HTML5, embracing some Flash specific features would have allowed for a perfect sync. So, although I didn’t use HTML5, its presence colored my game. The problem can only be exacerbated in engines with support for more platforms.

Most engines, like Flambe, aim to be transparent, while some, like Twine, OpenBOR, and M.U.G.E.N., are defined by their color. Either way, the engine will actively exert itself on the decision making of those involved in developing with it, thereby modifying characteristics of the game to fit the engine. To get slightly metaphysical, by the butterfly effect even the slightest of these modifications can have profound consequences, for better or for worse.

So, would a game in any other engine smell just as sweet? I think not.