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.
[/]
i know C# and c++ i like c++ more but i stay with unity no because C# but because is easy to develop.
normally unity users know more than c# and C++ cause we have been in game dev for a long not like unreal users that are just cod gamer that try to make another cod.
yes there are some unity dev in unreal but just because if you make a game with unreal (edit: people like caner_ozdemir) is like wow is nextgen(next gen cod XD).
c++ is really similar to c# so c# is not the problem.
Very interesting how discussion turned out I will add my two cents, since I believe that we should encourage a different mentality than it was shown here.
I have been using C/C++ for a long now and due to my work I started using C# a while back. At my workplace, we have been using the many tools out there you can combine with C# and Visual (e.g. resharper) or libraries that come with it (e.g. entity framework) - speeds up and simplifies many development steps remarkably lot. . C++ is much more tedious than C# is and quite bloated through those changes and revisions. But every now and then when I write code, I feel like it would be much easier in C++. is almost always the case when I care about performance or want to code closer to the hardware.
So while I favor both languages and would be quite happy if UE supports them both, I still think that the very discussion of leads nowhere anymore. But even then, we have a group of people here who would like to code in C# and they should still be allowed to post a request in the forum the same way else is allowed to request features they would like to see. But the way unfold months ago, the thread was trashed and users nearly tried to defame the poster and very idea as if they wanted to kill its appeal.
The pros and contras regarding the programming languages were listed quite detailed, so at least I will not make the mistake to repeat anything. But matmuze should nevertheless be allowed to try to appeal to the epic team.
@matmuze: I agree with you that it is easier to use C# and that it may lead to more productivity.
But you need to face two facts:
UE is around since 1998. It is entirely written in C++. If you really wanted to profit from the open sourceness of UE, you would need to get comfortable with C++ anyway. You will need to access its source code if you really wanted to make the engine your own - or request that the Epic team converts its whole project to C#, which would be very futile and a huge waste of .
UE is an engine, its not a tool. Whether you code in C++ or C#, you will need to get familiar with the Engine and its facettes. Whatever you want to do with the engine, 90% of the you will access the engine code and execute the functions and use the classes and structs that the engine provides. You will also have to use their macros - whether you are in C# or not. Because in the end, the project you create will be just an extension of the engine - or rather, the engine will be part of your game. You will have to dwelve into the documentation, learn about the engines terminology and look at the API of the classes you might need for your project. is a step that you will have to go through no matter which scripting language you use and can not be skipped. And most of the - unless you really want to extend the engine by new features - the only code library you will use is the engine itself. It is true that C# is easier in many cases, but in case - if we judge it by probability - it will probably be of no real value.
Just for those two reasons, I think there are many more important features that the epic team should care about.
I suggest that we let matmuze and kindred spirits speak for themselves and give them the to appeal to the epic team for as long as he wants instead of trying to silence him. is after the forum section for feedback and different opinions should be allowed here. Any further discussion from the opposition will be useless unless the epic team resonsiders whether to reject the idea or not. So to those people still opposing idea: Chill and allow other users to be. is probably what the epic team would like us to do as well. (I guess)
It indeed is, that is why I ask for the opposition to chill and sit back a little When I read thread I even forgot that was about asking for C# halfway through. What I want to say is: The opposition is way stronger than it needs to be. So strong that is no open discussion at , but rather an onslaught
Has pass 5 year since the first entry on post, and many things has changed in the .NET world.
is a summary of these changes, c#, , dotnet core, mono and many things inside the .net ecosystem are open source, .NET 5 come the next year with incredible performance improvement and platform support, including Linux, Android, iOS, OSX, WebAssembly and of course Windows, other platforms like PlayStation, Xbox are waiting for confirmation.
Currently there are open source projects like USharpthat use the MonoUE project and are making a great work, they need support to fill the gap of performance by improve the mono implementation.
In conclusion now is a good to thing a side by side language support.
I think now more than ever it is worth reconsidering. We’ve got pipelines with common C# libs building and deploying in Unity and UE in parallel. C# and .NET 5/6 are a whole new ballgame 7 years after the thread was started.
We were able to lift and shift our common core libraries, including Dark Rift 2 networking for our MMO, from Unity HDRP to Unreal Engine 5 as a POC relatively easily with Code Orchestra. Imagine how many Unity C# devs would dive right into UE 5 if it was that simple (which it truly is when done right)!
Open source projects like UnrealCLR and Usharp face similar challenges, comprehensive and commercial-grade support requires either investment from Epic, or a path to sustainability for 3rd party devs. Allowing a 3rd party developer to distribute and support such extensions with predefined SLA’s governed by Epic enables proper development, growth, and support of the tooling while ensuring 's concerns are addressed at the same .
It’s not about UE C++ vs C# or rust, etc… the value is so much more significant - available talent pool, cost of resources, developer productivity, tooling, reusability (shared DLLs across many engines/projects/platforms), and so much more.
Our .NET 5 back-end MMO dedicated compute nodes and proxy servers share the same DTO code/libraries as our clients (UE 5 and Unity). A single shared lib compiled and pushed across modalities and architectures in a common pipeline allows us to iterate incredibly quickly. I find immense value in for our use case and I am sure there are many who would find such capabilities welcoming as well.
I read Sweeny’s post and I don’t understand why clause is in place. project will bring more developers to work in unreal while putting the maintenance responsibility on particular . The developers are taking a risk by going with them. If their solution blows up and gets massively adopted is because they clearly provided a better developer experience than Epic could ever provide even if is at the cost of less quality/reliability in the code made. The reality is that Unity wins over developers in big part because it allows them to fail, to write bad code while at the same working on producing solutions that work for the enterprise and that provide quality. Failure is part of learning. Some people sometimes have to code it quickly and wrong to understand why they need to plan out your code better and use a different API like the C++ APIs in Unreal. Forcing people to do things the right way does not in any help developer growth if the motivation is not there. Failure creates motivation. Unity is an example of . You see the path of many unity developers and their commitment comes from their failures, that’s when they seek education and begin to succeed. approach that you have to do things the right way, the documented way to succeed doesn’t work.
Allow developers to go with these maybe paid options like Code Orchestra fail in them, fail to find good documentation, fail to understand the engine properly so they can then find their way to the C++ API and the full engine source motivated by the desire to overcome their previous failure.
Good education systems allow failure. By forcing any efforts like Code Orchestra to be open source you are not giving an opportunity for failure as there is no incentive for these Code Orchestra developers to even try.
I will add my two cents, since I believe that we should encourage a different mentality than it was shown here.