Ships, Icebergs, Game Engines

The Our Machinery fiasco has made an excellent case for more self-reliant, more from-scratch technology.

Within the past week, The Machinery went from being a beloved from-scratch game engine project to being a seemingly-dead project.

As far as I can tell, nobody seems to know why, other than perhaps Our Machinery themselves. Within the past few days, this email was sent to their users:

Hi Everybody,

Thanks so much for supporting The Machinery.

Unfortunately, we’ve reached a point where it’s no longer possible for us to continue in the current direction. Per Section 14 of the End User License Agreement, the development of The Machinery will cease, all licenses are terminated as of 14 days after the date of this notice, and you are requested to delete your copies of The Machinery.

We really appreciated you being a part of the Our Machinery Community. We hope we have been helpful in some way to your development needs.

-Our Machinery

There are a number of theories floating around on why this could’ve happened. I’ve heard ideas ranging from internal team disputes, to legal problems, to a competitor enforcing a patent. I don’t really have an opinion on the explanation for this bizarre abandonment of The Machinery users.

But I’m not sure the explanation for why this happened is all that relevant. What is the end result of this turn of events?

What becomes of work authored for a project that used The Machinery as its engine? If a game developer is lucky, their investment in The Machinery was kept to a minimum, and their content is largely decoupled from The Machinery technology. That, though, would be a very lucky (or careful) user of The Machinery—what is more likely, for that game developer, is that a hefty majority of the authored content—levels, gameplay code, assets—is, in fact, quite coupled to The Machinery technology, and so the value of that game developer’s content has dropped dramatically close to zero.

So, given that, how much has been lost for that game developer?

I’ll provide a rough estimate just by walking through the arithmetic. Let’s imagine a few numbers that would be reasonable for a small, in-progress independent game development project:

• Number Of Developers: 2

• Development Hours Per Developer, Per Week On Project: 50

• Project Age (Weeks): 52

Given these numbers, around 2 developers * 50 development hours * 52 = 5,200 hours could easily be invested into an unfinished project. To quantify that into, say, USD, I can assume a reasonable pay that those developers would’ve made working at a game studio. Suppose that one of those developers was a gameplay programmer, and the other was a tech artist:

• Gameplay Programmer Salary: $100,000

• Tech Artist Salary: $80,000

These numbers would suggest that the gameplay programmer would make around $48 per hour, and the tech artist would make around $38 per hour. Multiplying the sum of those rates to the number of hours spent suggests that 50 * 52 * (38 + 48) = $223,600 has been invested into the project.

That is, roughly, the scale of resources that have been lost if the game engine these developers chose—a major part of their development stack—falls out from under them. It isn’t even necessarily a hypothetical figure—there may literally be hundreds of thousands of dollars on the line for some investor, that a game development team was hoping to pay back.

It doesn’t stop there, though—the coupling of one’s skill to a particular engine that, one day, simply ceases to exist means that skill is also no longer as marketable to, for example, employers. So, even if that game project wasn’t really intended to be shipped as a “real” game one day, it was being used (perhaps implicitly) as an educational mechanism for professional development, and the returns from that have also been greatly diminished.

Such circumstances are surely not unfamiliar to at least many of The Machinery users, and so this strange turn of events has been very expensive, in terms of sunk financial cost, loss of possible financial gain, and most importantly, time.

The Reason For Ownership

This has taught many people—in a fairly cruel way, in some cases—a valuable lesson that I’ve been writing about from time to time, that I will sound off about again in this post: a lack of ownership is a lack of rights. When you give up ownership, you give up your rights—the game development world should be acutely aware of this.

The Machinery’s users did not own the software they were using. The Machinery sold licenses to users that prohibited forking; you can always fork what you own. As a result of having no ownership in this situation, they had no rights in this situation—they can’t legally fork the codebase and continue using it. As such, they necessarily delegated the stability of the technology they were using—and all of the money and time associated with that stability—to the whims of The Machinery’s development team. Thus, such users are subject to whatever business troubles, legal disputes, or exploitative circumstances that this team happens to face.

Just as a financial advisor might write a post recommending that you diversify your portfolio, I write in this post to recommend that developers diversify their tech stack, and be careful of investing significant resources into “stock” that you can’t trust. Dumping that $223,600 into a single technology startup would be an insane decision—I see relying purely on a single centralized technology under external control as comparably insane.

