I tried to learn it a little but I did not manage to understand how it works, I don't really like the whole WYSIWYG thing, it forces the developer to surrender control, and you waste a big amount of time teaching yourself how it works internally, time that could be spent being productive with a simple renderer.
It also seems to support c++ as "gdnative", although it requires another compiler to link against godot's binaries. It seems awkward because you still need to use the godot editor, and there is still a lot of interfacing to write.
It seems like a good alternative to unity, but in the end, all I want is an engine, not a "framework" or some awkward scene editor with some kind of Node hierarchy/interface.
I could say the same thing about UE4. I hear everywhere that's it's the place to go, that "everybody uses it and it's the norm in the industry if you want to make a game from scratch", but the reality is that those frameworks are too big and too feature rich. It sounds like they want to attract young developers to lock them into those awkward frameworks, because they advertise it as being full-featured engines, but small developers might not really need to focus on bleeding edge rendering, so it doesn't make sense.
I know there are engines like Ogre3D, but I would rather spend time learning an actual universal graphics API that works on all hardware, which has more value on a resume, and I can just use what I need. All other things like audio, animation, inputs, physics, etc are available as C++ libraries.
Those frameworks are saying "see? you can make your own game with those tools!", but when you actually learn how a computer works, and know how to write code, you realize you want to avoid those frameworks because they conceal too much from the programmer, and usually you don't want a developer to not understand what the framework is doing. I guess this is why people have a problem with certain object-oriented practices and abstraction.
I, like many hobbyist gamedevs, have: 1) built fully bespoke games, 2) built my own game engine, 3) built games using low-ish level libraries (like phaser.js), 4) used game engines. I offer this history to show that I too enjoy writing my own code.
But I love Godot. I struggled with it too, at first, but probably around hour 6 of messing around, it all just clicked: Godot is actually a visual abstraction of object oriented programming. You get to write and extend visual classes, then instantiate them in scenes.
Once it clicked, I realized this is exactly what I wanted. An engine that knows how to do physics, 2d, 3d, etc, and gives me very fine grained control over how objects in this universe behave (basically, anything you can code, you can attach to a node).
So based on what you wrote above, I think you would actually like Godot. There is a steep learning cliff, but once you get past that Godot lives at just the right level of abstraction. Doesn't do too much, but does the stuff you shouldn't have to worry about.
I think you are missing the fundamental purpose behind game engines. Game and graphics programming is really hard, and at times unapproachable to a lot of people. Moreover, in the real world, even experts prefer to use game engines just due to the fact that it is almost guaranteed that a raw renderer you write yourself is not going to be as good and optimized as a game egnine's renderer.
Using game engines may not suffice to your use case, but for a lot of people that's the best way to develop games. This argument is similar to using a systems level language vs a higher level language.
I myself prefer game frameworks over either raw graphics APIs and game engines, since it provides me with my preferred level of control while meeting my particular needs. I can see where you come from, if your goal is to learn and highlight that in your resume, writing and experimenting against the graphics APIs are likely the best bet. But for a lot of people, their main goal differs from yours, which is to... make a game.
Most of the effort that goes into a large game project is not in the runtime code, but in content creation: you probably only need one renderer or one physics system, but lots of levels, lots of characters with unique behaviors. So what does every one of the top general-purpose game engines provide? An IDE geared around content creation.
It is no surprise that you can find a benchmark where a general-purpose engine is slow. If you do nothing you go fast, but if you are supporting general-purpose use cases you add a lot of feature overhead, so you become slow. Why do pros use it, then? Because - if the engine is sufficiently extensible - they can use the built-in stuff as a placeholder and replace that subsystem with a custom one later. Project ships, everyone's happy.
With microbenchmarks based around scaling simple elements like "thousands of bullets" like the one in the video this point on general-purpose elements is especially important. As soon as you want to add any additional behaviors to those bullets your performance is going to plummet. And from a game design perspective, scale becomes boring very quickly. A player cannot really appreciate seeing more than a few hundred things on-screen at any moment.
So the way scenes are actually benchmarked in industry is by building out more of the behavior, adding placeholder assets at the estimated level of detail, seeing what frametimes result, and developing a scene budget around that. It all feeds back into the content creation pipeline again, because an optimized scene will have more care given to each of its assets.
>but I would rather spend time learning an actual universal graphics API that works on all hardware,
Unfortunately such a thing doesn't exist. You either have to choose something that hides the graphics API or use the preferred API of the platform (Metal on iOS/Mac, DX12 on Windows, Vulkan on Linux). If you decide to use a second class API then your UX will be second class but game engines don't suffer from that because they use the platform specific APIs directly.
> an actual universal graphics API that works on all hardware,
Good luck with that, no, game consoles don't do GL, most Switch games use NVN and it remains to be seen if PS5 will have Vulkan support.
These engines and frameworks are welcomed by the industry, because in most studios game development teams, the programmers are a minority, game designers and scripters are who actually make the game.
Anyone that wants to learn how a computer works should learn Assembly and low level coding.
Get a Raspberry PI and do bare metal game coding in Assembly like we used to do in the 80's.
It also seems to support c++ as "gdnative", although it requires another compiler to link against godot's binaries. It seems awkward because you still need to use the godot editor, and there is still a lot of interfacing to write.
It seems like a good alternative to unity, but in the end, all I want is an engine, not a "framework" or some awkward scene editor with some kind of Node hierarchy/interface.
I could say the same thing about UE4. I hear everywhere that's it's the place to go, that "everybody uses it and it's the norm in the industry if you want to make a game from scratch", but the reality is that those frameworks are too big and too feature rich. It sounds like they want to attract young developers to lock them into those awkward frameworks, because they advertise it as being full-featured engines, but small developers might not really need to focus on bleeding edge rendering, so it doesn't make sense.
I know there are engines like Ogre3D, but I would rather spend time learning an actual universal graphics API that works on all hardware, which has more value on a resume, and I can just use what I need. All other things like audio, animation, inputs, physics, etc are available as C++ libraries.
Those frameworks are saying "see? you can make your own game with those tools!", but when you actually learn how a computer works, and know how to write code, you realize you want to avoid those frameworks because they conceal too much from the programmer, and usually you don't want a developer to not understand what the framework is doing. I guess this is why people have a problem with certain object-oriented practices and abstraction.
EDIT:
Here is a nice video which benchmarks unity against a simple, very similar from-scratch equivalent. https://www.youtube.com/watch?v=tInaI3pU19Y