Closed Source Engines are a Big Risk

I've been learning a lot about what I prefer in terms of tech to develop games since starting a company where we help build a wide variety of games and demos for people.

So far, our two major projects have been a custom engine project and a Unity project.

The two of us have spent our whole careers writing C++ and making engines (in fact, we'd both worked at Unity building the engine), so we thought we'd take a nice vacation from memory management and C++ and pick that one first.

In short, this was far from a vacation and in fact using Unity put the entire project at risk of not shipping. Developing in Unity involved months of hunting down obscure, black-box bugs that were fixed by switching versions, we had to trash weeks of work for this. It was not fun. It was well worth the high rates we charged. It didn't help that we're still in the early days of VR, I'm sure.

It's the black box nature that's most troublesome to me. With source code, it's still a huge codebase that's hard to parse and has plenty of problems, but at least I can hunt down my bugs.

This project was able to build up really quickly at first, but almost couldn't launch because of Unity issues. And this is with two engineers on the project with tons of engine and game development experience.

I know not every project runs into this issue, but it made me never want to use Unity in production, ever. Prototypes are fine. Anything beyond that is a risk I don't need to take as a programmer perfectly capable of digging into the innards of engines.

In production-quality projects I lead tech direction on, I will only use an engine with source access, or build my own. I can't take this risk.

Building our own actually turned out to be a joyful experience. It was a simple app, didn't require a lot of features. It was an unexpected, fun breath of fresh air.

How It's Like to Work as a Graphics Programmer

Can Your Code Be a Product?