Epic Games acquired RAD Game Tools recently, which is another event in the worrying trend of an increasingly centralized game industry.

RAD Game Tools may be the most prolific game middleware company. Just watch for the "Bink" logo when starting up games and notice how widespread it is, to get an idea.

My goal with this article is to inspire some consideration as to where our industry is going, and what we should do as employees, business owners, and creators.

Note that I don't feel the need to present the argument for 3rd-party game engines, because I think it's already the default choice in most peoples' minds. The benefits do not need to be stated, because they are obvious. I also don't want to bash the big U engines' technology, which is no doubt good. However, even if it was perfect for every project (it isn't!), I think we should try our best to not sell our industry to a small number of companies.

Technology trends towards monopolization

Adobe and Autodesk are great examples for the software industry's natural tendency to become monopolized. Once one software product becomes successful enough, the owner gains the power to buy their competitors, as well as adjacent software.

While it may be convenient as a user to have access to a suite of creative tools, there's little stopping the company from changing their business model in a way you find unacceptable.

Epic Games is positioning themselves to be in a similar place as these companies. From a business perspective, it is an excellent strategy. However, I believe it harms our industry at large.

When you use a 3rd party tool, you are at mercy of their scheduling and priorities. While the source code is available, it may become unfeasible to modify later on, or they may close parts of the source to gain competitive advantage over other engines. If you own your own technology, you can make the appropriate decisions for your business. Using the major engines isn't without costs.

Collective technical knowledge is falling

When more people rely on an off-the-shelf tool to perform a task, there is less incentive to understand how that tool is created, and even how it functions.

Programmers who are intimately familiar with C and C++, and are used to managing their own memory, and having a good understanding of underlying processor architecture, are still very much in demand. The simple competitive edge that is had by having better performing games, that can render more, is enough to see that lower-level programming is still valuable.

I think it's safe to say that C++ will be the language of choice for AAA studios for at least the next decade. If you disagree, I doubt you are very familiar with the majority of AAA development. Even at studios which use Unreal, C++ is required to make new Blueprint nodes, or underlying changes to the engine. Unity is written largely in C++, and AAA studios pay extra for access to that code.

However, it is becoming increasingly difficult to find strong C/C++ programmers, for three major reasons:

• Schools are increasingly teaching higher-level languages like Python or Java instead of C
• Unity is taking over the hobbyist game development market, which essentially requires the use of C#
• Wide industry trends towards higher-level languages. This comes from a lot of different angles: people claim e.g. garbage-collected languages have no performance trade-off (they do, and that matters to games, a lot), most languages made today are higher level (Zig and Rust being notable exceptions), and there's a general discouragement of new programmers to learn C simply because they hear it's too hard

Even if companies are increasingly using higher-level dynamic languages, someone still has to implement the runtime of those languages, which are largely written in C or C++ as well.

Would you rather have an industry where skilled, expert programmers were available at every company, or one where a select few companies hold those valuable assets? I prefer working at a company where programmers are unafraid of making completely new systems tailor-made to serve the game and business needs, unencumbered by an ours-vs-underlying engine code perception that discourages modification.

Engines are not interchangeable

Building your own 2D paint program is not comparable to building your own game engine. With paint programs, you can create the same 2D image in more or less the same way, and have the result be identical across programs. Game engines do not function this way! The way you create games, and the way the game runs on end-user hardware are fundamentally different across different engines. Different performance, editors, APIs, feature-sets, etc.

This may be harder to recognize from an artist's perspective, where their main product, 2D/3D assets, are more or less plug-and-play across engines. (This is not actually true, because artists should be aware of their assets' impact on performance, which will widely vary with different engine technology).

What I am trying to say is that building your own paint program is probably unnecessary (though professional animation companies, for example, find customizing tools is necessary), whereas building your own game engine is often necessary.

Disjoint feature-sets

Detailed analyses will reveal great differences between different engines. In-house engines often sport bespoke systems for each product. These will be more tightly integrated than any 3rd party feature could be. Only the features that the game actually needs are present, which reduces bloat and some types of maintenance burden.

