I want Feedback from Epic about Mono for Unreal Engine

Hi there,

I posted a few posts here and there without success so I decided to start a new thread…

As many of you already know have been trying to bring C# to Unreal Engine via Mono, by exposing the Blueprint-exposed Unreal C++ code to C# (https://mono-ue.github.io/).

Unlike the various attempts already made by the community to provide scripting capabilities is a very serious project which also offers a lot of potential – especially since the decision from Microsoft to open-source the .NET framework and to cooperate with the actors of the .NET foundation (including ) in order to democratize the use of .NET as a multi-platform development framework.

As far as I know from reading the mailing-list of project, the development stage is still experimental and is rather a proof-of-concept in order to convince the open-source community to contribute to it.

More than anything I would like to hear any comment from Epic about …

Are you planning to support project accordingly to its potential ? And if not, could you debate your decision ?

We know that if Unity still exists it is because many developers are not willing to leave their C# comfort zone – C++ is really a no-go for many of us…

At least, I would really like to see added to the roadmap in order to expose it to a community vote, I’m sure you’ll be surprised to see how many of us badly wish to script UE4 in C#.

Regards, .

PS: Please for those that are not from Epic, do not start a debate C++ vs C# here, is not what thread is about.

Honestly, the usability of C++ in Unreal is top-notch. When I first started using Unreal, I was afraid of C++, but as I stared to use it I became comfortable with it very quickly. I really don’t miss C# that much. The only huge, real, tangible gripe I have is with compile times - I really do miss the 5-second compile for even large projects in unity. In Unreal, it’s a minimum 20 seconds even with Hot Reload.

I haven’t had a to try the mono implementation because it supports older versions of Unreal and my projects need 4.6+ features at point, but it is very promising. The sub-second recompile is one thing I wanna get my hands on! But in the end, I feel like the project may end up just as buggy, if not more so, than blueprints so I might as well just use those. Though is, of course, my own baseless conjecture.

[=matmuze;194059]
Hi there,

I posted a few posts here and there without success so I decided to start a new thread…

As many of you already know have been trying to bring C# to Unreal Engine via Mono, by exposing the Blueprint-exposed Unreal C++ code to C# (https://mono-ue.github.io/).

Unlike the various attempts already made by the community to provide scripting capabilities is a very serious project which also offers a lot of potential – especially since the decision from Microsoft to open-source the .NET framework and to cooperate with the actors of the .NET foundation (including ) in order to democratize the use of .NET as a multi-platform development framework.

As far as I know from reading the mailing-list of project, the development stage is still experimental and is rather a proof-of-concept in order to convince the open-source community to contribute to it.

More than anything I would like to hear any comment from Epic about …

Are you planning to support project accordingly to its potential ? And if not, could you debate your decision ?

We know that if Unity still exists it is because many developers are not willing to leave their C# comfort zone – C++ is really a no-go for many of us…

At least, I would really like to see added to the roadmap in order to expose it to a community vote, I’m sure you’ll be surprised to see how many of us badly wish to script UE4 in C#.

Regards, .

PS: Please for those that are not from Epic, do not start a debate C++ vs C# here, is not what thread is about.
[/]

is a commercially-licensed product put out by another company. The most you will see from Epic is checking over pull requests to ease integration. Keep in mind, everything in UE4 was either developed by Epic themselves, or is freely available with good distribution terms. Mono is another product, much like FMod, Enlighten, Scaleform: you need to license it separately, and it is the responsibility of the plugin maker to provide support.

[=;194092]
Honestly, the usability of C++ in Unreal is top-notch. When I first started using Unreal, I was afraid of C++, but as I stared to use it I became comfortable with it very quickly. I really don’t miss C# that much. The only huge, real, tangible gripe I have is with compile times - I really do miss the 5-second compile for even large projects in unity. In Unreal, it’s a minimum 20 seconds even with Hot Reload.
[/]

Come on guys, again, is not the right thread for a debate C++ vs C#.

