Game Engines

Historical Context

Tim Cain started making games in 1981. For roughly the first 20 years of his career, there was no choice — you made your own engine because there was nothing available to buy. Every game he worked on used in-house engines: Fallout, Arcanum, Temple of Elemental Evil, and even WildStar. The one exception was Vampire: The Masquerade – Bloodlines, which used Valve's Source engine.

Even within companies like Interplay, sharing code between programmers was a struggle. Some programmers refused to let anyone see their source code, only distributing pre-compiled libraries. Tim tried to write shared utility code — handling bank switching on video cards, assembly language timers — but territorial attitudes made collaboration difficult.

At Obsidian, South Park: The Stick of Truth used an in-house engine called Onyx (originally built for Dungeon Siege III), demonstrating that generic engine components could serve wildly different game types.

Since 2014, Tim has worked with both major commercial engines: Unity for Pillars of Eternity and Tyranny, and Unreal for The Outer Worlds. He already knew C# and C++ going in, which put both engines on level footing for comparison.

Advantages of Building Your Own Engine

Exact Feature Set

You get precisely what you need — nothing more. Off-the-shelf engines come loaded with systems for features you may never use (multiplayer networking, lighting models you don't need), all consuming CPU cycles and memory. Even with Unity's project templates (2D, 3D, side-scroller), you still end up with unnecessary overhead.

Deep Source Code Familiarity

You wrote it, so you know it inside and out. When it comes time to optimize and debug late in development, this intimate knowledge is invaluable. You understand not just what the code does, but what your original intention was.

Targeted Optimization

If your game is heavily dependent on dynamic lighting, you can optimize specifically for that rather than working within a generic lighting system designed to handle every possible scenario. If you don't need multiplayer, you simply never write network code — it won't be sitting there consuming resources.

It's Fun

On a personal level, Tim finds building engines genuinely enjoyable. It lets you touch every part of the game — systems you'd normally never interact with when working within someone else's engine.

The Big Con of Custom Engines

The disadvantage is obvious: you need enormous amounts of time, money, and people. You're reinventing not just one wheel, but many wheels — and you probably won't do as good a job on each one as the specialists at engine companies.

Do you really know all the GPU pipelines, pixel shaders, network card interfaces, OS memory allocation, timer handling, and input systems? Do you know all of that for every version of every operating system and platform you're targeting? The engine companies have dedicated specialists for each of these areas.

Advantages of Off-the-Shelf Engines

Immediate Productivity

The engine works from day one. When Obsidian started Pillars of Eternity, they had something up and running almost immediately — no lengthy prototyping phase. With free artwork assets available, you can throw together a playable prototype in no time.

Hiring and Talent Pool

It's easy to find programmers who already know Unity or Unreal, and this gets easier every year as these engines dominate the market. Employees also benefit — their experience transfers to other companies, unlike expertise in a proprietary engine that "nobody uses and nobody knows how it works."

Support and Specialist Code

You get support from companies with large, specialized programming staffs. You can report bugs and they'll fix them. The engine contains specialist-written code (GPU optimization, networking, platform abstraction) that you might never have been able to build in-house, or would have required expensive specialist hires.

The Cons of Off-the-Shelf Engines

Support Isn't Guaranteed

Unless you're a big studio making a high-profile game with personal relationships at the engine company, you'll likely wait for point releases to see if your bug was fixed. With Unity, you don't have the source code to fix it yourself. With Unreal you can dive into the source, but you'll need to re-integrate your fixes with every new release.

Revenue Sharing

Most engines have shifted from upfront licensing to taking a percentage of your game's revenue. Smaller companies may get waivers or reduced rates, but for any sizable game, expect to pay Unity or Epic a cut. If you roll your own, that money stays with you.

Tim's Verdict

In a perfect world with no budget constraints, no schedule pressure, and unlimited resources, Tim would always prefer to make his own engine. But by defining that hypothetical, he's erased all the disadvantages — and we don't live in that world.

His practical advice: unless you plan to reuse an engine across decades of games, or you're in an incredibly rare circumstance that justifies custom development, you should use an existing engine. The decision has essentially been made for the industry:

• 2D or mobile games → Unity
• Larger games, especially open-world → Unreal
• Niche cases → Other engines may make more sense for specific projects

The era of every studio building its own engine is over. It's in every developer's best interest to evaluate existing engines before reinventing the wheel.

References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=Iw3bCdIvAj0