In the game development and software engineering worlds, many people will offer advice to only use centralized game engines—doing anything else, to these people, is a waste of time. To them, there is no reason for anyone to ever work on tooling technology, or to iterate on engine technology. There is no reason for someone to want to make their own engine, because “Unity has already figured all of that stuff out”. I think such people could not be more divorced from reality, and The Machinery’s collapse demonstrates one reason why—when you couple yourself to external, centrally-controlled technology, you lose ownership, and therefore you lose your agency (over your time, your money, your project, your professional development). That isn’t some abstract theoretical problem, irrespective of how smug your Reddit sneering can be—it is a real, concrete, on-the-ground problem.

There are, of course, reasons why people use something like The Machinery, or Unity, or Unreal, or Godot, or any other game engine. They provide an enormous amount of value to many people. I do not write to suggest those people are all stupid and wasting their time—there are real reasons why an in-house engine is impractical for these people. So many beautiful and brilliant games have been made with such prebuilt engines, and those games have made the world a better place.

But the path forward for the computing world, in my view—even for the artist, the designer, the gameplay programmer, the writer—is self-reliance. Right now, many people choose game engines because self-reliance is notoriously difficult. I’m interested in making self-reliance in computing as easy for as many people as possible.

The Case For Self-Reliance

In self-reliance, there is agency—but importantly, there is also a greater degree of artistic expression.

Self-reliance provides agency because it provides ownership. You cannot force everyone to release their work under GPLv3 and make it forkable—not that this would even be preferable, because GPLv3 does not mean you automatically have ownership over the resource in question, other than a sort of quasi-ownership—but self-reliance implies the ability, and the means, to build that which you’d like to depend on yourself.

As for artistic expression—there is a myth that regularly circles around suggesting that “anything is possible in game engines that would be possible in your own engine”. This is often propagated by the same people who suggest that writing your own engine is a waste of time. This is simply not the case because of a fundamental truth about abstraction: something that is more abstract exposes fewer capabilities. A system with fewer capabilities implies a system with fewer possible outputs. So unless you believe that anything outside the set of outputs that Unity (or similar) provides is of zero value—a ridiculous belief, demonstrating quite the lack of imagination—then it necessarily trivially follows that, no, not everything you could do in your own engine is “possible in a prebuilt game engine”.

The designer, then, would be most empowered by good programming skills, which offer a unique degree of capability. Similarly, the best programmer—who has unique access to capability—is most empowered by good design skills. Unfortunately, the current computing world is one where people, broadly, choose one or the other. Designers, then, work primarily in tools with a high degree of abstraction, and thus with a much lesser degree of capability.

The computing world, as a result, has found itself in an odd situation—those most able to design are offered the least capable tools, and those who have no business designing have all of the most capable tools. The most compelling, functional, beautiful, thought-provoking, and meaningful work seems to arise when this artificial boundary between design and programming is blurred, and when one person embodies both the designer and the programmer.

How do we eliminate this artificial boundary, then? Right now, top-end systems programmers can already write their own game engines—they don’t need to rely on Unity or The Machinery. But artists, for instance, cannot do that. Gameplay programmers cannot do that. Writers cannot do that.

There is intrinsic complexity to game engines, of course, and so we may never live in a world where someone can trivially go from a design idea to a perfectly crafted, independent game engine that uses no external technology. Division of labor is still a necessity, and computers are complex.

The world I imagine, though, is not one where game designers need to sit down and learn to write C code. It’s already a ridiculous process for systems programmers, who have to survive awful tooling, poorly-made educational material, and obscure legacy cruft. The modern day game engine, though, is an extreme in the other direction—the artist, the writer, the gameplay programmer, and the designer couple all of their work to a single centrally-controlled technology stack.

Neither of these extremes are acceptable, but I also don’t see them as the only options.

The Self-Reliance Horizon

An artist today doesn’t sit down and produce custom tooling for their next game, not because it wouldn’t be helpful, but because it’s a practical impossibility. The barrier-to-entry for custom tool programming is too high. The tools are too obscure, too complex, too poorly-designed, and too opaque. So, they settle on the centrally-controlled game engine, which packages up a predefined set of tools for them.