[=;194092]
I haven’t had a to try the mono implementation because it supports older versions of Unreal and my projects need 4.6+ features at point, but it is very promising. The sub-second recompile is one thing I wanna get my hands on! But in the end, I feel like the project may end up just as buggy, if not more so, than blueprints so I might as well just use those. Though is, of course, my own baseless conjecture.
[/]

As I also precised in my previous post the current status of tool is very experimental, and they clearly specify on the web page that Mono for Unreal Engine it is not mature enough to ship games.
The problem is that they lack the man-power to develop the tool to a state of maturity, therefore I wish to see a tighter collaboration between Epic and on project, instead of having some kind of “Cold war” like with Unity and .

[=RPotter;194144]
is a commercially-licensed product put out by another company. The most you will see from Epic is checking over pull requests to ease integration. Keep in mind, everything in UE4 was either developed by Epic themselves, or is freely available with good distribution terms. Mono is another product, much like FMod, Enlighten, Scaleform: you need to license it separately, and it is the responsibility of the plugin maker to provide support.
[/]

I get your point, and I am aware of those licensing limitations, however many people might actually be okay with those terms…

I also reckon that would profit to a third party company, but is also the case for Unity right ? As far as I know those guys profited A LOT from fruitful collaboration with …

Furthermore you cannot simply compare C# scripting with FMod, Enlighten, Scaleform, since they do not usually represent a “deal-breakers” functionality – I am very much convinced that I am not the only one craving for …

However, if Epic is not willing to help a 3rd party company to develop product and at the same leverage the usability of their engine, then they are making a big mistake in my opinion and that is clearly a spit in the face of those thousands of modest coders that would like to grab their hands on engine.

[=matmuze;194237]
I get your point, and I am aware of those licensing limitations, however many people might actually be okay with those terms…

I also reckon that would profit to a third party company, but is also the case for Unity right ? As far as I know those guys profited A LOT from fruitful collaboration with …

Furthermore you cannot simply compare C# scripting with FMod, Enlighten, Scaleform, since they do not usually represent a “deal-breakers” functionality – I am very much convinced that I am not the only one craving for …

However, if Epic is not willing to help a 3rd party company to develop product and at the same leverage the usability of their engine, then they are making a big mistake in my opinion and that is clearly a spit in the face of those thousands of modest coders that would like to grab their hand on engine.
[/]

First: Unity really doesn’t collaborate with , they collaborated with Novell. Hence the reason why the Mono runtime in Unity hasn’t been updated since took Mono over after Novell was purchased. And they paid quite a bit of money for it.

Secondly: I would call the current in engine Audio solution for UE4 to be at least as much of a deal breaker as C# support.

Thirdly: It’s up to to make arrangements with Epic if they want direct support, but they haven’t even decided whether or not they want to take product to market, so the investment isn’t worth it.

Fourthly: C# is not the only option for people who want fast iteration, as there is experimental Lua support (which was built by Epic), as well as SkookumScript. Why would Epic offer preferential treatment to , unless was offering good value to the community? (Indie-friendly rates being the primary)

[]
Are you planning to support project accordingly to its potential ? And if not, could you debate your decision ?
[/]

Unreal uses industry a standard fast programming language that is C++, like SnowDrop engine.
is why C# is considered as some secondary language that is not supported by Epic directly.

[=;194321]
Unreal uses industry a standard fast programming language that is C++, like SnowDrop engine.
is why C# is considered as some secondary language that is not supported by Epic directly.
[/]

What you call industry standard is a completely non-objective remark, which might be true for AAA games, but completely wrong for mobile, web or indie games.

As a matter of fact Epic did implement the blueprints, which is also not an industry standard as you may call it.

Now I guess that Unreal Engine is trying to build a universal game engine which could target every kind of games (espacially indie-devs) and therefore it would make also sense to adapt the usability accordingly.

We are falling into silly debate once again… if you think that only C++ is used in game-dev fine, that is good for you, and I disagree, but please let’s discuss in some other thread.

What I want is to hear is Epic’s point of view, as one of their client I would like to see added to the roadmap.

