Nice article, engines are bloated and introduce so many overheads. If you don't intend to ship any AAA games, consider investing your times to learn code-first game frameworks like libGDX, MonoGame, love2d,... or even lower level stuffs like SDL, bgfx, opengl which are good enough for almost any cases. A bit higher learning curve is expected but it won't hide anything from you, or bury you under tons of bloated abstractions.

▲

simooooo 12 hours ago | parent | next [-]

Nobody seems to consider that doing it yourself, requires you implement it at least as efficiently as the commercial engine did, otherwise you're just creating a worse-performing implementation that seems to behave just like a bloated engine does.

▲

flohofwoe 12 hours ago | parent | next [-]

The big difference is that the big game engines have to cover all sorts of genres and scenarios, which often results in bloated "jack of all trades master of none" code compared to engine-layer code that's highly specialized for exactly one, or few very similar games.

▲

Joel_Mckay 10 hours ago | parent [-]

If building a custom commercial game engine these days... A team is 100% focused on the wrong problem, as the game-play content is what sells. Customers only care about game-engines when broken or cheating.

Godot, Unreal, CryEngine, and even Unity... all solve edge-cases most don't even know they will encounter. Trying something custom usually means teams simply run out of resources before a game ships, and is unlikely stable on most platforms/ports. =3

▲

flohofwoe 9 hours ago | parent | next [-]

Many of those "edge cases" lurk in the platform abstraction layer (driver or OS bugs which needs to be worked around), and many of those problems are also taken care of in cross-platform wrappers like SDL (and for 2D games this is completely sufficient, you don't need UE5, Unity or Godot to render a couple thousand sprites and play music and audio effects).

But even more complex custom/inhouse engines are usually not written from scratch, those are often mostly glued together from specialized middleware libraries which solve the tricky problems (e.g. physics engines like Jolt, vegetation rendering like SpeedTree, audio engines and authoring tools like FMOD or WWise, LOD solutions like Simplygon, etc etc...)

▲

zetanor 7 hours ago | parent | prev [-]

>Customers only care about game-engines when broken or cheating

Most game engines are broken by default. Modern customers just aren't very discerning ("It's for the pigs. Pigs eat slop."). You can feel holes and rough edges in the vast majority of new releases, including AAA titles.

Unreal is the worst for this and Unreal-based games almost always have two things in common: a very particular, soft, sticky and unresponsive look & feel (often alleviated but never fully corrected by turning off some combination of motion blur, AA and VSync), as well as a UI that mishandles mouse pointers.

Unity devs seem to rely on a (more diverse but still quite) small pool of subsystems and renderers; possibly some mix of baseline and Asset Store components. This gives each Unity game a specific subset of flaws from a wider common pool. That is, you can tell that game A uses the same movement subsystem as games B and C (but not D), that game B uses the same UI subsystem as games C and D (but not A), and that game D uses the same rendering subsystem as games A and B (but not C).

	▲	Joel_Mckay 7 hours ago \| parent [-]
		In my humble opinion, the difference between good and great was often whether the Shaders and pre-Baked work was done well enough to go unnoticed. Forcing devs to use a mid-grade GPU also tends to reduce chasing performance issues later. For example, high frame-generation artifacts users often perceive as "floats" or "wobbly". =3

▲

Levitating 8 hours ago | parent | prev [-]

That's not necessarily true, engines also create overhead. If you create your own engine, you can tailor it exactly to your use case.

Besides not all games need performance, I have been working on a clone of the original elite game using SDL. It gets 6000 fps easily.

▲

Cthulhu_ 12 hours ago | parent | prev | next [-]

SDL is used in Factorio, which IMO is the best showcase of what is possible if you go all-in on e.g. C++ when it comes to performance, both in terms of what is rendered on screen and the mind-blowing numbers of what your factories are doing.

	▲	rahkiin 6 hours ago \| parent [-]
		And most gameplay is written in Lua

▲

rimmontrieu 11 hours ago | parent | prev | next [-]

For more context, I've developed over 200 games[0] using libGDX and threejs. I've learnt so much from working with code-oriented frameworks that are closer to the system APIs. I can never imagine if I could do all that in today full-blown game engines in term of effectiveness and development speed.

[0]: https://ookigame.com

▲

racefan76 2 hours ago | parent | prev | next [-]

How does one pick a tool/framework from these options when starting out with game development? I've seen the sentiment of "just pick anything" but the amount of choices is giving me some analysis paralysis.

▲

JoeyJoJoJr 14 hours ago | parent | prev | next [-]

I’d highly recommend going with SDL if it’s 2D. IMO libraries like MonoGame, Love2D, LibGDX only offer small conveniences over SDL with big negative tradeoffs, sacrificing portability, quality of libraries, and conventions. The downsides of using C++ are now heavily mitigated with the use AI tools.

I could never jell with C++ until I had Cursor hold my hand (especially around the build system), and now I feel like I am developing games with a razor sharp knife that I could never before access. The patterns associated working directly with memory suddenly clicked and now it’s the only I want to build games.

	▲	tripledry 13 hours ago \| parent \| next [-]
		Similar, I also went back to mainly C++ and Raylib now that I can delegate the "boring" stuff to AI, never had any issues with programming in C++ it was mainly adding dependencies and builds I hated (configuration). I still don't use it (AI) for the game programming as it sucks the joy out of it for me. Especially when AI usage is currently being pushed hard at work.
	▲	raincole 12 hours ago \| parent \| prev [-]
		I'm actually building my own mini-engine with SDL_GPU. It works ok so far. I'm quite confident that it's capable enough to replicate most of Unity's URP features (except the shader graph as I don't plan to expose such an interface for artists). But I haven't reached to the more tedious parts, like doing skeleton animation on GPU and testing cross platform (SDL should be naturally cross platform, but I never tested it...), etc. The most tedious part, imo, is to build your own 3D scene editor. At very least I can say SDL has reached a passable state for 3D. It doesn't support some modern features like bindless though. And one doesn't need to stich with C++ if they don't want to. SDL is pure C and if your favorite language can call foreign function it's not that hard to make it work with SDL.

▲

Froztnova 8 hours ago | parent | prev [-]

I've been building some stuff with love2D for a while now, more a hobby than anything else, and I've really enjoyed the process. Nothing really crazy, just a 2D platformer.

I think that if I were making something in 3D or I were more serious I'd use an engine, but I've found that I get more satisfaction from building tools than from learning how to use tools that other people have built.