New version of Mono with Unity 4.3 - Any additional details on that?

Do you actually have any good suggestion? I love Unity but I really need to import some third-party dlls in my project and I can't run them with the current version of Mono. Is the only solution looking for another game engine? As others here, I only target desktops, don't care about phones and would be happy to pay a fee for less obsolete support.

Thanks!

 

Agreed. I'm already running into several mono related issues myself. Nothing I can't work around yet in some way but annoying as hell and wasting development time. I also have to re-implement certain .NET 4.0 features by hand which is also a waste of time.

Considering there's the rumor that the Unity sellout offer came from Microsoft I have to say: Ok Unity Team, great that you decided to remain independent and all that... BUT... I'm pretty sure now that Microsoft is cooperating with Xamarin a sellout would have mean immediate upgrade to the newest .NET stuff and out of the box full support for visual studio.
Microsoft does a lot of stuff wrong but they know how important their developer base is and they do know how to keep their developers happy and aboard. Unity currently seems to more and more fail to do this therefore my voice into the room: If nothing happens soon about this I might actually regret that you didn't sell out. There's worse things that could have happened to Unity than becoming the offical replacement for XNA AND MonoGame. So you didn't want that, well, then show us that you can do better than MS would have and make sure we get great IDE support and an up to date runtime.

 

If you can't afford a license, UPGRADE MONO FOR DESKTOPS ONLY. Just like you did with DX11 (I'm still angry about not getting OGL4 support, by the way). Then, when Xamarin and you guys are back on speaking terms again, get it for all platforms.

 

As Unity is extremely portable, it would not be a good idea to upgrade mono just for some platforms. Think about the situation that you purchase something in the asset store and then you find out that it works only on some platforms, because they are not using the same mono version.

 

That's the S*** I have to go through every time I see a DX11 only thing...

 

The OpenGL issue really is an annoying one, but it really hasn't been in Unity's favor to do much. OSX only just go 4.1 support with the last release and Linux drivers are pretty much all over the place.

 

my issue is that I absolutely love unity, and don't really want to go to another engine. usually, it's along the line of: the engine is excellent, but the tools and editor suck, or the editor is great but the engine sucks, or the engine is great, editor is decent, but there is no community or assets. this is as close as I've seen to a complete package

pros:

• the editor is by far the most usable and mature that I've found. drag and drop ftw
• the extensibility is excellent, and the fact that I don't have to learn and use some arcane or proprietary scripting language is a big deal, c# ftw
• the asset store. HUGE deal for me since I suck at making mesh or texture assets..
• the engine quality and speed are better than average imo
• multiple platforms
• the community, large and active. I could go on, but if you're reading this then you already understand most, if not all, of the pros

cons (again, imo):

• lack of precision internally in the engine.. needs doubles at least or the option to use them. i'd like to use unity for loading dem sets..
• spending way too much time architecting solutions to be able to mimic or use functionality that's already available in .net 4.0/latest version of mono
• absolutely NEEDS a shader editor ala strumpy's, intrinsically added to the editor
• conversion tools, such as cg/fx/glsl for shaders. trying to convert shaders is painful and to be honest, existing asset authors would benefit from this as well by being able to convert/update their existing shaders to dx11, quickly and easily

 

Look at what I just on Noticed on mono Git hub

I hope unity gets a newer version some day, .net 2.0 is getting old. However, the new garbage collector uses the Mit license.
https://github.com/mono/mono/commit/758246c2aa9f40f2859e78def0c4d7118b767366

 

They could always freeze the .net implementation and move to a c++ one;
leave the unityscript there. etc.

or dump boo and unityscript and leave c# there and create a c++ implementation. that would work for me.

 

Please start a new thread if you want to talk about C++...

 

he was talking about dumping the more obscure langs in favor of more widely used ones. and I agree.

the more the scripting engine uses mainstream languages the better and that increases the attractiveness as a whole. I know I was ecstatic when I saw c#. no more bouncing between lua, or javascript (yuck) or some other obscure lang. I could leverage what I already know and hit the ground running instead of having to figure out the syntax of yet *another* 'script' lang, proprietary or not.

 

