Hacker News new | past | comments | ask | show | jobs | submit login
Mono for Unreal Engine (tirania.org)
221 points by jstedfast on Oct 23, 2014 | hide | past | favorite | 90 comments



Maybe this will light a fire under Unity to get a recent version of a C# compiler. No one has ever been able to point me to an official explanation for why theirs is so far behind.


That was my number one reason for moving to UE4; announcing Unity 5 with no Mono runtime update was the last straw. Current versions of Mono could probably do a serviceable job with simulation-heavy games, but not Unity's ancient one.

Bizarrely, they don't even have a C or C++ API. You can add native code libraries to your project in Unity Pro, but you always have to go through Mono to interact with the engine.


Unity is writing a C#-to-C++ compiler, il2cpp, see

http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-...

it's much faster that Mono on some things currently,

http://blogs.unity3d.com/2014/10/07/benchmarking-unity-perfo...

but it is so far only used in the WebGL port. Long-term, il2cpp is meant to replace Mono in Unity, according to the first of those links.


Small clarification.

It is faster than the old Mono they ship.

Their Mono is at best Mono 2.10, about three years old, without any of our optimization work for three years, very notably, a lot of the LLVM support, or the new garbage collector.

That said, the il2cpp looks like a very promising an interesting project, so kudos for that!


Yes, I think those benchmarks are based on the Mono they use, which is indeed old. I would be very curious to see benchmarks compared to trunk Mono - should be interesting.

My information may be out of date, but typically people tell me that Mono tends to not match Microsoft's .NET implementation in speed, and in turn, .NET tends to not match native C++ either. So I would still guess il2cpp can win here. Or are there benchmarks showing Mono matches .NET and/or native C++?


It's important to consider that C++ code, is not the same as C# to C++ code. The Facebook guys originally converted PHP to C++ code for speed, just like il2cpp, but eventually they wrote a JIT because it was faster AND they could keep the dynamic features like code generation and dynamic loading.

C# is ment to be a safe language, unlike C++ which has, among other things, the notion of undefined behaviour and manual memory management. This is what makes C# initially slower than C++. You might be able to compensate with a JIT, but safety still costs. Not to mention, the Unity guys will still probably have to implement their own GC and spend years on optimisations.

Also, several games are using dynamic loading for things like plugins and mods, as far as I know, il2cpp will force them to change how this is implemented.

From my standpoint. The cheapest option, and best option for everyone really, is to continue using (an up-to-date) Mono and instead allow for writing games in C++ as well.


> From my standpoint. The cheapest option, and best option for everyone really, is to continue using (an up-to-date) Mono and instead allow for writing games in C++ as well.

Yes. It seems logical that there have been some licensing negotiations that we're not aware of, and maybe all this is part of ongoing negotiations too.

What's puzzling is that they're keeping il2cpp closed. Opening it would make sense and would show they mean serious business but keeping it closed makes me wonder if their risk will pay off or if it's just a bluff.


Good point about code compiled to C++ not being the same as idiomatic C++ code.

However, unlike PHP which is dynamic, C# is statically typed. It is a much more direct match for C++, and performance should be pretty good.

But with that said, I think your point still stands, as there are still things like bounds checks in C# which would need to remain when compiled to C++, while idiomatic C# might not have those checks.

I wonder though if those bounds checks couldn't be disabled in some cases. Sandboxing isn't a concern on the Unity WebGL port, for example, since the browser provides that, so il2cpp code doesn't need to be safe in that sense.


C# has very defined behaviour that when "ported" to C++ is going to result in similar speed hits. Allocations are zero'd out. boxing/unboxing objects, array bounds checking.

GC is going to be the big hit as you're still going to need to pay for that even in C++ land. I'm not really seeing what you'd get over just C# with a more modern JIT unless you start converting to non-safe C code and doing sneaky c stuff behind the scenes (and I'm sure absolutely nothing will go wrong*).

The webgl stuff is fine to not be bound (I'm assuming it's being converted to js anyway?) but anything running in the plugin better be.


First and foremost, compiling to C++ means you then optimize it using a full C++ compiler like gcc or clang+LLVM. Not only are those compilers generally better than JITs, they can also do whole-program optimizations. JITs are getting that too (Dalvik=>ART, newer .NET runtimes), but the C and C++ compilers have a big head start.

