Original “The Mono Project likes scripts. Does Epic Games?”
Mono wrote an article about scripting and the use of Mono for it. is the whole thing.
Yeah, we have Skookum Script now. And some devs like it. I didn’t yet really have the time to look into this scripting language further just yet. But Skookum’s Script IDE feels kinda messy for now.
Regarding C++. No it doesn’t have to be complex, obviously. Yet it is still tedious to work with C++ either way.
Now back to Mono. The first paragraph sounds good to me.
Increased productivity? Cool. Without having Epic Games to rewrite code? Cool. Not having to rewrite code should sound interesting to Epic Games.
How fast is Skookum Skript’s execution? Does anybody know? This language reminds me of F# that I looked up recently. Less code noise, good coroutine support. Mono supports F# by the way.
In Unity all is C#. I never used C++ plugins with it. But Unity is build all around C#, how much access do those plugins even have to C++ Unity code? Because the way it looks to me with Unreal engine and its openness. Could we even get to use both? Like having a V$ solution with two projects inside of it. One C++ project for whatever we need if performance matters. And a C# project for top level programming.
Now to the bad part of a scripting support via Mono. I think it was even Epic Games itself, who said that if we had C# in addition to C++, then it would split the community and would require additional documentation. I gather that “documentation” means not the engine itself, but refers to tutorials. Obviously the point where to decide whether to use C# or C++ is not fixed on the mid level (because of the game’s target platform and project size).
Xamarin could bring C# to UE4 because Mono is now under MIT. Seems if C# would come to UE4 “Whether Epic or anybody actually wants it or not”, it would stay and divide either way. But, Epic could teach the right balanced use of C#/C++ to minimize the “damage”. The scripting approach does have a point after all: “The right tool for the right job.”
To finish, I’m going to add this.
And not to forget.
Update “M$ makes a new language?”
Update 2 (No this is more of an overview than an update, but the clowns are spamming already)
I really get bored of all the “but C#” posts. After all, you could say Unreal Engine C++ is not really C++ due to the gigantic amount of stuff it has, like garbage collection or reflection. The thing is that implementing C# would be completely reduntant, given that unreal engine C++ with its stuffs its very VERY close to C#, but people tend to just be used to Unity and given that its a different lenguage they “dont like C++” even when UE4 C++ its 95% the same as Unity C#. But faster and with very good integration, alongside complete engine support.
I agree in usability terms, but it’s no good for scripting. Prototyping in C++ is prohibitive because of gargantuan compile times. Blueprints are good in that case, but they’re largely useless for engine extension. I’m hoping blueprints improve in that area because writing C++ for that is not only frustrating but time-consuming and the documentation on it is thin at best. I can only wonder how many great plugins could exist by now if there were an easy and quick way to write engine plugins. Not to say that implementing c# would automatically allow for that and I’m told skookum is on its way in that direction, but it’s not just the perceived difficulty of C++ that keeps users from using it.
C# wouldnt help in any way with the documentation or “easyness”. And the compile times are indeed a concern, but due to incremental compile, if you have a bit of care, you can avoid long compile times, as it only compiles the units that changed.
The concern isn’t really documentation or ease-of-use or compile times by themselves, but a combination thereof. I’m fine with experimenting if there’s little documentation, but not if it’s going to take too long to compile to find out my experiment failed. I don’t mind learning something complex if there’s some documentation for it. I don’t mind waiting for compilation too much if I can be confident that what I wrote is likely to work as I intend.
Compiling plugins, even with small iterations, does not happen quickly. My plugin iTween takes 7 minutes to compile, even when making a tiny change like turning 1.0f to 1.1f. That’s really not ok. It kills my desire to work on the thing because iteration is an enormous pain and small features can take the whole day to implement. Maybe that’s my failure as a programmer for not structuring my plugin correctly, but when there’s no documentation on it, how would I know?
Understand this is not an argument to ask for c# in the engine. I really couldn’t care less. It’s more of a shout into the void for a better way to write extensions. C# is one possibility.
I didn’t post this as a request. As a matter of fact, if you look at this post’s tag, you will read [Programming] and not [ Request]. This feedback of mine only exists in order to learn what Epic Games thinks now. It is not really meant to push C# to UE4. I can program C++, too. And frankly, what ever it throws at me, it can’t kill me with that.
However back then, there was a licensing problem. Epic’s mind about C# could have already changed for all we know. Maybe, back then, Epic could have made an exception for Xamarin, but I think that it would be a slippery slope. So, now the licencing problem is out of the way. And something like that doesn’t happen every day. Not every day some company gets acquired by another one and opens such opportunities for the rest of us.
Do you know when the last time that happen? I can remember. It was Micro$oft again when they bought the developers of that Unity debugger for Visual Studio. That plugin actually had a price tag of ~100 Terran Credits, if I recall. And M$ gave it away for FREE! For all we know, even a Xamarin C# could com out for free now. Well, it probably will hugely depend on how much work is behind all this, however.
Epic said that they wanted to explore support for additional languages. Well, now they can explore and what they find and like about Mono, they could even use. It is under MIT now.
said if UE4 will ever get C# (but there are no plans for it) it will never be like C# in Unity. So, anyone who have hopes to have it as in Unity are out of luck, and I bet will complain if C# ever makes it into UE4.
If C# ever comes to UE4, they will then ask for a component system similar to Unity. Then a similar “way to doing things”. And finally, a completely similar interface.
And why C#? Why not python or Lua. These languages are much more productive than C#.
Threads like these quickly get out of hand so keep it chill guys
Anyway, weighing in (this is obviously all just my opinion):
I started learning C++ around 2 years ago as my first real programming language, and I can write C++ in this engine faster than I can Blueprint now. Iteration time is more than acceptable with hot-reload (so long as you know the caveats of it, such as header changes taking forever and some items not supporting it). So long as your processor isn’t a MK1 potato, it’s just fine. In fact, in some cases my Blueprints take longer to compile than code!
I went from being a technical / VFX artist to a full-time gameplay, multiplayer and physics programmer in a very short period of time. My point is, it’s NOT hard or tedious to work with at all if you’re prepared to put the time in - and the minor caveats you have to pay are worth the ridiculous amount of control and power you have. Also FYI, Unity engine is written in C++ not C#. C# is just the exposed layer on top and I know more than enough people that say a lot of the time - it isn’t enough.
Out of experience, I’m calling BS on that. Remember what you’re looking at is probably also a sales pitch.
That literally sounds like the stuff of nightmares personally.
Nope, Epic care about artists, not programmers, and if there is any code to write they make the artists do it with blueprints.
As for C#, it’s useless, that’s why every other engine written in C++ make the effort to expose it through C#.
and btw, if you avoid labda, linq, tasks, or the entire .NET framework and you compare the first version of the clr garbage collector to the epic c++ gargabe collector than they are pretty close!
This has not once been my experience coding C++ in Unreal. Bugs have a tendency to find me, so maybe I’m just one of those people that hot reload just doesn’t work as advertised for. The compile button is always greyed out for me, so it’s possible I have a real bug on my hands in every project. But yeah, even changing a float value in the source means at least 60 seconds of downtime and closing/reopening the editor.
You must be referring to the debugging experience. mentioned that too. And, there is a solution to this…
Yes it does. It is going to be only one V$ project for both, C++ AND C#. V$ must be able to generate its own external dependencies for the C# side, and there are generation tools M$ can make use of. E.g. Mono.
And did I just say “going to be”? I said that because a logical step in the evolution of programming languages would be to combine the native source code and the managed source code. This is not about “scripting” or “just” bringing C# to UE4 so that the fangirls finally shut up. This is a software engineering challenge! So this is about to finish that what C++/CLI or Managed C++, started in 2004.
No, I’m not too tech savvy regarding all this. But I’m sure you get the idea.
I may have missed the statement about what M$ said when they bought the creators of the Unity C# debug tool for V$. But I suspect that they wanted to learn more about managed code and native code relations at runtime. And maybe even acquire more devs for research and implementation. That’s is why they bought that tool. Think of it, why else would M$ buy them out and the even remove the price tag of whooping 100 dollars (Electronic Arts would sell it for 200 dollars :D)? Because this ain’t about some **** Unity scripting. This is about the creation of a new programming language! Yes, there is a paid version of V$. But Unity is more like indie and not enterprise.
Micro$oft ain’t a stranger to creating new programming languages. They made Visual Basic, F# and C#. Guess who is making the module system for C++? And why? To “save” C++? More likely to get rid of C++, and only use the current standard of it as a “migration syntax”. The “target syntax” could be that new native C++ that can work along with managed code that is a C#, and that within the same exe/dll/V$ Project file, and full debugging support.
The benefit of having a “migration syntax” and a “target syntax” on the native side, is that it could allow even the Unreal engine to function along side C# already. This can give the devs at Epic games, or any dev of any software, the time to migrate their C++ source based on the current standard, to a new native C++ of a hybrid programming language defined by the target syntax. No, the whole idea of this is not to get ourselves another C++/CLI thing. If you want to call it that, you could call this a “native C#” with a clean syntax. At least with a syntax as clean as possible, so only as much as the rules of native programming allow it, or the handling of managed code and native code within the same project.
I wonder how close we already are to this hybrid language. The constellation of the Unity debug tool, Mono MIT Licence, M$ Xamarin acquisition, the module system for C++ by M$, along a few other things, look very good to me. The very crucial part of a new programming language is to have a smooth/simple-as-possible migration procedure, though.
The solution is simple - learn C++ if you want to work with the engine, and learn BP if you want to make game using engine’s existing functionality. That’s it. There is so much sh#t missing from the engine or not working properly that having C# or some other scripting language is the least of Epic’s and other devs’ concerns. I think debating about it takes away so much time from actually learning C++ and BP, and from making something meaningful, that it could be compared to mild trolling.
I am not trolling. I am trying to open your eyes, Unity fans. New users come , see these whinings about C#, and think UE4 is such a horrible engine from programming point of view that it’s not worth dealing with. And join endless pool of C# whiners. Why don’t you stay with Unity if C# such a deal breaker for ya ?
People are arrogant? Want to troll they way in and get what they want regardless of what it takes? (those aren’t questions btw)
5% of devs ask for C#, the rest ask for something that actually is needed.
If UE4 offered ASM as primary programming language, I’d understand a need in another programming language. However, you have C++ (which isn’t conventional C++ but C++ specifically adopted for game dev with UE4, which makes it easier to work with) and you have BP. Use it and make something out of it.
Anyhow, it’s an amusing thread so keep whining. I’ll go get some popcorn.
