C/C++ plugins, Mono, .NET 1.1 and .NET 2.0...

Unity Engine
1

Hi there,

I was wondering about a few things. First of all, what is the difference between C/C++ plugins and scripting in C#? If I don’t like C/C++, does that give me any serious disadvantages concerning what I can do with Unity3D (concerning functionality of the game itself, not the IDE), or could one basically say that what can be done with C/C++ plugins can also be done with C#-scripts or C#-DLLs (or any other .NET language)?

When I understand it correctly from the documentation ( http://unity3d.com/Documentation/Manual/Plugins.html ) it’s more like the plugin functionality is for people who prefer C/C++ over C# (um… which is something beyond comprehension for my little Java/C#-infected mind :wink: ).

Second question is: as far as I understand it, the C#/.NET-support (maybe even JavaScript support) of Unity3D is based on Mono. Since Mono is somewhere in between .NET 1.1 and .NET 2.0, would that mean that some (or most) of the .NET 2.0 API is not available in Unity3D? Specifically, System.Net.Sockets.UDPClient would be important for me :wink:

Also, what about the new C# language features that came with .NET 2.0, like generics and the like (nullable primitive types are also quite nice)?

And: even if those may currently not be supported by Mono, would they be once Mono “gets there”, and would it be possible using the power of .NET 2.0 at least on windows machines until then (without making working with Unity3D on the Mac really complicated).

Hm… as I can see from http://www.go-mono.com/archive/1.2/ Mono 1.2 implements the greatest part of .NET 2.0, so maybe the question should rather be: does Unity 1.6.1 fully support Mono 1.2?

Still, looking at some of the “API-addons” that come with .NET 3.0, the question of “is it possible to have Windows.NET features in a Unity3D game” remains. And, if so, would there be a convenient way to still publish Mac OS versions (with a little less features, maybe) aside of Windows versions? I’ve had that extensively doing J2ME development for mobile phones (e.g. somes phones do support 3D, others don’t - in my case, I could then have one build with 3D, and another one without, done with pre-processing the sources).

Finally: will much of that change in Unity 2.0?

Oh, sorry, one more: somewhere in the documentation or forums I read that JavaScript is somewhat preferable over C#, and it seems like most examples are JavaScript based. Is there any specific reason for this, or is it just the way it currently is (I’m doing a lot of Web development using C# on the server and JavaScript clientside, and I must admit the word “JavaScript” does give me a little pain by its sound alone :wink: ).

Sorry for the many questions… it’s simply because I’m getting really enthusiastic about Unity3D :wink:

If there’s any documentation (or forum threads) that answers my questions, I’ll also be quite happy with links (I did research the forums and docs a little bit, but may certainly have missed some things) :wink:

Kind regards,
Jashan

2

Whoa. Long post. Let me try to get you some info.

C# / JavaScript / Boo is THE way to use Unity. The C++ plugin functionality is more for adding in 3rd party libraries (want to get input from a midi keyboard? use plugins). The game logic is done in a .Net language.

A.t.m. Unity is .Net 1.x only, AFAIK. Whether or when the more advanced options come in basically depends on how much the new features add to the download size of games or the web player (e.g. if .Net 2.0 adds 5MB to our 3MB player, it’s not coming in). The jury is still out on that - my personal feeling is that .Net 2.0 is quite a bit nicer, but that’s all it is. Nicer. We’ve made a pretty large game with .Net 1.0 and we didn’t need any particular language feature.

Not sure about the .Net UDP client thingy, but most likely you can gum it in someway as a DLL.

The main reason we recommend JavaScript over C# is that it’s easier to get into. Out javascript also has some nice features (esp. type inference) - so its less hassle to use. We’ve used C# at Serious Games. It’s a matter of preference - Unity doesn’t really care :wink:

3

Hi Nicholas,

thanks for shedding some light on this. Being able to do everything I need to do in C# feels really good (I don’t need access to external plugins for now :wink: ).

I can see your point, but I have a different perspective: Taken to the extreme, anything could be done even in assembly language - but it’s quite a bit less convenient. I’m not saying 1.0 is like assembly language, but I do think there still is a significant difference in “convenience” between .NET 1.0 and .NET 2.0. And a significant difference in convenience means: saving significant development time (= money) and headaches.

For instance, collections without generics can be a nightmare if you “somehow” get objects of a class into the collection that simply isn’t expected (giving you sporadic type cast exceptions). With generics, the compiler says “no thanks”. So such a bug can’t ever make it into the runtime.

Without generics, you may spend hours to find out how this nasty object got in there (especially annoying with sporadic bugs that occur only once in a while).

Of course, there’s constructs around that even when you only use 1.0 - but implementing these also takes its time (and with that, mistakes also can be made).

I do understand your point about not adding maybe 5MB to a a 3MB player. This sure is not a decision made easily. But I would still love to have .NET 2.0 as an option - even if it did triple the download size of the player (which I don’t think it will). A checkbox somewhere in Unity’s project options that says “support .NET 2.0” or the like. And if you click that, your app needs the “heavy version of the player”.

That way, people who don’t mind using 1.0, but who do mind requiring a larger player download can create for 1.0 - while people who don’t mind requiring a larger Web player (or who are developing stand-alone games), can switch to 2.0. Use any choice at your own risk :wink:

Naturally, games that require little custom coding would probably be very fine with 1.0, while games with a great deal of custom coding might be build quicker and less painful with 2.0.

I’m aware that this does add complexity to the IDE, though… There sure is a good reason that it’s not possible to develop for .NET 1.1 with VS.NET 2005, but maybe Unity3D is different in that :wink:

4

I just want to say that having a light version and a heavy version of the web player sounds so horribly bad to me. Support problem. Perception problem by users (Didn’t I JUST download this plug-in?) Unnecessary complication. It’s sort of up to the Mono(cross platform .NET) developers to keep the size down and they very well may do that.

On the flip side I’d love any and all advantages of .NET 2.0. I’m sure the Unity guys will make an intelligent and helpful decision about this. They’ve done a good job prioritizing so far, IMHO.

I really don’t think maintaining two versions of .NET is the way to go, though. Another issue that comes to mind is the occasional need to give coding solutions that work better for 1.0 AND 2.0 in places like the manual, the script wiki, etc.

Of course, the best outcome would be that supporting 2.0 adds little to the webplayer. Then, everyone’s happy.

5

Giving this another thought, I fully agree to that… I only took into account the added complexity it adds to the IDE, which probably is already quite significant - but with the whole picture in mind, supporting both 1.x and 2.0 seems like a definite no-go…

Well, so I’ll pray for 2.0 support on a daily basis from now on :wink:

6

Funny you should mention the generics thing. We got bit by that on GC:Palestine - late in the dev cycle we decided to switch from int to floats throughout our internal scripting system. All variables were stored in a huge map, so was so hard to track down. It was one week of sheer utter horror debugging. I’d loathe to do it again.

But lets look at it from another perspective:

one dev. week out of 2 people working for 20 months. That’s about .58% that would have been saved. This project is about 14000 lines of C# code, so its not because of lack of size.

Thinking through the code, I can’t really see other places we would have benefitted, so in this project (which is the largest Unity game to date), the total saved is neglible. All the niceties don’t really add up to all that much saved time in real life.

Not that it wouldn’t be very, very nice, though…

7

I’ve posted about this before, I’m in favor of switching to 2.0 and the reason is simple: usually people develop .NET things in windows environments with the 2.0 version, and I can’t connect these libraries with unity. I will have to create some sort of communication layer or downgrade the library to 1.0.

Although it is possible, both solutions are horrible, specially the second.