(In theory a JIT can do all the things C++ compilers do, of course.)

Aside from performance, Mono must be ported to each target platform (I've heard this can take significant effort). On the other hand, well-written C++ code should just run (the rest of the engine is in C++ anyhow).

edit: yes, Unity compiles C# to C++, then to JS to run in the browser.


All true, but you're forgetting that Mono can AOT compile C# to native code using LLVM. That's how Xamarin.iOS works. So il2cpp doesn't really bring anything new to the table.


But it does solve their biggest issue - ultimately enabling Unity projects to publish to the web without plugins (WebGL / javascript).

Once all code in a Unity project eventually ends up as C++ (even if it started as C#), they can leverage Emscripten, asm.js and related technologies to enable Unity devs to use C# in the editor, which is converted to C++, and ultimately Javascript. It seems crazy, but it might just work!


"But it does solve their biggest issue - ultimately enabling Unity projects to publish to the web without plugins (WebGL / javascript)."

I'm not really sure that is their biggest issue; HTML5 publishing of Unity games seems mostly a novelty at this point.


It is still pretty new, yes, but it seems to work well (see for example https://hacks.mozilla.org/2014/10/unity-games-in-webgl-owlch... ), and it's been one of the most-asked for features by Unity users on their forums.


Regarding the C# -> C++ -> JS thing, it really must alot easier to do a C# -> JS conversion...


>NET tends to not match native C++ either

Let's see if with the new RyuJIT and the AOT compiler sharing the Visual C++ compiler backend in the upcoming .NET, that still holds.


Can't be understated - I've benchmarked my current MonoGame stuff with 2.10 and 3.10 and the modern stuff is leaps and bounds better in terms of GC performance (that alone being my biggest hurdle). Perf improvements have been coming very steadily and while there are areas I wouldn't recommend it for I wouldn't hesitate in recommending it for the logic level of many games.


But why? Why not directly compile it by implementing an LLVM frontend? And if you're going to transpile like this, I would assume translating to Java would be easier, since the languages are really similar. The JVM is, depending on task, as much as four times faster than Mono, and that's the official Mono, not Unity's stagnated one.


The unoffical reason is Xamarin wants too much money.


Or the Unity guys want to pay too little money.


You haven't seen Xamarin licensing prices...


No, but they are surely cheaper than a lot of comercial software I have to deal with in the enterprise space.

Plus let's not forget Unity was just another 3D engine before they got Mono integrated. Whereas Mono was already being used in multiple areas.

Anyway, this is playing conspiracy theory until someone issues an official statement.


Mono is open source and free software. Because of the "single static binary" policy (no dynamic linking) of app stores you have to obtain a proprietary license from Xamarin.

• The C# compiler is dual-licensed under the MIT/X11 license and the GNU General Public License (GPL).

• The tools are released under the terms of the GNU General Public License (GPL).

• The runtime libraries are under the GNU Library GPL 2.0 (LGPL 2.0).

• The class libraries are released under the terms of the MIT X11 license.

and:

When do I need to obtain a license from Xamarin to the Mono Runtime?

We only require licensing for uses of Mono and Moonlight on embedded systems, or systems where you are unable to fulfill the obligations of the GNU LGPL.

source: http://www.mono-project.com/docs/faq/licensing/


>We only require licensing for uses of Mono and Moonlight on embedded systems, or systems where you are unable to fulfill the obligations of the GNU LGPL.

In other words, you have to pay a license fee for shipping the Mono runtime in a proprietary game, which is what Unity does.

So Unity has negotiated a license deal with Xamarin for the Mono runtime version they use, and if they want to use a newer version they will have to pay more, which they aren't doing.

Instead Unity has developed il2cpp which means that they no longer have to ship the mono runtime with each game and therefore no longer have to pay the license fee for shipping mono.

Atleast that's what I've gathered.


Unity has negotiated a license with Novell. Now they would have to do it again with Xamarin for the newer version of Mono. But we don't know if Unity was really nice to the Mono guys when Novell pushed out what would quickly become Xamarin. As always, if it were only money things would be simpler. But if there is some beef things will drag.

Plus, Unity has forked Mono and they contribute to their own internal version. At the same time they are working hard on their own proprietary il2cpp (to export to C++). The writing is clear: they will drag things as long as possible with using their old version of Mono until they are able to switch to il2cpp.

My personal opinion is that Xamarin guys are better at Mono and that UE4 coupled w. Mono/C# might put quite a bit of pressure on Unity.


>Unity has negotiated a license with Novell. Now they would have to do it again with Xamarin for the newer version of Mono.

Ah, so the deal was before Xamarin bought the rights to Mono from Attachmate/Novell, I didn't know that.

>At the same time they are working hard on their own proprietary il2cpp (to export to C++). The writing is clear: they will drag things as long as possible with using their old version of Mono until they are able to switch to il2cpp.

From what I understood they would still ship Mono as part of Unity (as in development framework), however what they want to avoid is the license costs that comes with shipping the Mono runtime with each Unity game, hence il2cpp, but perhaps I'm mistaken here ?


For them to invest serious resources into a Mono fork and also in a proprietary solution (il2cpp) shows that they do not believe in a deal for a license of their liking, whatever the reasons: interpersonal or purely monetary.


You can bundle LGPL libraries with proprietary applications quite easily; it just has to be possible for the user to replace it, which is rarely a problem because the usual situation is that your proprietary code sits "above" the LGPL library.

But reportedly Apple does not allow LGPL in its app store for some reason.


Well there are likely lots of potential markets where a prerequisite of allowing the end user to swap out LGPL libraries won't be accepted (sadly), not only Apple but the consoles as well, so from that perspective Unity needs to buy a license which allows them to forego the LGPL requirements.


It's not just mono they need, it's the IDE. The default IDE that comes with Unity is MonoDevelop. If they upgraded the runtime, they'd have to pay for Xamarin's IDE. I wonder if embedding the java runtime would have been cheaper in the long run.


Our IDE is free for anyone to use, whether you are using our iOS, Android or Mac products or not. It's also open source (except for the addins that work with our iOS, Android and Mac products).

There are a lot of Unity customers on our forums using Xamarin Studio already.


How would that work with the App store now, since you can dynamically link to frameworks?


I think it is very fair if Unity will be in the same boat as e.g. MonoGame.


> No one has ever been able to point me to an official explanation for why theirs is so far behind.

They don't want to pay Xamarin. Mono commercial licensing sucks...


Compared to what? I fail to see any difference to other comercial software offerings.


Compared to free. The version they're using doesn't require any licensing.


I suspect the issue is related to the licensing fee which might be on a per dev seat and hence might not fit unity 3d's business model. Unless there is a hard stop issue, business wise, it won't happen.


When unity got their mono license xamarin wasn't yet a business, hence the license was most likely zero.


It would have been zero to Xamarin, but doubt it was free.

I imagine they bought a perpetual license to distribute sans-GPL the full code of a specific version of mono from Novell.

This thread has a bunch of speculation and a few comments from unity developers: http://forum.unity3d.com/threads/new-version-of-mono-with-un...


They forked a long, long, long time ago.


One concern here is portability: If you write your game logic in C# on Mono, it won't run on all platforms (possibly for either technical or licensing reasons - you're limited to where Mono runs). For example it won't run on the HTML5 target. For comparison, Unity has written il2cpp to replace Mono to get around that,

http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-...

it basically compiles C# to C++, which they found is much faster.

I wonder if this project has a solution in mind for platforms where Mono won't run? Or maybe it targets just a subset of the things Unreal Engine can target?


Mono is a well designed, very portable codebase. The only platform I can imagine having trouble _is_ the browser, but I would bet that you could compile mono with emscripten quite easily. Also, there's http://www.jsil.org/


There are also issues with Mono on some consoles and mobile devices, due to how linking works as well as some non-technical (legal) restrictions the platform owners place.

From talking to Mono devs, definitely Mono can be ported to new platforms, at least if there are no license problems. But even then, it can be quite a lot of work. il2cpp avoids all those issues, it emits C++ which every significant platform can handle very well.


Also, there's NaCl.

Some Mono games (like Bastion) have already been ported to run on the browser:

http://www.supergiantgames.com/blog/surprise-bastion-now-ava...

(then again, NaCl is not probably what most people have in mind when they think about browser support)


This means a lot to me. I will try to contribute to this one, nice kickstart guys!

I don't have much C++ experience and I had doubts about getting into UE only with blueprints. It feels like there will be cases that I won't able to cover just with blueprints.

I was experimenting Unity just because of their C# support but now I can gladly turn back to UE and it is more exciting for me.


As a long time Unity developer that hasn't touched C++ in years, I can say that I have been experimenting a lot with UE4 and I haven't really needed to touch C++. Blueprints are really powerful.

Having said that, I'm really excited to see c# supported.


>>This is a project that allows Unreal Engine users to build their game code in C# or F#.

F# support is the real kicker.


Blueprint, the default UE4 language, seems functional. All functions are pure functions, with input and output, not methods, there's no 'self' or 'this'.

That said, I'm not an expert on Blueprint or FP so maybe someone who knows more can tell me whether that assessment is accurate.

(And I totally understand that some people will prefer F# and access to all those .net classes anyway)


That's not true at all, There is indeed a "self", and nearly all functions are executed in a context with a valid self.

Additionally, there are plenty of nodes such as "Get Player Controller by index" which allows the user to access and modify global state.

There is a "pure" option to check on a particular function, but the language itself makes no checks as to the validity of this, it just allows the execution engine to make assumptions.


Ah interesting re self - how did you find out about that?


I wouldn't say it was pure, since a lot of the commands have side effects. Probably more accurate to say that it's a powerful flow-based language with a graphical representation.


Blueprint is essentially a C++ Framework API that you interact with using a GUI


But "Features and roadmap" at http://mono-ue.github.io/ says "Our current release supports C# on Mac and Windows. We hope to add many more features, such as support for the F# language [...]". Confusing.


This is what is on their page: http://mono-ue.github.io/roadmap.html <Quote> While you can use F# today, we want to provide default templates that people can use. Currently, you must set the projects on your own. </Quote>


Apologies, I have clarified this.

It works, we just do not provide any code templates yet.


From http://mono-ue.github.io/about.html

> To redistribute code written with Mono for Unreal Engine, you must have a commercial license to the Mono runtime. These licenses are available from Xamarin for Mac, Android and iOS online, and you can request Windows licenses through support.

So, if I want to use this commercially on Windows I will have to buy a license for the Mono runtime ?

Judging by the price for the Mac license it should be around $300 per year, while the Unreal license itself is about $240 per year.

Now, if I want to use the same code on iOS, Android, Windows, Mac I will pay to Xamarin about $1200 per year.


The Unreal license is only that much if you keep your subscription going. You can subscribe and then cancel your subscription whenever you want, while still being allowed to publish using the latest version of UE4 that was available while you were subscribed.

From the EULA:

After cancellation of your Subscription by either you or Epic, you will not be entitled to access or use future Versions of the Engine Code or Assets that Epic makes available under the License. However, cancellation of your Subscription will not affect your rights under the License with respect to any Licensed Technology you have already downloaded under the License.


Unreal's model of subscription+5% of top revenue becomes a real nice deal when coupled with Mono. All o fthe sudden there is room for C#/.NET devs to be able to contribute to the platform. It should be a nice boost for UE4's adoption


I know about the Unreal license and I actually think it is a decent price for the engine. My comment was more about the Mono runtime licensing that ads up quickly and it is more than the initial cost of UE 4.


This is another game changer. Personally, the portability of C++ is, by far, its own reward. But I'm thrilled for others that C# is finally becoming an option. It's been many months in waiting for Unity users sitting on the fence.


Hopefully, Xamarin will add Visual Studio support in the Indie dev plan at some point. Currently, if you want to support iOS, Android and use Visual Studio you need to pay $1798 per year which is a bit more for a one man shop.


For a larger corporate, ~$1,800 is very reasonable.

Xamarin have a tough line to walk - larger companies will happily pay that price, while still being reasonable for indie developers.

Xamarin support is excellent - their forums, twitter etc. I haven't worked with a vendor before that has been that helpful. Xamarin need to cover their costs.

I've been using Xamarin Studio for a while now for both iOS & Android and its fine.


They just need to make two different price plans: you are a corporation? Here the corporation pack. You are a alone dev? Here a very lowered-price alone dev pack.

It is not that hard, just put a clause in the license that oblige the corporations to buy their related pack


Or maybe just charge more for the 2nd and later license seats. That may make it even easier to get business to go all-in.

There really should be a one-man shop deep price break. I've used the iOS Pro edition for years since I got grandfathered in for my small iOS app but I don't come anywhere near to breaking even with that so I can't consider adding on Android at full price. I've love to but since I have Pro iOS I can't even add on non-Pro Android licenses either. My little app is a labor of love type of thing with a small, niche user base, not something that will ever cover my costs yet I don't want to give up VS and all that muscle memory and familiarity, etc... I can take a little loss each year for side projects but I can't lose $1800/yr.


On the other hand, if you aren't earning at least 10 * $1800/yr, are you really a professional games programmer?


Yes, corporations do not start nice github projects. Indie community would be a good gain.


Now that they've added a profiler as another differentiator the chances of that happening may have improved slightly. They do have 'call us' deals for small/new businesses.

I'm wondering if you would mind sharing what features you miss the most when you are away from Visual Studio? I've not tried it but I'd guess a lot of the editing is possible even if you do wind up stuck using Xamarin Studio for building and debugging.


I've never played enough with Xamarin Studio and only tested Xamarin Business with Visual Studio (I've used a 30 days trial).


Its essentially branded monodevelop with bundled addins(or is mono develop now unbranded xamarin?). In any case, it has improved dramatically over the past couple years. I write services/daemons in it and find the C# functionality to be fantastic now. F# is coming along too.


Thanks for sharing your experience.

Xamarin Studio is definitely rough around the edges but for the most part it seems to get the job done. For example, I've had issues where the update dialog steals the modal focus from the source control dialog(s) and that's basically the end of all interaction with the app until I restarted it.


Having spent some time writing JNI wrappers for a hobby application in Android, I think it depends on what one is trying to achieve.

For hobby purposes and small development, it is expensive and probably is doable doing everything alone.

However, for usual business with short time to market, taking into consideration "time spent on feature" X "hourly rate" per developer time, the prices are quite cheap.


> However, for usual business with short time to market, taking into consideration "time spent on feature" X "hourly rate" per developer time, the prices are quite cheap.

I fully agree, for a business that say makes 100k per year, paying about 2k for a Xamarin Business license is affordable.

An interesting pricing strategy would be:

* Free - for hobbyists, give them complete features and make the resulting executable expire in a few days. This will let them try and play with the tool. After they are comfortable with using C# and Xamarin, they will chose a paid license if they want to make money from their work.

* Indie - same as above for small business (less than 100k per year).

* Pro - same as above plus (paid) support.


Or you could look at Apache Cordova. Support is in CTP now and full release in Visual Studio 2014 hopefully.


Have you shipped an app with Cordova?

Thought so.

I always recommend Cordova to my competitors


Are you seriously comparing JavaScript to F#/C#? Really?


Cordova still has performance problems on Android and even on iOS. Maybe in the future.


Not even close to being the same thing.


My only disappointment is that Linux support isn't mentioned anywhere, not even in the roadmap.


I'll add it to the FAQ, but a variation is already there:

You should be able to make this work on any platform where Mono and Unreal Engine work together.


Good! Unity is in a desperate need for competition. How old is their Mono version again?


Unity runs on a custom Mono 2.6.5 with some fixes cherry picked from Mono 2.10.


I think they are still using 2.10 which is about 3 years old.


Definitely game changing. The barrier to move from Unity to Unreal is really low if this works out. Still best to do C++ where possible but this opens up Unreal drastically.


> The barrier to move from Unity to Unreal is really low if this works out.

Not at all. You still have a huge chunk of your code written specifically for interfacing with UnityEngine. Also, coroutines instead of async.

It still won't be easy to migrate.


Migrating an existing project won't be easy sure, but making the move to UE for a new project would be much easier for Unity devs now.


But a very good lesson for proper design (not tying to specific engine too much).


Awesome, the last thing that held me back jumping ship from Unity was that i love C# so much and have no prior C++ experience.


The installation process (PC) kinda just threw me off :/


Well this is very strange. Language shouldn't matter so much. Eventually you will use the same function name for any language. Whether it's c++, c# or f# you will use same functions e.g. `setActorLocationAndRotation` so I didn't get that.


I wonder if Xamarin are considering acquiring Untity 3D?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: