The Invoice for a Borrowed Engine

When Unity announced its runtime fee model in 2023, I thought it was just news of a price hike. The idea of charging per install. Developers revolted, and the company backed down within days. The CEO was replaced and the policy scrapped. The incident appeared to be closed.

But what the uproar revealed wasn't the price. It was the structure. The moment an engine declared it would charge not on the shipment of my game but on the fate of my game, it laid bare what the relationship between tool and user had really been. The engine was not a hammer. The engine was the landlord of my workshop.

A tool fee and rent are different invoices

Traditionally, game engines sold tools. Buy a license, and the game you made with it was yours. Even Unreal's royalty model was clear: five percent above a certain revenue threshold. You gave a share in proportion to your success, but the rules were fixed before the game launched. You knew what you were giving up when you started.

Subscription and runtime billing change the tense of that contract. A tool fee is a cost you pay before you make something. Rent is a cost that flows out after you've made it — and flows harder the better you made it. The reason the per-install pricing concept was so terrifying wasn't the size of the fee. It's that the more my game thrives, the bigger an invoice I cannot control becomes. A design where success itself becomes debt. For an indie developer, this isn't simply a cost problem — it's a deal where you hand over a share of your own success in advance, and permanently.

As a critic, I often look at the economies inside games. A well-made game shows the player an honest relationship between risk and reward: stake this much, get this much back. Runtime billing models are the exact opposite. What the developer is staking is clear, but what they stand to lose only becomes apparent after launch. It's like buying chips at a casino and being told the exchange rate only after the game ends.

Why do indies hand over the handle of that knife?

Then why not just stop using it? This counterargument is fair — and only half right.

There is Godot, an open-source engine. MIT license, zero royalties, zero runtime fees. It was no coincidence that Godot donations surged immediately after the Unity incident. Technically, indie developers already have an escape hatch. For 2D games, Godot is mature enough — and in some respects lighter and faster.

The problem is that an engine is not merely a program that runs code. An engine is an ecosystem: tutorials, asset stores, credentials that carry weight in the job market, a common standard when outsourcing work. The reason a small team in Busan can't abandon Unity isn't fear of runtime fees — it's that colleagues who know Unity are easy to find, and a portfolio built in Unity brings in the next job. Lock-in is secured not through technology but through human capital and path dependency. Engine companies know this. That is why they can charge rent.

Here you can see the true cunning of the design. Engine companies don't bind developers with their tools. They bind them with the time developers have already invested — the workflow refined over five years, the keyboard shortcuts that have become muscle memory, the know-how documented in the company wiki. The cost of abandoning all of this is the switching cost, and the size of that switching cost is precisely the ceiling on the rent an engine company can extract.

Where to place the friction

I always write that fun comes from friction. A good game puts intentional resistance in front of the player. Just as Dark Souls earns its victories by refusing to be kind. Tools are no different. A tool that is too smooth conditions you to depend on that smoothness.

The essence of engine lock-in is a question of where friction is placed. In exchange for removing friction during creation, friction at departure is amplified. The entry is smooth; the exit is sticky. This asymmetry is what drives the rental model. So what an indie developer should be asking is not which engine is more convenient, but where they want their friction placed. Do you choose a somewhat inconvenient open-source engine now and buy yourself the freedom to leave? Or do you choose a convenient commercial engine now and mortgage a share of your success as collateral?

For Busan's indie scene, this is not an abstract discussion. Teams here are typically small — two or three people, six at most. A scale where the departure of one person can shake the entire workflow. The smaller the team, the greater the impact of switching costs, and the more deeply they become bound to rental models. Large studios at least have the capacity to build their own engines. Small teams don't have that option.

My suggestion is simple. From your very first project, build the exit as a design variable. Separate core logic into pure code that doesn't depend on the engine, keep your asset pipeline in standard formats, and try building at least your next project on an open-source engine. This isn't idealism — it's negotiating leverage. Only those who can leave have the power to negotiate the cost of staying. Making a great game and protecting your share of that great game are different skills. If Busan's small teams are to survive the next decade, they need to start practicing the second skill from their very first project.