Godot at GDC 2018(godotengine.org)
godotengine.org
Godot at GDC 2018
https://godotengine.org/article/godot-doing-well-gdc-2018
103 comments
Godot is advancing at a fast clip. Godot 3 is a nice milestone. They're on bullet now for physics, which is nice (just like all the GTA games). Disney BSDF, their pbr stuff, and global illumination lighting look really good. https://godotengine.org/storage/app/media/devlog/rendering/f...
Here's some video of their third person platformer demo project: https://www.youtube.com/watch?v=aRwCxMYSIk8
And their post about 3.0: https://godotengine.org/article/godot-3-0-released
If nothing else, I hope it puts some pressure on Unity to solve and ship fixes for some of their longstanding weaknesses — (their bizarre and fundamentally handicapped prefab system, their slow runtime boehm garbage collector which hasn't been updated in a decade, the need to expensively recompile your entire project with every small change to a .cs file, etc) as opposed to just making grand promises at keynotes. I do like Unity's recent integrations of ProBuilder and TextMeshPro. I don't mean to bash it, but Godot deserves to succeed alongside it given its admirable development and licensing model.
Here's some video of their third person platformer demo project: https://www.youtube.com/watch?v=aRwCxMYSIk8
And their post about 3.0: https://godotengine.org/article/godot-3-0-released
If nothing else, I hope it puts some pressure on Unity to solve and ship fixes for some of their longstanding weaknesses — (their bizarre and fundamentally handicapped prefab system, their slow runtime boehm garbage collector which hasn't been updated in a decade, the need to expensively recompile your entire project with every small change to a .cs file, etc) as opposed to just making grand promises at keynotes. I do like Unity's recent integrations of ProBuilder and TextMeshPro. I don't mean to bash it, but Godot deserves to succeed alongside it given its admirable development and licensing model.
> miles ahead of the commercial offerings
In some ways, maybe. In all ways, or even "most", no. Definitely not.
For a free engine it is impressive, no doubt, but it is not miles ahead of commercial offerings.
In some ways, maybe. In all ways, or even "most", no. Definitely not.
For a free engine it is impressive, no doubt, but it is not miles ahead of commercial offerings.
In some ways yes, and it will only get better over time as more developers become aware of Godot. It may even be that most people wont realize the richer plugin ecosystem that will grow around Godot (which is surely growing!) and that will be it's biggest strength much like how Atom and VS Code spread so quickly. Godot doesn't force you into their ecosystem, they welcome you to use GDScript but it's not your only path forward thanks to GDNative.
You weren't kidding about D. It looks like just this week someone released some D bindings for Godot. Exciting! I really like D, and I am curious to try gamedev in D.
https://code.dlang.org/packages/godot-d
https://code.dlang.org/packages/godot-d
I really wasn't! Glad you found it, I think the Github repository is even older if it's the project I saw a while back. All of that is possible because of GDNative, which ties together native code back to Godot itself so you don't have to recompile the whole engine just to bind native code to it.
Adding a link to their GitHub since to me is looks like the dub website is slow / down?
Link to D bindings for Godot:
https://github.com/GodotNativeTools/godot-d
Edit: Looks like they got Rust and C++ bindings in their umbrella too:
https://github.com/GodotNativeTools
Adding a link to their GitHub since to me is looks like the dub website is slow / down?
Link to D bindings for Godot:
https://github.com/GodotNativeTools/godot-d
Edit: Looks like they got Rust and C++ bindings in their umbrella too:
https://github.com/GodotNativeTools
Unity can use .NET 4.6 now. It wasn't because they were slowpokes, xamarin would not license it to them until they were acquired by Microsoft.
- Mono's license prior to the Microsoft/Xamarin acquisition was LGPL, which is open ended and doesn't allow e.g. discriminating against Unity; Unity would not accept it under those terms
- Xamarin did offer a commercial license to Unity; Unity would not accept it
- MS began to release their own .NET implementation under the kinds of license terms that Unity wanted years ago, but Unity didn't budge
- In the meantime, MS then relicensed Mono itself—the .NET implementation that Unity actually wanted—under the kinds of terms that Unity wanted, but still Unity didn't show signs of moving until very recently
The whole it's Mono's fault that Unity sucks was essentially a successful PR attempt for Unity to disclaim responsibility for their shortcomings, with the (maybe not unintentional) side effect of directing public ire towards Mono for not doing enough free work (to benefit what was already one of the industry's most successful companies!)
- Xamarin did offer a commercial license to Unity; Unity would not accept it
- MS began to release their own .NET implementation under the kinds of license terms that Unity wanted years ago, but Unity didn't budge
- In the meantime, MS then relicensed Mono itself—the .NET implementation that Unity actually wanted—under the kinds of terms that Unity wanted, but still Unity didn't show signs of moving until very recently
The whole it's Mono's fault that Unity sucks was essentially a successful PR attempt for Unity to disclaim responsibility for their shortcomings, with the (maybe not unintentional) side effect of directing public ire towards Mono for not doing enough free work (to benefit what was already one of the industry's most successful companies!)
"Its mono's fault" was told to me by one of the founders of Xamarin, in person, not by Unity. Perhaps they did offer Unity a license to their newer stuff, but at completely unacceptable terms. Xamarin's concern was that Unity would be a direct competitor with their own cross platform product.
I don't consider this to be anyone's fault, my point is that post-MS acquisition, it is easier to get access to the newest mono runtimes/compilers, which is why we are seeing them appear in Unity and in Godot.
>MS began to release their own .NET implementation under the kinds of license terms that Unity wanted years ago, but Unity didn't budge
That one wouldn't have targeted all of their platforms, right?
I don't consider this to be anyone's fault, my point is that post-MS acquisition, it is easier to get access to the newest mono runtimes/compilers, which is why we are seeing them appear in Unity and in Godot.
>MS began to release their own .NET implementation under the kinds of license terms that Unity wanted years ago, but Unity didn't budge
That one wouldn't have targeted all of their platforms, right?
Perpetual arbitrary changing license fees are something everyone wants to avoid.
The fees went away, they started moving.
Its more complicated than that, but ultimately they won: the people demanding license fees got flipped off and they got what they wanted for free.
...so, I know a lot of people have been angry about this, but by every metric what they did was a total business success.
If you want the guys from Unity to act differently, you have to actually tangibly affect them (eg. pick a different engine), not just complain.
The fees went away, they started moving.
Its more complicated than that, but ultimately they won: the people demanding license fees got flipped off and they got what they wanted for free.
...so, I know a lot of people have been angry about this, but by every metric what they did was a total business success.
If you want the guys from Unity to act differently, you have to actually tangibly affect them (eg. pick a different engine), not just complain.
[deleted]
I sort of feel the same way, but they've just copied the Adobe and Autodesk licensing model, and its hard to blame them considering how well that has worked out for those other companies.
As a fulltime Unity dev, this doesn't matter much to me, because it doesn't address the major pain point for larger Unity games. This .NET upgrade does not include a modern garbage collector, and the garbage collector update has been "maybe next year, but definitely not now, because it's hard" for as long as I've been using Unity.
Workarounds exist. That's great. I don't care. Workarounds don't address the default experience of writing idiomatic C#.
I've considered switching to Unreal, but that has GC built into it a little too much. I know nothing about its characteristics, but it makes me wary. This thread makes me want to investigate Godot. Can anyone provide a one-sentence summary of the GC situation there?
Workarounds exist. That's great. I don't care. Workarounds don't address the default experience of writing idiomatic C#.
I've considered switching to Unreal, but that has GC built into it a little too much. I know nothing about its characteristics, but it makes me wary. This thread makes me want to investigate Godot. Can anyone provide a one-sentence summary of the GC situation there?
I have yet to have any GC issues in a Unity project over 5 years of using it, even larger scale ones. But I would agree I rarely write "idiomatic" C#, I don't like many things about that style of programming in the first place to be honest.
A garbage collector is rarely the issue; poor development practices and not planning memory usage patterns in the architecture will cost you orders of magnitude of performance long before the GC itself is an issue.
Its not even hard to have zero GC allocations on ~99% of frames. This will give you better performance than the best GC implementations over bad allocation patterns ever could. This is also true of Unreal (UObjects are GC'd as you mentioned) and literally everything else using a GC; its not a free pass to forget about memory management.
Thats one of the primary reasons why I rarely use code assets from the Asset Store; most people don't know how to write performant C# whatsoever; they get killed by a thousand cuts but none of them show up in the profiler, effectively wasting 90% of the CPU without any warning signs. (This is true of almost every software ever released.)
I'm not one for premature micro-optimizations, but on the other hand I don't see how you can get any kind of performance without accounting for macro-optimizations from the very beginning.
Blaming the GC for poor performance is pretty much the same as doing unbuffered byte-by-byte I/O and then wondering why its 1000x slower than the competition even after weeks of micro-optimizations.
A garbage collector is rarely the issue; poor development practices and not planning memory usage patterns in the architecture will cost you orders of magnitude of performance long before the GC itself is an issue.
Its not even hard to have zero GC allocations on ~99% of frames. This will give you better performance than the best GC implementations over bad allocation patterns ever could. This is also true of Unreal (UObjects are GC'd as you mentioned) and literally everything else using a GC; its not a free pass to forget about memory management.
Thats one of the primary reasons why I rarely use code assets from the Asset Store; most people don't know how to write performant C# whatsoever; they get killed by a thousand cuts but none of them show up in the profiler, effectively wasting 90% of the CPU without any warning signs. (This is true of almost every software ever released.)
I'm not one for premature micro-optimizations, but on the other hand I don't see how you can get any kind of performance without accounting for macro-optimizations from the very beginning.
Blaming the GC for poor performance is pretty much the same as doing unbuffered byte-by-byte I/O and then wondering why its 1000x slower than the competition even after weeks of micro-optimizations.
> Workarounds exist. That's great. I don't care. Workarounds don't address the default experience of writing idiomatic C#.
I blame Unity's GC for what it is bad at. It's both stop-the-world and non-generational. As I said down-thread, it's a lot of work to design for avoiding allocations. Even then, Unity will still GC from time to time, and whether it matters will depend on the characteristics of your game's managed heap as a whole. This is the major stumbling block most times people argue with me about how GC is fine. Your data is like your data, because your app is your app. It's not like my data. The next step is not to use the managed heap for anything that isn't a temporary. Again, quite a bit of work. And the beginners and intermediates who are most of Unity's users aren't going to do it. Hell, in general I consider GC a non-starter for games, but sometimes I want to work at a company that uses C#. So I repeat:
> Workarounds exist. That's great. I don't care. Workarounds don't address the default experience of writing idiomatic C#.
I blame Unity's GC for what it is bad at. It's both stop-the-world and non-generational. As I said down-thread, it's a lot of work to design for avoiding allocations. Even then, Unity will still GC from time to time, and whether it matters will depend on the characteristics of your game's managed heap as a whole. This is the major stumbling block most times people argue with me about how GC is fine. Your data is like your data, because your app is your app. It's not like my data. The next step is not to use the managed heap for anything that isn't a temporary. Again, quite a bit of work. And the beginners and intermediates who are most of Unity's users aren't going to do it. Hell, in general I consider GC a non-starter for games, but sometimes I want to work at a company that uses C#. So I repeat:
> Workarounds exist. That's great. I don't care. Workarounds don't address the default experience of writing idiomatic C#.
Blaming the GC for poor memory performance isn't the issue.
I still wouldn't call that a workaround but rather properly using memory in the first place; you'll get GC pressure even on a concurrent generational GC if you constantly push garbage down its throat. You'll get slowdowns even on reference counting if you naively assume it to be faster than a GC then blindly pass references all over the place causing tons of increments/decrements on the refcount; trashing caches in the process and causing tons of branch mispredictions.
I've worked on a LOT of radically different games; I don't believe the specific game, genre, engine or language changes how you manage memory, at all. I don't even believe its more work when you account for all the debugging and profiling time you save by the end of the project; a data-driven approach is almost always simpler. Heck Unity is even moving towards a new Entity-Component-System that explicitly relies on the user managing their memory (and in batches too!), with massive performance gains, same for the Job system currently in the 2018.1 beta. We're talking gains of orders of magnitude in performance, not the tiny ~10% gains you'd get profiling and micro-optimizing at the end of a project.
Beginners and intermediates don't manage memory on large scale Unity projects, and memory management isn't nearly as important on smaller ones; they can waste 80% of hardware resources and still hit 60FPS, computers are that fast. So I don't think that's a valid point. Also saying my data is different than your data may be true, but that has no impact on how memory management works whatsoever. Just like you don't stop using SQL because a different app has different relations.
Its almost impossible to get any kind of performance without accounting for memory allocations and layouts, no matter the engine/language you pick. You're bound to waste 90% of the hardware while being left profiling within the remaining 10% from the very second you stop thinking about memory. I really dont get this "again, quite a bit of work" you mention; idiomatic C# is literally more work than data-driven C# at a fraction of its performance and simplicity.
I've seen death by a thousand cuts "we enter crunch mode for months because the game is dog slow before shipping because nobody cared about architecture for 10+ months" kill many game projects; they all had fancy idiomatic code, everything looked good in the profiler yet the problems were systematic. Its pretty much being Agile without having any actual agility.
So I repeat: blaming the GC for poor memory performance isn't the issue. I'll bet I find tons of complexity issues long, long before I see GC issues in any codebase; that's the real issue. Its not that the GC is one huge slowdown, its that the codebase is littered with tiny slowdowns all over the place, so tiny they're effectively invisible to the profiler, yet their sum is still greater than that of the GC.
I still wouldn't call that a workaround but rather properly using memory in the first place; you'll get GC pressure even on a concurrent generational GC if you constantly push garbage down its throat. You'll get slowdowns even on reference counting if you naively assume it to be faster than a GC then blindly pass references all over the place causing tons of increments/decrements on the refcount; trashing caches in the process and causing tons of branch mispredictions.
I've worked on a LOT of radically different games; I don't believe the specific game, genre, engine or language changes how you manage memory, at all. I don't even believe its more work when you account for all the debugging and profiling time you save by the end of the project; a data-driven approach is almost always simpler. Heck Unity is even moving towards a new Entity-Component-System that explicitly relies on the user managing their memory (and in batches too!), with massive performance gains, same for the Job system currently in the 2018.1 beta. We're talking gains of orders of magnitude in performance, not the tiny ~10% gains you'd get profiling and micro-optimizing at the end of a project.
Beginners and intermediates don't manage memory on large scale Unity projects, and memory management isn't nearly as important on smaller ones; they can waste 80% of hardware resources and still hit 60FPS, computers are that fast. So I don't think that's a valid point. Also saying my data is different than your data may be true, but that has no impact on how memory management works whatsoever. Just like you don't stop using SQL because a different app has different relations.
Its almost impossible to get any kind of performance without accounting for memory allocations and layouts, no matter the engine/language you pick. You're bound to waste 90% of the hardware while being left profiling within the remaining 10% from the very second you stop thinking about memory. I really dont get this "again, quite a bit of work" you mention; idiomatic C# is literally more work than data-driven C# at a fraction of its performance and simplicity.
I've seen death by a thousand cuts "we enter crunch mode for months because the game is dog slow before shipping because nobody cared about architecture for 10+ months" kill many game projects; they all had fancy idiomatic code, everything looked good in the profiler yet the problems were systematic. Its pretty much being Agile without having any actual agility.
So I repeat: blaming the GC for poor memory performance isn't the issue. I'll bet I find tons of complexity issues long, long before I see GC issues in any codebase; that's the real issue. Its not that the GC is one huge slowdown, its that the codebase is littered with tiny slowdowns all over the place, so tiny they're effectively invisible to the profiler, yet their sum is still greater than that of the GC.
Dude, you are being extremely arrogant here, like what you've seen and what you know are universals. I've already violated my own policy of never arguing with other people about GC in games, so serves me right. Peace out.
Sure!
Hopefully a more experienced Godot dev will jump in and correct me if I'm wrong here..
Godot uses reference counting, but additionally supports a function which you can call on an object which will cause it to become 'unmanaged' by the reference counter, allowing you to free its memory on your own terms (or leak the memory, if you're not careful).
Godot 3.0 added support for Mono, but I'm not sure how that works. I'm guessing that game objects in Godot are still reference counted, but now you also have memory allocated by the Mono runtime which will be garbage collected.
Hopefully a more experienced Godot dev will jump in and correct me if I'm wrong here..
Godot uses reference counting, but additionally supports a function which you can call on an object which will cause it to become 'unmanaged' by the reference counter, allowing you to free its memory on your own terms (or leak the memory, if you're not careful).
Godot 3.0 added support for Mono, but I'm not sure how that works. I'm guessing that game objects in Godot are still reference counted, but now you also have memory allocated by the Mono runtime which will be garbage collected.
Ironically, no amount of care towards memory management could approach even one tenth of the care and attention I'm required to devote to memory management in Unity (and, FWIW, also in actual Windows .NET) to avoid frequent dropped frames. This is exactly what I was hoping to hear, thanks!
Yep, I abandoned Unity after encountering the same issues as you. My experience is that every Unity GC run takes 10+ ms on my machine, even when there is no memory to clean up.
I tried MonoGame once and the results were much better--garbage collection was fast when there wasn't much to do. However, I'd still choose a non-garbage-collected engine any day because I dislike lag spikes.
I tried MonoGame once and the results were much better--garbage collection was fast when there wasn't much to do. However, I'd still choose a non-garbage-collected engine any day because I dislike lag spikes.
While I hear generally about garbage collection causing dropped frames. I've had this happen to me in HTML5 land. I haven't heard about it as much with Unity, that C# was fast enough, and the under the hood pieces are C++ anyways. Perhaps I'm reading the wrong channels :). I'm curious if your game project is 3D, and what sort of intensity you tend to have with it.
It depends entirely on the details that affect the GC. The biggest factors are the size and structure of your heap data. If the game uses a lot of memory, the GC will try to collect more often. If the heap data is large and graph-like (lots of refs to refs), it takes longer to walk.
From: http://docs.godotengine.org/en/3.0/getting_started/scripting...
' Memory management
If a class inherits from Reference, then instances will be freed when no longer in use. No garbage collector exists, just simple reference counting. By default, all classes that don’t define inheritance extend Reference. If this is not desired, then a class must inherit Object manually and must call instance.free(). To avoid reference cycles that can’t be freed, a weakref function is provided for creating weak references. '
' Memory management
If a class inherits from Reference, then instances will be freed when no longer in use. No garbage collector exists, just simple reference counting. By default, all classes that don’t define inheritance extend Reference. If this is not desired, then a class must inherit Object manually and must call instance.free(). To avoid reference cycles that can’t be freed, a weakref function is provided for creating weak references. '
Reference counting is a form of garbage collection. And depending on your usage patterns it might not even be the fastest one.
Lots of increments/decrements on the refcount interleaved in normal code can kill the gains over a traditional GC that has nearly free allocation, batched finalizations and doesn't pollute the instruction stream with increments/decrements.
Also with a traditional GC you pay nothing if you don't allocate memory; the collector will never run. You still pay the full price of reference counting no matter if you're done allocating or not.
Lots of increments/decrements on the refcount interleaved in normal code can kill the gains over a traditional GC that has nearly free allocation, batched finalizations and doesn't pollute the instruction stream with increments/decrements.
Also with a traditional GC you pay nothing if you don't allocate memory; the collector will never run. You still pay the full price of reference counting no matter if you're done allocating or not.
Unreal doesn't have GC as far as I know. Everything is built on C++ objects. There's some reference counting here and there, but I've not yet run into problems with it.
https://docs.unrealengine.com/en-us/Programming/UnrealArchit...
I know very little about it, but in general there's a lot more information in the docs about the Garbage Collector than there is about how to not use it.
I know very little about it, but in general there's a lot more information in the docs about the Garbage Collector than there is about how to not use it.
Unreal does use GC and it is the stop the world variety, yet unlike unity the GC has never even showed up for us as a problem. I cannot tell you why or how but Unreal just handles GC better than Unity. I am speaking from my experience of shipping a commercial game on console with Unreal. Maybe things are worse on mobile.
TIL (thanks for the correction!) I guess they do this to break reference loops. The difference I guess is that it only applies to UObject derived things, which are higher level objects, rather than across your entire codebase. I’ve never seen GC take up processor time, but our project doesn’t have a lot of runtime churn of objects.
You still run with the same naive and expensive boehm garbage collection sweeper that Unity has always had (since 2005?). The machinations some Unity developers go through to avoid allocating memory and inadvertently triggering a sweep are worse than the old days of just managing your own memory manually in C and C++.
Why they have never hired a team to simply create a reference counting fork of their object system is beyond me. Their GC is the reason Unity games have a reputation for running with inconsistent choppy frame rates. You'd think fixing that would be top priority.
But they have never committed publicly to a timeline to fix it, and it is a glaring weakpoint in their runtime environment. Possibly worse than any other, besides the insane and broken way they designed their "prefab" concept. Those 2 flaws have led me to call Unity the "Javascript of Game Engines" in the past. It's not quite that bad, but it's close.
Why they have never hired a team to simply create a reference counting fork of their object system is beyond me. Their GC is the reason Unity games have a reputation for running with inconsistent choppy frame rates. You'd think fixing that would be top priority.
But they have never committed publicly to a timeline to fix it, and it is a glaring weakpoint in their runtime environment. Possibly worse than any other, besides the insane and broken way they designed their "prefab" concept. Those 2 flaws have led me to call Unity the "Javascript of Game Engines" in the past. It's not quite that bad, but it's close.
Curious to hear your critique of prefabs.
Unlike any reasonable nested entity tree system, you cannot have a prefab that contains other prefabs in its hierarchy, or they lose all concept of being independent prefabs themselves.
Say you design a car prefab and a wheel prefab. If you put 4 wheel prefabs in your car prefab, and then update the wheel prefab, it will not be reflected in the wheels to your car, because you can not have nested prefabs.
Neither will any other set of prefabs — say, the tires on your wheels, or the seats in your car — without going to ludicrous workarounds.
Think about it like a programming language. Imagine if you had a class, and you wanted to include an object of another class in it, but instead of including a reference to that object, your IDE just pasted the entire contents of its class implementation verbabitm into your class, once, and left it like that.
That is how they designed it and that is how it has been, to the frustration of all, for over 13 years. Everyone has to design around this bizarre limitation that isn't present in any other (even simple) game engine. They've promised to fix this before, but haven't.
Now do you understand?
Unity is filled with weird kludges like this, that aren't apparent when you are just starting, in basic systems and critical corners, which is why so many are frustrated with it, despite its strengths in platform ubiquity and market adoption.
Say you design a car prefab and a wheel prefab. If you put 4 wheel prefabs in your car prefab, and then update the wheel prefab, it will not be reflected in the wheels to your car, because you can not have nested prefabs.
Neither will any other set of prefabs — say, the tires on your wheels, or the seats in your car — without going to ludicrous workarounds.
Think about it like a programming language. Imagine if you had a class, and you wanted to include an object of another class in it, but instead of including a reference to that object, your IDE just pasted the entire contents of its class implementation verbabitm into your class, once, and left it like that.
That is how they designed it and that is how it has been, to the frustration of all, for over 13 years. Everyone has to design around this bizarre limitation that isn't present in any other (even simple) game engine. They've promised to fix this before, but haven't.
Now do you understand?
Unity is filled with weird kludges like this, that aren't apparent when you are just starting, in basic systems and critical corners, which is why so many are frustrated with it, despite its strengths in platform ubiquity and market adoption.
FWIW, they've announced nested prefab support in Unity 2018.3 (https://blogs.unity3d.com/2018/03/20/unity-unveils-2018-road...). It's mind-boggling that it has taken so many years to implement such a simple thing.
They've also announced it before at previous keynotes, only to abandon it. They had me convinced enough to tweet this, in 2014.
> Unity's only achilles in this is the stupid nested prefabs handicap, but hopefully we won't have to live with that much longer
https://twitter.com/Doomlaser/status/550129905028300800
Fool me once. Let's see what they ship. :)
> Unity's only achilles in this is the stupid nested prefabs handicap, but hopefully we won't have to live with that much longer
https://twitter.com/Doomlaser/status/550129905028300800
Fool me once. Let's see what they ship. :)
>announced
Soon™.
Soon™.
> It's mind-boggling that it has taken so many years to implement such a simple thing.
Something "looking" simple from a distance and actually being simple when you code it are two different things. Also its not like that was the only feature they had in the backlog to work on.
Its mind-boggling that people don't realize how much work actually goes in writing a game engine.
Something "looking" simple from a distance and actually being simple when you code it are two different things. Also its not like that was the only feature they had in the backlog to work on.
Its mind-boggling that people don't realize how much work actually goes in writing a game engine.
Yeah, that makes sense.
I remember when I first learned I couldn't nest prefabs, and I couldn't believe it. Here's hoping they actually fix it.
Besides that, I think the Unity prefab system is really nice, and Unity in general seems very nice.
But I may lack context! I'm coming up on two years using it, and it's my first time working with a game engine (or in games).
Still, it seems much nicer than interface builder or qt designer.
I remember when I first learned I couldn't nest prefabs, and I couldn't believe it. Here's hoping they actually fix it.
Besides that, I think the Unity prefab system is really nice, and Unity in general seems very nice.
But I may lack context! I'm coming up on two years using it, and it's my first time working with a game engine (or in games).
Still, it seems much nicer than interface builder or qt designer.
I just tried to upgrade my project to 4.6 in Unity a few hours ago (using the 2018.1 beta). I ended up having to switch back because of build errors. For anyone who is interested in upgrading to 4.6: I suggest waiting until later in the 2018 release cycle so that all the kinks can be worked out.
I also encountered problems upon the first upgrade. But it was easy to fix after doing some googling. On Windows, you need to make sure you install the correct .Net Targeting Pack.
Do you use any external C# dlls? I use NewtonSoft's Json.NET, MessagePack, ShaderForge and a few C/C++ dlls. I think it should be pretty straightforward for simple projects without any of these dependencies. I've had good luck with upgrading to newer versions of Unity in the past, but this time I got a ton of errors.
It took a bit of work, but I got 4.6 working with Json.NET and a few other external dlls.
Unity is a bottomfeeding company in so many ways. If they were more upfront about prioritizing phone-apps and low-fi projects, it would be acceptable. But instead, their business plan appears to be:
1. Rope in beginners with network effect, asset store, popular fear of C++.
2. Promote as many new features as possible, with only the most minimal discretion of whether the features actually work or help, anybody because once their demographic notices the ploy, they are too invested to leave. Ideally, they will build a few products for the asset store to make up for the dismal investment.
3. Throw enough dirt and some of it will stick. Mass promotion to beginners gives them enough sign-ups to keep going. Interesting how the pricing model means beginners can’t view the unpredictable performance issues until they start paying.
They consistently fail to prioritize the problems with memory management, lightmapping, and material standards that plague serious Unity devs. I have switched to using Unreal and it’s like night and day. I am super interested in Godot.
1. Rope in beginners with network effect, asset store, popular fear of C++.
2. Promote as many new features as possible, with only the most minimal discretion of whether the features actually work or help, anybody because once their demographic notices the ploy, they are too invested to leave. Ideally, they will build a few products for the asset store to make up for the dismal investment.
3. Throw enough dirt and some of it will stick. Mass promotion to beginners gives them enough sign-ups to keep going. Interesting how the pricing model means beginners can’t view the unpredictable performance issues until they start paying.
They consistently fail to prioritize the problems with memory management, lightmapping, and material standards that plague serious Unity devs. I have switched to using Unreal and it’s like night and day. I am super interested in Godot.
Given the love they get from companies like Nintendo, Google and Microsoft, it seems to work quite well.
Loving Godot so far. I'd tried many an engine to get into gaming. With Godot, i felt the least resistance.
My kid who's in high school watched a few Godot tutorials on Youtube and then created a nice/simple game in about 24 hours.
We walked me through the whole process and it is amazing the whole system is free.
We walked me through the whole process and it is amazing the whole system is free.
> it is amazing the whole system is free
Speaking of which, they have a Patreon. Anyone interested in the prospect of contributing financially to the development of Godot, check out https://www.patreon.com/godotengine
Speaking of which, they have a Patreon. Anyone interested in the prospect of contributing financially to the development of Godot, check out https://www.patreon.com/godotengine
Here is my personal opinion about Godot vs Unity.
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
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
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?
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.
Hope that makes sense.
[1] GDNative Architecture https://godotengine.org/article/look-gdnative-architecture
[2] Main GDNative Language Bindings https://github.com/GodotNativeTools
[3] Python via GDNative https://github.com/touilleMan/godot-python
[4] Nim via GDNative https://github.com/pragmagic/godot-nim
[5] GDNative C++ API Sample https://github.com/GodotNativeTools/godot-cpp#creating-simpl...
[6] C example of GDNative (Godot Docs) http://docs.godotengine.org/en/3.0/tutorials/plugins/gdnativ...
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.
Hope that makes sense.
[1] GDNative Architecture https://godotengine.org/article/look-gdnative-architecture
[2] Main GDNative Language Bindings https://github.com/GodotNativeTools
[3] Python via GDNative https://github.com/touilleMan/godot-python
[4] Nim via GDNative https://github.com/pragmagic/godot-nim
[5] GDNative C++ API Sample https://github.com/GodotNativeTools/godot-cpp#creating-simpl...
[6] C example of GDNative (Godot Docs) http://docs.godotengine.org/en/3.0/tutorials/plugins/gdnativ...
I wonder if one could couple it to Swift.
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.
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.
> Unity has second class Linux (editor) support.
Still better than Unreal’s Linux support. :/
Still better than Unreal’s Linux support. :/
Thanks for such a detailed comparison--I think I'll give Godot a try!
Thanks for this really nice comparison!
What about Cocos2d-x?
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 :)
[1] Cocos2D-x desktop game "Songbringer" http://store.steampowered.com/app/367080/Songbringer/
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 :)
[1] Cocos2D-x desktop game "Songbringer" http://store.steampowered.com/app/367080/Songbringer/
I love Godot right now. I have made a ton of progress on my game in the last two months using it. Highly recommend it to anyone wanting to pick up game dev as a hobby.
I started using Godot recently. Do you have any good tutorials to recommend?
SimulaVR (Linux VR Desktop written in Haskell) is currently in the process of integrating Godot into its rendering loop.
In order to do that we've been making Haskell FFI bindings for the Godot API. If anyone's interested check out: https://GitHub.com/SimulaVR/Simula
In order to do that we've been making Haskell FFI bindings for the Godot API. If anyone's interested check out: https://GitHub.com/SimulaVR/Simula
Are the Haskell godot bindings in a usable state? Very interested
They're not in a usable state yet but will most likely be by the end of the month. They are being generated in one shot via Template Haskell, and will be located here: https://github.com/SimulaVR/godot-haskell
Drop by https://gitter.im/SimulaVR/Simula to discuss this at any point. There are some other Godot people involved in this project as well if you have any questions.
Drop by https://gitter.im/SimulaVR/Simula to discuss this at any point. There are some other Godot people involved in this project as well if you have any questions.
I'm keen to try Godot.
The only thing I'd like to see soon or at least on the roadmap is Switch support. Other open source toolkits, like Monogame, have included it. I believe Love2D also supports it now, or at least has a partner that will build projects for it.
The only thing I'd like to see soon or at least on the roadmap is Switch support. Other open source toolkits, like Monogame, have included it. I believe Love2D also supports it now, or at least has a partner that will build projects for it.
According to the Godot docs[1] this doesn't seem to be a priority for them, though I would also love to see Switch support.
Though in those same docs they point out a third-party which provides console ports. Not an ideal solution by any means, but it is still an option.
[1]: http://docs.godotengine.org/en/3.0/tutorials/platform/consol...
[1]: http://docs.godotengine.org/en/3.0/tutorials/platform/consol...
Mate I wouldn't really worry about Switch support. Even if you could port your game to Switch, Nintendo has a tight ironclad gate on the "indie" titles that make it in the store.
And if you're thinking homebrew, the only thing you could run your game on would be a Switch devkit.
And if you're thinking homebrew, the only thing you could run your game on would be a Switch devkit.
It's not unrealistic to worry about Switch support. You seem to be coming from the perspective of a hobbyist game developer, which is fine, but anyone running a serious game development project should at least consider the cost of potential console ports, even if it seems inaccesible to a hobbyist.
I don't think you've tried submitting a game to Nintendo like we did, for 6 months.
Does anyone have an opinion on Godot Vs Unreal Engine?
Unreal is great for graphical fidelity. It also has tons of stuff built in because of Epic's own use of the engine. Things like multiplayer support, replay recording, and mobile support are there right out of the box. Plus the engine has been widely adopted (it was used to make PUBG and Fortnite), so you have an active community of amateur and professional game devs who can help you.
While Godot has been adopted by some studios, most stick to their own engines or use Unreal/Unity due to the lack of some of these features (or just a lack of adopters in general, which becomes a chicken-and-egg problem).
However, I'd love for Godot to become as full-featured as Unreal. These are exciting times that we live in.
Edit: Actually Godot also has multiplayer support out of the box in 3.0! It’s getting close in terms of features.
While Godot has been adopted by some studios, most stick to their own engines or use Unreal/Unity due to the lack of some of these features (or just a lack of adopters in general, which becomes a chicken-and-egg problem).
However, I'd love for Godot to become as full-featured as Unreal. These are exciting times that we live in.
Edit: Actually Godot also has multiplayer support out of the box in 3.0! It’s getting close in terms of features.
I don't think graphical fidelity is a good argument for any engine today. People are making movies with Unity[1] and Godot has demonstrated[2] all the bells and whistles you could want at least if you intend to target consumer PCs that exist today.
[1] https://www.youtube.com/watch?v=GXI0l3yqBrA [2] https://www.youtube.com/watch?v=XptlVErsL-o
At least for anyone developing a video game right now, unless you know of specific rendering techniques you need that Unreal has that the others don't, there is nothing you can really come up with that one can do the others cannot.
That being said, I'd imagine in a benchmark of GDNative vs Unity vs Unreal Unreal would probably win, Epic has way more than enough cashflow to throw tons of engineers on optimization that Godot just doesn't have. It wouldn't be an orders of magnitude difference, though - we are talking optimization of already tight render loops, and Godot benefits highly from having a tiny renderer.
[1] https://www.youtube.com/watch?v=GXI0l3yqBrA [2] https://www.youtube.com/watch?v=XptlVErsL-o
At least for anyone developing a video game right now, unless you know of specific rendering techniques you need that Unreal has that the others don't, there is nothing you can really come up with that one can do the others cannot.
That being said, I'd imagine in a benchmark of GDNative vs Unity vs Unreal Unreal would probably win, Epic has way more than enough cashflow to throw tons of engineers on optimization that Godot just doesn't have. It wouldn't be an orders of magnitude difference, though - we are talking optimization of already tight render loops, and Godot benefits highly from having a tiny renderer.
I'm working full time in unity, but the game is 2d and I don't have much reason to learn about 3d rendering. I'd love to at some point...
From my perspective, and probably many other amateur game developers who are making all three engines popular, I think the big difference may just be that ue3 comes out of the box with a bunch of random postprocessing things turned on. The base ue3 scene looks amazing, with lots of interesting materials and textures, whereas the base unity scene is completely empty space with an ugly blue-grey gradient horizon (which I've seen unchanged many times in game jams and indie game competitions). Regardless of potential, most indie devs similar to me don't care enough to make their indie games look good because they're busy making them fun.
From my perspective, and probably many other amateur game developers who are making all three engines popular, I think the big difference may just be that ue3 comes out of the box with a bunch of random postprocessing things turned on. The base ue3 scene looks amazing, with lots of interesting materials and textures, whereas the base unity scene is completely empty space with an ugly blue-grey gradient horizon (which I've seen unchanged many times in game jams and indie game competitions). Regardless of potential, most indie devs similar to me don't care enough to make their indie games look good because they're busy making them fun.
> These are exciting times that we live in.
The OGRE 3D engine has been around for almost two decades [1]
Unfortunately, all the tooling is built by the community (with varying degrees of quality), which means, for example, no integrated scene editor.
1. http://wiki.ogre3d.org/Brief+history+of+OGRE
The OGRE 3D engine has been around for almost two decades [1]
Unfortunately, all the tooling is built by the community (with varying degrees of quality), which means, for example, no integrated scene editor.
1. http://wiki.ogre3d.org/Brief+history+of+OGRE
Unreal is ahead on some of their 3D capabilities—Godot only targets OpenGL ES 3, at the moment. However, this affords Godot a huge number of target platforms on the same codebase and, in a huge turn, now that MoltenVK is being open sourced by Valve, Godot is moving its render API to Vulkan.
If you want to play with all the bells and whistles now, Unreal currently let’s you use a more advanced graphical pipeline; if you want to multi-platform your game or you won’t be releasing a shader-heavy 3D game in the next year, I would at least try Godot.
If you want to play with all the bells and whistles now, Unreal currently let’s you use a more advanced graphical pipeline; if you want to multi-platform your game or you won’t be releasing a shader-heavy 3D game in the next year, I would at least try Godot.
Unreal Engine is a paid engine with highly developed, opinionated engineering in many subsystems. (visual blueprint scripting, unified material render engine, actor model) Its featureset is advanced enough to support AAA games.
Godot is a free engine offering a C# scripting environment.
Godot is a free engine offering a C# scripting environment.
Actually, Godot offers visual scripting, C# scripting, Python-like scripting, and C++ scripting by default.
More options are available through their GDNative bindings (D, Nim, Golang, etc.)
More options are available through their GDNative bindings (D, Nim, Golang, etc.)
> Python-like scripting
GDScript is nothing like python.
GDScript is nothing like python.
That’s interesting, the features page claims it is similar to Python: https://godotengine.org/features
Documentation[1] is more specific.
> It uses a syntax similar to Python (blocks are indent-based and many keywords are similar).
The following example shows that many keywords are different and the syntax is different as well. Not to mention the rest of the language (standard library which is given when talking about python and things like iterators/iterables/decoratos/comprehension/... If indent-based blocks are all it takes for you to call two languages similar, then I guess they are.
1. https://godot.readthedocs.io/en/3.0/getting_started/scriptin...
> It uses a syntax similar to Python (blocks are indent-based and many keywords are similar).
The following example shows that many keywords are different and the syntax is different as well. Not to mention the rest of the language (standard library which is given when talking about python and things like iterators/iterables/decoratos/comprehension/... If indent-based blocks are all it takes for you to call two languages similar, then I guess they are.
1. https://godot.readthedocs.io/en/3.0/getting_started/scriptin...
Syntax is somewhere between Python and JS, but simpler than both. Almost looks like pseudo-code.
I think the Python comparison is made because of significant whitespace, easy to understand syntax (control structures similar to Python from what I remember), and that was their inspiration. It's easier and simpler than Python though.
I think the Python comparison is made because of significant whitespace, easy to understand syntax (control structures similar to Python from what I remember), and that was their inspiration. It's easier and simpler than Python though.
There is also support for Python via GDNative: https://godotengine.org/article/beta-release-python-support
Is this a good engine to begin game programming with? I am an experienced web developer with deep interest in interactive stuff.
Yes, absolutely. Probably by far the optimization between being able to do anything you want while being dead simple to do it in. "Easier" engines like rpgmaker or LOVE severely limit what you can accomplish with the game, while more established engines like UE and Unity have a lot more front loaded scaffolding to do.
> more established engines like UE and Unity have a lot more front loaded scaffolding to do.
This, in my opinion, is Godot's biggest advantage. UE and Unity are a lot for a new user to contend with.
This, in my opinion, is Godot's biggest advantage. UE and Unity are a lot for a new user to contend with.
Löve has only one limit - it's 2D. Other than that, you can use build anything you want, in simple and cross-platform way. Löve is easy in terms of API size and tooling, but it's more low-level than other engines and therefore aimed at developers that like to build their own tools along the way. It feels very liberating and productive, plus you are not stuck with sub-par editors (unless you make them such).
Awesome! I have played with godot before, and while it has some sharp edges I am thrilled to see an opensource engine coming together so well. Great job to all involved!
Been following Godot for a good while but never tried it myself. I support them on Patreon anyway though, just because I think it's important that we have a truly open source game engine like Godot :) Did you try Godot 3.0 yet?
Looks great! I've heard of Godot quite a bit and have been meaning to check it out.
Boy do I feel like a dummy though... I thought it was "Go"dot and it was built with and/or uses Go(lang). Can't say I wasn't just a tiny bit disappointed!
In any case, I just checked out some of the videos and the IDE in particular looks pretty amazing. Will check it out for sure.
Boy do I feel like a dummy though... I thought it was "Go"dot and it was built with and/or uses Go(lang). Can't say I wasn't just a tiny bit disappointed!
In any case, I just checked out some of the videos and the IDE in particular looks pretty amazing. Will check it out for sure.
You can actually use Golang with Godot to code gameplay using some open source bindings[1] for GDNative.
[1]: https://github.com/ShadowApex/godot-go
[1]: https://github.com/ShadowApex/godot-go
Not being tied to "Go"lang is the reason I am interested in it.
Any good tutorials to learn this ? I want to make an outrun like game but no experience in this area
Here are a few YouTube channels with tutorials:
https://www.youtube.com/channel/UCNaPQ5uLX5iIEHUCLmfAgKg/pla...
https://www.youtube.com/channel/UCxboW7x0jZqFdvMdCFKTMsQ/pla...
https://www.youtube.com/channel/UChv-gaPlKNROf6iMDhxIpUA/pla... (Godot 2 videos but good)
You can also find more links here: https://godot-engine.zeef.com/andre.antonio.schmitz
https://www.youtube.com/channel/UCNaPQ5uLX5iIEHUCLmfAgKg/pla...
https://www.youtube.com/channel/UCxboW7x0jZqFdvMdCFKTMsQ/pla...
https://www.youtube.com/channel/UChv-gaPlKNROf6iMDhxIpUA/pla... (Godot 2 videos but good)
You can also find more links here: https://godot-engine.zeef.com/andre.antonio.schmitz
I'm really excited about Godot. I started using it and saw the limits of the 3d stuff that is there right now but I'm excited to start using it when really good 3d animation libraries become available which seem to be lacking at the moment.
I first discovered Godot when working on an ambitious game. While my ambitions have tempered, my stance on Godot hasn't. It's been a great product to turn out 2D games on, and I am looking forward to trying out some 3D projects with the v3 Renderer. It's not going to replace Unity or Unreal for any ambitious AAA-level title, but it can't be overlooked for rapid prototyping or 2D games.
Godot is also the first project I've ever given Patreon funding for.
Godot is also the first project I've ever given Patreon funding for.
I read most of that press release with no idea if Godot was a real thing or if it was an eloborate riff on Waiting for Godot
It took clicking around their site a bit to realize it's actually a real thing. I think.
It took clicking around their site a bit to realize it's actually a real thing. I think.
re: "The Gambling Industry is Largely Moving to Godot."
I don't know, seems like the author should have at least mixed feelings about this? It can't be prevented with an MIT license, but it doesn't seem like great news?
I don't know, seems like the author should have at least mixed feelings about this? It can't be prevented with an MIT license, but it doesn't seem like great news?
What is your objection[1]? If companies in that industry are contributing directly to funding development or hiring developers it's positive for the engine and for the rest of the community who get it on the same license terms. Look at how Bet365 (iirc) has kept Riak and some other bits of the Erlang ecosystem going.
[1] Conceding that some minority of people find gambling addictive and they are the customers the game makers tailor their product for.
[1] Conceding that some minority of people find gambling addictive and they are the customers the game makers tailor their product for.
It's exactly what you conceded in [1].
If I found out that that open source software I'm working on is ending up in slot machines, I wouldn't feel great about it, even if there's not really anything to be done about it. It just seemed like an odd thing to brag about.
If I found out that that open source software I'm working on is ending up in slot machines, I wouldn't feel great about it, even if there's not really anything to be done about it. It just seemed like an odd thing to brag about.
Probably one should be equally uneasy about one's OSS contributions ending up in F2P games too, since they are often highly addictive time- and money-sinks.
I'm surprised gambling needs 3D at all…
related: AMD is making embedded products for gambling now (look at their YouTube channel)
related: AMD is making embedded products for gambling now (look at their YouTube channel)
They have very flashy, AAA-style graphics now. Check out Konami's pivot:
https://www.casino-review.co/wp-content/uploads/2016/08/CR16...
https://www.casino-review.co/wp-content/uploads/2016/08/CR16...
One of the reasons is that Godot has a dedicated 2D engine with pixel units etc.
Also don't forget, they've got the latest of Mono available to you, so modern C# features at your fingertips, no more C# 3.5 like a certain industry slowpoke...