But what if programming didn’t have to be quite this bad? Is it so difficult to imagine a programming environment where an artist can make high-level decisions about game logic, physics, a rendering pass, or even multiple threads of execution? Popular game engines, audio synthesis software, and other projects have already proven—to some degree—that artists can make at least some decisions about topics that were once thought to be strictly the programmer’s responsibility through non-textual programming tools. Obviously those can tools can get out of hand, but I think there is a rich future for this line of research—there is no reason why future programming tools would need to adopt only the data-flow node graph paradigm, for example.

In such an environment, I am not saying that the artist would write everything from scratch, but they would be able to “diversify their investment” into various centrally-controlled technologies (instead of investing only in a single one, which is true in the case of game engines). This environment, then, would offer composition between software building blocks. These building blocks can be shipped by engineers who can write them from scratch, and then easily used in an “orchestration” by, say, a designer or artist. The orchestration is where ownership lies, even if it is simple, and only ties a few pre-packaged features together.

Within this environment, all of the data that is relevant in design—textures, fonts, models, levels, materials—can be nested within the same structures, and used as resources in an artist’s orchestration. This environment, then, becomes the place where design and programming blur together—it forms a single and uniform medium in which information relevant to computing exists and is coordinated.

So, in other words, I see the solution to the ownership and agency problem as fundamentally the same as the solution to the lacking design and artistry tools problem—it, ultimately, is a world built around self-reliance.

People who scoff at this without further investigation are simply those who lack creativity and imagination (which is surely why it often happens in programming circles). Those depraved people will continue about their lives—perusing the Internet, pissing on the kindling of those wanting to start fires. But there are always such people before a revolution, and time has a way of keeping those people where they ought to be: lost to history. It is not so difficult to imagine tooling that makes this, if not easy, easier, and capable programmers with imagination and creativity will be those to get us closer to such tooling.

Nothing good comes easily, however, and so this future is going to take a monumental amount of research and development—it’s not likely to come very soon. But, nonetheless, I think this high-level concept illustrates the beauty of a future where self-reliance is much easier than it is today—it is a goal to shoot for, if nothing else.

The Programmer’s Concrete Steps, Today

This is, ultimately, a computing problem, and programmers today are those who will play a role in the solution.

While I find the future ideal of a computing environment that is built for self-reliance and artistic expression endearing, we cannot start there, simply because we aren’t already there. We need to start today, on the ground, and shoot for that future. Along the way, we cannot compromise the principles of self-reliance and ownership, nor can we compromise design principles. There won’t be a moment in history when we can suddenly turn those features on; instead, we must bake them into the computing world we build from the beginning.

If you’re a beginner or intermediate programmer, and if you’re interested in being a part of the solution, then I’d recommend the next steps are simply improving your own self-reliance over the short-term. Learn how to dispense with a library you use—learn how to write the equivalent from scratch. Dig a bit more under the hood. Learn more about the way your computer works, and understand the problems you solve from the ground up.

For experienced programmers who are interested in being a part of the solution, in my estimation, we can start today by gathering all such people who are of a similar mind to mine on this subject, and forming an inner-circle where people are interested in working on engine and tooling technology, and computing ecosystem research. This work should be done from scratch when feasible, by at least one person in this inner-circle—ultimately, no stone should be left unturned in ensuring that all parts of the computing ecosystem are accounted for.

If you are interested in this, then just shoot me an email.

Closing Thoughts

The Machinery’s collapse has given us a stark reminder of the presence of what seems to be a fundamental human truth—ownership is agency. If we continue to approve of a world in which ownership is regularly compromised, we will continue to see a decrease in agency, and all of the downstream effects of that—lost work due to the collapse of teams and projects, corporate or governmental exploitation, and diminished artistic expression.

I grow tired of the infantile, bland, and weak modern game development and software engineering culture with its “don’t reinvent the wheel” mantra, and its addiction to piggybacking off of the work of others. This culture diminishes ownership and scoffs at self-reliance. I value self-reliance, and so I’d like to be one part of a world which also values self-reliance—in that world, there would be stronger artistic expression, and design and programming would not be as distinct as they are now.

I think that world is possible, through deep understanding of computing, creativity, a design intuition, and some hard work.

---

If you enjoyed this post, please consider subscribing. Thanks for reading.

-Ryan