When the C# in UE project was canned back then it was because Xamarin was not open source. Now that Microsoft has acquired Xamarin and relicensed Mono under MIT, will Epic greenlight the Mono in UE project?
Epic doesn’t have to greenlight anything. Xamarin pulled the project because the EULA was seen as hostile to the mono project. ie, the source has to be free and open (which it wasn’t for commercial use). Now that Mono, and indeed Xamarin as a platform are both just that, and under MIT license no less, the road is clear and the mono for UE4 project is 100% doable. Now either Epic or Xamarin need to finish the project. Or someone like myself needs to get of their butt, grab the source and contribute it to UE4… hmmm
I look forward to seeing it, I’d really like to use Unreal but I’m staying with Unity my project and dabbling with learning CryEngine, while I don’t expect it will be as easy to use as Unity’s component stuff which makes it really quick to use. The fact C# is just alot easier for many like me to make use of… C++ is headache with headers and pointers, and a syntax that looks like txtspk>>::<< tribe lingo from a decade when programmers didn’t seem to care about design readability aesthetics of the language that its grown to look like an unsightly mess no indie developer really wants to deal with imo.
And blueprints are just meh… Its like catering to high end programmers, and low end newb… where is the middle ground for those who value sanity
I prefere code overall… and don’t get me wrong blueprints are great for material shaders, flowgraph ui stuff… but overall they get messy if not contained to just very specific things. Doing an entire game with it is insanity to me, that I’d rather stay away from much like not ever having touch c++ just to use api’s outside of the engine stuff.
Adding first class C# support could like going back UnrealScript… a somewhat saner middle ground from designer/coder but actually using a ‘popular’ and established language without any weird quirks from a script language built specifically for an engine.
Well do or don’t Epic but I think it would be crazy not too get some progress on it.
P.S you’re VR GDC demo was way better than Unity’s but I don’t care about VR so VVwhateveRR
Hey that’s cool, but, not this again. I can not understand the obsession with C# in unreal. It is no different than C++. The C++ in UE4 is not C++, it is basically scripting. If you are using C# it will look almost identical. Unreal Engine won’t become Unity because you’ve switched to C#.
Am I missing something? I don’t consider myself an expert, but is there really a point? I would love to hear from a CS major or someone very well versed in the low-level workings of both engines.
lol I tried to bite the bullet the other day and learn Unreal with C++ … eventually it ended with WTF!! this is tedious… why so much preparation to do something simple… arhhhhh
I then started to prey that C# would be an option in unreal engine.
I think for a seasoned C++ developer that works on C++ fulltime wont find it a problem and will probably love it, but for an indie developer that usually has to do many things themselves *(programming, sound editing, animation, 3d modelling, UI 2d design, level building, game design etc) * then C++ becomes a time hog…
It would probably be a good idea to integrate Mono in UE4 using the already existing scripting language extensions, as detailed here: https://forums.unrealengine.com/showthread.php?3958-Scripting-Language-extensions-via-plugins/page6
Well, I’ve coded with both C++ and C#, and for me C++, even with (or perhaps especially?) with UE-specific additions (all that decorations tho) is very cumbersome. C# is managed and is much more abstracted, and just feels much more natural to use. They are definitely not identical.
If you were to do a direct port of UE4’s macro-heavy API into C#, gameplay code would look very similar to it’s C++ counterpart (which uses it’s own management, not that inherent in the language, for the purposes of multi-platform support).
Exactly. I can not wrap my head around why people are not understanding this, or just outright ignoring this fact. If you can’t understand c++ UE, you won’t be able to understand c# UE. It’s that simple. UE c++ is the scripting language and a direct c# port would look nearly identical. What we need is a stronger focus on documentation when UE becomes more mature and things are not in so much feature shift.
This is the issue, C++ is tedious and complex to use for new comers unlike C# , Cryteck understood it and made C# happen.
Fighting the language: overbearing-syntax: pointers, headers, macros, virtual-funcs, mem-management:
C++ polarizes opinions like nothing else, and I think that explains the diversity of views on these forums or any others… But why is that?
For some, C++ is pure joy or divine clarity, and it doesn’t impede their thinking, ideas, or creativity. I’ve seen this even apply to non-techy artists sometimes!
For me C++ is probably the least easy thing I’ve had to do in a varied tech career. It all depends on how your brain is wired, but there’s nothing more humbling.
The attention to detail and the highly specific syntax tends to get in the way of ideas, especially creating Indie games, where you already have to wear multiple hats.
Its misleading to place C++ even UE4 C++, on the same level as Unrealscript, componentized Unity-C# or JS / Java etc, and imply they’re equivalent in terms of difficulty.
To those who believe that, ever have a boss put a gun to your head and say fix this outside teams C++ code in 30 mins ‘cos we gotta get a fix to 1000 VIP clients’???
Sure, if you know the underlying processes, or game engine components, then its manageable, especially given time or talent (something that can’t be understated).
But if this isn’t your code or your area and you also have to learn new APIs or game engine internals, then the difficulty level is enormous, especially if there’s networking!
Whereas if you’re an Indie on a free schedule then BP lets you plug things-in and see what comes out. But that isn’t the case with C++, its closer to an all-in poker bluff.
If you have to guesstimate numbers in terms of levels of difficulty: I’d say Office-VBA: 0-1… JS: 2-3… SQL: 2… Unity-C#: 3-4… M$.Net: 5-7… Recursive Lisp: 10-20.
Arguably C++ is 10 on a good day, and 20 on a bad, especially if you’re deep in the trenches debugging your own code and / or 3rd party APIs and a game engine etc.
However, C++ is powerful and the ability to debug the entire engine must be a revelation to those frustrated by years of code hidden away inside Unrealscript / Unity-C#.
Overall, I’d say figure out which way your brain is wired and choose the group that you naturally fall into and leverage that without over-focusing on C++ vs C#…
Discussions like this are so polarizing many devs will disagree. But the thing is, if you find C++ a breeze, then you’re probably really talented and take it for granted
Seeing C# talks going nowhere past 2 years my question to EPIC is why not Python scripting? easy and free to use anywhere.
Epic answers were always a solid NAY for C#, i understand i dont like microsoft either, but if youreally wanted you could have used Python or Lua or any other scripting really. Visual scripting is awesome for materials and such, but when it comes to more complex workflow it falls on its head and its probably slower than any other scripting language.Now it seems the Blueprint work has gone so far that Epic will not consider any other scripting ever.
I guess at this point Epic wont fragment the engine even further with extra scripting languages that need separate tutorials/support and so on so we are stuck with C++ for coding and VS for quick prototyping.
I would rather lean towards something like python, not sure how good the mono C# support is on linux and mac.
if C# port would look exactly like C++ that would been an extremely bad port, it needs to look like unity’s or better
C++ gives you the ultimate power, Blueprints give you the best visual programming available in any game engine, and Skookum is the only truely game-centric scripting language out there. All is available in UE4 today and people still ask for C#, LUA or Python. It boggles the mind.
It would not be an “extremely bad port”. The look of it depends highly on the underlying API and engine architecture. Unreal is not Unity, and neither should it try to be.
UNREAL IS NOT UNITY
People. Please. Engrave this into your minds. If UNREAL looked like UNITY with a scripting language it would be a BAD PORT. You can not put off learning Unreal because it’s not Unity. If you interpreted Unreal’s c++ directly as c# it would look the same. Your logic is fundamentally flawed.
I think it boils down to the fact that people keep seeing C++ less productive and a aged language even if its superior in terms of performance or as some say freedom. As the time has gone by everything seems to be moving away from C++ or similar style languages to more “flexible” ones. On software front it’s not really been used a lot for ages. On major mobile platforms it’s pretty much gone from the top used languages too. For people asking LUA, Python or C# they are used to them from other engines or from scripting/modding games/apps. Moving to C++ after using them can feel like degrading back to stone age for many.
I can assure you, the C++ market is still and will continue very large (and growing), in fact larger than C#.
niceone… I never knew Skookum existed until now.
C# was already ported to 4.4 of UE with full API and debugging support, MonoDevelop IDE support, multi-platform support (iOS, Android, Win, OSX, PS4, XB1 etc), as a plugin. It had full access Unreal’s public API via the build system (just like Unreal.js). It was pulled from github because of licensing issues towards the release of 4.5. I’m currently in contact with Miguel from Xamarin, to help bring it back. Based on any discussions there, I will pull down the pre-4.5 branch of mono and look at the changes to core UE, perhaps get some PR requests to Epic to fix any integration issues and then hopefully get it back up to speed with Master branch as a plugin. This is all contingent on getting my hands on the mono-ue source and time availability(I do have a day job :))