> Could you elaborate on that?

I can try, but I may not do the idea justice.

When I was working on the game, the only thing that mattered was the _game_. Was it fun? Intriguing (we are a story based walking simulator)? Original? In line with our story structure (we wrote the story side by side of making the game because sometimes the best words on paper just couldn't be translated by us to a player experience)?

You make changes non-stop to iterate and tweak and perfect. You learn quickly that someone's gut feeling can kill an entire chapter of the game, or change the ending completely.

At some point, my code was just a tool in making the game. I didn't see myself carrying this codebase further to other projects (we built the game on Unity so already writing an engine was "solved"), so it just turned into working prototype after working prototype.

Your code doesn't have to solve for all the corner cases you may miss in QA, because in our game the state was almost guaranteed at different parts of the play through. You need to remain extremely flexible with your design and code because its possible the game shifts drastically under your hands, more so than I've ever experienced at an already-chaotic "big" company.

So it just stops mattering that much. At least for us. We didn't have a team for code (just me), or a separate art team, or a separate story team, or even a single game designer throughout the project. Everyone wore almost every hat, and you lose the grace of planning and process.

It's more a feeling than something I could quantify exactly. An interesting reflection is that I became more rigorous and detail oriented at the day job after the wild west of my game code.

On top of what the others said, you basically answered it with "However, on the other hand, the engine is only a part of game development". Game dev is one of the most technically complex subfields of software dev, but it still pales in comparison to the total package of disciplines (and skill levels in those disciplines) to make a game.

Compare a basic CRUD webapp to a game. Most webapps won't need stellar art, it just needs to look okay and have some logos or default assets. Games often need to run their own assets for uniqueness, have way more freeform art, you name it. That includes pixel art, the often lowest barrier to entry. Animation? Webapps generally don't need animation beyond some default practice tweening, most games require animation to make things feel smooth and actually give the feeling things are happening, on a vastly higher level than simple tweening of color and position of some flat objects. Audio? Where the average person hates the embedded autoplay video/audio, games generally require at least sound effects, preferably a sound track too. Storytelling? Unless you count the average buzzword-filled marketing video as storytelling, webapps don't need that. Marketing, collaboration, etc. are all factors that come to play as well depending on corporate size, so depending on your goals, you will run against those too.

There is much more too. Psychology can play a huge part if you don't just blatantly copy existing things, and it is far more difficult to map a vague "I like this / I don't like that" than a business requirement. If you don't require animation, in all likelihood you're either creating a game in a genre where other demands are higher (visual novels with higher storytelling and individual art asset demands), or you'll be outcompeted if you don't have something to stand out, in which case one could argue the load is shifted to other disciplines anyway.

Maybe most of all, you generally don't need to develop content in most webapps: you are enabling users to create content themselves, whereas in gamedev, you are more often providing them with content. Of course this comes with exceptions (What about Sims? What about Rollercoaster Tycoon? What about mods?), but most games deliver at least some content developed by the makers of the game themselves. Or you spend days agonizing over algorithms to generate content in a way that makes it fun, making tons of art assets players can fiddle with, etc.

> Could you elaborate on that? I find this perspective very interesting.

In addition to what others have said, game development places a massive priority on optimization and performance.

You have to write code that updates game state and renders a scene in under 16 ms. CONSISTENTLY under 16 ms. Otherwise, you get stutters and choppiness as it fails to maintain 60 fps. If you want to please your top-end PC gamers with their 144 hz monitors, you need to render each frame in under 6.9 ms.

With a web app, you can make up for underperforming code by scaling horizontally. That's simply not an option for game development.

Normal software engineering is 95% glueing libraries together.

Gamedev is mostly about iteratively changing some equations to make the thing behave like you want it to behave.

Disclaimer: I never worked commercially in gamedev, but I wrote a lot of games as a hobby. Most of them unfinished of course.