Nice, another candidate for my current still-ongoing engine checking-out journey!
Looked around the space recently with a focus on "Linux-usable, C++-able, Vulkan-able non-abandoned/non-rather-too-outdated engines today" (license unimportant in my search) and came away with: Unreal 5, Flax Engine, Godot (C++ story shaky / WIP, C++ is not a first-class game-dev scenario here AFAICT), Wicked Engine. (There's more out there that I ruled out for this or that reason and thus forgot about by now.)
Top candidates for me ended up being UE and Wicked, the latter currently preferred due to my actual (somewhat foggy/fuzzy =) code-first & code-mostly use-case idea. UE5 has way more batteries-included but it feels heavy and presses your C++ coding into a cage of its various de-facto-required macros, the whole setup seems to throw off both major VSCode extensions for C++, and its hit-or-miss hot reload thingie. Everything very geared to its authoring environment, understandably. But I really just want "engine as a linked .so library" here for my stuff..
(By Linuxable I don't mean Proton/Wine, but actual compiled-for/compileable-under-and-for Linux.)
You might find that Nebula lacks a bunch of tools.
We have ImGUI integrated so it's easy to use, but considering there are plenty of systems to interface with, it might be hard to deal with content without some content tools.
We mostly work on the core engine side of things. I am still not happy with a bunch of things rendering wise and want to make the engine capable of current gen rendering with GI, raytracing and whatnot.
But it's an open source project, so anyone could build tooling around the engine if they want ;)
Have you considered not using an engine at all, in favor of libraries? There are many amazing libraries I've used for game development - all in C/C++ - that you can piece together:
Ok, Quake is more of an engine than a library - but it is well documented & widely used. Even many current day AAA engines are still originally based on the Q1 engine (though, of course, heavily modified over the years to stay modern).
I don't mean to bring down anyone but I feel like game engine announcements are a dime a dozen these days. As someone who has worked in the industry I'd favor putting together my own simple engine based on libraries for smaller scoped projects. Most open-source engines, I presume, are not really going to be battle tested, well-supported, well-funded etc. There are some exceptions of course (like Godot). If your goal is too complex; why not just use UE5 or Unity? Epic has been in the industry for a long time, Tim Sweeney is a really smart guy, and the engine has been widely used in AAA and indie games.
Building your own engine is fine advice for someone with experience throughout the whole stack, but for most people who just "want to make a game" it's just going to get them stuck in the weeds of intractable problems once they get past the "fun parts" and things get complicated and out of their depth.
Of course depends on ones mindset and scope for the game. If you made one or two very simple games "back in the day" and just want to repeat the experience, using libraries can be a smaller hurdle than to grok a game engine.
But if you want 3D objects or game networking etc etc, a game engine will probably be the right thing.
> Godot (C++ story shaky / WIP, C++ is not a first-class game-dev scenario here AFAICT)
Godot C++ here - works fine so far. I use C++ for the heavy lifting and GDScript for gluing things together. Pretty stable, and the engine compiles in minutes (needed double precision). C++ game logic compiles rather fast. Since the engine is written in C++, that language is right at home.
You only need to make sure your extension API file is in sync with any “main” engine version upgrades. And for major upgrades godot-cpp.
Everything compiles really fast in both Linux and Windows and dependencies are easy to set-up.
However, there is little C++ documentation but that is because once you get the gist of using their Ref<T> wrapper everything is intuitive (functions and methods map one to one from GDScript). Just download their example and have a look around.
Also the engine’s code is _very_ easy to follow if you get stuck and can itself be used as samples.
I am really rusty (even rust can be used btw) with C++ and was able to pick things up quite fast.
Let me know if you have any questions. But really all I needed to start was their example above.
This is one of the best parts of Godot, it's small enough to compile pretty quickly, and simple enough that you can jump in and understand the code and debug any problems with minimal friction.
The maintainers are also good about quickly accepting small bug fix PRs.
And yeah, the development experience with GDExtension is now really nice, though it's best to do a little work to set up a CMake project rather than relying on scons.
Unfortunately, I spent too much time building a game unity. As soon as I switched to Godot I was able to make meaningful progress, and I am getting closer to release. Unity was buggy, getting in the way, and lacked the right features while it was full of all the features I didnt need. While it may be an excellent tool for shovelware it sucks for novelty.
Hot reload basically just doesn’t work. Prototype in blueprints and do hard calculation, replication relevant stuff, and algorithms in cpp.
But the batteries included are almost always useful. If you don’t really know what you’re doing, you’re likely to make something that sort of works but fails to consider edge cases the engine designers have dealt with other time through trial and error.
Mindblowing might be an overloaded, underdefined term but... the homepage top is a series of vids and if one bears through the anime stuff, one comes to rather fine terrain/foliage, weather, sky / volumetric-cloud renditions. Maybe that was meant above. It's all not readily myFavoriteAaaGameClone.Run() but at least it's quite wildly capable as far as the whole rendering-capabilities landscape nowadays goes.
Maybe I'm being thrown off by the anime characters, but I associate even the grass and trees with the kind of low effort 3d meme games that permeate steam. From what I understand, it's difficult not to make a game look like this if you're just throwing unity assets together.
Looked around the space recently with a focus on "Linux-usable, C++-able, Vulkan-able non-abandoned/non-rather-too-outdated engines today" (license unimportant in my search) and came away with: Unreal 5, Flax Engine, Godot (C++ story shaky / WIP, C++ is not a first-class game-dev scenario here AFAICT), Wicked Engine. (There's more out there that I ruled out for this or that reason and thus forgot about by now.)
Top candidates for me ended up being UE and Wicked, the latter currently preferred due to my actual (somewhat foggy/fuzzy =) code-first & code-mostly use-case idea. UE5 has way more batteries-included but it feels heavy and presses your C++ coding into a cage of its various de-facto-required macros, the whole setup seems to throw off both major VSCode extensions for C++, and its hit-or-miss hot reload thingie. Everything very geared to its authoring environment, understandably. But I really just want "engine as a linked .so library" here for my stuff..
(By Linuxable I don't mean Proton/Wine, but actual compiled-for/compileable-under-and-for Linux.)