Please work with Xamarin to make Mono for UE a reality

Hi Epic,

A while back Xamarin released a preview of Mono for UE that gives us the ability to use C# instead of C++. This is great for those of us that know and prefer to use C#. Let alone it taps into the market of one of your main competitors Unity. I can personally say that i have tried learning C++ and the more i learn, the more i prefer C#. But i’ve also used Unity and UE and i personally think the UE editor and Epics values are a far better experience. I can also say i would have never tried UE because it was C++ and not C# or one of the many languages similar to C# if it wasn’t for a bad experience with Unity that turned me off them. But this is not about what is a better language to program games in, its about expanding your reach to a larger audience.

Recently Xamarin has announced that they will stop updating Mono, and rightly so, because the setup and installation process required is far to problematic. They just could not get a decent enough experience with it current UE licensing. I’ve tried it myself, having to download UE source, apply a bunch of patches and try to build the engine has been very painful. It requires far to much insight into the source to get it working when you come across a problem in the process. In saying that once you got it working developing in C# was great. It can only get better.

I would happily pay for a plugin that was easy to install and gave me access to C#, hopefully Xamarin would stick to there typical model and only require a development license when you are ready to publish. This would fit in nicely with UE’s model of being free until you become successful.

So please epic, can you partner with Xamarin to resurrect Mono for UE and bring a truly easy to install, setup and use plugin that will bring us all the benefits of working in C# and expand your market reach. It would be a win win for everyone and you would have the upper hand of being able to use C++ or C# for UE Games. With your constant improvements to the marketplace, friendly editor, company values and the ability to use C# it would be hard not to look closely at using UE over Unity.


I second that. The most successful softwares built on the past years are the ones that provide a platform and means for extending it. As Nitro said, it’s a win-win situation. And it’s is being jeopardized by Unreal’s strict EULA. Epic, please review your license and let’s make C# for Unreal happen! :slight_smile:

Hi Epic, Ryan,

After spending many hours myself compiling Xamarin for UE the limitation are too great for our project and only having this working on a lesser version of UE it is not practical for my team. I would fully embrace C# as a programming language for UE as this my primary language, however I do have a working knowledge of C++.

I originally created all our game servers with C# having limited C++ knowledge for networking this made the job a little harder using UE, I too am a seasoned Unity programmer with many large projects completed and I find UE a much better environment to be working in and the results are just stunning. With a C# plugin my life certainly would be much easier.

As Ryan said, please epic, can you partner with Xamarin to resurrect Mono for UE.
I for one are interested and I’m sure there are many others that are too.


What from UE4 EULA (quote would be good) prevents from “easy installation”? So everyone (imcluding me ; p) knows whare is the issue

I think the main pain point from the EULA is:

Please correct me if I am incorrect

So Xamarin dont want to distribute it “free of charge”? Or there issue with “free of charge” with Mono? Since source code avability is not a issue. Also just find other issue that might be related:

But thats not really a issue since marketplace plugin distribution is coming and currently is planned around 4.9

Well they are a business, they need to pay for developers to maintain the tool. By the sounds of it the ELUA makes it very hard to justify the cost and provide it in an easy to install plugin.

So “easy to install” is not really issue here, since it eventually can be distributed in marketplace regardless if it’s gonna be free or not. Problem is that it needs to be free in order to integrate different language. Would be good start if we hear from Epic reasoning behind that point in EULA, i think it might have something to do with compatibility with more restrictive platform licences like PS4 or Xbox One or even iOS

I got idea for potential workaround: Make runtime and compilation things free and tools that they showed in there video paid as a extra. But i’m not sure if Xamarin is ok with something like that.

Well compared to what it is right now, easy to install is an issue. From my understanding part of the reason we have to compile the source our self is to prove we have a license to the source (though now UE is free this might not be a big deal). But they basically said that the EULA is difficult for third party vendors and that meant they were not able to create the type of integrated experience they would like to have.

Ok. I’ll probably get some noob smack-down, which is fine. But just out of curiosity; some Epic programmers register GitHub files with the .cs file extension. I ask you now, before all witnesses! Is this or is this not a C# language file?

They are used during the build process only, to configure targets and libraries and such. There is no official C# integration in UE4.

Wow! GalaxyMan2015, that was fast. Reloaded my page after writing the comment, and there was an answer. Cool. And thanks for the reply. So much to learn. :slight_smile:

Thanks for your feedback! This topic is really important to myself and the engine team – we regularly discuss the possibilities. We use both C++ and C# every day. We’d love to support additional programming languages someday, including C#. That’s why we made the engine extensible to allow new scripting language plugins to be created by third parties. (The upcoming SkookumScript UE4 plugin looks awesome!!)

For now the engine team is committed to making the C++ programming and Blueprint scripting workflows clean and efficient – every release we try to make programming in UE4 faster and easier to use. C++ is an amazingly powerful language, and gets you top performance on every platform. High performance gameplay is absolutely a pillar of Unreal Engine. But so are fast iteration times, extensibility and and ease of use.

We’d consider supporting C# as long as there is a way for developers to release their games on any platform at no extra charge. This is really important to us! We’re not going to be able to put significant Epic resources into a project that adds “built-in cost” to UE4 developers who want to ship their game developed using a particular programming language.

We’ve been really impressed with the quality of Xamarin’s efforts, and we’ve been excited to see Microsoft open-sourcing their CoreCLR runtime and their upcoming cross-platform code IDE. There are many possibilities for C# to become more broadly adopted on all platforms. This is the same excitement I felt when the LLVM/Clang compiler reached critical mass and really inspired a lot of awesome change in the C++ community. For now we’re watching closely and talking excitedly about potential futures.

Remember if we eventually are able to support additional programming languages “out of the box”, we’ll want those to be first-class features! Besides fully supporting all UE4 target platforms, this means generating plenty of examples, dedicated API documentation, new video tutorials… the list goes on. It would be quite a large project! I’d be very excited about it though – but wow, it is a huge initiative. Either way we’re forever committed to making the C++ and Blueprint development experience as awesome as we can, even if add more languages someday.

Another thing that’s sort of interesting to keep in mind. Syntax niceties and iteration times aside, Unreal gameplay programming in C++ isn’t all that different than in C#, JavaScript or any other language. You’re still sub-classing actors and pawns, selectively exposing properties to the editor (or to Blueprints), and carefully considering local or remote actor roles when writing your replication in your multiplayer games. The gameplay framework still works the same, and there is fundamentally a “Unreal Way” to go about writing your classes. This is why we’ve also been focusing on changes to make the gameplay framework easier to learn and use, which will benefit developers using any programming language.

In any case, on the engine team we’ve really had our hands SUPER full since we launched last year. We’re carefully picking which large projects to put our resources into. We always try to be really open with you guys, and if kicked off a “new programming language” project we would want the whole community’s input and help as we brought that online. I think that when the time comes for that, it will be really fun. :slight_smile:


Just going to leave this here:

This post in particular:

Well i don’t see issue here since, source can be available it does not mean it can’t be distributed in binary form. 2nd marketplace support for plug-ins is coming, so all Xamarin would need to do is place binaries there… but free of charge as EULA states which from what i understand is a issue for Xamarin

Those are build scripts used for UBT which let you modify compile process, aditionally all code build tools are written in C#, but they are technicaly separate software, not real part of the engine, editror just run them.

Hmmm? Am I sensing a little change in the wind? (Re: Mike’s comments above) I know it’s been talked to death (C# in UE4) but it is interesting.

We would have liked to support Unreal - but… not without C#

The guy quoted below has it clearly stated. C# isn’t just a development option. It should be embedded WITHIN THE PRODUCT, and just be compiled as part of the normal build-release cycle.

How much business are you losing (we went with Unity because of this) because you don’t spend about 4 hours per release recompiling this integration for everyone?


I dare to hope. :rolleyes: Could this also mean that support for Delphi is theoretically possible? :smiley:

Actually, Blender needs better support for FBX… :stuck_out_tongue:

That’s the kind of absurd statement that sends these threads insanely off topic and causes arguments.

EDIT: Actually, not even going to waste my keyboards lifespan.