Read on Twitter
My favourite subject of game engines is being discussed again, so here's some cases where I think custom game engines are actually a Good Idea:
(Note that these will mostly be code reasons. On teams where code is not a large aspect of the project, these are less relevant.)
(Note that these will mostly be code reasons. On teams where code is not a large aspect of the project, these are less relevant.)
Architecture: the way an engine is architected has severe implications on what your code will look like. One of my driving factors for developing Halley was my displeasure with how Unity and Unreal games are ultimately architected, leading to lower overall game code quality.
Interfacing with new technology: Large, generic engines will typically take a while before they're fully stable and performant on new consoles (see: Unity on the Switch at launch), and you can beat them if you only have one game to optimize and early access to SDKs.
Choose the correct compromises: Every game engine has to choose compromises. The more general you are, the more efficiency and stability you lose in order to support more and more abstract use cases. Often, you have to choose where to compromise. Custom lets you make those calls.
Language: Some people will claim that the language a game is written in doesn't matter, which sounds WILD to me. It's reasonable to write a custom engine because you want to use a specific language. I see a lot of people doing this with Rust, and I do it for C++17.
Custom tooling: A double-edged knife for sure, but depending on the needs of your project you can easily do better than an engine that needs to support a GENERIC kind of game - but tooling requires a lot of time investment so YMMV.
How small things work: I've seen this happen a lot with Unity, where a team needs to replace Input, Rendering, Network, Physics, etc. One by one they need to be changed since the engine doesn't fit your exact requirements. This greatly reduces the benefits of off-the-shelf.
Ownership of whole stack: I have seen at least two mid-sized projects suffer enormously from not owning the engine layer. Having access to the whole stack makes issues easier to debug and allows you to make better optimizations. [1/2]
Sure it's an OPTION to get the engine source and modify it, but then you're on a fork and it's a nightmare if you need to update to latest (which you often have to do). IMO if your project and engine don't compile together in the same codebase you're in some trouble. [2/2]
Misc technical constraints: Maybe you want to do one of the following examples:
- Run multiple isolated game worlds in the same process at the same time
- Hot-reload assets on a console
- Hot-reload native code
- Spread gameplay code amongst multiple real threads
[1/2]
- Run multiple isolated game worlds in the same process at the same time
- Hot-reload assets on a console
- Hot-reload native code
- Spread gameplay code amongst multiple real threads
[1/2]
Last I've checked, none of those things (other than hot-reloading C# code with variable success) were possible in Unity (please do correct me if it's since changed!), but they're all possible if you need them, in a custom engine (Halley supports most of those). [2/2]
Build pipeline: Building a project efficiently and correctly is very important. In my experience, there are always small compromises that you have to accept with any engine, and again being able to make decisions on those compromises is quite valuable.
The "feel of an engine": This is more subjective, but you know how different (natural) languages influence literature and culture? IMO the choices made by an engine will always subtly influence projects. Controversially, I think that a lot of gamers can actually tell, too.
2D Games: Yeah you CAN make 2D games in Unity, and a lot of good 2D games are made in Unity, and to their credit they've slowly improved things on that front... but it still doesn't change the fact that the architecture wasn't designed for it, and a lot of things are awkward.
Performance: This can go either way. If you're looking for 3D rendering perf, it'll be VERY HARD to beat something like Unreal. But if you're looking at running your TBS Pixel Art game on the Switch with low battery usage, you can surely do better than e.g. Unity.
Break new grounds: There are some kinds of games that are just not suitable for an existing engine.
IMO you couldn't make Flight Simulator on Unity/UE4. I'm not sure if you could have made No Man's Sky, Dreams or Elite: Dangerous on those (cue people telling me wrong here!).
IMO you couldn't make Flight Simulator on Unity/UE4. I'm not sure if you could have made No Man's Sky, Dreams or Elite: Dangerous on those (cue people telling me wrong here!).
With all of this said, there are many games for which those reasons don't matter too much, and the cost of developing a custom engine is usually too high for most teams. But ultimately IMO there are CAN be MANY benefits for going with custom, for the right project/team.
Do I RECOMMEND people to use a custom engine?
For most teams, no, I do not.
Ultimately, a custom engine is a very large investment - you'll potentially be able to achieve something better, but it won't be easy, quick, or cheap!
But IMO there are definitely cases for it!
For most teams, no, I do not.
Ultimately, a custom engine is a very large investment - you'll potentially be able to achieve something better, but it won't be easy, quick, or cheap!
But IMO there are definitely cases for it!
