Since DotNet Core 1.0 is as good as done. I couldn’t help but to wonder if there are going to be news about a C#/F# for UE4. Xamarin, even after the new licensing model for Mono, didn’t say much. So, now is the time?
I missed the first 30 minutes. But he mentioned Unity, and then he said… Samsung… -.-
Bummer… I guess I just go for Unreal.js then. Don’t have a 4K monitor (yet).
I hope this thread wont get hijack with talk about skookum script, how C++ is easy and can do things better or how blueprints are enough.
With that said, i really hope Epic reconsiders C#, i hope UE4 can get a friendly framework as Unity’s that would be bliss. And hopefully i wont have to use BP intercomunication anoyance again.
Dont need another long talk about C++, its bad and thats just it, usefull for building the engine, not the game.
BP to C++ translation tool unless it becomes automated behind the scenes translating the BP’s to native for automated improvements, only helps shorten the ammount of code you write, but the C++ style bugs,lack of autocompletion and compilation times wont change.
Anyway ill work with whatever, for a cheap/free, good, high quality engine as UE i cant ask for more, if they want to i hope they provide C#.
Well, this language is made of paper. VS moved from Update 2 to 3, and now no C++ code compiles anymore.
Truly wonderful Cancer**++** is. One tiny update and it comes crashing down. You know, I had to reinstall VS, and VS only comes now with Update 3. -.-
Really implementing C# scripting language doesn’t make sense for anyone to do by EPIC , because
1- As Mr CEO Tim has mentioned before, C# would not really be as beneficial to developers as say blue print unless EPIC adopts it as first class citizen in their ecosystem
2- Because of UE license, other 3rd party companies would need to open source their version of C# implementations and wouldn’t really make any financial gains from investing time into making one ( that was the reason xaramin stopped their version of c# for unreal )
The only way for us to get C# is to make a real strong case and would convince the epic team to invest spend time energy and money into C#, and just saying I like C# is not good enough. Maybe if we create a petition and really show EPIC that the community would benefit from C#, they might consider it, we are at their mercy!
some points that might help convince EPIC
1- C# would bring alot more developers to the eco system , which would mean more potential games , more revenue
2- C# would bring alot more plugins to market would again would mean more money for EPIC
3- C# would invite more artists with weaker development background to create and sell their assets on their Market
The reality is , C# would not benefit Unreal Engine technically, it would benefit unreal engine’s community and would help Unreal grow as a world class engine.
This is a hard sell to epic guys, I have a feeling people at EPIC are not really money driven, they are passionate about what they do, guys at unity for example would do alot more if it makes sense money wise ( look at EPIC stand on UWP for example, even tou it would mean more money for them, they would not implement it because they dont think what Microsoft doing is right )
They only hope we have is to really show EPIC that as community we are worth the investment and would really benefit from this.
Just my 2 cents
Personally, I’d like to see Unrealscript make a comeback, more than C#; just update it work with the current blueprint byte-code and features.
They’ve already done it, there’s a branch that supports UWP. I assume it’s not yet ready for public consumption.
You realise Microsoft can do the exact same thing with their support for other languages, right? They could easily drop a service pack bomb that breaks compilation for applications in C# just as easily.
Yes. I lack experience with all this, but I think i would be better to go via the Blueprint subsystem instead of wrappers. Such a C# would have the limitations of Blueprints, like not having full access to the engine. But even Blueprints are getting more nodes. So, Epic Games builds the engine around the Blueprints already. And a such a C#, could make benefit from it. Epic would this way also automatically build around C#.
I don’t know if I have mentioned this, but this way one also could just keep using C++ when needed and even interface with C# just like one would do with Blueprints.
So, why did they even remove Unrealscript in the first place?
People complained that it wasn’t C++. It had it’s problems in UE3; primarily being unable to compile whilst the editor is open, and nasty native-script interfaces, but Blueprint seems to have solved both of those problems.
Yeah, I read about that. Tim Sweeney
Seems Unreal Script was able to do interop to C++ and vice versa. Unlike now with Blueprints that are literally on top of C++, Unreal Script was more “side by side” to C++?!
The last time I looked up how to access Blueprint variables via C++, it required additional code, so it wasn’t that simple. It was like C++ “calling up”, instead of just making a C++ function, exposing it to the Blueprint system, and then let the Blueprint “call down” into the C++ of the engine.
If I understand this correctly, then that’s why it all works fine now with Blueprints. UE4 is designed around Blueprints just like Unity is designed around C#. And that’s also the reason why a C# via wrapper would be a bad idea and would just reintroduce the problem of Unreal Script. Seems the only solution is to induce C# into the byte code of the VM, that runs now the Blueprints. I don’t know if one could lock the interop in C#. But since Unreal Script was made by Epic, they just could make a few changes and give us a text based Blueprint!?
You know the problem with Blueprints. As soon as it gets a bit more complex, than it ends up being a node mess. And I do have a 1080p monitor (two actually,) not a 4K monitor. I think those with a 4K monitor would have less problems keeping an overview.
Java and Python are more popular than C#. Which means, if Java or Python were used instead of C++ or C# more people would use UE4.
Java ain’t more popular than C# in Unity, though. A C# may draw tons of Unity devs. Especially those who are very serous about game development and need a more feature rich editor/engine.
But I don’t really think it matters what language Epic may implement next. For as long as that language isn’t committing the same crimes Cancer++ did. Leaving C++'s other short comings aside, headers are the biggest atrocity. And that’s my main reason why I’m on this “crusade against C++”.
I gotta tell ya. Every time a programmer writes a header, somewhere in the world, an innocent kitten dies! 
Headers are great, I have no idea what your problem with them is. You can even distribute the header files directly without giving away the implementation and people can compile against them. UT2004 as an example did this.
My problems:
- They make compilation longer.
- Headers which depends on other headers and must be included in correct order.
- Headers are reason why auto-completion for C++ is slow (headers must be parsed, before anything useful, can be done with them).
Anyway. this thread again. People. Please. Stop. There is not going to be C# implementaion from Epic in Engine. I’m very happy about that. Working with two or more languagues in single software piece is debugging nightmare. I will set aside all things that annoy me in C++, just because I can use debugger properly.
Once you hit into transition layer (like C++ > C# or C# > C++) debugging code become nightmare.
You forgot Blueprints. And regarding interop, here you go:
Too much to read? Well, seems you didn’t read that above the first time so now you will have to read it again.
In C# they are called Assemblies, and they do provide the same information without having to write any headers. Welcome to the future, son…
By the way. When I say that a script should go via Blueprints, I mean it. And it would look like this.
So the tabs Components, My Blueprint, and Details should stay! If we could declare variables in My Blueprint tab as usual, and use the Details tab to set usual extra stuff we can find there now, this could make a script even a bit lighter. And most importantly, this would be more integrated than a C# via wrappers.