If there's truly no end in sight with Mono and Xamarin (it's been how many years now?), Unity can't stay on an ancient version of Mono forever. There has to be alternatives, and realistically that means a proper C++ API with an interface to JavaScript (V8) or something similar.

But really I just want a new Mono. Count me in as another person who'd gladly pay for Pro just to run the latest version of Mono on desktop builds only.

 

Which I'm sure is why Unity has a language called "JavaScript", even though it isn't the same language that anyone else on the planet calls JavaScript.

I think that getting "mainstream" languages is exactly what Unity have done. C# keeps application/games programmers happy, JavaScript keeps web/Flash developers happy, and Boo keeps 3D package plugin developers happy. Plenty of us have strong feelings about a favourite of the three, and that's probably because we're the ones they had in mind when they decided to include it.

I'm really not sure where people are getting the idea that C++ is a no-brainer alternative to the current system, though. I love C++, but it fits quite a different role to the one that makes me productive in Unity, and would completely blow away the accessibility advantage of Unity.

 

If they were to switch away from Mono, a C or C++ API is the best way to also provide support for Lua, JavaScript, Python, or whatever other scripting engine they might embed. If it's implemented correctly, it gives you a lot of flexibility.

And there's also no real alternative to C/C++ in terms of a powerful language that they could support. Scripting languages have come a long way with stuff like LuaJIT and V8 and PyPy, but you need another option for performance-critical code.

 

This has been discussed to death. Unity already supports C/C++ in Pro if you need to do performance critical stuff where the language will make a difference.

 

We are not talking about language here, we're talking about Mono. And mono means runtime and runtime library AND C# language features in the compiler. To be honest I could live without the language support for async/await for a while still, but better garbage collection and especially the .NET library features are a big deal. Right now people work against an old runtime. Switching languages will not fix anything but make things worse. I don't care whether I program in C# or C++ for the language, I care about c# because that gives me access to .NET as a whole, and currently that's lacking. Talking about C++ or Javascript doesn't help one bit since you're throwing the entirety of .NET away then.
So let's keep this focused. This is about an updated Mono Runtime, not about "which language is better".

 

+1 on all of that.

 

C++ is a nonstarter, dead on arrival.

 

you misunderstand what I was talking about. "C# keeps application/games programmers happy" it doesn't, thus this conversation...

 

Sorry to sound harsh, but any person starting this stupid "this language vs that language" crap usually has no idea what they are talking about. Could we stop that amateurish crap now and get back on topic? The topic wasn't "meh meh meh I want C#", but "We want to make sure we're investing into a future proof technology here" and a continued support for newer Mono Runtime versions is an essential part of this.

 

I believe there are two issues here -

1) Is Unity's mono runtime going to be updated with a garbage collector that resolves the current issues with GC in a real time environment?

2) Is Unity going to update their mono runtime with the latest .NET features?

I really care about 1) and would like it to happen yesterday. But I'm not terribly fussed about 2).

This seems to align with the snippets of official info we've gotten from UT who appear to have branched mono and are currently working on their own, improved GC. But it's not so good for the people who are desperate for the latest .NET features.

 

I don't think branching is a good investment. In the long run that is going to pull a lot of capable people away from important stuff to re-invent the wheel. And quite frankly when it comes down to it, I believe Microsoft and Xamarin, especially now that they're cooperating, have the better people to do that. Unity should focus on other things, including updating their API to a better design and actually working on the engine instead of doing work others have already done.

 

I agree. From my perspective branching is a TERRIBLE idea. But I'm going to go out on a limb here and suggest that there are things going on that David Helgason is aware of and I am not.

We know that UT are branching. We don't know if that means a deal with Xamarin / MS is off the table. And we have yet to see any work resulting from this branch.

I believe that's the current state of play.

 

Looking at it as if it's a .NET implementation, yeah, branching is a sucky idea.

Looking at it as if it's a scripting runtime for a game engine... branching something existing that's pretty close and making improvements to better suit requirements isn't that terrible. Plenty of engines have created their own scripting runtime from scratch. This is just somewhere that's not at either extreme of the buy-or-build spectrum.

Though for what it's worth, I personally think that .NET/Mono compatibility is a fantastic benefit that should be preserved as much as possible.

 

I see it a little differently. I think the .NET/Mono compatibility is not just a nice-to-have. I think it is the do or don't for unity. If you look at successful environments out there, then its success was nearly always bound to how large its developer base was. And I think Unity's success is largely due to the fact that there are simply that many .NET developers out there that either work on this themselves or are a resource for learning .NET/C#. If you are moving away from that, you are losing a heck of a lot of know how. .NET doesn't evolve just for the heck of it. A lot of the development in there since 2.0 has been about making modern applications easier to build. Especially also for mobile devices, which has been a major point for MS since windows 8. All that work that has been put into working with nice responsible APIs, extendable applications and all kinds of stuff is just not there for Unity developers. And the longer that stays that way the more C# developers will get turned off. I knew quite a few C++ developers who quit working in gaming because they were sick of console programming because that means working against stone age compilers, not being able to use boost because it didn't compile for lots of consoles and all kinds of crap. Especially when C++11 came out lots of console developers were crying because they knew all those platforms will take ears to support that stuff in their compilers. Staying up to date with the curretnt state of the art is important, especially in IT. I don't care whether they're branching to make the runtime fit the needs of gaming platforms more, that's fine. But if you're branching, then branch the newest version, not a 10 year old one. And it IS a 10 year old thing. 2.0 is still the officially supported version and from what I can see aside from LINQ not much is going beyond that. and frankly, if LINQ wasn't supported I wouldn't touch this engine.
10 year old stuff... sorry that's just not ok, not in any way. And I don't care if they do it themselves and do it well. But they are NOT doing it. They're improving .NET 2.0, they're not writing their own 4.0, If they did that and did it well, fine, but they're not. They're neither buying it, nor doing it themselves, and that just sucks. So it's not like a discussion about whether buying or branching is better, they're doing neither. They're tweaking stone age crap. And THAT's the real issue here. And I'm one of the people who just want to know whether it is a good idea to stick with unity after our current project. because if this is the way it's going to stay, then I say no. Because we'll be needing to hire good people, and good people don't like working against stone age stuff. They're used to and trained to work with the newest way of programming in C' and with .NET and currently you cannot do that in Unity at all, unless you recreate half of .NET 3.5 along the way.
Imagine LINQ wasn't in there, or even generics (which nearly are not in, since they're hardly ever used in any useful way. Not even namespaces and interfaces are really supported in the Unity API). Would that bother you? I bet yes. And I bet you in one or two years the absence of stuff like async/await and the TPL and PLINQ and incompatibilities with Rx and all kinds of useful stuff WILL bother you.
So my question is, will that change, will that come, will Unity evolve alongside .NET (lagging behind or not), or are we stuck with what we got.

 

Taking that point of view (which is a perfectly reasonable one), what other tools are available?

But anyway, that stuff hasn't bothered me for the last 5 years, and currently continues to not bother me, because of the context in which I approached Unity. Before Unity I did some of my own tech in C++, and/or used other tech which had their own scripting systems and/or other scripting systems nowhere near as capable as .NET 2.0. Oh, and I used early XNA which had... wait for it... epic GC issues.

So yes, I totally understand that someone coming from a recent .NET background would be annoyed at all of the stuff they're used to that Unity's old Mono doesn't provide. But from my context, I lived without those things for years without it being a problem, so they're not going to suddenly be a problem tomorrow. Better tools would be great, I'm just not upset with what I've got, and no other overall package works better for me on the whole (ie: I could get newer language support, but I'd be giving up a lot of other benefits to get it).

I'd be happy if they upgraded. The lack of an upgrade just isn't a deal breaker for me.

 

Btw, one thing I also don't see evolving is the entire API. And that ill-equiped support for a modern C# API is already throwing its shadows. We're already facing problems working with a lot of content from the asset store. Why? Because we'hace our code not in the assets but in an external build and put the DLL in the assets. There have been talks about the benefits of that already on the Unite conference so we know we're not exactly the only ones doing that. If you do that however you can't access half the stuff in the asset store, among such things the NGUI, DFGUI and other big stuff, since they publish source code. why? Because they can't easily separate their implementations from their API since Unity has crappy support for interfaces, let alone extensibility via dependency injection which is the state of the art way of solving such a problem in the industry. That forces you to compile their stuff into several different platform DLLs which is a crapton of work and makes the entire building process a pain and beats the platform independence of "one code, build for all".
That and a whole lot of other problems are caused by the fact that Unity has simply a crap C# PI that is completely outdated. And I think that's where the manpower should go, not into reinventing .NET 2.ß and trying to write a garbage collector that has already been done. That API is also a reason why we're question sticking with Unity for any future project. Working with 3rd party libraries is a big pain in the butt if you're working in large scale. Working with async APIs is a big pain, the enitre naming convention is a joke and the problems with splitting behavior hierarchies across DLLs is also still not fixed. All that is amateurish and not exactly what we'd consider future proof so we'd really like to see some indication that Unity is actually aware of this and working on bringin Unity into the present, not even talking about the future.
Most of these problems will probably not be faced by very small indies working on very small code bases but if unity really wants to be the one of all engine for small to big projects, then a LOT has to change. And frankly, even small indies could benefit a LOT from supporting some of the new .NET stuff that is optimized for mobiles. the latest visual studio has profiling of battery use of your code. you can hardly use that if you can't compile your code outside of unity without major problems, can you. MIGHT be interesting for mobile game developers...

 

See at that has always been the problem with the industry's attitude in my opinion "Yeah we know there's cool stuff out in the REAL IT, but we're kinda used to working with this crap you know?"
I've heard that a thousand times, and I never understood why the gaming industry is happy with being always 10 years behind the rest of the kids. Old compilers, old runtimes, old design principles, not testing, no nothing. Sorry but maybe that is the reasony why the industry is constantly bleeding talent and why most game developers leave the industry after less than 5 years. Talented and motivated people don't like working in that environment unless they love working on games really that much that they don't care or have done it so long they don't even see the glaring difference anymore.
And yes there might not be that much of an alternative around... yet... from what I know microsoft had interest in UNity? at least a rumor? Well they didn't get it but obviously the saw the point of having it. And they have a cooperation with Xamarin, which they made shortly before trying to aquire Unity. MAYBE they'll try one of they're own, I don't know. Maybe someone else will. Maybe Epic will come of with some new stuff at some point that kills it all or make a deal with MS/Xamarin, who knows. All I know is that Unity's biggest advantage over its competitors is sure as hell not its great power. it's its ease of development and the fact that you can leverage the C# knowhow of a huge developer base to work with it. If that is left to rot, then good luck with the competition. Because if I can choose between crappy dev and high power or medium power and great dev, I'll choose the latter. If the dev is meh on both ends I'll rather take the one with the more horse power.

 

Haha, wow. That's growing to be a hell of an extended rant.

 

Hey... I'm hungry and uh...somebody had to...

on a more serious note though. I really like working with the engine so far but I've also run into dozens of major limitations. And every single one of them is due to crap API, bad C# support and lack of most recent Mono runtime support.
So yes I like Unity a lot, but I also see where the major problems are that NEED to be adressed for the engine to remain cool. I never rant about stuff I don't care about

 

You have no evidence of this.

1: Switching mono version take a significant amount of work on Unity's part. There have been blog posts about how hard it is to switched. In the past they were slow to change as well, because they maintain their own bug fix branch of mono.

2: Unity wants to make sure that the new mono run time GC etc. Is in a good state and will in fact be an improvement. Because once they switch they will be stuck on it till the next major unity version generally 2 years plus.

3: Licensing issues. You really don’t know anything about this Unity may have not even contacted Xamarin yet; which is the most likely scenario.

 

Exactly.

If you're coming to Unity with it's decade old .NET API (along with the state of Unity's own APIs) and alpha quality GC from within the gaming industry where you may have been using Torque or UnrealScript, things seem pretty decent, though still quite painful in many ways. But you're used to living in constant pain, and, like all the motley fools in the "Why you should be using version control" who are backing up their projects on USB sticks, may not even know that there's another way.

If you're coming to Unity from a background as a professional programmer in any other domain outside of maybe mainframe COBOL maintenance or LOLPHP, you're going to be absolutely shocked at how people live and what they put up with. Outside of gaming, productivity and the ability to write clean maintainable code is constantly progressing and is considered PARAMOUNT, priority ONE, and frameworks / stacks that stagnate in that regard lose market share as more productive frameworks are used for new projects. Especially at the leading edge companies where talented programmers want to work.

Unity is in a position to be the head-and-shoulders above the competition leader in productivity, time to market, and developer happiness and an engine good programmers demand to use by leveraging all the truly hard work done by MS and Xamarin. And that would be awesome for everyone.

 

Exactly my point. And frankly, I just don't want to end up in the position where I feel sorry that Unity WASN'T bought by Microsoft (if that was really who made the offer, haven't kept reading up on that). Say about MS what you will but in terms of creating tool and environments where developers can be incredibly productive they are by far number one out there with long time nothing between them and the next guy.

XNA may not have been fantastic in several ways but it sure as hell had a well designed API.
Unity is my "light in the tunnel" for a game technology that could be duking it out with the rest of IT and keep up, and the integration of Mono and C# is THE reason for that. There is no other major engine out there that uses a main stream application development language for its scripting (And no C++ is no longer a main stream app development language, it is a main stream system development language, there's a difference).
Using C# alone is a major part of what made Unity so easy to connect to and what drew such a large developer base. If that is neglected and the good old "we're game devs, we don't need all the new stuff" crap is creeping in again (which obviously has happened to some degree already), that chance is completely wasted.
Unity constantly pat themselves on the back saying they have such great, talented people working for them. Well, engine designers maybe yes. system programmers maybe yes. I have yet to see proof of anyone great in designing frameworks and API. Guys.. if you haven't got someone, hire someone. Your API is simply crap, sorry to say, your scripting support is crap, sorry it say.
I'm not saying integrating a newer Mono and redesigning the API is easy or won't cost a heck of a lot of money and man-hours. It definitely will. But it should be on a very very very high spot on your priority list because THAT is where your future is. Microsoft doesn't keep their number one spot by always being the first or being the most innovating (as we all know), but by being the easiest to develop for and by having the absolute best frameworks and development tools out there.
Unity is not helping themselves become the number one development platform here. Some of the scripting looks like Unity has never even heard of interfaces, multi-assembly frameworks, extendable applications, generics, dependency injection etc. While the technology works very well, the API and the framework look like they're been written by a 12 year old, and no I'm not kidding. To anyone coming out of professional programming that API is something I would fire people for.

So in my opinion updating the runtime to the newest version (not a newer, to the newest, being AGAIN 10 years behind, this time just a bit further forward won't help a bit) and redesigning the API should be number one priority for Unity 5 (obviously too big a task for Unity 4.x). Nobody will complain if Unity 5 breaks backwards compatibility if that means we get state of the art technology and a framework that competitors can only dream of. You'd draw a major portion of professional developers out there who may be interested in gaming but not at the price of lagging behind.

There is one big issue people don't seem to understand. Some developers might be enthusiastic enough about games to accept old technology, yes fine. BUT I've seen what happens to people who work with that stuff too long. They completely lose touch with the industry, don't visit or watch conferences anymore, they don't read up on stuff anymore because "we're not gonna be able to use that anyway for the next 5 years". And after just a few years these guys are completely unable to find any job OUTSIDE of the gaming industry, even if they wanted to. Why? Because they have no idea what's going on anymore, and nobody needs someone like that. Does Unity want to follow this sad tradition that drives talented people away every day, or does Unity want to be the leading force in bringing gaming into the present (and the future but... don't start dreaming about innovating anytime soon. You have to catch up with a whole decade of advances first of which there is no sign whatsoever in your framework).

 

And just because the question "what do you need it for anyway" has arisen that often, a few examples:

DFGUI/NGUI and others cannot be easily integrated if you have your code compiled into an external DLL because there's no DLL containing the API to reference.

Solution with proper .NET support: Create one DLL with the base classes, interfaces and factories using an IoC container and dependency injection. Keep the actual implementation in source code inside unity if necessary, compile all the API into a DLL. The game developer can work against that API without ever caring where the implementation comes from. At runtime it just has to be somewhere, IoC detects it, binds it, provides the appropriate implementation for whatever the current environment is since that's what Unity will compile it to, using all the compiler flags inside the implementation code. Problem solves. This is done everyday out in the industry. It's not like this problem is anything new.

Writing more stable and maintainable code: Solution: First of all get rid of this idea that we cannot easily use the MonoBehavior constructor, because that's where dependency injection hooks in. We cannot decouple behaviors from the rest of the system easily because we can't access the constructor. If we're not supposed to construct them, fine, but put an IoC container natively into UnityEngine.dll that we can access and which will instatiate the behaviors to we can inject dependencies into them. Being able to instantiate them for testing reasons would be a lot easier if most of the dependencies of the behavior would rely on dependency injection instead of some hardcoded reflection whatever magic that puts low level engine stuff into them. That way people don't have to trick around to make those easy to test without having to mock the entire engine away all the time.
Also newer .NET support would bring in MEF and expecially CodeContracts (never worked with them? Then look em up, using the static analyzer for code contracts alone will open your eyes on how crap and volatile some of your game code is in some places and is in my opinion even more useful than any unit testing in the world, because it forces you to think very very well about how your stuff works together and what the expected inputs and outputs are).

Responsiveness: For god's sake take a look at modern stuff out there, maybe Caliburn Micro, to see how to properly design a coroutine based API. Better yet, bring the newest Mono in and redesign your API to use async/await and also take a look at Rx (if you've never heard of it, do your homework)

Splitting a large project into multiple assemblies: You're out of luck if you have a behavior hierarchy spread across those. And that could even be as small a thing as having one base class for all your behaviors in your cross-project "framework.dll" and then derived stuff in your game.dll. Won't work. Unity will not find them. That puts a heck of a lot of issues in your way of designing a maintainable framework for your own games.
Solution: Properly support multiple assembly-code. It can't be that hard to let reflection detect what the base class of a type is and where that base class lives.

Those are just a few useful things or problems that people seems to constantly run into. And I mean people, not just us. I googled for every single one of these issues when we ran into them and there were entire forums filled with questions about this exact issue and several conference talks discussing them as gotchas. So those are real issues faced by a lot of developers and currently everybody has to work around them. That's BAD. Especially since every single one of these issues is a totally trivial thing in the software industry. Those are completely typical problems and the solutions have been around for years if not decades. And it is made incredibly complicated in Unity due to lack of proper runtime support and bad API and architecture.
So yes, there's HUGE benefits, especially for larger projects but also for very small projects.

They can make your life incredibly easy, they improve the code quality, the maintability, extensibility, performance, everything. All those innovations, patterns and solutions haven't been developed out there just for the fun of it you know. They're solutions for real problems that are faced by devs every day and I don't understand why people always believe games are some sort of special breed of application. They're not. They're simply not. So if we're facing the exact same problems as everyone else, isn't it kind of silly not to use the exact same solutions?

 

At the moment Unity just has a licensing issue. I would be surprised if they didn't work on that matter. They are aware how important Mono is in Unity.

 

It's quite clear that you care. And hey, if I didn't care I wouldn't have even responded.

But I don't feel that there was any need to knock my level of talent and/or care and/or professionalism, or that of my peers and colleagues. There's plenty of cowboys out there to be sure, but that's not all of us.

As I've said a couple of times, I would indeed be happy if this stuff was upgraded. However, as you've said, Unity is on the whole a great package. And when it comes to productivity it already is head and shoulders above most if not all of the competition. That's not somewhere they need to get, that's somewhere that they are - but which they do definitely need to defend!

As for why talent leaves the games industry in droves... I can assure you that using old tools is way down low on the list. I'm lucky in that for the most part I've not been in the parts of the industry where the working conditions are S***, but I know second hand about the S*** conditions and the complaints have never been about outdated tools. They've been about the ultra-competitive nature of the industry and the 60-to-80 hour standard work week and management structures (inside or outside of the studio, or both) making stupid or unrealistic decisions. I don't care what the job is or how awesome the tools are, I wouldn't put up with that, and to be honest I don't understand why anyone does.

 

Actually Unity does not even have the choice. If they don't plan to update the mono version they use, then Unity is already dead.
If this is the case, then please Unity developers, let us know it quickly so we can move to another engine as early as possible.

It's pretty clear that there are some solutions. Mono developers are not stupid and know that some companies need commercial licenses: http://xamarin.com/licensing

It's already sad to see how outdated the mono used by Unity is.

 

Unity will update at a certain point, that's for sure. Do you really think they are not aware of that?
The license link that almost explodes your post is the kind of license that Unity already has for the outdated Mono version. This is very likely just about money. I expect that Xamarin simply wants more money than Unity is willing to pay. At the end it is also to our advantage that Unity is getting a good deal that hopefully lasts for upcoming versions as well. The less Unity pays, the more will they have for the development of Unity.

 

no offense dantus, but I kind of feel you are missing the point. first of all, I must've missed where they said explicitly that they would be updating, when and to what.

and that in a nutshell is what's got folks riled up. myself personally, I want them to update to a version used in *this* century, not a next step version used 10 versions ago..

 

Unity would run with newer versions. For some platforms they even used newer versions of Mono, but now all the platforms are using the same version again. Here and there you find signs that they would like to update. The reason why they don't talk officially about it is pretty obvious for me. They are talking to Xamarin. They can't shout out that they are going to update because they are negotiating. If they announce anything, they weaken their position and Xamarin could charge even more for the license. That's business, that's how it works. It takes time, we all hate it, including myself, but we can't change it.

 

I think it is pointless to ask about updated mono, they will say nothing about this, be it for the negotiation or some other reason. I just hate been left in the dark... It will happen or not.

Another surprise the other day was that System.Net is removed from mobile publishing in the free version. I think it is fine for ut to remove things they implemented but a feature from a core class lib? Pretty cheap if You ask me. Given the state of mono in unity it is like taking a wheel chair from a crippled.

All this old mono, horrible mono develop, old physx, unstable 4 version among other things the illusion of a great indie engine is starting to fade, the ad bubble is starting to burst. I bet we will receive another or several "cool" features (audio system hasn't received any stuff for awhile, maybe a mixing desk?) before we get update on mono if ever.

My post might seem a bit harsh but the struggle with Unity these days is a bit much, I'm beginning to doubt my decision to use Unity in the first place.

 

Dantus,
It's already happening, Xamarin knows that Unity have a very outdated mono version and mono is really tied up to Unity. If Unity announce they are about to license a new version of mono it won't change anything.
Unity is at the mercy of mono. And they must find a way (if not already done) to free themselves from Mono by either, buying Xamarin itself (yeah that sounds crazy and costly but still an option) or by providing direct access to their C++ API (with an option to automatic memory management).
I remember long-time ago when Apple was enforcing applications code, Unity presented a solution in C++ with some example code which appeared to be pretty darn awesome.
Anyway, being a new mono version, C++ or C# support isn't that much of a problem (at least to me). I think the biggest problem here is the way Unity engine is designed. The Editor is pretty nice but the Engine itself (as lot of people already pointed out) have lots of limitations and requires heavy re-design.
Don't get me wrong, Unity it's awesome, but it could be gazillions times better!

 

C++ access isn't a solution at all, except maybe for very very specialized stuff. We're writing applications here, not low level engine features. You don't need the C++ low level stuff for application development. C# is a much better language for that, as long as the runtime behind it is up to date.

But I agree that Unity is pretty much at Xamarin's mercy right now. And I see only two ways out of that. Either Unity hires a really big team to build their own version of the .NET runtime and compiler, after all they are open standards... or they bite the bullet and pay Xamarin for the work that's been done. I'm sorry but Xamarin and Microsoft in a cooperation seem to promise a lot of high quality development and a great future for cross-platform C#/.NET development and that simply has its price. unity has the chance to be THE gaming platform on that platform family (and let's face it, .NET/Mono has become its own platform now, just as much as Java.) Since the deprecation of XNA there doesn't exist anything like that anymore, let alone an industry level engine. If the buyout offer came from Microsoft that makes it kinda obvious that even the big boys have recognized this. Having this spot is a big luxury and staying in it should be worth something to Unity. So they should make a deal with MS and Xamarin to form a cooperation and stick with it. There's certainly a way to do that. These guys can only profit from games being developed for their platform.

As for the C++/C# thing... again, this isn't about language. I'd happily accept having to use C++/CLI to program for Unity. Wouldn't be my first choice but why not. The issue is not the language syntax, it is the power of the runtime and libraries behind it. And that's what's lagging behind the most. Sure it would be nice to have some of the newer language features as well but those are not the main issue. Issues are outdates compilers, runtime (especially GC) and libraries. AND an updated API. The Unity API could make use of MEF for extensibility, especially for extending the editor, but also for hooking up manager type classes that are not used in any game objects. Why is that not being done? Third party developers could use MEF to link into the framework. Using third party stuff is outright awkward right now,especially because some people have trouble even useing namespaces. That clutters everything full with crap code nobody wants.
If the editor itself was written in a nice WPF based MVVM style, adding editor windows would be a breeze, actually using XAML sinstead on this OnGUI crap where every control is hardcoded... geez. People could easily offer skins and styles for the editor, offer control-libraries with extended color pickers and all kinds of cool controls. But noo, outdated crap wherever the eye can see. That's just not cool.

I'm not saying, as implied by someone earlier, that every Unity dev and gamedev working with Unity is an amateur and doesn't know what they're doing. Not at all. But I see an awkward complacency regarding the state of Unity, its editor and API. As if everything was soo cool and indie friendly. Sorry it's not. It's awkward, has S***ty API and makes tons of workflows much harder than they need to be as soon as you move past a simple breakout-close sized project. I'm not saying things can't be done with it. I'm saying things are much more awkward than they need to be and I'd simply like to get SOME communication from UT that they are actually aware of this and putting some work into doing something about it.

I know from personal experience that you develop a bit of a tunnel vision when working in a closed up environment on a project so I think it is important that we as "customers" let the UT know what the major issues are that absolutely NEED adressing. And updating Mono AND updating the Engine AND Editor API is the biggest issue by far right now in my opinion. And I think a LOT of the awkwardness of the API also lead to the constant delays in GUI development since UT is no obviously running into the limitations of their API themselves.

 

What are the licensing problems? I quickly skimmed over http://mono-project.com/FAQ:_Licensing and two libraries are MIT / X11, the runtime is LGPL2 which should allow commerical use and only the tools are GPL.

 

Beside freeing themselves from Mono and buying Xamarin, they may also fork. As the majority of Mono is released under MIT, they could keep those parts and reimplement just troublesome LGPL parts. In that context, "just" means quite some work. But financially it wouldn't be such a big deal for Unity to do their own thing.
If Unity can prove to Xamarin that they don't depend on Mono, they will be in a stronger position. Xamarin would not be interested in getting a direct competition, which Unity could be or become if they had their own .NET implementation. Sure that's probably not what Unity wants, but from a business point of view, it would make a lot of sense to be in a strong position for the negotiation.

I am too aware of that

 

LGPL can't be used for mobiles.

 

These troubles are also proof enough that the entire GPL family of licenses is as far from "free software" as you can be. They are a cancer. Whoever came up with those needs to get his ass whipped hard. GPL has done more harm than good. Open means open, free to use means free to use and not "you can use it if you do what I tell you and everyone who uses your stuff also does what I tell them"

 

And to add to that, likewise for the game consoles that Unity supports (no dynamic linking, from what I understand).

One of the UT engineers voiced his opinion that they'd rather not fragment the codebase with "some platforms can use the latest Mono, some don't" (probably a maintenance nightmare).

It's already fragmented a bit with having DX11, which obviously only works in certain platforms, and I guess they don't want more of that.

 

Do you have any reference on this? It looks like a false claim to me. For instance, the library Qt for Android is LGPL licensed. WebKit, which powers Safari and Chrome is also LGPL.
From what I know, Unity's use case should fit with this license.

 

You cannot link to them in the way necessary for LGPL to remain a free license. On mobile the LGPL would force you to publish your source as well, which means the unity code and the game code of anyone working with unity. And that's obviously crap. As I said, LGPL is a horrible license.