Sure there's a place for these engines. They abstract away graphics layers and bring convenience. But if you are a (semi-?) professional game dev, that's not a major hurdle.
I have a toy game in play around in my free time and started with SDL like so many. You can create windows and draw bitmaps really easily. But sooner rather than later you discover limits (bugs, performance limitations, less than ideal APIs) and see that just writing OpenGL code yourself is actually easier and more flexible. Many people go down that road.
edit: Concerning your edit about "more than a renderer": Yeah that other stuff is annoying and many still use SDL, SFML or whatever for that. See Factorio and many many others who do the rendering themselves and offload the other crap. I do that myself too.
> And bring physics, input, asset loading, networking, systems, scripting, etc.
Along with their own idiosyncrasies and assumptions. Which is something you may decide you do not want to deal with. E.g. hand-coding the little physics you need may be easier than learning the physics engine's API and adjusting your own architecture to mesh with it.
Yes. That's a very fair point. Most engines I've seen try to implement a general physics model that can handle every genre of games, and there's a lot to be gained by not using that and building something more focused on what you actually need.
Further to that very few engines are developing their own general purpose physics solver and are using middleware. Bullet, PhysX and Box2D are the most popular.
Roblox is the only really big engine company I can think of that actually develops their own physics tech (because they started off doing it).
NVIDIA completely bungled PhysX because they chased accuracy for ML/robotics reasons in the newer releases, and the latest PhysX is slower and deprecated useful games tech like cloth.
So both Unreal and Unity now have their own physics tech.
A lot of engines are still using PhysX (albeit stuck on version 3.x). Upgrading a physics engine is often a pain point, either because it is so tightly integrated in the code base or because game assets have been tuned for the current physics implementation and even a small accuracy or behavior change will require assets to be re-tuned.
What do you mean by slower? Is it the new TGS solver you’re talking about (which is optional and really doesn’t need to be on for games)?
You’re right that it seems like Unreal and Unity are ditching PhysX for something else (Unreal for the new Chaos engine, Unity for their new DOTS engine in collaboration with Havok). I’m just surprised that PhysX‘s performance problems had something to do with the move.
Unity started their physics engine as a test of the job system. When they got the latest PhysX drop, and it was slower, they made it into a full team. Unreal had been annoyed with PhysX for a while, and entertained the idea of writing their own, but never actually did it. When Unity engineers told them about the latest PhysX updates, they launched the Chaos project.
NVIDIA's incompetence is what kicked both of them off, basically. Both engines will continue to support PhysX 3.6 for existing customers.
That depends on the engine. The big guys do. But the pure 2D engines do not.
And again the point I was trying to make was about graphics. Most if not all do not roll out their own code for input management, window creation, Networking and so on. But 2D graphics is relatively easy to DIY.
Those libraries don’t provide any game structure though (well, SDL and glfw at least, I think the other two do give you a small amount of structure), they only provide functions to get input style, open a window and basic rendering primitives. You can build an engine out of them, but I wouldn’t call them engines by themselves any more than you would call DirectX it the windows API a game engine.
You can make simple games out if just hose libraries, but anything complex will tend to require a ton of support code (characters, animation, maps/levels, camera control, collision detection, event triggers and such for example) and other libraries, at which point you’re basically writing a small custom engine on top of those libraries.
Yes! That was more or less my point. But since we're all confused anyways: Do you have an example for a real 2D game engine? with "game structure" as you call it.
Godot has a 2D renderer and physics option, Defold is 2D by default, Game Maker Studio, Cocos2d, Corona, Construct, Phaser.io, Buildbox, Gamesalad, Stencyl, Clickteam Fusion
Unity is very capable of 2d games too and provides a lot of game structure and so do many other engines (I want to mention Heaps.io because it’s awesome).
Commenting because noone else has mentioned it; I've been enjoying love2d[1] because it paves over all the annoying technical issues I might run into, and exposes it all in a nice lua api[2].
Most of those are libraries/frameworks rather than engines though. A fuzzy distinction I know but most of these are something you might build an engine of top of to avoid some of the cross-platform drudge.
GLFW, SFML, and SDL absolutely aren't game engines, I don't think it's fuzzy at all. They're libraries for graphics, audio, and other useful APIs. Monogame I'm not familiar with, but since I can't tell by skimming the wikipedia article, I'd call it fuzzy.
MonoGame as remake from XNA is much more higher level, as Microsoft made it for Indie games on the original XBox and WP7, and with some lessons taken from the earlier Managed Direct X attempt.
So while not at engine level, it already provides higher abstractions than those libraries, and a content pipeline.
You are still severely underestimating what a modern game engine does. The technical side is only one part of it. Integrated content creation and editing is a huge part of it.
That is the point: the "drawing code" is perhaps 20% of a game engine.
You are missing asset management (loading, streaming, caching...), audio (big enough to split into libraries and actual audio engines), input (of different kinds), networking (big enough to split too), AI, scripting, physics...
The one who misunderstood is you. When people talk about a "game engine" in 2020, they are not talking about drawing code. They are talking about something much, much bigger.
"Drawing bitmaps" with SDL or OpenGL is a trivial part of developing a 2D engine.
Calling SDL/SFML for "other stuff" is, again, a tiny part and it is in no way offloading "the other crap" (as you call it).
I assume you are biased because you have only coded toy examples. When you start anything remotely complex, you have to do way more things than just "drawing bitmaps".
As for Factorio, it is actually a very complex and fast simulation. Downplaying engine devs as "rendering and other crap" is derogatory to say the least.
I'm so confused about the heat. The idea that 2D engines are orders of magnitude less complex than 3D engines is ubiquitous and frequently stated by many reputable game devs. Complex game engines will obviously have more complex code. Factorio in particular is certainly pushing the envelope there - with or without a 3rd party rendering engine. A better example would be 2D RPGs.
The distinction is in quantity and types of assets. In 2D you usually have some bitmap and vector assets, collision data, animations, and scene structures to tie it all together. In 3D you have all of those things plus the texture/model/material distinctions, lights, skybox, and all the other details that come in as you add more rendering capabilities.
However, you can absolutely make 2D games that need lots of kinds of assets. RPGs happen to be one of them, in fact: The incidental details of adding inventory, NPCs, abilities, dialogue, etc. does add up. Every little message and description, every item's properties. You can ship a game by hardcoding much of it, but that's not going to scale with any substantial team. You need real data management, build processes, etc. Where assets interact with each other you get incidental complexity of the Dwarf Fortress bug kind, so where you can, you add static checks. The engine is built in tandem with the asset pipeline, in effect.
So - whether it's 2D or 3D, what actually matters is the assets. That's why even in the early 80's you had vector games with 3D effects in them; they just took approaches that simplified the assets and the resulting scenes.
Because that's not what you were saying: You literally said a 2D engine barely deserved the name, and that it was usually not worth the hassle to use one rather than writing your own.
I have a toy game in play around in my free time and started with SDL like so many. You can create windows and draw bitmaps really easily. But sooner rather than later you discover limits (bugs, performance limitations, less than ideal APIs) and see that just writing OpenGL code yourself is actually easier and more flexible. Many people go down that road.
edit: Concerning your edit about "more than a renderer": Yeah that other stuff is annoying and many still use SDL, SFML or whatever for that. See Factorio and many many others who do the rendering themselves and offload the other crap. I do that myself too.