Unity Is Just the Tip of the Iceberg

Choice of game engine is one of the most fundamental decisions in game dev, for so many reasons.

I imagine by now most people have heard the news, how the executives responsible for trying to make the Unity game engine profitable, have made (and subsequently walked back) a number of, shall we say, curious decisions regarding their new revenue generation model. I’m not going to rehash how their choice to monetize installs, rather than implement a simple revenue share, like Unreal, creates a bizarre scenario in which some studios might be staring at negative revenue or how their scheme for counting installs is almost certainly a violation of European privacy laws. Rami Ismail has done a great job of laying out everything that makes this change so incredibly bewildering and potentially harmful to smaller studios.

For those unfamiliar with video game production at various scales, the simple response might be, “well, use a different engine.” And this perspective isn’t entirely without merit. We live in a world now with powerful open source engines like Godot, bespoke engines like RPGMaker and Ren’Py, as well as commercial engines like Unreal, whose revenue share scheme doesn’t collect a dime until the studio has brought in a million, so smaller studios and hobbyists can have access to powerful tools without paying out their eyeballs. At the same time, what this perspective misses is the degree to which choosing an engine represents a massive investment of time and other resources. Even if engines were simple one-to-one replacements—they aren’t—with experience in one transferring seamlessly to another—it doesn’t—that still wouldn’t address the major issue, which is the way in which game engines are, in a sense, entangled with a number of other things.

Engine as Nexus

So, I have something to admit. I’ve been making a game. About four months ago, when I was planning and conceptualizing things, I knew I wanted to make a visual novel, but I had yet to decide on whether I would work in Unreal, Godot, or Ren’Py, all of which I had some limited experience with. When I finally decided on Ren’Py, part of the choice was based in how the engine is specifically designed for making visual novels, but the primary motivator was the fact that I’m much more comfortable coding in Python than I am in C++ or Godot’s scripting language. The game I’m working on is based around a narrative encounter system with some wonky math underlying it, so not having to build my skills in an unfamiliar programming language meant I was able to get a demo off the ground in far less time that it otherwise would have taken me.

While an extra month or two of my time may amount to a few thousand dollars, at a larger studio with, say 50-100 people, shaving a couple months off your production time can equate to hundreds of thousands if not millions of dollars. The point I’m trying to make here is that even for me, a lone dev, an engine is not a self-contained entity. It’s a nexus into which a number of things plug in: tools, individual skills, and even institutions.

Unity now makes up a large number of games on the market. Something like 70% of all games on Steam were built in Unity. As such, much of the educational pipeline that feeds into gamedev jobs is Unity-centric. If, as a result of the recently announced changes, studios shift to other engines, much of that carefully built institutional knowledge will become less valuable, and it takes a long time for post-secondary institutions to implement widespread changes, even longer than it would for a AAA studio. I’ve seen this first hand in my own previous life as a university educator. Academics fear change.

This isn’t a post about Unity’s self-inflicted woes. I just want to show how an engine functions primarily as a source of articulations. You might use other tools to create various assets like guns or particle effects or character meshes. But the engine determines how the gun will generate the particle effects, how those particles will move through the playspace, and how it will affect the character mesh when the two collide. Moreover, this how is not agnostic. It expects assets to have been created in particular ways, using specific file formats, within narrow limits of sizing and so forth.

As a silly example, when I was making the sliders for my game, my first version of the cameo that serves as the slider button was much larger. I thought this would be fine, because I could just center it on the bar and have it overlap the text above a bit. Nope. No matter what I tried, the cameos hung down awkwardly from the bar. Eventually I realized I had two options for how to fix this. 1) Go into the .rpy files and change the sizing on the bars in every menu screen or 2) just resize the cameo. So, I did #2, because it was easier and because that’s what, in a sense, the engine was expecting. With the way the engine was setup out of the box, altering its expectations was much more complicated that just adapting the things that feed into it.

A Nexus of Tools

So, you have an engine, but you’re also going to need some kind of image editor (Gimp in my case). You’ll probably need an audio editor (Audacity), a video editor (DaVinci), and a 2D/3D CG generator (Blender). You might want to pick up free or paid assets from something like the Unreal Marketplace or Unity Asset Store (I made my own shit!), or you might even hire someone to work on specialized tasks like rigging or marketing. I also made use of Figma to create some wireframes and mockups, which might seem a little strange when your workflow includes exactly one person, but hear me out. When building UI and other layout elements, you’ll want sizings and placements to be pixel perfect, and Figma is helpful for giving x and y distances for something that you may have otherwise just eyeballed.

Figma was probably one of my most important tools, due to how it helped me with precise placement of game elements. My game has a number of elements that dissolve into one another, so precision of placement was key for making the transitions appear seamless. Figma helped me, in a sense, speak the language the underlying code does, saving me a great deal of time and hassle, since I didn’t have to randomly enter xalign or xpos values until things “look right.” The nature of the tools, then, feeds directly into the nature of the engine and the code its built up from. Likewise, the more you adapt yourself to these expectations, the easier time you’ll have developing your game.

