“Make a game, not an engine” is good advice for a reason. It is possible to spend two years polishing a renderer, asset pipeline and level editor without ever making the game that was supposed to justify them.
Elias Farhan is nevertheless moving Soup Raiders in the opposite direction. He is porting the game to custom technology. His argument is not that one developer should build a better Unity. He explicitly describes the goal as building an engine specifically for this game.1
That distinction changes nearly everything.
A custom engine can be much less than Unreal
Farhan uses a practical definition. An engine runs the game loop, polls system events, invokes gameplay, handles rendering and manages assets.1 Custom does not necessarily mean writing every layer from scratch. Combining SDL3 with rendering or asset libraries can already form a custom engine when the team owns the layer connecting the game to the operating system.1
Conversely, extending Unity with internal tooling does not suddenly make Unity a custom engine. The useful boundary is less about how many lines you wrote and more about who owns the important abstractions.
That avoids a false competition. A general engine has to serve thousands of very different games. A specific engine can reject capabilities its game does not need. For Soup Raiders, Farhan can make rendering choices around this art direction and this camera instead of supporting every possible scene structure.1
The real purchase is control, not necessarily time
The article emphasizes learning. Building the engine forces developers to understand choices Unity, Unreal or Godot normally make on their behalf: asset organization, compilation, rendering, memory, game loops and ports.1 Samuel von Stachelski describes a similar motivation in his own account of building an engine: fewer imposed layers and a more direct understanding of what the program is doing.2
That control is not free. Farhan collects several warnings: the tool takes time to build, bad architecture remains your bad architecture, and the pool of people who have already solved your exact custom problem will be smaller.1
Portability makes the trade-off obvious. Established engines can make additional platforms feel almost magical. With custom technology, every new console or operating system creates work nobody else will quietly absorb for you.1
Technical independence therefore also means technical responsibility.
The engine matters when it fits a real constraint
Farhan ends on a rule more useful than “custom engines good/bad”: custom technology should be specialized for the game, its art direction or the technical constraints of its target platform.1
That makes an engine closer to a workshop tool. Building your own screwdriver is ridiculous when every existing screwdriver fits. It becomes less ridiculous when the screw is otherwise unreachable and the same awkward operation keeps returning.
The rest of Farhan’s series is meant to document the native Soup Raiders port and its performance targets on Nintendo Switch.1 Those are development targets, not published proof that the finished port already reaches them.
That is exactly why the project is worth following. The engine is not presented as a standalone technical monument. It has to do something less glamorous: run a real game with real visual choices and real constraints, without becoming the project that consumes the game itself.