Once it would be in the roadmap, we could finally let the community decide if is really wanted or not via a democratic vote.

Wasn’t really trying to spark a debate, I love C# and would love to see it in Unreal. I was just offering a little info for C# veterans who may be browsing thread and are unsure about jumping into C++. I feel it’s relevant.

[=RPotter;194284]
First: Unity really doesn’t collaborate with , they collaborated with Novell. Hence the reason why the Mono runtime in Unity hasn’t been updated since took Mono over after Novell was purchased. And they paid quite a bit of money for it.

Secondly: I would call the current in engine Audio solution for UE4 to be at least as much of a deal breaker as C# support.

Thirdly: It’s up to to make arrangements with Epic if they want direct support, but they haven’t even decided whether or not they want to take product to market, so the investment isn’t worth it.

Fourthly: C# is not the only option for people who want fast iteration, as there is experimental Lua support (which was built by Epic), as well as SkookumScript. Why would Epic offer preferential treatment to , unless was offering good value to the community? (Indie-friendly rates being the primary)
[/]

I was not aware of how did the collaboration go for Unity, thank you for pointing out.

The Lua plugin is not longer supported by Epic btw… I’ll have a look at SkookumScript though looks interesting, although I doubt people would prefer over C#/.NET…

I dont wanna seem as troll but people who wants to use C# over C++, please just leave and use Unity.
Unreal is designed for top class AAA games mainly, indie developers is not on top priority take it or not.

[=matmuze;194371]
The Lua plugin is not longer supported by Epic btw…
[/]

It is supported, in a “if it is broken, bug it and we’ll try and fix it”, but features are backlogged right now. It could be picked up by the community and taken the last mile, however, and Lua’s runtime source license is very flexible (as is LuaJit, a better runtime for games).

[=caner_ozdemir;194379]
I dont wanna seem as troll but people who wants to use C# over C++, please just leave and use Unity.
Unreal is designed for top class AAA games mainly, indie developers is not on top priority take it or not.
[/]

Please let’s not start kind of thing. We don’t want to foster that kind of exclusionary behavior here.

[]
As a matter of fact Epic did implement the blueprints, which is also not an industry standard as you may call it.
[/]

It’s a similar system adopted in SnowDrop engine to allow 3D artists to add gameplay to their 3D models without knowing a programming language.

, you are persistant, I’ll give ya that

but to start a debate over C#, because that’s exactly what is, then say you don’t want a debate?

I don’t care if I ever see C# again, it wasn’t bad, but it sure isn’t good either, it’s nothing but a subset of C++ in my opinion and will be nothing else, heck I think plain C is better.
I don’t want to take another hit to performance, I can deal with the scripting hit from BPs but another, no thank you.
I don’t ever want to see C# in Unreal Engine unless it’s a plugin to access Windows Phone, and that’s it.

BP is a scripting language, have you tried it? you can make your own BPs, anyone can. you should try it because in the it takes you to ‘debate’ subject you could already be using C++.
you don’t have to use C++ at if you don’t want to, Unreal has exposed & are exposing more & more to BPs every day.

But can you tell me that ‘those Other Guys’ don’t use C or C++ for their actual engine and expose of to you as a user like Unreal does, check out puppy:
"The Unity runtime is written in C/C++. runtime is used in any build you create using the editor - for webplayers and plugins it is installed separate from your build, whereas it is included in it for stand-alones and other platforms such as iPhone and Wii.

The editor is built on the Unity runtime and additionally includes editor-specific C/C++ binaries.
Wrapped around the Unity core is a layer which allows for .net access to core functionality. layer is used for user scripting and for most of the editor UI."

Unreal Engine 4 has exposed it’s engine to you if you need it, and a strong API that allows access to it as well. On top it has BPs which is really more powerful than they can even imagine.
if I, woops WE keep pushing them in the right direction. (yes, a lil’ world domination coming through there)

