Conventional wisdom dictates; make a game or make an engine. If you're making a serious effort at actually delivering a game, then you may want to use an existing engine. However it's also a nice challenge to write an engine of your own. And perhaps some true legends can actually do both - just look at Animal Well.
The author made this game for his son. I think this qualifies more as a hobby/side project than a serious effort at delivering a marketable game. In the hobby case I think the conventional wisdom no longer applies. That puts this sort of project in line with folks building hot rods or restoring classic cars right down to the last bolt. Rebuilding a car's engine is a similar exercise which rarely makes commercial sense but can be an absolute joy for the hobbyist mechanic!
It's always worth remembering that when people suggest not writing an engine the sentiment is usually "Don't try to write a Unity/Unreal/Godot equivalent".
This is very reasonable advice. Those tools are software behemoths, by design, because they have to account for all possible use cases and give people a way of opting in to any possible combination of provided features, along with providing various abstractions (scene hierarchy, gameplay scripting, graphics API abstraction, materials, VFX, animation state trees, etc., the list is seemingly endless) as they need to support making essentially any kind of game.
And not only are they software behemoths, they also represent a huge amount of mindshare in the form of documentation, support, community, customer-provided content, (marketplace assets) and so on.
If you're making a game and you know what your requirements are up front, it's possible you just don't need most of what the engine provides.
If you don't need to support multiple graphics APIs, you can get away with just using the specific API yourself (and then you don't need a different shading language). If you don't need complex VFX you might not need a VFX graph. If your rendering code is closer to your gameplay code you don't need a separate gameplay scripting system, you could actually write your gameplay code in the same language and build them together. Don't need rigid body simulation? Great! Throw that away. Don't need RVTs? Goodbye. And so on.
That doesn't mean throwing away some engine-like structure, you'll almost certainly still end up with some representation of a scene, but if your requirements are minimal you can get away without most of what's in the above tools.
And there's always the middle ground (that seems to get forgotten). Open source rendering libraries such as Ogre integrated into your own program, such that your game stops being a completely isolated component that sits on top of the engine and is regular code integrated with rendering (and so on), while being a more cohesive whole.
Of course, if you need the features in Unity or Unreal and you don't have five years to burn then maybe you should just use them after all.
Here is what I dictate: this is fucking stupid and I'm tired of seeing this nonsense parroted.
Working on your own engine gives you a level of understanding that cannot otherwise be obtained. It's like writing your own OS. This is very much a worthwhile endeavour. People should be encouraged to write their own crap, even if they don't end up using it on the job or whatever (whoever the fuck said this was the only metric for deciding what to work on?) because of the level of insight it provides.
Generic engines like UE5 and Unity break down both in terms of functionality and performance the moment you do something they are not intended to do. They are also an overkill for a project of the scale shared here. From an engineering perspective, it's absolutely ridiculous to use an engine for this project.
So please stop parroting this nonsense. Use your goddamn brain to form opinions. There isn't an off-the-shelf engine for that.
