Download

Mono relicensed under MIT - C# for UE4 can come back?

But to be honest one thing I miss from C# and which are not likely to show up anytime soon in Unreal, are multithreading capabilities.
Async, Await, Tasks, Actor Model.

I’m using C++ in my UE4 projects and I know “the very basic level of c++ competency”, I would still prefer C# and it’s not gonna happen. That’s about it.

C# will happen, just as a community addition project. I highly doubt it’d be officially supported.

To be honest, Unreal could steal a lot of Unity folks if they supported C# as well, so it’s a bit foolish that they’ve shunned it so much.

Maybe Epic cares more about the quality of the games released than the quantity because of the royalties.

I think Epic already has a working C#/Mono integration and is waiting for GDC 2017 for the big unveil. The entire documentation/training team is probably working full time to get it fully supported (same level as Blueprint) hence we been getting Unreal Tuesday/Thursday with technical people instead of the training staffs. This is just a guess. Putting tinfoil hat on :cool:.

My 2 cents from using Unity: Async Await and other C# 4.5 features aren’t available in Unity3d’s mono 2.0 runtime either. There is a mono upgrade beta but it has been in almost a year now. There are community extensions such as UniRx and CSharp60Support, which try to fill this gap but they aren’t official.

With Unreal I read the there is out of box multi threading:

And AsyncTasks:

Personally I felt a bit frustrated by C++ syntax at first also. But having embraced and done lots of golang, I feel that low level languages can be quite powerful and elegant also if you design things right.

But having said all that, if there were a C# plugin of course I’d use it.

Hey Everyone - Have you seen the UnrealCS plugin?

You can find it here on github and more info about it here.

From what I understand it has full access to the Unreal C++ API but do not quote me on that. :slight_smile:

I will give it a try. I think it shouldn’t be a problem to replace the C# project with an F# project. This is one of the good things of F#, since both are CLR, we don’t even need any extra bindings. We can just use any .Net/Mono CLR assembly.

I appreciate that. Especially after having witnessed “Unity Quality”. The end result, so the actual Unity game, is surly much better these days. But the development experience is still off. I’m not even going to bother making a list of the flaws in Unity. It’s just too easy.

For gamelogic/scripting. Truth be told: F# > C# > C++

I’m sorry. I forgot the trolling: F# > C# > Visual Basic > C++

:slight_smile:

As the interest seems high:
Xamarin/Microsoft is actively working on bringing C# to UE in the form of a plugin. They are currently working on having some changes made to the core of UE4 in order to get the plugin working as intended. This is apparently a somewhat slow process.

(Source: The projects mailing list.)

Yeah Xamarin/Microsoft wanted to add some changes to the main UE4 version, but there are some legal issue. Xamarin has been talking about getting these legal issue cleared since September 2016. I has been 5-6 months and it look like it is still stuck :(. I’ll post a link of the post by Miguel de Icaza. I assume “integrated into the upstream UnrealEngine” meaning adding some changes from the Mono code to the mainstream UE4 version.

I think they will work it out eventually. As long as Microsoft does the majority of the work it would be very beneficial for Epic to get “official” C# support. And I’m sure Microsoft is willing to dedicate the resources, especially with their new .NET cross platform development push.

The ideal scenario really, if a 3rd party wants to invest the resources to implement a solid C# offering without taking any of Epic’s resources away from core engine features.

Also M$ is a strong supporter of the FSharp Software Foundation. F# is part of the .Net family, so Visual Basic and C#. Just like C# started out being used for scripting in games. So can F# start out. And if there is C# support, there can be F#. And that without much, or any extra work. Game engines like Unity, Xenko, and UE4, can help F# to grow into game development. In scientific fields, F# seem to like the take the lead over other languages. But for game development, it’s like a desert. I was the one who had to make the final push towards a Game Dev channel on their Slack. And that was just a few weeks ago.

Of course, this cannel was created now. The F# 2D Nu Game Engine researches F# for game development. Because apparently, OOP is a problem. And functional programming is the solution. I don’t have too much insight of this. But I use F# with Unity already. And I would view going back to C# as a downgrade. Last I checked, F# was the 7th most voted feature for Unity, of a total 8262 feature request.

Forget C# for a moment. It’s about kicking in doors like a Roman. And drag C++ devs out of their programming misery. -.-

It certainly is. MS got both the resources, incentive and knowhow to do it properly. And with Epic giving money to Skookumscript, we know they are in no way opposed to third party scripting languages.

What many people don’t seem to realize is that Unity has been stuck in the same Mono licensing quagmire as Mono for UE, as described by Miguel de Icaza a few posts above. Unity’s C# integration is based on a version licensed from Novell back when they were still owners of the Mono project, around 2010-2011. When Novell got acquired and the Mono project was dropped, Xamarin took over stewardship and ever since then, Unity has been unable to renegotiate a license for Mono that suited both parties. The result is that Unity’s implementation of the C# language is now years behind on the mainline .NET implementation by Microsoft, with relatively poor performance, an outdated garbage collector and missing out on a lot of modern features. This is one of the main reasons why Unity is commonly associated with bad performance, especially on consoles. Compatibility with third-party libraries is also becoming more and more of a problem for Unity programmers, because a lot of libraries by now have dropped support for C# versions older than ~2012. Things might get better now that Xamarin and Mono are in Microsoft’s hands, and Unity has in fact made improvements to their C# compiler over the last year, but in the meantime the Mono runtime used by Unity is still the same old junk from 2010. And with each passing year, it will become harder and harder for Unity to upgrade the Mono runtime without breaking every single game ever made on the Unity engine.

In that regard, we should be glad that Unreal Engine is based on an open standardized language like C++ without any licensing issues to bog down development. UE effortlessly upgraded from C++11 to C++14 recently, something you might have seen in the release notes but otherwise probably never even realized had happened. IMHO Unreal dropping its custom scripting language and going full C++ and open source has been a godsend, and was a major reason for me as a programmer to jump ship to UE4.

P.S.: don’t get me wrong, I’ve done a lot of work with C# and love it as a programming language. It has a lot of amazing productivity features and multi-threaded programming in modern C# with async-await is a cinch. But what you gain in ease of use, you do lose in raw power and direct control over how your code runs on the hardware. Which is why for high-performance game programming purposes, I personally prefer to use C++ and will take the increased complexity for granted.

Has anyone notice how the Coding Standard page now include stuff about C#? Just reading it again today and notice a couple of things. Link Coding Standard | Unreal Engine Documentation

That is really interesting… Any way to find when that page was updated?

I checked it on Github. Looks like it was updated December 8, 2016 roughly 3 months ago. Link here https://github.com/EpicGames/UnrealEngine/blob/release/Engine/Documentation/Source/Programming/Development/CodingStandard/CodingStandard.INT.udn

Unreal uses C# for its build system and various other tools, so those coding standards might just refer to that.