← All writing

Game Dev · · 5 min read

When your engine flips the table

Unity's 2023 pricing change landed when we were halfway to launch. It mostly blew over, but it changed how we think about every dependency we build on.

We had the misfortune of being deep into development of our first game when Unity's leadership decided it would be a great idea to flip the table on their licenses and, by extension, on everyone who licensed their engine.

That was September 2023. Unity announced its Runtime Fee: a charge per install, on top of the subscription, once a game crossed certain revenue and install thresholds. We were roughly halfway to launch.

Two developers, two reactions

We weren't in a position to be hit by the changes right away. But it was a gut-wrenching moment, and it caused some real conflict between Derek and me.

We had different perspectives on how bad it was, what it meant for us as we kept building, and whether it was a problem we were ever likely to run into at all.

I was angry. For years I had trusted Unity to be the platform where independent developers could not just exist, but thrive. The new model felt like it was going to crush small developers.

There are a lot of people out there making games entirely for the love of it. My real fear was for the free game that takes off. Remember that Minecraft started as a free download on Notch's website. Charge per install, and a game that makes a little money while millions of people play it for free could be crushed by its own success.

Running the numbers on success

We also had to think about the other end of the spectrum.

We had, and still have, ambitions of selling so many copies that we'd have to worry about this kind of thing. Those ambitions are currently unrealized. But the question was real: could we survive being charged per install? Was there a tipping point where the arithmetic turned against us, where selling more meant earning less?

When a player becomes a cost

That question pointed at something we'd been thinking about since the beginning: keeping our cost per player low.

Empire Builder doesn't have in-game purchases. We've talked about cosmetics and the like, but today none of that exists. A player pays once, or a few times if you count DLC maps.

So what happens with the player who loves the game and plays it every day? Every service that charges us while they play keeps charging us long after their last purchase. Somewhere there's a threshold where a devoted player stops being a profit center and becomes a cost.

That's not a hypothetical. It's real and it has to be considered.

Too far in to turn back

We had been weighing all of these decisions throughout the project. The Unity announcement just forced them into the open, all at once, halfway to launch.

In the end, we felt we were too far in to turn back. We held out hope that the community outcry would push Unity back from the brink.

So we kept marching toward release, with our fingers and toes crossed.

Mostly in our heads

As it turned out, most of it was in our heads. Unity walked back the most offensive parts of the change within weeks, and eventually dropped the Runtime Fee altogether. For us, in the end, it was kind of a nothing burger.

It didn't feel like one at the time. A decision we'd made months earlier, choosing an engine, suddenly felt like it could sink the whole project.

Hitching your pony to the right wagon

We did learn a valuable lesson. Especially in today's world of SaaS products and third-party services, it's entirely possible to hitch your pony to the wrong wagon.

If you're a new independent developer, be careful about which dependencies you build into your product. Understand what they cost today, and what they'll cost later, when your fledgling studio trips some revenue limit that changes the arithmetic.

Derek and I were wary of this before Unity's announcement, and we've been very wary of it since. The situation we work hardest to avoid is one where we're spending money to support an existing player base in a game whose revenue has slipped below break-even.

Here's what that looks like in practice. Today, Empire Builder is played entirely between players' machines. One player's game acts as the host, and we've taken reasonable steps to keep everyone in sync and to prevent cheating. (We've never caught anyone cheating, but reasonable steps.)

A small but vocal group on the Steam forums would love for us to add asynchronous play. Think back to the days of yore, when people played strategy games by emailing their turns back and forth. In today's world, that means a service in the middle: something that keeps track of every game in progress, takes in each player's turn, and hands it to the next player whenever they get around to loading up the game.

That service is a cost that never ends, paid on behalf of players who paid us once. A service like that might seem like a drop in the bucket, but our bucket is pretty freaking small. So we're unlikely to ever build it.

It's not fun to tell your players no. Sometimes it's necessary.

Choose your engine, your backend and your storefront the way you'd choose a business partner. Whether you signed anything or not, that's what they are.