This means one’s choice of engine has to reflect competencies with other tools. I noted above, one of the primary motivators for my choosing Ren’Py was my facility with Python. And this wasn’t a simple decision. As weird as it might sound, I was originally going to work in Unreal, due to the variety of visual tools that engine offers that Ren’Py simply doesn’t. Video, for instance, has pretty middling implementation in Ren’Py, which claims to support .mp4, for instance, but the internet is replete with people complaining about the many issues with using .mp4 in the engine. This leaves you with only .ogg to work with, unless you want your video to look like shit, which can be a faffy format to work with in the most popular video editing apps. In the end, because of the math issue I mentioned, I went with Ren’Py and decided to just ditch using video. I could have made it work, but for a demo, at least, the extra work just didn’t feel worth it.

A Nexus of People

So far, I’ve discussed matters primarily from a solo dev perspective, but the basic issues operate at scale as well. In fact, scale exacerbates them. If something isn’t working to my standards, like the video example above, as a solo dev, I can make an immediate executive decision to just ditch it. No harm, no foul. No one’s feelings are hurt beyond my own disappointment. However, in circumstances where, say, your in game menus are being designed by a UI person and the art assets by a 2D artist, then you can’t make changes like that on the fly. One of the things an engine does, by setting certain design expectations, is help make sure these disparate people working on their own will be on the same page. And if they’re not, the engine actually establishes a standard by which the efficacy of their work can be evaluated. You might come up with a particularly clever UI design, but if it doesn’t work in engine, all that work is for naught.

There’s an irritating thing you hear from time to time from people with a lot of experience playing games but none actually making them. It typically takes the form of “it’s a simple database fix” or “it’s just a checkbox in Unreal Engine.” Few statements are as clear an indication that the person has no idea what they’re talking about. But let’s say there were a setting in Unreal called “Fix Your Bug” that all you had to do was tick on. Done and dusted, right? Well, it’s something of a truism in gamedev that for every bug you “fix” you create a dozen more. And quite often fixing what you’re working on has the potential of breaking things for what someone else is doing, leading to a cascading series of recriminations where everyone is blaming everyone else for things not working properly.

This is why, at their core, engines have to provide a degree of consistency and stability. There were (are?) studios still working in Unreal 4, long after 5 had come out, precisely because as time passes and your game becomes a massive web of inter-dependencies, you need to be certain that how things interact with one another remain consistent. Likewise, with people, they develop certain affinities and skills based on existing processes, so if you pull the rug out from under them by mandating an engine change, all that lived experience and know-how has to be reconstituted.

Which is to say the people who make games need to “plug into” an engine in much the same way tools do. Sure, you could hire someone who’s only ever worked in Unity to come on board your Unreal project, since most of the fundamentals of combat design or level design carry over, but it’s going to take some time for them to produce at the level the project demands. More time, arguably, than someone with a similar level of experience but in the engine you happen to be using.

Stop Blaming the Engine

In the aftermath of Starfield’s release, while the game has been widely popular, there have been the usual “gamer” complaints. I should be clear, I use the word “gamer” with utmost contempt. Because if we’re talking about “people who play games,” then, well, that’s basically everyone. But if we’re talking about people who loudly identify as “gamers” and use this as a badge to browbeat other people who play games as well as those who make then, then… well… die in a fire. I’m only half kidding.

One critique that has emerged from this set has to do with Bethesda’s proprietary engine, Creation Engine. I shouldn’t say fully proprietary, I suppose, because if you’ve ever used Skyrim’s Creation Kit, then you’ve made use of an earlier iteration of Creation Engine, albeit in a more limited form. What’s annoying about these critiques is how they seek to blame Creation Engine for what are, ultimately, aesthetic choices that have nothing to do with the underlying tech. And the reason why this is so annoying is because it once again signals the general ignorance that so many “gamers” apply to the very games they play. There is a failure to understand that 1) devs make hard choices in order to get the fucking game out on a reasonable schedule and 2) perhaps a studio has a particular aesthetic they feel compelled to reproduce, even if the individual employees feel it’s long past time to rethink things.

Neither of these two points have anything to do with the engine. Engines are quite versatile, despite having certain limitations or being designed for specific types of games. You can make a visual novel in Unreal, though I wouldn’t especially recommend it. You could even make a puzzle platformer in Ren’Py, but it would require so much Python code that, honestly, you could just write it all without the engine. The point here is engines are a framework. They might guide or facilitate certain forms of game design, but they don’t determine them. An enterprising engineer could bend any engine to their will.

I guess the point I want to end on, then, is that game engines are not this end all, be all of game design. In fact, it might make more sense to regard them as another tool—a tool of tools, if you will—that facilitates creation rather than determining it. It would be silly to blame the composition of an image on Photoshop, so it should be equally silly to make assumptions about a game based on the engine it’s built in. And if you find yourself ever wanting to say, “it’s such a simple fix!” then, maybe, just don’t. Few things in gamedev are truly simple, and if you want your critique to be taken seriously, you might want to keep that in mind.