K, enough of , simple solution is you need to watch for a Twitch stream that has someone involved with the engine & ask your questions, like else does.
(if they can’t answer then they can probably find someone who can, and give you a reasonable response)
So if you have concerns or questions that bother you much, take the to ask on twitch, if you can’t make the Twitch ask in the twitch announcement post & watch the Twitch later when it’s posted on .

Again… completely against the idea, I hated being forced to try to use C# & .Net when I had to and I don’t want to ever see it again.
(you can’t even do the simplest things in C# sometimes, C++ has stayed long for a reason)

1 Like

's C# integration is promising and follows a technically well thought-out design, however is a fairly complicated topic.

The challenge with and other programming language integrations into Unreal Engine 4 is that, unless they were to be genuinely and thoroughly adopted by Epic, they would not quite be first-class citizens in the way that C++ and Blueprints are. Specifically, we put substantial work into documentation, samples, pre-release testing, compatibility, porting, and support on C++ and Blueprints that we can’t feasibly replicate for a third-party plug-in. For example, unless the documentation on UE4 programming were updated to include side-by-side examples of C++ and C#, the programming experience with C# in UE4 could feel disjointed, and downside may outweigh the upside of one’s familiarity with C# and its easier header-free programming model.

Programming language integrations are very different in nature than middleware integrations such as SpeedTree and Substance in regard. Though the later are -rich, they are fairly self-contained in their interactions with UE4. A programming language integration can interact with just about any part of the engine and therefore has unlimited scope.

For these reasons, we updated the UE4 EULA to require redistributed programming language integrations to be free and open source, so that if one gained a critical mass in popularity, Epic could adopt it and ensure its future viability in the areas described above. I’m hopeful 's C# integration goes route in transitioning from closed beta to full release but I can’t speak for them.

There is another key point to consider: C# in UE4 more closely resembles C++ in UE4 than it resembles C# in Unity. Unity users coming from a background working with the componentized C# behavior model with Unity’s MonoBehaviour framework will find that UE4 doesn’t follow that model and therefore the emergence of UE4 C# support isn’t quite the hoped-for panacea.

Finally, when an engine is written in C++ and gameplay is scripted in another language, the interoperability barrier between languages eventually grows overwhelming. is why we ultimately abandoned the UE1-3 era’s UnrealScript language and moved to a pure C++ programming model. gives UE4 the ironic property of making it harder to learn the engine and start writing a game, yet ultimately easier to grow, finish, and ship.

Therefore, my recommendation for developers who want to use UE4 but prefer C# over C++ is to bite the bullet and give C++ a thorough . of us at Epic clearly see the many ways that programming in C# is more enjoyable than C++, from header-free source code to generics to rediced boilerplate code. However, C++ is a language that scales upward without limit, and the experience of whole-program debugging (engine and game together) is incredibly illuminating, as are the power and visibility that come from having the full C++ source and ability to call into any part of it.

3 Likes

Hi,

Thanks for the clarification .

[]
For these reasons, we updated the UE4 EULA to require redistributed programming language integrations to be free and open source,
[/]

Which kind of halted my endeavors to make UE4 compatible with the Embacadero RAD so I could enhance the engine as a Delphi programmer, so my 15+ years of coding expierience wouldnt be down the drain…(RAD allows cross coding).
Side question to that: Would it be Ok to use the Rad C++ Builder together with UE4? (I really really dont like Visual …)

Im thinking however to make a little framework for custom dlls. If they use the FreePascal compiler (which can also compile ObjectPascal code), that would be ok since its free, right?

Cheers,

Thanks , for that clarification.

Few comments though…

[= Sweeney;194593]
Finally, when an engine is written in C++ and gameplay is scripted in another language, the interoperability barrier between languages eventually grows overwhelming. is why we ultimately abandoned the UE1-3 era’s UnrealScript language and moved to a pure C++ programming model. gives UE4 the ironic property of making it harder to learn the engine and start writing a game, yet ultimately easier to grow, finish, and ship.
[/]

What about Blueprints ? You are not very constant in you argumentation since one can develop its own game-play via another programming paradigm than C++…

[= Sweeney;194593]
Specifically, we put substantial work into documentation, samples, pre-release testing, compatibility, porting, and support on C++ and Blueprints that we can’t feasibly replicate for a third-party plug-in. For example, unless the documentation on UE4 programming were updated to include side-by-side examples of C++ and C#, the programming experience with C# in UE4 could feel disjointed, and downside may outweigh the upside of one’s familiarity with C# and its easier header-free programming model.
[/]

I shall also remind that “Mono for Unreal” does is exposing to a C# environment the blueprint-exposed functions that are already defined in the C++ environment, and therefore maintaining the C# API would rather be trivial.

tl;dr -> Blueprints-exposed code in the C++ will automatically be made available in C# via the tool.

[= Sweeney;194593]
The challenge with and other programming language integrations into Unreal Engine 4 is that, unless they were to be genuinely and thoroughly adopted by Epic, they would not quite be first-class citizens in the way that C++ and Blueprints are.
[/]

Do you think that if Mono was completely open-source and free to use for any body then Epic would have done it’s move towards ?

[=matmuze;194678]
tl;dr -> Blueprints-exposed code in the C++ will automatically be made available in C# via the tool.
[/]

We actually love scripting languages, and we want developers to be able to use the right tool for the job. We designed the scripting layer in Unreal Engine to be totally extensible through a pluggable API that uses the same surface area as our own Blueprint language. So you guys are free to use whichever language you want or create your own!

As said, we do require that language extensions to the engine to be totally free and open source. We believe is in best interest of the Unreal Engine community. Just as an example, if a huge number of developers suddenly adopted using Google’s GoLang for their projects, we would want to be able to make Go a built-in and support it at the same quality level as Blueprints (sample games, documentation, templates, video tutorials) and ensure developers could release projects on platforms without restriction.

We’re really still focused on making the C++ experience for developers. We have dozens of improvements coming, including faster compile times, fast code outdatedness checking, simplified Unreal syntax, and better API documentation. Of course many of these improvements will benefit scripting languages as well, and with every release we expose more engine features to scripting APIs.

[=matmuze;194678]
Do you think that if Mono was completely open-source and free to use for any body then Epic would have done it’s move towards ?
[/]

We do certainly keep an eye on .NET and other languages. We talk to Microsoft frequently and we’re pleased they’re opening up the core .NET code. For the foreseeable future we have our hands full with improvements to Blueprints and C++. We have a great trajectory with these languages and some extremely cool ideas yet to implement that we’re very excited about.

Please keep the feedback coming, we are always listening and trying to do the right thing for the engine and developers.

I think you need to use Mono http://mono-ue.github.io/ and give it a if that’s what you want. put your efforts there or are they not answering your concerns like UE has?

Epic has kept Feedback Forum open and even though I don’t agree with what you suggest (at ), I agree that you should be able to voice your opinion, as should they be able to voice theirs. And they are a lot nicer than I would be.
(maybe one day I’ll look back at C# & even Mono but not today because I’ve seen what they both can do)

Whether I agree with Epic, whether I like what they are doing the , whether I’m able to make something out of Unreal Engine or not, whether I stay or go, I still believe in Epic & Unreal Engine and what they are trying to do here. They listen and try to go forward with the community & their users in mind. And I will always uphold their right to do so, because it’s something I believe in, as do many if not of community.

If it seems I took offense, maybe I did, and I’ll take moment to apologize for it if I offended you or anyone. But it’s because they do answer these concerns when they can or when they have an answer that is correct for the situation or the timing is right. you should respect, as I suggested above you should take the , if you can, to join the Twitch streams, voice your concerns etc. and there is also an Off-Topic forum thread that I’m sure you can continue your topic with. (if you can’t make the Twitch you can ask the question in the Twitch Announcement topic)(look for someone that has something to do with your topic in the stream is best though)(never hurts to ask)

So again, if I offended anyone in any way, my apologies. And Epic/UE4 you make me proud to be a part of community! I still don’t want C# tho’, not today anyway! :stuck_out_tongue: