- I've used Unity for small to medium sized commercial industry projects (3D, VR Tours etc.).
- I've used Unity for a 2D Gamejam.
- Various Unity research projects.
Background Godot:
- I've started using Godot v2.1 with little preparation successfully on two Game jams (2D) [1]
- I've contributed smaller additions and bugfixes to Godot in the past months, in order to help the 3.0 release and also to understand more of the internals.
- I am currently working on a bigger 2D game in Godot 3.0.
This is my personal experience and opinion:
First of all: For sure Unity is great and I would not hesitate to use it again in future, especially for 3D (without having much experience in Godot 3.0 3D environment).
However it has drawbacks compared to Godot, especially for 2D which is my main focus:
- Terrible 2D support in Unity (for retro/pixel perfect projects). It's not that it is impossible but you need to know and work around many aspects to setup something that works. Same setup in Godot needs literally two clicks. Units in Godot are pixel units. Perfect.
- No Nested prefabs in Unity. Check out their GDC 2018 keynote (end). It is even a joke to them. Well, to me it isn't. Godot does nested instances and it is a great productivity gain.
- (Open/Public) Source code access in Godot. That probably only applies to people with C++ experience but it was great that I was not stuck since I could dive in and find and fix my problems. Often I found other people with the same problem, and sometimes a PR to fix it, so I could build it from their PR before the official merge and could go on doing my work.
- Source code state/community for Godot. Godot has a pretty non-idealistic style of code. It's not heavily abstracted. And while one could argue if it always has best design choices at least it makes it very easy to dive in. My PRs and fixes were gratefully accepted, it is a very open and productive community. Discussions on Github were constructive in my experience.
- Unity has second class Linux (editor) support. To be fair: it seems to gradually improve. Thanks for that btw. But whenever I try I get showstopping weird issues. Every build is a different problem. In contrast: Godot under Linux is flawless. To be honest: Unity Editor does much more under the hood. And again: I personally do not care. I am focused on 2D and I feel I pay a lot extra.
- GUI. I know that there is now a new GUI framework in Unity but I feel like it made things worse. I have a hard time getting the results I want as compared to Godot's GUI system. Not impossible per se, just not as intuitive as I would like it. Godot's GUI frameworks works similar to Qt Designer. Simple layouts and widgets.
- Nodes and scripts (Godot) vs. Objects and Components (Unity). I have found that the nodes available in Godot make it very easy to come up with various setups. There is just a bunch of (useful) functionality build in. Especially their viewport/offscreen rendering on top of canvas mixed with GUI and shaders make things pretty easy. No need to script for various scenarios + the benefit of these nodes being native.
- 2D Physics. Unity uses box2D (like?) physics. Godot has a custom physics engine that works pretty much like old school arcade physics. It is a perfect starting point for platformers etc. without the sacrifice in control. If your game is NOT an angry birds clone then probably a box2D like physics engine is not what you want.
I was quite surprised myself that Godot boosted my productivity so much as compared to former workflows.
Initially one of my first doubts with Godot was GodotScript. And I must say I was wrong. It is a great little language which helps iterating quickly. And if you are not happy with the performance, you can use C++ or C# or anything else with GodotNativeScript (around 2.6x speedups with C++ in my measurement[2]). I for myself kept GodotScript as iteration speed is more important to me than native performance, especially in the initial stage.
The big negative point as already pointed out is that Godot has few proven examples of successful bigger projects. Therefor platforms may be another issue. But having the source code under control helps, plus there is a drive that hopefully spawns more interest and support in future. Godot deserves it.
To conclude. For 2D I have not found a better tool than Godot.
Please disagree if you like but give the tool a fair chance.
How's the interplay btw GodotScript and C++? (and the several other scripting options they give you)
I've played a bit with Unreal, so I'm not very qualified to have opinions, but I really like how the system is mostly a C++ stack. The Blueprints are in effect extending underlying C++ classes. The "FFI", if you want to call that, is pretty clean and easy and if you want to write C++ it works very well with the rest of the system. It definitely could be cleaner... not exactly git-clone, cmake, make, make install... there are magic macros, some C# that does godknowswhat and over all it's messier than I would like.
But with all the scripting that Godot supports it seems like it'd be even messier still? You'll have some assets in C++ some in GodotScript and some in C#. Or am I wrong?
(Please correct me if any of the following is imprecise, as I am not a core dev of Godot)
Languages are roughly stacked like this:
1. Internal scripting
Godot internally (C++ source) makes a distinction between core and modules.
So many of the functionality that do not necessarily belong to the core engine are modules.
You are free to write your own extension to and modules to the editor (for example custom Node types).
There is also an EditorPlugin API so you do not necessarily have to get your hands wet in the engine API itself if not necessary.
Btw. the latter API is also exposed in GDScript.
Anything that implements script_language.h as a module is considered part of the editor (e.g. exposed in-editor script support etc.)
In 3.0 that would be GDScript and C#.
2. GDNative
Additionally 3.0 introduced GDNative which in essence is an API that exposes the internal C++ API that makes up the In-Game scripting as C symbols. This has the benefit that C can be bound to anything. Going this route even the C++ API is bindings created through C :-). More details here [1].
It is a relatively new effort but so far the following languages are supported (not making claims about stability/maturity here):
- C (just the API itself via the shipped headers)
- C++ [2]
- D [2]
- Rust [2]
- Python [3]
- Nim [4]
- Possibly others?
Once you have a library that can be hooked into you load it in the editor for each individual platform you try to target.
That being said: There is no heavy boilerplate-magic going on. I've setup a CMake file to handle C++ plugins without big issues.
There is no real hot-loading AFAIK but you do not need to restart the editor since it loads the libraries in play mode.
This is a sample of the GDNative API [5].
Here is a manual setup with C [6]. While the tooling improved meanwhile (e.g. in editor tools to set the libraries) it gives you a good overview how the GDNative API works.
Good post, it closely matches where I'm at. For any 2d project I'd look at using Godot (or even a custom/SDL solution) over Unity.
Even for 3d Unity is great to get into, but I always feel that for any non cookie-cutter project I want to build that it is always fighting back against me.
Unity is REALLY bad and unintuitive for 2D games. It's a 3D engine that begrudgingly lets you draw sprites except alpha and overdraw are really expensive. Basically any 2D engine will perform 1000x better out of the box.
This is exactly the comparison I was looking for - thank you for posting it. I tried Godot back in the pre-2.0 days and found it lacking a number of features I needed for 2D development. I'll definitely be picking it up again.
I think Cocos2d-x is a perfectly suited alternative, especially when you target mobile. However I remember that e.g. render targets were experimental, and in general Desktop is not the main platform. That being said if you hook up an input library even for desktop you can achieve remarkable results [1].
I haven't used the editor much so I won't make any claims here, but if you want to use code, C++ or one of the bindings is your favorite why not Cocos2D-x.
I hope my initial comment did not sound to biased, but to clean this up:
Use whatever feels right to you. I felt very productive with Godot for the type of game I am doing and I just wanted to share my experience :)
Background Unity:
- I've used Unity for small to medium sized commercial industry projects (3D, VR Tours etc.).
- I've used Unity for a 2D Gamejam.
- Various Unity research projects.
Background Godot:
- I've started using Godot v2.1 with little preparation successfully on two Game jams (2D) [1]
- I've contributed smaller additions and bugfixes to Godot in the past months, in order to help the 3.0 release and also to understand more of the internals.
- I am currently working on a bigger 2D game in Godot 3.0.
This is my personal experience and opinion: First of all: For sure Unity is great and I would not hesitate to use it again in future, especially for 3D (without having much experience in Godot 3.0 3D environment).
However it has drawbacks compared to Godot, especially for 2D which is my main focus:
- Terrible 2D support in Unity (for retro/pixel perfect projects). It's not that it is impossible but you need to know and work around many aspects to setup something that works. Same setup in Godot needs literally two clicks. Units in Godot are pixel units. Perfect.
- No Nested prefabs in Unity. Check out their GDC 2018 keynote (end). It is even a joke to them. Well, to me it isn't. Godot does nested instances and it is a great productivity gain.
- (Open/Public) Source code access in Godot. That probably only applies to people with C++ experience but it was great that I was not stuck since I could dive in and find and fix my problems. Often I found other people with the same problem, and sometimes a PR to fix it, so I could build it from their PR before the official merge and could go on doing my work.
- Source code state/community for Godot. Godot has a pretty non-idealistic style of code. It's not heavily abstracted. And while one could argue if it always has best design choices at least it makes it very easy to dive in. My PRs and fixes were gratefully accepted, it is a very open and productive community. Discussions on Github were constructive in my experience.
- Unity has second class Linux (editor) support. To be fair: it seems to gradually improve. Thanks for that btw. But whenever I try I get showstopping weird issues. Every build is a different problem. In contrast: Godot under Linux is flawless. To be honest: Unity Editor does much more under the hood. And again: I personally do not care. I am focused on 2D and I feel I pay a lot extra.
- GUI. I know that there is now a new GUI framework in Unity but I feel like it made things worse. I have a hard time getting the results I want as compared to Godot's GUI system. Not impossible per se, just not as intuitive as I would like it. Godot's GUI frameworks works similar to Qt Designer. Simple layouts and widgets.
- Nodes and scripts (Godot) vs. Objects and Components (Unity). I have found that the nodes available in Godot make it very easy to come up with various setups. There is just a bunch of (useful) functionality build in. Especially their viewport/offscreen rendering on top of canvas mixed with GUI and shaders make things pretty easy. No need to script for various scenarios + the benefit of these nodes being native.
- 2D Physics. Unity uses box2D (like?) physics. Godot has a custom physics engine that works pretty much like old school arcade physics. It is a perfect starting point for platformers etc. without the sacrifice in control. If your game is NOT an angry birds clone then probably a box2D like physics engine is not what you want.
I was quite surprised myself that Godot boosted my productivity so much as compared to former workflows.
Initially one of my first doubts with Godot was GodotScript. And I must say I was wrong. It is a great little language which helps iterating quickly. And if you are not happy with the performance, you can use C++ or C# or anything else with GodotNativeScript (around 2.6x speedups with C++ in my measurement[2]). I for myself kept GodotScript as iteration speed is more important to me than native performance, especially in the initial stage.
The big negative point as already pointed out is that Godot has few proven examples of successful bigger projects. Therefor platforms may be another issue. But having the source code under control helps, plus there is a drive that hopefully spawns more interest and support in future. Godot deserves it.
To conclude. For 2D I have not found a better tool than Godot. Please disagree if you like but give the tool a fair chance.
[1] Small Godot based Game jam projects: https://itch.io/profile/stateoff
[2] Personal benchmark of GDNativeScript: https://twitter.com/StateOffGames/status/944878511801753601