That’s why I’m not porting my current project ;). You must’ve misread my post, happens :). Anyway, having access to either C# or Lua (both I am very proficient with) as half-way between blueprint spaghetti mess and C++ pointer hell, would really make me seriously consider UE4 for my future projects.
And before you ask/suggest it, Skookum, while nice, has not suitable business model for me as they seem to offer “paid” version of it which means that in future some language features or compiler features may be withheld from “free” version. Would consider it if it’d be MIT/BSD/Apache-licensed with creators making money of training material and so on, but as it stands now, while language seems nice, it doesn’t make sense for me to use it, especially since it’s just “level scripting” and not complete solution so to do any i/o (even not “mission-critical”) you need to drop into c++.
As for why I want to use C# even if the API stays relatively the same? Ever heard of SIGSEGV? It doesn’t happen in C# apps, yet it does happen in C++ ones all too often from my coding experience.
Actually you can still use C# with C++ using DllImport, that way , you can bring all the major functionalities of C# in Unreal C++. I have done that very effectively to bring support for MS SQL in UE4
The problem with adding C# non officially by Epic is, the thing is so huge, that it will always be around 2~3 engine versions behind.
Expect C# for 4.13 when we are at UE4.15 or even worse…
I totally understand your point since I came here from C#.
However, you won’t see SIGSEGV under the UObject system; just use UObjects and/or TSharedPtr and you’re free from that nightmare.
as Epic said in one of their stream “we understand the potentials of C# but we would not have anyone who would internally use it”.
I think that instead of improving the programmer experience they are trying to reduce the need of it through blueprint, any scripting talks is probably related to blueprints itself (maybe giving a base intellisense to a text-based version of blueprints).
Furtheremore I didn’t see any updates from the xamarin team and Microsoft is pretty much pushing Unity. There is also a new engine (now in beta) which is called Xenco that may became a valid alternative.
Well they know it wont make any large difference if they do . People in the end use whatever is better supported.
Take python for example, there are many implementations , Jython for Java, Ironpython for .NET, PyPy for JIT VM and CPython. The vast majority of python users use CPython, the others have almost nonexistant communities compared to CPython. Having the ability to use Java and C# libraries apparently never really tempted python coders when they could still with whatever had much better support python wise, CPython.
Right now Blueprints are a huge success, people love them and lately have given the ability to even convert to C++ code. There is very little reason to use another scripting language.
On the other hand none stops anyone from offering C# support, there are libraries out there that can auto-generate wrappers for C++ libraries using header files. However maintaining and keeping bugs and bay is a lot trickier.
Also there is the question of practical advantage , what kind of advantage I have to use C# and does justify sacrificing the ease to find documentation and libraries as I have with Blueprints. Even compared to C++ because Unreal C++ has its own GC and even reflection its just not that tempting to jump into a language like C# as it would have been if Unreal C++ was the usual C++ we all love to hate.
On the other hand, people do whatever they want, if one want to use C# with Unreal , none stops them to do so. I even integrated an unknown language called Pharo with Unreal. You do not need full support when you know C++ you can jump in and wrap the code you need. Its extra work of course but if that is what you want, that is what you want. Plus you can always use the other language only rarely and slowly and steadily build Unreal support.
Sure we all want full Unreal support for C# but do we need to, nope, we are coders afterall.
M$ also is a partner with Xenko. Xenko is a FULL C# game engine, not just scripting! If one even wanted to use F#, one wouldn’t require bindings since both languages are CLR based. This means you could always use the newest engine version. Sadly though, currently Xenko got some funky .Net hack which seem to break F#. But I’m positive that once .Net is more cross platform, this problem would get fixed, and anybody could use F# and Xenko without any hassle.
I observed on the Interwebz, that there is some growing grudge against OOP. And one of the solutions is functional programming. That’s why I mention F# here. I’ve been learning some F# during the last past month. And I understand now why its hype is so rock solid. For my current game in Unity, I use F# scripting. Finally I can work with game states without feeling like a weirdo.
Really? I kind of follow channel9 and they only show unity stuff, not even the .net blog has anything Xenko related.
btw can you give us a feedback on your experience with Xenko?
blasfemy
You could say that once that you have proper intellisense you don’t even need to “learn” a new language ^^
I written my last game directly in assembly, I mean… I’m a coder afterall
To be clear with everyone still hoping for C# in Unreal, it’s not gonna happen. Maybe they would never tell you in the same way you can’t say a customer that you will never do something, but it will never happen.
They made it really clear that blueprints it’s their solution, they could support third party initiative but it would still be something at blueprints level.
I’ve seen many blog posts and youtube video and they all show that they want to remove the need of programmers, you have C++ and source code access so you can deal it with it if you absolutely need it but it’s not recommended anywhere. It’s a temporary patch while blueprint will be eventually be able to do more and completely remove the need of c++.
The partnership with M$ can be seen on the Xenko homepage. At the bottom it reads “Partners”, and there is an M$ logo and name. I think the reason why Xenko isn’t actually mentioned, or shown by M$, is because it is still beta. So, it is very buggy and lacks features. However, the roadmap looks good.
I found that on the fundamental level, Xenko is way better than Unity. And because it’s a C# game engine, it’s also better than UE4. Since F# is better than C# (I would say so). Unlike Unity, Xenko got separated editors for prefabs and GUI. All code and its serialized editor data and game assets, are put into “Packages”. I think those packages are going to be used for assets from an asset store (soonTM), too. So, unlike in Unity, you will have your editor extension code from the asset store cleanly separated with in your VS project.
Xenko is open source. Unity isn’t, and is also C++ at its core. Unity got this moronic Awake(), FixedUpdate(), and LateUpdate(). Xenko, like UE4. Seem only to have Start() and Update() for the scripting loops that also can be async. Unity isn’t async. Xenko is the newest C#. Unity isn’t even the new C# 6.0. It’s still the C# 2.0 with a crappy mono GC. -.-
Have you used F#? Maybe it is just me. But F#'s immutable values are quite mind bending. F# is functional not OO. So everything is different and looks like some math equation. Which seems to be the whole reason why F# can be better than C#, by being more direct and compact but doing the same thing as C#
In case you didn’t know. The creator of F#, Don Syme, was awarded the Silver Medal of Engineering. Apparently F# brought async to C# 5.0. And Apple’s Swift already stole some ideas from F#, too. I was told that Swift is more protocol oriented programming. I expect for the future, that the cry against Objected Oriented Programming only could get louder. In an old interview with Anders Hejlsberg (creator of C#), he also mentioned the moving away from OOP.
my main concern with Xenko is if they intend to finance this by selling third party plugins on their upcoming store. This would mean the same **** that happens with unity.
I’ve been stalled so many times because of third party plugins. I’ve had to wait for plugin devs to read/reply/fix their plugin. its been the worst part of game development for me.
i dont mind spending money, its the spending most of my time chasing developers that kills productivity.
so if Xenko rely income off tools then why would they make the tools themselves.
I just heard of xenko. What is up with that license? You have to use their signed binary to release royalty free otherwise you have to publish source of your game. Makes me wonder what they plan on doing with the final release builds down the road.
To use the engine effectively you use a combination of C++ and Blueprint, where appropriate. That should be obvious to anyone that’s used UE for any length of time.
I don’t think Epic are going to lose any sleep over a few people that can’t/won’t learn the very basic level of C++ competency required to use code in the engine. For many of us, C++ is the major selling point of the engine.
But to be honest one thing I miss from C# and which are not likely to show up anytime soon in Unreal, are multithreading capabilities.
Async, Await, Tasks, Actor Model.
I’m using C++ in my UE4 projects and I know “the very basic level of c++ competency”, I would still prefer C# and it’s not gonna happen. That’s about it.
