If Unreal got proper scripting language support, I'd seriously consider giving it another go. I'd rather they go the Unity approach than the Godot approach and use a real-world language (C# is used outside Unity of course, GDScript is only used in Godot, though it does have bindings), but I'll take what I can get, clearly as I use Godot rather than Unity.
As it stands, picking up blueprints feels like I have to learn a whole new system which will go to waste if I decide not to stick with Unreal, and C++ seems like it'd be a pain to work with.
Edit: Forgot Godot had C# support. It still doesn't feel as "first-class" as GDScript, but its certainly more closely integrated than bindings, so maybe something to consider. Also, whilst I generally prefer a single language being tied to a single tool (trying to learn Raylib taught me this, where every example you find is in a different language), its nice knowing I can use C# without being locked into Microsoft
Unreal has dropped their scripting language for a visual alternative called Blueprints. It is possible to make an entire game with it not writing any C++ and is possible to make one completely in C++. The best is of course using them together. And exactly the same applies to Godot. Just swap Blueprints for GDScript a Python-like scripting language. In a final note Unity, has dropped JavaScript. Though C++ can somehow be used, C# is indeed more or less Unity's language.
While looking into new engines recently I bailed on Unreal because all the docs and tutorials push towards Blueprint. I'd happily use C++ over Blueprint but everything is pushing Blueprint hard to the point I just moved on. Been looking at Godot lately and I really like it and if I need something more than GDScript provides there are bindings to GDNative. I think for some people Visual scripting is probably nice but for me it's an inscrutable mess of flow charts that's way more difficult to use, debug, build understanding of quickly, etc.
Having used Unreal for years in the past (UE4 only), I agree with you that C# would definitely win over the C++/Blueprint combo.
Over the years, especially since blueprints compile down to C++, I've learnt to let go and embrace a lot more this visual programming approach. And it does have its benefits. With a strict approach, just as you would in programming paradigm, the readability and 'visual scanning' of opening old code in blueprints really stands out. You instantly feel where everything is, much faster than scrolling up and down code, navigating to/from methods.
I've had experimented with Unity but I found at the time that UE4 was the way for me. At the time I was even working with some guys promoting UnrealJS or something, can't remember the name now, which was bringing JS to Unreal, but it sort of faded as it takes a monumental effort to bring another language to such platform. Ultimately, blueprints are fine, and I'm only using C++ for A* path finding or other heavy algo where math functions are the main focus. You can also make a library of C++ heavy math'ish things and expose them to blueprint. Overall It's pretty ok.
One aspect that is not talked about much is the weight of it all. UE4 was huge. Recompiling the engine was a 3-4 hours business. When I switched to Godot for lighter games, the whole thing was rebuilt in 5-10 mins.
Unreal is the worst here because their C++ API documentation is unusable, and all their official, fleshed out docs are for a visual node-based scripting system called blueprints. Those blueprints seem to be their main focus and I just hate programming via click and drag.
In unity/Godot, at least you can still write a program mostly in code
It seems like one of the primary reasons why Blueprints are well-loved in Unreal Engine, is that the only mainstream alternative is full-on c++ (and it's not an easy c++ codebase to work with).
But without that pressure of limited choice, blueprint visual scripting seems to have a hard time gaining ground in godot.
I do wonder how much of this is because godot's visual scripting never got the polish it needed, and how much is because gdscript is a superior approach.
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?
C# support is pretty great at this point. There are some awkward parts, but overall I don't think you really need to use GDScript. I think GDScript was the biggest mistake Godot made, but they are making strides to make the engine accessible via a conventional language.
I am always skeptical about these type of projects. Out of the box Unreal Engine supports C++ and Blueprint.
The problem with C++ is the slow compile times, and if you make mistakes the engine crashes. In general you produce stuff slower by using C++.
Blueprint is a visual scripting tool, it compiles fast. But it stores code as a binary blob in source control. And I'm personally not a fan of visual scripting, I would prefer scripting by just writing code.
So generally I prototype in Blueprint and then rewrite in C++ later on. I would love an intermediate language that has fast compile times and saves as a source file instead of a binary blob.
The problem is most of the projects that integrate with another language get abandoned after a while. MonoUE was abandoned, USharp was abandoned, now the newest attempt to integrate UE with C# UnrealCLR looks abandoned. SkookumScript doesn't support UE5. Haxe support for UE was abandoned.
Do I really want to risk writing a ton of code in a language that might not support future engine versions? To be honest, I don't want to take that risk.
There are really good reasons to choose Unity over Godot, but C# isn't one of them. You have to learn a whole new API, framework, workflow, etc. Learning GDScript is the least of the issues.
Unreal's Blueprints handle what you need for a scripting language and then some. If you spend a few months learning C++ so that this is no longer an obstacle, then start using Unreal to do a project, you'll discover that it'll be a very long time before you actually need to use your C++ skills. It's true C++ is easier to express certain things in a smaller amount of screen real estate.
But Blueprints are pretty darn amazing. They have subclasses, inheritance, composition, interfaces, public and private variables, functions, enums, events, user-defined structs, network replication, server-only functions, broadcast functions, user interface interaction. You might say to yourself "Yes, but I have a table of 5000 datapoints in Excel I need to work with"; you can put those into a datatable and work with them just fine from Blueprints. You can use the tools to visually edit curves of data, for example for tweaking the effectiveness of some gameplay system like armor or experience or energy consumption. You can write GPU shaders in Blueprints, too, astonishingly easily.
What are your thoughts on GDScript?
The reason I ask is I do a lot of work with Python these days and I like it most of the time. So I've been curious about a high level dynamic typed language for game dev. I have played around with Unity in the past and picked Unreal for my current project this time but kinda regretting that. I'm not doing anything technically impressive so I thought blueprints would help speed things up but I'm less than impressed.
I find GDScript to be fine and very easy to pick up having never actually read a tutorial on the language. With that being said I'm more of an average programmer and I don't spend my time debating every nuance to a language so your mileage my vary. Godot does officially support C# now and there are plugins for many other languages including Python, Go, and Rust.
This is just personal opinion on my part. Godot is a wonderful project and the Godot team have done great work.
I gave up on Game Maker years ago because I realized I was pouring hours and hours into learning a language I would never be able to use anywhere else, and as much as I like Godot (and I'm really starting to like it) I feel like I'm kind of making the same mistake. Even though Godot has support for C# and third party support for other languages[0..5] I have no idea how mature such projects are, or what the long term support prospects are.
Like as not, Godot is built for GDScript, most if not nearly all tutorials assume GDScript, and any plugins you find will probably be using GDScript. You can probably assume that GDScript support is guaranteed for the future, and at best, C# support is probably guaranteed for the forseeable future, though not necessarily at parity with GDScript, version to version.
Oh, and it also apparently Godot has its own shader language so forget about using GLSL as well, probably.
As far as the language itself goes, GDScript has significant whitespace, and I don't like significant whitespace. Its idioms tend to be just unfamiliar enough to me that I keep forgetting things that would be obvious in another language. I really wish it had lambdas.
BUT... it's still a capable language and obviously it does what it says on the tin. I guess you can stick with C# or wait until one of the other language projects matures, or just bite the bullet and use GDScript. The framework itself is so much easier to deal with than Unity IMHO, and for 2D I think it's worth the frustration. All of my issues with the language, thus far, are relatively minor and entirely subjective.
I had this opinion when I first began working with Godot, which regardless of language I've just found incredibly intuitive.
I used C#, but kept getting frustrated cause the support isn't at 100% (this is currently expected, I think C# is still declared alpha?). It was pretty easy to fill in the gaps between gdscript documentation vs C#, but certain built in functionality was missing.
My main use case for C# was strong typing, and the community support it has either with libraries or just getting answers online.
Eventually I caved in and tried gdscript. I can develop MUCH faster, and am still able to use types. You can also still use C# in the project, since the languages can communicate.
I think once C# has feature parity with Godot I'll move back to that, but until then, GDscript is great, and really easy to pick up.
Agreed, having C# be the default would also better incentivize former Unity devs to jump ship. Not to mention that learning C# has value outside of Godot, whereas GDScript is not exactly transferable knowledge.
> Programming in C++ is well supported though. This is the main reason I personally would not use C# in Godot much. It is really good general purpose language that will do fine in almost any situation but it will not excel as much on performance critical stuff like C++ does but also does not have the ease of use for quick scripting like GDScript.
This is an excellent point, though it also brings the complexity of C++ as a language to light as well. That's why many use Blueprints in Unreal Engine, just so they wouldn't deal with a powerful language like C++ that has lots of footguns, despite its libraries, interop and other capabilities. So much so, that they tried getting C# support into the engine (as well as a few others over the years).
In a sense, it's a spectrum, with something like C++ on one end, C# somewhere in the middle (reasonably performant and capable, but also with relatively few footguns) and GDScript on the other end, even though the library support isn't as good as, say, Python. Hence, if you need bunches of fancy functionality, you'll probably need to choose between either C++ or C#, not having access to the latter complicating things.
> Can you, though? Writing a CRUD app in C# is quite different to writing C# in Unity which is different to C# in Godot.
The concerns are a bit different, especially when you're racing against the render loop, but I'd argue that it's not all that dissimilar, be it in regards to C# in specific engines or different types of applications.
Personally, with a few key differences in mind, there isn't that much difference between developing local CRUD apps, doing web development, or even game development - those key differences in the case of game development being more focus on linear algebra and performance, and utilizing other abstractions (for example the whole scene graph concept and traversing it, which honestly is not that dissimilar from something like Pinia stores, which might be an interesting comparison).
Between different engines, you have the whole component system of Unity, which I think is a better fit for my personal headspace, but then again having everything be nodes in Godot is also great, especially since dealing with prefabs is no longer quite as awkward, even though you cannot attach multiple scripts to a single node, which is inconvenient.
In comparison, writing any kind of piece of software in Rust would be a wildly different experience from doing the same in C#, due to how different the language concepts (e.g. borrow checker) are. Similarly, I'd personally say the same about C++ and C# (the whole approach to memory management, even with smart pointers) and C# and GDScript (the gradual typing in particular).
> Learning a new language takes days or worst case a week, learning libraries, best practices, switching towards a whole new area like game dev vs backend dev, that takes lots and lots of time.
I'd suggest that learning a new language can take anywhere from a few months to close to multiple years, depending on the language and what you intend to do in it, especially when coupled with particular stacks/frameworks/engines. Just look at how much C++ software there is out there and how much of it is full of memory management related bugs. Sure, you might knock something together after a weekend with a book or two, but getting to truly know the ins and outs of a language, as well as some of the more popular design patterns (at least in the context of that language) will probably take way more than a week.
I do fully agree with your points about different engines having plenty of specifics, but would like to offer the suggestion that transferring from C# in Unity to C# in Godot will be a comparatively easy process, versus learning GDScript and not being able to use any of your in house non game engine specific libraries for development. Something like maths for splines, some back end logic for handling inventories, levelling up, dialogue trees, quest systems etc. Of course, in practice many end up being tied to a particular engine because nobody cares about portability - much like ORMs in practice rarely allow for painfree migration across different DBs.
> That said Godot is not ready for complex 3d games yet with or without C#.
With this, I can agree. It's nice to think about the future of the game engine, though. Somehow Godot seems to have gotten way more traction than the likes of Stride (which was great), NeoAxis, or even something like jMonkeyEngine. Not sure what their magic sauce was, but I hope they have a bright future ahead of them.
I know Godot team is very committed to GDScript, but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, complicated project.
Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.
Unreal Engine's scripting language called Blueprints - https://docs.unrealengine.com/latest/INT/Engine/Blueprints/. It's pretty cool and useful - you can make everything in Blueprints that you can in C++ in UE (10% slower than pure C++ code).
However there are some problems. If you have too many nodes in a script it's very hard to navigate and understand what's going on. So I'd say that there's place for both, because it's easier for quick prototyping, but I don't think it'll ever replace programming to that extent. It's just another tool for the toolbox.
As it stands, picking up blueprints feels like I have to learn a whole new system which will go to waste if I decide not to stick with Unreal, and C++ seems like it'd be a pain to work with.
Edit: Forgot Godot had C# support. It still doesn't feel as "first-class" as GDScript, but its certainly more closely integrated than bindings, so maybe something to consider. Also, whilst I generally prefer a single language being tied to a single tool (trying to learn Raylib taught me this, where every example you find is in a different language), its nice knowing I can use C# without being locked into Microsoft
reply