I work on games and I would not say, “this is how all major game-dev companies operate”. However, I have worked at companies that make their own engine and it’s easier than people think if you have the correct scope. Your first bullet is the most important one. I feel like the issue most companies have is that they get into engine building mode and get caught up in the fun of building the engine rather than delivering value to the player and shipping a game.

Step 6. Engine dev leaves, game devs hate this undocumented internal tool, and the labor market wants to use publicly available things they have trained on.

terrible idea.

> This is how all major game-dev companies operate.

Patentedly untrue. MANY major game companies use existing engines. For example, the pokemon gen 4 remakes are on it.

> the pokemon gen 4 remakes are on it.

Yep, and it kinda shows the difference between using an established engine vs making your own. The gen 4 remakes (Using Unity) run smoothly and look great as well. Freedom for artists, and they can easily hire new people as well since Unity is an industry standard.

Meanwhile, the recent mainline Pokémon games roll on their own engine. And guess what? Those games look and perform like shit. It's as if someone screwed up something while making the renderer and since they had no way to profile what's wrong, they'd end up making some crappy optimizations to compensate for it. Popping objects everywhere, low quality textures/shadows/LODs, low framerate on non-so-distant animations, etc. Chances are they use the same 10 shaders at best, since they can't easily make their own (No shadergraph for artists, and probably hard to justify new shaders since they must be native and they would decrease performance since for a high amount of shaders you'd have to code a strong shader warmup/compilation system first)

And no, this isn't because it's an open world game. All problems seems to be due to the engine. And somehow all of this usually happens on modern AAA console games as well, when they have to make a PC port.

Indeed. Hearthstone is Unity-based, for example.

Why would an indie dev want to spend years making a game engine instead of building an actual game? Especially for small teams or solo projects?

Many people do work on their own engines, and do not have a game to show for it - which isn't to say they aren't cool projects, but it does involve reinventing many things people have already done, and also takes away time that could be spent prototyping

Extremely valid question. Most devs should not attempt making their own engine. But 2 caveats:

- learning is also fun

- Most engines (by force or by available tutorials and docs) railroad the end user into some specific genres (in my experience: side scroller, FPS). If you wander too far away and understand the risk/complexity, it might be worth considering.

What most seem to do is to use an application like Godot or Unity to build the engine in step 2. You do not have to start from scratch you know. Those things are more or less toolkits for building your actual game's engine. Not like the more specific game engines that you might think of if you are older and remember game engines last century.

Depending on what game it is I can see someone using something like Raylib to build their engine instead. The abstraction level there is about the same as Godot. You get high-level API:s for a large number of things and support for many platforms (far more than what Godot or Unity supports). What you do not get is a GUI for building scenes or editing scripts.

Starting from a lower level with something like SDL sounds like something more suitable for hobby projects, like coding a game in TIC-80 or writing a 16-bit DOS game in FreePascal or other hobby-activities (things that I enjoy). Fun, but probably almost never a good idea for a business.