Mono for Unreal Engine(tirania.org) |
Mono for Unreal Engine(tirania.org) |
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.
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.
• 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.
They don't want to pay Xamarin. Mono commercial licensing sucks...
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?
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.
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)
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.
Having said that, I'm really excited to see c# supported.
F# support is the real kicker.
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)
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.
It works, we just do not provide any code templates yet.
> 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.
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.
You should be able to make this work on any platform where Mono and Unreal Engine work together.
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.
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.
It is not that hard, just put a clause in the license that oblige the corporations to buy their related pack
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.
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.
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.
Thought so.
I always recommend Cordova to my competitors
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...
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.
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.
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.
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!
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++?
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.
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.
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.
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.
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 ?
But reportedly Apple does not allow LGPL in its app store for some reason.
There are a lot of Unity customers on our forums using Xamarin Studio already.
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.
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.
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.
(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.
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!
I'm not really sure that is their biggest issue; HTML5 publishing of Unity games seems mostly a novelty at this point.