Since people are glossing over it, I’ll quote directly;
People could just be prepared to learn C++, rather than wait for an entire fleet of engine changes and legal support which would be horrifically buggy to start with and take years upon years to mature into something really useable, only to end up nothing like Unity’s integration anyway (which let’s be honest, is what most C# developers want because it’s familiar). I don’t think there’s any issue with Mono being supported (note: NOT integrated), but that should be up to Xamarin to cater to the engine like any other plug-in, not the other way around.
My main issue with supporting the language is that it splits the community into yet another programming domain. We already have BP and C++ which integrate very well with one another, and therefore both sides of the community benefit from developments in both domains - even if they don’t necessarily understand all that’s going on. It’s very easy to cross between the two, but the instant you add a third syntax-based language like C# - it divides the community up again. You’ll end up with people posting C# answers to C++ questions and vice-versa, and that won’t help anybody. In fact, that’ll be infuriating.
Before long you’ll end up with loads of projects with an abomination of a code-base crossing three different languages, all of which you expect to talk to each other seamlessly. ‘There be Dragons’.
It’s taken a while to catch up, but you can post a C++ question in the relevant forum section now and usually expect a good answer (providing you’ve at least tried to think about the problem and make a decent, informative post).
It puzzles me that nobody wants to embrace the idea of learning something new, and stick at C++ for a suitable period of time. There’s only benefits to be made from doing so, it’s a language worth learning one way or the other. That’s just the way I feel; I’m usually the first person to jump down somebodies throat if they’re too lazy to put in the effort to learn how to do something or spend some time in unfamiliar territory, since I don’t think that’s a very good attitude if you want to survive, or be taken seriously in this industry.
It’s not ugly, it very simple and logical once you understand what it isl. Pointer is integer with memory address pointing to specific type, if use “.” you referring directly to pointer, if you use “->” you referring to object it points to. In UE4 because object management all UObjects are pointers, so you always use “->” on them, if deal with Structs or non-UObject classes you use “.” or else you using pointer.
The problem with IL2CPP isn’t with the concept itself (native compilation yes, compiling to C++ first no), but the sheer amount of effort that needs to be devoted into such a project to make it viable. That’s effort that isn’t going towards improving Unity itself.
As I said before, I have no doubt it will end up costing Unity more money than it would have to have bought a Mono license.
That being said, even if such a solution already existed I wouldn’t want it to be used for the reason TheJamsh said. Fragmenting the community across more languages merely to cater to people unwilling to learn C++ is not a very good idea.
Bottom line is, Epic is missing out on a lot of potential business because they are lacking C#.
It would be nightmare for Unity if Unreal would decide to officially support C#.
, can you stop with the “It’s the C++ way or the highway” with every thread that wants to discuss alternative language use in UE! Esp. since you obviously don’t use both languages.
Pro C#:
garbage collection
array bounds checking
huge .NET-Framework library
types have a defined size (e.g. a long is 64Bit)
strings are encoded in UTF/16
autoboxing – every type can be treated as if it inherits from object
supports constructor-chaining (one constructor can call another constructor from the same class)
when a virtual method is called in a constructor, the method in the most derived class is used
static constructors (run before the first instance of the class is created)
exceptions have access to a stack trace
advanced runtime type information and reflection
supports variadic functions nicely
built-in support for threads
no need for header files and #includes
no fall-through on switch-statements
arithmetic operations can be checked for overflow if required
objects must have a definite value before being used
attributes can be attached to classes and retrieved at runtime
no forward declarations required, classes can be arranged at will
access to class members / functions is done only by the dot (no more -> or :
conditional functions (e.g. for debugging)
structs and classes are actually different (structs are value types, have no default constructor in general cannot be derived from)
supports properties
readonly members are const, but can be changed in the constructor
finally block for exceptions
arrays are objects
support for anonymous functions
supports the base keyword for calling the overridden base class
Pro C++
better performance
portability
multiple inheritance
deterministic destruction (allows RAII)
any type can be thrown as exception (only classes derived from System.Exception in C#)
ability to enforce const-correctness
implicit interfaces on generics (in C#, generics must be constrained with an interface)
offers pointers (C# only offers pointers in unsafe mode)
support for macros
support for global variables, functions, constants
allows default arguments on function parameters
STL
supports bitfields
IMHO, C# is the better language, productivity is the key, it’s easier program in, faster to get things done in general and less prone to bugs due to its more modern design.
Much of the stuff you listed as Pro-C# is either irrelevant for UE4 dev (example; UE4 GC’s already, .Net lib would not be an advantage), comes with a performance cost/already done (bounds checking isn’t free), or is subjective (struct vs class, inheritance for all the things (fyi; inheritance in an of itself should be avoided anyway, composition is better)).
I use C# a lot.
I’ve also used modern C++ a lot.
C# is a great language.
C# is not The Best At All The Things however.
More to the point adding C# support to UE4 would add additional on-going cost (in terms of code, maintenance, examples, etc) for what might well be little to no gain.
The code engine would still be C++, that wouldn’t change, all you would get are bindings much like the blueprint ones which already exist.
Adding would also be non-trivial in any meaningful sense, again this is cost with no proof of gain.
The way UE4 is constructed, you will find lot of those features useless or unusable in UE4 envriament, because whatever you gonna implement C#, you will be still using UE4 APIs with it’s limitations which sometimes limits C++ too. For example you won’t have all constructor features, because UE4 has it’s own object deployment systems which makes constructors useless even in C++, they just default variable setter. UE4 also don’t use any exceptions support, just series of check() functions that crashes application, so your C# code would go with it. It will also have problem with invoking properties, but i’m note sure about that. UE4 also has implmented some of those features already, UE4 has garbage collection, UE4 has it’s own reflection system, which see classes and struct differently (but in C++ you can normally treat them as classes), UE4 has large collection of APIs making thigns a lot easier, it also own multithreading system, so some features of .NET might be conflicting with UE4.
Also C++ is not portable at all, yes .NET requires ported runtime, but the code running on it will work everywhere, where C++ need to be revised on each platfrom or requires wrappers… UE4 APIs do that for you and .NET/Mono currently supports more platforms then UE4 does (most notably Windows Phone). Ofcorse C# won’t fix that problem in UE4
I would love to see first-class support for c# in UE4 as well but the truth is, UE4 just isn’t a good candidate for c# as a first class citizen. The amount of interop that would be required would be an absolute nightmare for performance and unless you have worked heavily with interop between c# and c++ you couldn’t imagine the type of overhead this would incur. Even going beyond the goto method of p/invoke calls and taking the time to make c++ CLR wrappers for the entire engine (I pity the guys that would get stuck with that one) the overhead would still be too much for it to be feasible.
Simplifying things by making an official c# API with UE4 would be nice for somethings but you wouldn’t be getting the type of functionality you are most likely desiring. It would be a scripting API and nothing more. It may add convenience via familiarity for some but it wouldn’t be worth taking away from the dev teams focus on much more important things.
Personally, I think the better alternative would be that Epic maybe consider for a future version of the engine (UE5 perhaps) to feature c# as it’s primary language from the ground up. It would mean abandoning pretty much all of the legacy c++ that has been dragged along since the beginning but given the shifts in the .NET world recently, it may actually be a feasible choice. It wouldn’t be a simple task to do but the rewards of such could be enormous for both Epic and it’s patrons.
No doubt any suggestion involving c# and unreal engine will draw fire from the usual suspects in these type of threads (lol) but the fact is c# is actually ready for it (almost…). With literally all required components of the .NET framework becoming both opensource with MIT licensing AND continuous porting to basically all platforms of interest to game development, it’s just a matter of waiting for the final release and it to mature a bit. I’m currently a bit disappointed with the limited SIMD support in .NET 2015 due to the last minute pulls they did to basically the most desired accelerated math functions from System.Numerics.Vectors assembly but this was a stability choice for the early access versions and will be reimplemented in final versions. Avoiding c++ entirely obviously wouldn’t be possible because of the need to use various third-party tools such as graphics APIs, physics APIs, etc but the graphics APIs can be wrapped successfully from c# with competitive performance and the licensing of existing and well established wrappers such as SharpDX, OpenTK, feature licensing which would allow for custom builds within a commercial product. The same could be done for physics APIs too, however I’m not sure how the licensing for NVidia would work for PhysX but there are other terrific physics APIs that are terrific as well. The performance argument of c# vs. c++ is negligible now in this day and age. Heck, with the new licensing of the opensourced .NET framework, one could even build their own custom .NET specifically for their engine!
The insanely fast iteration times of a language such as c# are amazing but I doubt this is something we’ll see from Epic any time soon. Unreal Engine is such a well-established platform that it would be very difficult (and a business risk) for Epic to make that kind of change. I’ll be very surprised if I don’t see some company decide to make that move though. For those that dream of a fully-managed c# game engine (not just a scripting surface API) I’m sure we’ll see it happen in the next few years from someone.
Sweeney told everyone some posts back that this will not happen.
A lot of the things said here are true, yes, but I see no point in further discussion now.
Of course we can start another thread about “porting” some kind of functionality from c# to C++2011, but that would be a feature request level not a system level request.
The community should try to find a group of people who could work on the C# bridge, as shared and open source anyone could maintain it or upgrade it to a new Unreal version. C# would produce a faster games versus blueprints.
I would assume that access to their full forums, documentation, etc will be opened up to the public soon, if not already as well.
Entry level is free & you can run both their standard IDE (free) & premium IDE ($200 USD per-seat) alongside each other to save on costs & to get the full use out of bother versions based on who needs which IDE.
NOTE: You can build an entire game from start to finish with the standard IDE (free) if you so choose, so we are not looking at crippleware here.
So , just stumbled across this thread… what would you say if someone actually integrated Microsoft’s clrcore/roslyn(vb & c#) with UE4 and made a plugin that was free (and came with source) and it was obviously cross-platform. The license seems to be… MIT. Would that get you excited? If I could get something like this off the ground, and it was well mature, would EPIC be interested in helping with any final integration issues? Just wondering because it DOES seem like an opportunity. I might be up to the task.
The other thing to consider for this conversation; because of all the back-end goodness that C# brings to developement, porting core over correctly is not trivial. Mono made this easier, but:
a. Xamarin do not want to be free (so they are out)
b. MS CoreCLR port would require the garbage collector playing ball with EU4 memory subsystems, including UE4 life cycle of objects etc
c. Not sure what is included in the core compiler set, including whether there is an ARM target compiler in there or even a AOT compiler of any kind. Remember you cannot run interpreted or VM code on iOS, or at least distribute on the appstore with that (unless this has magically changed), which would be awesome
d. We have no IL2CPP equivalent, maybe we will need to because of performance?
e. Is a C# syntax to C++ language on-the-fly conversion a better option (so exactly like a IL2CPP)?
Don’t know… just running some things around in my head. What do people think?
Only caveat (and it’s a big one) is that this only supports Windows. Hopefully one of these days someone takes advantage of the CoreCLR, but that might not be far off.
You basically created another language called “blueprints”, how can be C# meaningless? proof of gain? what about your main competitor?
Microsoft supports hundreds of languages and not just CLR (look what Azure support, visual studio, win 10 apps),
I’m not sure how they do that but I presume that they expose a well made set of API.
Xamarin for example could simply map to those API.
My impression is that everytime there is a version upgrade, everything can change, everything can became deprecated and being “open source” doesn’t help as much as a consistent set of API.
Of course this is just my guess, but really… saying “no proof of gain” seems more of an excuse