There are games that would be fighting the engine more than be helped by it. The following games are heavily reliant on custom engine technology:

This is not an exhaustive list, these are just some games I think are particularly good examples. See CUSTOM GAME ENGINES: A Small Study to get an idea how many studios opt to create custom engines.

Good engines tend to be built with a style of game in mind. Unreal Engine has a clear lean towards low-player-count single and multiplayer action and shooting games. Dig in to the Character and Controller source code and you'll find hard-coded fields that only make sense in these types of games.

This doesn't mean you can't make whatever you want in the engine, but it does mean that the engine is influencing what you make and how you make it. Our tools change what we make, and how we make it. For example, if No Man's Sky licensed out their engine, developers using it would be incentivized to make procedurally generated open-world games.

Call to Action

Major industry trends are often influenced by collective opinion. This means that your opinions and actions do have an impact, especially if you can prove to others that they are valuable.

Software engineers

Develop your lower-level skills as much as possible. Try to learn more about the machine instead of relying on increasing levels of abstraction. You may find it is rewarding to know as much as you can about these machines that have fundamentally changed how the world works. Low-level knowledge gives you much better ideas of the possibilities available.

Over time, you will gain a sense for how an overall technology stack "feels". For example, I think the Unreal Engine feels rigid and heavyweight. Pay attention to these feelings, and you'll find you have tastes for certain styles of tools and methodologies. Game engines can have great feature sets, but terrible development feel, and I believe that feel can change what you're willing to create with that tool.

Try not to support companies using the major 3rd-party engines with your expertise. This might not be an option when starting your career, but as you get a stronger resume you will have more options.

Building an engine

I've written before about the things you should consider when deciding what technology to use.

The internet has an especially negative view towards anyone who claims to be building a game engine. Ignore these people, for these reasons (at least):

• They do not know your situation, the problems you are trying to solve, what you are passionate about, etc.
• They likely have invested serious time into their decision (likely using a big-U engine), so they will partially be validating their own decision by putting down yours
• They likely are not experienced developers, simply because there are way fewer professional game developers than hobbyists commenting on internet posts. Everyone tries to sound like an authority online, while hiding their true credentials
• People and studios successfully build engines frequently!

If you're one of those people always discouraging engine-making, please try to imagine a world where one size doesn't fit all, because that's the one we are in.

The best thing for some hobbyists to do may be to write their own engine, if only for the huge amount of knowledge gained. For example, if you know how underlying skeletal animation works, you will likely not need any tutorial to figure out a 3rd party engine's animation suite, because the features all operate on those fundamental concepts. You may find you don't need all those features engines provide to make your project. A 2D game would vastly underutilize an engine like Unreal, which is designed for cutting-edge 3D games.

Even as an indie developer, developing a game without any existing "engine" is a viable strategy - see again how many hugely successful indie games use custom tech. If you write the game using only the lower-level libraries like OpenGL or SDL, your game will be easier to port (especially on long time scales; Unity projects from two years ago will already require you to make changes to run on the newest version), be less bloated, and may generally just make you happier to work on.

Designers, artists, etc.

Recognize the value of your existing proprietary engine, if you have one. For example, artists frequently request switching engines at my current company, without realizing the immense value of our MMO infrastructure, of which there are zero viable, proven off-the-shelf alternatives.

Encourage management and engineers at the company to develop features you want, but recognize the opportunity cost of the features. For example, your game may benefit from a fancier materials system, but it may be better for the engineers to spend time on overall performance or gameplay programming.

Development is rife with trade-offs, and don't think that going with a big-U engine won't also have trade-offs. While your department may benefit from fancy new Materials, or a Behavior Tree system, the engineering department is tasked with inheriting a multi-million line codebase with tons of unnecessary features.

In sum

As an industry, we should not be so keen to jump aboard a select few engines. There are serious trade-offs which must be considered. We should do our best to foster a technologically diversified industry that values independence, innovation, and knowledge. We should try to do what's right for our project and our industry.

While there may be nits you can pick with my arguments, I hope we can agree on the overall sentiment: our industry's technology should not become owned by only a few companies. We have a really good thing going right now, and we should hold on to it.