That is nice. I have just one question, what kind of stuff will you wrap and how will you do it?
(I am not a C# guy so it might not make sense what I am asking)
Will you try to wrap every unreal class like AActor? I don’t know how hard this will be and maybe it’s even easier to wrap these things in C++ cli. Or will you wrap the lower level engine stuff like accessing the mouse, FVector etc and then rewrite the gameplay code in C#?
Either way this will be a huge undertaking and I am willing to help.
Mainly to learn about the engine more. I don’t really have much to offer 's project yet, since I only just started. My experience with embedding Mono until this week had been zero.
We also don’t know when will release his version, so I figured I’d at least try get something working until then.
Why do you need C# bindings? Honestly C++ isn’t that complicated to use…
You really just need to get used to the interaction between classes and pointers across your project.
The only real annoying part is having the rebuild your project and re-open the editor any time you add a class/variable. The better you plan your project, the less this will effect you.
Why not? A lot of people are better at C# or just like it better for game development. As it is the primary language of Unity it will also make the transition from that engine to UE4 easier.
I myself eagerly watches the progress of these initiatives for all the above reasons.
We are currently looking at releasing v1 of our C# implementation by June. We are also planning on an evaluation, indie, and pro build of the plugin.
Great to hear how ambitious the community is with embedding mono. One word of caution is on the GC side of things. You’ll want to use SGEN for an embedded Mono implementation. Otherwise you’ll start running into memory thunking issues pretty quickly. Embedding Mono is no small task in UE4 and requires some serious thought as to what the outcome should be for UE4 developers. Are you looking calling the engine or calling the C# DLL? What about integration with BluePrints?
Also another word of caution. Our solution takes advantage of the existing macros in the engine used for declaring BluePrint exposure such as UFUCTION() UCLASS() UPROPERTY() macros decorated across the codebase using a clever little macro setup that is engaged by the UBT.
================
Right now we have a C# based UE4.DLL which can be included in any standard C# compiler as well as used by our own compiler built directly into the UE4 Editor. On the C++ side we have a MonoRuntime and Script Engine Plugin for Engine as well as a Script Editor Plugin for Editor.
The UE4 C# library currently as it stands binds to the entire Game Framework sanely as well as any inherited classes that the Game Framework uses. So this includes common game logic UClasses like Actor, PlayerController, and Pawn (just to name a few). We have also binded Core and several other necessary parts of the engine.
You will have a few setup steps in C++ before you can begin using the Plugins with your game. You’ll need to setup the Plugin in your Game DLL. We are working on ways to overcome this step to make this feel as natural as possible to C# developers.
We also provide a Script Editor which lives inside of the UE4 Editor which allows developers to write and compile C# directly in UE4! We use the mcs to compile C# scripts into DLLs which are placed alongside the C++ Binaries.
We are shooting for the most natural Unreal Coding experience possible in C#.
Thanks for updating us. Can you provide more details on how you plan to licence this? I really hope you don’t plan to close-source your C# implementation as I think everyone here is keen to keep the open standard Epic has set in their commercial pricing model. Otherwise I think its a great idea to commercialize it - Should mean a more solid implementation on your part and if you keep it open I’m sure your customers (Us included) will be happy to contribute.
I’d assume with the eval, indie and pro he mentioned. Evaluation will be just that. Indie will be a closed source license and cheap. Pro would be open source and cost more.
I’m not against C# at all, I’m being realistic. If you wanted a slow engine why aren’t you using Unity? Anything larger than a non trivial project in Unity runs into memory issues.
Do you know anything about VM’s?
In C++ you have deterministic control over memory but not in a C# VM. How do you bind UE4 memory control system to a VM so that get the 2 to synch and not cause performance problems?
You need to introduce some form of determinism which will take it out of C# VM spec. See here memory management: Common Language Runtime | Microsoft Learn
