Here are some thoughts in regards to Godot vs Unity vs jMonkeyEngine (another project i like).
Godot:
- completely free and open source, it actually seems viable long term because it has a pretty active community and lots of contributors, which is honestly pretty important
- the best aspect in my eyes is the fact that it can be installed as a single binary and runs really quickly, none of the bloat of needing complex installers and dozens of packages like Unity does
- the language choice is also pretty interesting, their GDScript language being a bit like Python and being integrated pretty well with the engine, as well as other builds support C# and thus switching from Unity is easier (and C# is just a really nice language); there are community bindings or the ability to use C++, but i find those to be less viable, given the lack of ease of use and documentation
- that said, in most cases i'd opt for C#, not just because of its performance being better, but GDScript lacking certain functionality to be able to use design patterns, for example singletons or service patterns or anything else that attempts to centralize bits of game logic into manager classes versus having everything be some distributed mess of interdependent game objects/scripts
- the tools and functionality that is included is pretty good, however there are some things that are lacking, like a terrain system or dynamic render resolution, though thankfully there are community plugins which address the most severe of these shortcomings
- that said, there is not even 1% of the assets that you'd get in other game engines like Unity or packages, because Godot hasn't really figured out the financial incentives and having a marketplace yet - it's great that you can get a variety of free assets, but as a content creator you might not want to expect Godot to be a viable financial venture yet
- currently version 4 is in development, which adds Vulkan support and numerous other quality of life improvements (like automatic LODs), however 3 is also actively supported and functionality is occasionally backported
- also, the asset formats and other imported files (apart from binary data) can be easily versioned with regular Git installs, maybe with LFS for assets if you want
- overall, it's a pretty nice project and one of the few ones that i'd call "production ready"
- wins in regards to job positions available, hands down
- the support for C# is top notch, IDEs also have nice plugins, e.g. JetBrains Rider tells me which methods are likely to be slow and gives me other hints which is really great
- the documentation is pretty good, there is an absolutely staggering amount of quality tutorials and even written guides out there as well
- the amount of both free and paid assets is absolutely amazing, you can solve most programmatic and other problems quickly (need splines? pathing solutions? dynamic LOD? billboarding for objects far away? or maybe models? what about shaders? all of those and more are covered)
- personally, i also think that the GameObject system with components is really nice - you can attach numerous different behaviors to any object that you want (composition) vs needing to either work with inheritance in Godot by extending scripts or having child nodes affect the behavior of parent nodes (which feels odd, maybe i'm just used to how Unity works)
- the performance for exported games is really good, all of the built in rendering solutions are performant and have been tested really widely in the industry
- speaking of tested, it's also been used for a really wide variety of platforms and has support for lots of input devices etc.
- all of that said, it feels like the engine has made a steep nose dive in the last 5 years, DOTS (their new ECS) is being implemented gradually and oftentimes still isn't as stable as it could be
- the build in rendering solutions are problematic (built in render pipeline, Universal Render Pipeline (URP) and High Definition Render Pipeline (HDRP)), since many of the assets clash, projects need to be converted if you ever switch, external assets might not be compatible, shaders break etc.; a demo scene from 2019 had most materials be pink and became invisible after reimport
- the editor has gotten way worse performance wise, a scene with about 1000 assets takes a minute to load and display (wanted a scene with every asset i have displayed side by side for scale comparison), editing scripts and switching to editor lags noticeably, moving stuff around is slow, just horrible performance on a vaguely modern hardware setup
- the situation of the engine and its parts is an utter mess altogether: they have multiple UI solutions, multiple input solutions, no workable multiplayer solutions (they deprecated what they had, replacements are not ready yet)
- because of all of the above i've since moved from Unity to Godot, the engine feels like some mess of trying to add new flashy features without properly testing them before release while at the same time having most of the legacy stuff stick around except for when they pull the rug out from under your feet and break something
- also, its integration with Git isn't too good
- just suggesting this because i like the project but it's also an example of what not to do
- being able to write games in Java is actually a pretty good idea and works decently in practice, regardless of what others say
- being able to export a cross platform .jar file and run it almost anywhere with a JDK/JRE is also really nice in regards to portability
- the engine being free and having vaguely passable docs and some extensions (similarly lacking like Godot's though) is also okay
- it does fail in regards to UI/UX, though, since not having a user friendly visual editor is one of the larger mistakes that you can make
- also, while code-heavy engines definitely have their place, some of the integrated solutions, e.g. the UI ones are a bit of a mess and the docs were incomplete last i checked
- the graphics capabilities are also a bit limited and it seems that the engine never really got off the ground that well
- that said, i wish the engine would become more popular and would find its niche with passionate supporters, though thankfully it's at least more stable than both Godot and Unity are, so there's that
Link to their OpenCollective, to illustrate my point of why you might need a following: https://opencollective.com/jmonkeyengine (contrast that to Godot's budget, which is shown on their site)
In summary, i think that Godot has gained the critical following that it needs to be viable for game development and other pursuits (e.g. tool creation) long term.
Unity will keep to being in slow decline until they'll hopefully get their stuff together down the road yet will also be a dependable workhorse for the industry in a professional capacity. I guess you could also mention Unreal in this niche, albeit it's a tad different (better suited for a particular type of game, a bit harder to code in but also capable of really good graphics).
jMonkey engines and other projects like it (e.g. Xenko/Stride) will pop up occasionally but without Godot's following they might survive at best while having one or two nice innovations or features that set them apart and make them decent for some use cases.
Overall, one has to admire that they can get started with game development at almost no expense, since lots of other tools like Blender and GIMP are also free!
> it does fail in regards to UI/UX, though, since not having a user friendly visual editor is one of the larger mistakes that you can make
Keep in mind that for some of these projects having a visual editor might be outside of their scope - these are often "engine frameworks" (or as i like to call them "engine engines" :-P) for making your own engine and tools rather than complete turnkey solutions by themselves like Unreal or Unity. This approach gives more freedom to the developers but at the cost of having to make their own tools (though they still take care of the low level plumbing bits). The idea with those isn't to make a generic catch-all toolset like Unreal/Unity, but something that is specific to the project at hand. Note that sometimes they do offer some tools but they tend to be separate projects that use the framework like "your" tools would do rather than being part of the engine itself like in Unreal/Unity.
There are a bunch of those, though they are not as high profile as Unreal and Unity - two commercial ones you'll most likely have heard of would be Gamebryo[0] and RenderWare, though the former is nowadays mostly limping along and the latter was been shut down years ago after EA acquired them.
I think Sony's PhyreEngine is/was something like that but i'm not 100% certain as that is only via hearsay and not something i've seen myself.
> Keep in mind that for some of these projects having a visual editor might be outside of their scope - these are often "engine frameworks" (or as i like to call them "engine engines" :-P) for making your own engine and tools rather than complete turnkey solutions by themselves like Unreal or Unity.
That's a fair point! Though jMonkeyEngine actually uses LWJGL so i guess at this point we're talking about "engine engine engines". Of course, there is certainly merit to a layered and modular approach like that!
> This approach gives more freedom to the developers but at the cost of having to make their own tools (though they still take care of the low level plumbing bits).
This is excellent for when you have the time and resources (and the desire/motivation/discipline) to make your own tooling and end up with something bespoke, that fits your needs/project well.
But it's a non-starter for those who just want a usable package with batteries included, which i'd argue is the majority of the users and therefore will impact the popularity of the project negatively.
It's interesting to behold and is probably quite the learning experience, though i'm not sure whether Randy's game will come out first, or whether GNU Hurd will beat him to it.
> But it's a non-starter for those who just want a usable package with batteries included, which i'd argue is the majority of the users and therefore will impact the popularity of the project negatively.
Well, yeah, i think the popularity of Unity even at its earlier versions over -say- Irrlicht is a testament to that despite the latter containing pretty much everything one might need for a 3D game :-P.
But my point is that popularity here can be a red herring because frameworks like that never set out to provide the same solutions as Unreal/Unity and for someone who is looking for a framework to build on or use as opposed to an all-in-one solution like Unreal/Unity, the latter's popularity wont matter much (and there are such people - it is not uncommon to see developers who say that, e.g., they'd like Unity if they could use it as a library).
> personally, i also think that the GameObject system with components is really nice - you can attach numerous different behaviors to any object that you want (composition) vs needing to either work with inheritance in Godot by extending scripts or having child nodes affect the behavior of parent nodes (which feels odd, maybe i'm just used to how Unity works)
Component system is terrible. You only use it to reference Unity built-in components(text, animation, position etc).
> - the support for C# is top notch, IDEs also have nice plugins, e.g. JetBrains Rider tells me which methods are likely to be slow and gives me other hints which is really great
Rider thinks that every method is slow. The hints are useless.
> - all of that said, it feels like the engine has made a steep nose dive in the last 5 years, DOTS (their new ECS) is being implemented gradually and oftentimes still isn't as stable as it could be
As someone who works with Unity every day for the last 11 years now - No! During the last 5 years a lot of new stuff got added. I was seriously not expecting so much to be done given how slow the development was all the way from version 3. I agree that currently it is a bit of a mess with the new UI framework still being in preview and the old one being terrible. I agree that it sucks that there is no networking solution out of the box(there are several good ones out there tho). But I absolutely don't agree that Unity is in a slow decline. I see it getting better with every release and accelerating while doing so.
However, at the same time a lack of earning opportunities will prevent a lot of people from participating and creating content for it: be it content creators who'd provide turnkey solutions for non-trivial mechanics and engine extensions, asset creators who'd allow the less artistically inclined developers to plug their skill gaps with those or even ad solutions for monetization of freemium games or ad supported games.
(i don't necessarily support the latter, but that probably matters to some)
While I agree that Java is much better than most people think, it's not an alternative on low power systems for clientside work.
Try running Java Minecraft on a Raspberry 4 and you understand how.
The why is complicated but the solution is to run Java on the server and C+ on the client... I'm still debating internally if I should port J2ME for scripting my 3D action MMO system but so far it is hot-deployed C with .dll/.so!
> You can certainly have Singletons in Godot using GDScript [1].
That is somewhat true in that you can get most of the way there with some pitfalls, from the documentation:
> Act like a singleton, since GDScript does not support global variables by design.
(of course, it's their language so they can design it however they wish)
The note sheds more light on how it works:
> Godot won't make an AutoLoad a "true" singleton as per the singleton design pattern. It may still be instanced more than once by the user if desired.
It's still nice that they added the AutoLoad section with the ability to use the checkbox to enable referencing your variables with the class name qualifier vs having to get the singleton node first. Truthfully, it should cover most use cases out there with no issues.
Also, Godot's docs are actually improving at a pretty nice rate!
Hi KronisLV, I am thinking of learning game programming and teaching some kids the same. I realize that publishing the game on consoles like PS4 or making it available on Mac, or Android, Iphone is the _end_ that we will like to see with this adventure.
Would Godot engine help me publish games in all the platforms? Or would Unity / Unreal are more suitable for that?
Thanks for this comparison, it helped with some perspective.
Similar story to the above (that one link should be enough).
In summary, i'd suggest that you don't bother with consoles, because those take a lot of time and effort to export anything to. Other platforms should be easier to work with in all of the engines, desktop/web probably being the best bet.
There's a company run by one of the Godot devs that offers console porting services. Keep in mind console specific code is protected by NDAs plus you need to have a devkit. Godot definitely CAN be ported to consoles, that code just can't be open source nor freely distributed.
With your summary in mind, would you say in 2022 one should start with Godot instead of Unity to learn the basics of game dev? Godot to me seems "tidier"
Personally, i'd suggest that you try out a variety of engines and use whatever is the most comfortable for you, given your background (for example, C++ devs might go with Unreal instead of the other options).
For me, if i wanted to learn game development and do so in a pretty easy fashion, i'd most likely go with: Godot + GDScript, since those two are integrated rather well and are easy to pick up and learn. I'd suggest that you stick with the Godot 3.X.Y stable releases for the time being, though, since Godot 4 is still in development and is subject to changes.
It can definitely also lead to shippable products with not too many issues along the way (apart from the asset store being small), though currently Godot is definitely more capable for 2D games than it is for 3D games (if you ever want advanced graphics, you might have to wait for Godot 4).
Of course, if you're learning game development in hopes of getting a job in the industry, then you should most certainly go with Unity due to its popularity.
Godot:
Suggestion of some Godot videos - GDQuest channel: https://www.youtube.com/c/Gdquest/videos (they have a site as well: https://www.gdquest.com/)Unity:
Suggestion of some Unity videos - Sebastian Lague: https://www.youtube.com/c/SebastianLague/videos (more about getting things done with the engine)jMonkeyEngine:
Link to their OpenCollective, to illustrate my point of why you might need a following: https://opencollective.com/jmonkeyengine (contrast that to Godot's budget, which is shown on their site)In summary, i think that Godot has gained the critical following that it needs to be viable for game development and other pursuits (e.g. tool creation) long term.
Unity will keep to being in slow decline until they'll hopefully get their stuff together down the road yet will also be a dependable workhorse for the industry in a professional capacity. I guess you could also mention Unreal in this niche, albeit it's a tad different (better suited for a particular type of game, a bit harder to code in but also capable of really good graphics).
jMonkey engines and other projects like it (e.g. Xenko/Stride) will pop up occasionally but without Godot's following they might survive at best while having one or two nice innovations or features that set them apart and make them decent for some use cases.
Overall, one has to admire that they can get started with game development at almost no expense, since lots of other tools like Blender and GIMP are also free!