Think Twice Before Using Game Engines

The war between creating a game with or without an engine has been raging since engines existed. This reddit post isn't a perfect example of a reasonable counter-argument to always using an engine, but I found the overwhelming engine support a bit fanatical.

Let's be reasonable

I think that there is no cut-and-dry answer to whether any developer should use an engine or not. A wise developer will evaluate all of their options before deciding what technology they will rely on.

Skill level

Are you skilled enough to effectively use the option you are considering? If you have zero programming experience, you need to learn a whole lot before you will be ready to build a game from a collection of disparate libraries.

If you have no technical skill and no interest to learn, you really have no option but to use an engine (or convince someone to do the technical stuff for you; good luck with that!).

There is a middle ground between completely technologically unskilled and professional-level. It exists primarily in scripting-language land: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D, etc. all cater to those willing to gain some technical knowledge to quickly achieve results.

If you're a skilled/professional programmer who feels comfortable evaluating 3rd party software, you can use that skill to decide how minimal or maximal your approach will be (whether it be solely SDL, a minimal setup, versus Unreal, a everything-but-the-kitchen-sink setup).

Developmental Goals

What are your goals with the project? Your technology should facilitate your goals as best as possible:

Are you a hobbyist, wanting primarily to learn/grow as a developer? Maybe straying from Unity and Unreal into lower-level library-based game development is a good idea for you.
Are you running a business? It is much more complicated at this level. You need to evaluate your options based on multitudes of factors: can you hire people who will know about the technology? Do people want to use the technology? Does it match your timeline? Do you have the skills required to effectively use it? Are your artists/designers excited about the tech?

Interest

If you are working with (or plan to work with) more developers than just yourself, you need to gauge how interested other people are in the technology. If you're working in an old engine/framework that everyone hates, you're going to have a really hard time finding motivated developers to join your cause.

Also consider how artists and designers will interact with your technology. Are you willing to build tools for artists to catch up to Unreal, because they will absolutely look over the fence and compare. I have heard even AAA studios have a problem with artists demanding new Unreal features which the studio does not yet have in their Unreal fork.

If you are working alone, you need to keep your passion for your projects high. If you hate the technology you work with, you are more likely to quit. If you quit, all is for naught (besides the experience gained along the way, which is invaluable).

What is it really buying you?

Jonathan Blow has some great wisdom around what game engines actually buy you. They solve the "easy", cut-and-dry problems for you, then get in your way while you're trying to solve the hard problem, which is actually making a compelling game.

Sure, you get a great editor, professional-level tools, and an engine worked on by thousands of developers, but you pay for it in many ways:

Sometimes things are too generic: Maybe your game uses gravity in a novel way, but you must battle Unreal's hard-coded gravity setup. Maybe you're building something with an advanced network setup, which means you have to completely toss out Unreal's server infrastructure
Sometimes things are too specialized: If you've ever browsed Unreal Engine's internals, you'll find first-person shooter code all over the engine. If you're making that type of game, great. If not, it's just bloat that adds confusion
Sometimes there is just too much going on: This is both a mental burden and a performance burden. Running a full rigid-body physics simulation, 3D pipeline with skeletal animation, and three different UI frameworks all the time for a 2D game is complete overkill. Good luck figuring out how to turn those features off in Unreal though. I've found personally that Unreal's performance is disappointing even for lean test worlds

You should ask yourself, "What do I really need?" Cut down to the bone. Every unnecessary system is wasted performance and time.

What does your project demand?

Your project should drive the technology. If you are making a tech demo, this isn't the case. If you're making a game, you should only work on technology which impacts gameplay—must-haves for shipping your vision. If an engine provides you with the quickest possible path to shipping your game, it is a good option. This isn't always the case though!

There are some successful games which would be ill-served by any engines available:

Dreams wrote a completely custom renderer to facilitate intuitive 3D asset creation and fast delivery
No Man's Sky used extensive state-of-the-art procedural generation. Doing this type of thing in an engine will result in constantly fighting the engine
Minecraft would utilize few features of off-the-shelf engines

The Future of Your (and Our) Industry

When using any technology, you should be thinking about lock-in. Joel Spolsky has a series on software business strategy where he talks about software lock-in. The gist of it is that companies have an interest in keeping you using their product, because if you're not using their product, they're not making money. Apple, Microsoft, Adobe, and Autodesk are masters at making entire industries feel like they have no other option but their software.

Lock-in even will even affect hobbyist/solo developers. I have a friend who constantly fights Unity (updates breaking compatibility, the prototype system, navmesh, poor 2D support…). He wants to move away from Unity, but is heavily locked in due to how much his code (and data) relies on the Unity APIs.

What sells engines?

