> I think a lot of programmers get stuck in this trap of thinking that making a game is an engineering task. It isn’t.

Here are a few (non-engineering?) tasks unity does not ship with (last I checked):

* AI Steering behavior

* 2D Pathfinding

* Localization (pre-2018 unity)

* A quality terrain editor

* A quality UI layout mechanism (like why is the UI 100x bigger than the game scene?)

* Any sort of complex multiplayer (pre unity 2020 at least)

And more depending on what specific game your working on. Skill trees? Gotta roll your own. Building a 2D game with tile maps? Good luck using their builtin tile map editor. Complex procedural worlds? Have fun rolling your own. Maybe use some prefabs to speed some of that up.

In addition to that, most of what we call "engineering" today is "how do I organize my CRUD app with a bajillion over-engineered design patterns to make my code cleen and Xtendable". You can do that in a game if you want.

> The level to which modern game engines have reached means its really just about your game design, artwork, music, etc.

Ah yes, all that's left is the easy stuff. After all, designing a custom app workflow, with it's own UI/UX, etc isn't engineering or difficult... Oh wait, doesn't 99% of modern software engineering consist of, "let's make a react app with some custom UI/UX and it's own data models and microservice architecture and blah blah blah". But web dev is definitely "real" engineering unlike these game dev folks.

> Toy engines like this don’t really have much value, and your time is better spent learning how real engines work.

I'm confused by this? So you should invest in learning how engines work? Or you should learn how to use unreal or unity? That's like saying, "Small web frameworks don't really have much value, and your time is better spent learning how real frameworks work". That's just blatantly false. Rolling your own framework has value in the fact that: you learn a lot from it, you learn why certain design decisions are made, and you can more efficiently use big web frameworks since you know the foundations.

Finally, why is it a new fad to say game devs are dumb for wanting to code custom game mechanics? Game engines can only handle the most common use cases. Sometimes you want to try creative things that are simply not possible unless you code a custom engine around it (cough, Minecraft).

Other times you want to make your game stand out by having various custom effects, like embedding velocities in a texture and then using that texture to create dynamic intractable objects like this video[0]. This sure doesn't ship with unity, and all the concepts necessary to make it (physics algorithms, shaders, dynamic textures via framebuffers) are usually encountered when coding your own game engine.

So what does it benefit you to code your own engine? You learn, a lot. All of these concepts give you better tools, tips and tricks you can use in other scenarios. If you can only think about a problem one way, it's likely you'll never innovate much. If you know how to think about game dev from low level graphics to high level game design, you have a lot more ideas and problem solving techniques at your disposal.

Edit: I would also like to add that using lower level frameworks like this helps gain intuition about a lot of concepts that are useful for many things. When I talk about coding your own engine, I don't mean you have to go as low level as bare metal graphics APIs like Vulkan, even using something like Monogame (used to make stardew valley)[1] is beneficial in a lot of ways.

[0]: https://youtu.be/BhtNgHg8gqk

[1]: https://mobile.twitter.com/ConcernedApe/status/1091418705605...