I know this has been a well trodden path however I’d like to re-iterate how beneficial it would be to enable some kind of Blueprint runtime implementation of C#. I’m aware of the performance boost from C++ for the engine however from an architectural and computational design perspective, C# is used way more commonly (eg the very nice integration that Grasshopper (see image) has provided for years).
There are also a number of C# plugins that have been developed for UE4 over the years that have been gathering dust eg:
If there was a way to integrate this into the Unreal Studio offering, ideally within Blueprint (however even support with VS simpler integration like Unity), this would be a really big win for Epic in making it easier for the community to take Unreal even further. The Grasshopper approach is however a very neat way to integrate code into a visual scripting environment.
And sure there will be a slight performance drop but we can live with that for these kind of projects if the benefit is c# runtime integration which is really useful for the community.
Would be great to be able to easily implement libraries from other code bases - hence the C# parser would be really helpful. If Enterprise teams have libraries of functionality that have already been developed then they could re-use modules across different applications and maintain a constant code base.
Plus as an extra carrot for Epic, C# may also help lure more Unity devs who have developed tools already in C#. This would make migration to Unreal even easier.
Right now, We’d take anything that gets us closer to be able to use our own pre-existing code that has been developed and works across multiple platforms. I’m sure that we’re not the only ones.
Those arguments that the Unreal’s team has been using about “C# in Unreal would be nothing like Unity” is not a valid argument for me… If anything its a prove that adding C# to Unreal would easy up even more the transition for those developers since there are so many different things they have to learn that at least the language is something they already do know. The main point here is that C# is becoming “the standard” for gameplay logic and “high level” systems in games today, with pretty much ALL engines supporting it besides Unreal. IMO C++ is not for gameplay logic and BluePrints does not appeal to developers as much as it does for designers.
I’m a Unity developer for 10 years now, and I’ve been using Unreal for a couple projects in the past 2 years, and I still struggle to find my way into the engine and I really dislike having to rewrite my BPs in C++ when performance becomes an issue, I simply hate the C++ workflow, it’s slow, messy, and those Unreal Macros are just “trash” in the middle of my code that I just can’t remove, they are as much “magic” as the “update” methods in Unity and they are as hard to understand as the “tick” methods from cpp…
I’ve been fiddling with some new game engines in the past months and CryEngine has been a breeze to learn after they added the C# support and Godot is just becoming my favorite engine now that C# is a thing (I just wish it had half the features unreal has) and all of them use C# in very different ways than Unity (but when you change engines you expect some learning curve anyway). BTW, the Godot team has publicly mentioned that adding C# to the engine was actually not that complex, specially because Mono is a great and well documented tool and now that .net5 is here, open source and multi-platform (supporting even html, ios, android and you refrigerator) there’s not a big argument against it (lets remember that the Godot team that did it was a 1 man party… Unreal would have infinity budged to make this integration happen at the BP level in prob. a couple of months).
Also, I have a ton of libraries that I’ve built along those years for Unity, specially when it comes to online features (and multiplayer) that I can pretty much use unchanged on Godot. Also, it allows me to share code between my back-end website (written in asp.net core with a custom CMS and logs dashboard) and my game logic, which for me is a enormous time saver, specially cuz I’m still an indie developer… I want to see someone write web servers (and even some simple mp game servers) in c++, because it sounds so insane (and also the C++ code from unreal can´t be used outside of Unreal… There’s no point in that, so expect no code sharing anyway).
So my point is, Epic has really no good argument not to add C# support other than “we don´t like c#” which we know is not true, since they already use C# in the build systems for Unreal (have you ever cloned the Unreal source code? They use C# in there).
I don’t like the argument that Epic isn’t implementing C# for anything more than defining build settings because they don’t like it. It’s just as valid to say that the people who are requesting C# be implemented want it because they do like it. Python is more widely used and understood by a far greater number of people across a wide range of disciplines, and it’s incredibly easy to implement, so why not Python? Honestly it just seems that people who have used C# just want to use it for everything, even if it’s not the best choice, it’s just familiar, therefore it’s “better”… Which isn’t true. I got my start in programming working with C and C++ and I would much rather work with those, not because of preference, but because they’re infinitely better for the task than a language like C#. I use C# for developing applications on Windows where I want to use the .NET Framework/Core, as doing a lot of things specific to the Windows OS is trivial that way, but for me that’s the only time I’m happy to work with C#.
I worked with Unity for several years before jumping to Unreal. I found it extremely refreshing to be able to work with C++ and directly work with the source of the entire engine. Basically, I can do whatever I want. A C# API that would allow you to do a fraction of the things you can natively do using C++ in Unreal would just not be feasible to create. And of course Epic’s sole ambition is not to convert Unity devs.
@Noxxie
Python doesn’t run everywhere… C# (mono/.net5 to be more specific) does. Python prob. has a worst performance than BP does. But anyway, my point is not “add C# because we like it”, even though that’s a valid argument for myself, my point is C++ is not a language for high level logic (and Unreal knows that, and that’s why we have BP, which is good for designers but bad for coders). If you like it, great! But I bet you would be more productive working with a better tool for the job.
If Epic decides for something different, like Java, I’ll find that amazing anyway! But once you consider adding a better programming language for high level programming there is no better option than Mono/.NET5.
There’s a reason why CryEngine, Godot, Lumberyard, Xenko, Unity, Wave, Unigine and others support C#: it’s easy to integrate (really, mono is quite simple), it’s multi-platform and fast (not as fast as C++, ofc, even though Unity has manage to beat C++ performance with the new ECS framework) while being incredible productive.
Unreal CLR (GitHub - nxrighthere/UnrealCLR: Unreal Engine .NET 5 integration) appears to be a new development in supporting C# with UE4. Haven’t yet tested it however would be interested in anyone else has used it yet. Again a 3rd party plugin so would be great if there was some support from Epic in ensuring either C# integration was present or supporting plugins like this to ensure they remain up to date (as many, the latest being the great USharp have ceased development
Rider for Unreal Engine (in beta - https://www.jetbrains.com/lp/rider-unreal/) at least helps take some of the pain out of C++ development for UE4 but doesn’t change the fundamental issue that a lot of users would see value in sustained C# support in UE4.
UnrealCLR is quite inconvenient for use, as there’s no native interop between Unreal and .NET environments, except few functions and type marshalling. So either you’d have to use that interop functions a lot, or write a lot of wrappers.