Unreal and Unity are driven by market demands. Their AAA customers are going to drive feature development with multi-million dollar contracts. If you are working on a game which isn't aligned with these AAA game goals, you aren't going to be served nearly as well. For example, 2D, procedural, data-heavy, experimental, or voxel games are almost always served better elsewhere.

The flashier the features, the more executive types (likely non-technical executives) will get excited about using the engines. Features like Unreal's Blueprints get artists and designers very excited, but cause programmers a lot of problems. (This comes with any scripting language; letting people who haven't studied how to program do programming is going to be messy, in a similar way to how programmer art looks terrible).

Are the new features actually making your game easier to finish? Are they really adding value to your end product?

Fight centralization

Each time a studio switches over to Unreal or Unity from an in-house engine, Epic and Unity as companies gain more power over the game industry as a whole. This centralization may seem beneficial at first (hey, they have 500 engineers working on this engine, great!), but comes to be a real problem in a couple decades. Google comes to mind as a company which has taken over huge parts of people's internet usage, costing people great loss of privacy.

Even at the hobbyist level, discouraging exploration of technology by recommending Unreal or Unity will harm the future generations of engines. This can even come around to hurting Unreal: If everyone just used Unreal, Unreal wouldn't be able to hire anyone to make the next generation, because no one would be familiar with writing game engines!

Open source could be the future

If we want to grow as an industry, making better and better products, we need to be sharing technology more, not less.

I think that the industry has been moving in the direction, albiet extremely slowly. AAA game studios especially still keep their custom engines confidential to give them a (imagined?) competitive edge.

Microsoft has been making huge steps in this direction. If they can change, I can believe any other company can
Unreal's license agreement includes a clause which allows for referencing their code even while working on your own (proprietary or not) engine. I think this is good progress
Godot is gathering a lot of hype for becoming a fully Open and Free game engine which will hopefully rival Unity (and eventually Unreal) given enough time and support
id Software (in the John Carmack days) released the complete source code from Doom through Doom 3. Carmack had many reasons for his decision to push for it. The most compelling reason to make to businesses is simply that it won't hurt sales. Doom's shareware model of giving away the engine then selling the data can still be an effective strategy today. If your business is worried about competitors "stealing" your technology, then you can only release your code after you've already 1-upped it with your latest game (which is what id did). Ever since Carmack left, id seems to have zero interest in releasing code.

Software quality

Jonathan Blow and Casey Muratori are outspoken critics of modern software practices. The gist of it is that we've been building on top of layers of abstraction for so long that we have immense, fragile layers of unnecessary cruft, and it's holding us back from making better products.

Their philosophies can stray away from pragmatism into idealism (which generally causes delays in shipping games), but if they resonate with you, you shouldn't ignore them.

Do you care about the performance, quality, and elegance of your technology? 'No' is a valid answer for many people, but some people do want to make things in a "cleaner" way.

What are the alternatives?

Rather than using an engine, you can just write the game.

Beginners often think they need to create an engine before making a game. They should most definitely discard this mindset. Beginners will waste their time implementing useless engine features instead of letting the game decide what is absolutely necessary. Only a game can drive what is needed for an engine (of course, Unity comes up as a counter example, an engine-first approach; Unreal Engine 4 had Paragon, Fortnite, and Unreal Tournament to inform its direction, not to mention decades of experience shipping numerous games on previous versions).

The library approach

Starting "from scratch" only makes sense if you have the skills and plan on innovating that component (or you have constraints). For everything else, there are plentiful libraries for integrating. This is especially good when you know, for example, that an off-the-shelf physics system will satisfy your project's needs (especially because implementing your own takes a large amount of domain-specific knowledge).

Here are some libraries which can bridge the gap between starting with absolutely nothing and starting with absolutely everything (an engine):

Graphics: SDL, SFML, Ogre
Physics: Bullet, PhysX (which just went open source; huge win!)
Sound: SDL, SFML

This is a very small subset of what's available.

The big appeal to taking a library-based approach is that it gives you the most flexibility of all the options. If you write all your code for a single engine, it is going to be a massive effort to port it if you need to do that. If you write your game as a collection of libraries, you have a lot of mobility to swap out whole subsystems. If a library isn't meeting your needs, you can try a different one, or even write your own replacement.

Additionally, both Unreal and Unity support importing dynamically linked libraries. This means that you can start out with a library-based approach, then move to Unreal without having to rewrite all of your core gameplay code, because you put it in a library. It takes some forethought to keep your code flexible to huge changes like this, but I think it's worth it for a medium- to long-term project.

In Conclusion

I have presented several different angles you should view the technology you are considering using. Spending a couple weeks of deep research up front can save months of porting work or years of discomfort.

At the end of the day, the goal should be finishing a project. You should figure out as best as you can what the shortest path to accomplishing that goal is. It might not be what you expect!