Heh? they not support hundreds of languages, only selected few if you mean overall support of langueges in Windows, it’s because you can implement any language as long as you can operate in machine code and from there you can call any system function, it’s common to most OSes.
I would love to see C# too. Unity gets a huge plus for this…
For example when I was in unity, only ONE line of code needed to either show the cursor or lock him. In UE4 even in blueprints I must make more than 1 nodes to make that happen…
In overall unity has done a really great job integrating C# as well as Java to their engine and let developers work with it. That’s the truth…
I know that it is a lot of work to epic to add a programming language but I think that if it’s done, epic will gain more developers so more money from royalties, so “no actual gain” which an epic staff stated is false…
I for my part want c# for its incredible extensibility and foremost for its faster development process.
I work much with procedural generated content. While developing i dont care much about calculation speed (since my rig is a fast one) and its much easier and faster to try out things in c# than in c++ because of the .net libraries/nugets etc and because with klawr it’ll be like its scripted. You change the code and then you’ll see the result a few seconds later.
I have to write less and the error messages in c# are always spot on (not always the case in c++). I dont have to manage header files additional to my code class files (which is a pain in itself, but thats another problem i generally have with c/c++).
Development speed, thats a main driving factor if you try something new with a yet unknown result. The process of optimization (speed and/or memorywise) comes after that for me, because something i cant code in c# i wont be able to code in c++ either.
The blueprints in UE are very nice, but they’re also not suited for complex calculations. They have to be coded.
TheJamsh isn’t wrong if he tells ppl to learn something new (thats never wrong), but for me c#'s pro’s (RAD, easy extensibility, vast number of libraries and reflection) are clearly more important than c++ strengths (mostly speed)
I second the point from Algorithman : I totaly agree. I find C++ is really powerfull for production-grade and optimized code, and UE4 API relieves from some C++ hasles. But R&D on prototyping complex logic may generate the BP spaghetti effect and it very time consuming in C++.
More over, you may do some prototyping outside of UE4, in some standalone console or WPF application in C#, because of its productivity-gain, or when you need an context-free testbed. Then, when come the time to go from R&D to UE prototype, it would be cool to test the UE4 integration of a component with minimal conversion, before investing time in BP or C++ translation.
I personally have a few components, engine-agnostic, that I used in various environment (standard Winform, or Neoaxis Engine for example), in C#, which I will have to recode in BP or C++ just to integrate at prototype stage, to test the usefull-ness (procedural algorithms, some specific math, etc…).
For this reason, I thank you, Algorithman, for your klawr initiative !
I think you mean JavaScript which is diffrent from Java, it only sheres similar syntax but if you try to use both they fell like opposites.
Reason the unity is using C# is most likely not because it benefits or anything, but fact they they didn’t wanted to expose native code (which is writen in C++) of unity to public and didn’t have balls to make there own scripting system, as JavaSctipt is very limited (it can do only things you plug to it via C++) so they adapted C# which is more extendible. Note that UE for long time also had it’s own scripting language called UnrealScript, which could only work in UObject space and only licenced devloper had access to C++ guts, in UE4 they throw it away (and Kismet they experiment with in UE3 which was based on top of UnrealScript, been turned in to blueprint. Blueprints still using UnrealScript virtual machine) and they though people that used UScript will switch to C++ (which when you used C++ from UScript, it feels kind of the same in terms of APIs), didn’t expected wave of Unity ex-users which got addicted to C#.
I don’t think it’s worth for them to implement C# either, they got lot of problems with UE4 overall that they need to solve, Mattine and Particule system really didn’t evolve from UE3 and replacements are still in development. With access to C++ and Plugin system you can implement any scripting you like, so i think they can leave it to community, if not now then in future when there will be plug-in marketplace.
My personal concern i have is that people seems to want to use .NET framework, instead of framework that UE4 have made to ensure portability and that might turn in to mess.
Not instead, in addition to. And why shouldn’t they? I miss many functions in c++, for example fluent Linq (i dont type sql-like statements in code), Lambdas, Reflection and the possibility to even compile dynamically created code. These higher functions make coding real fun time for me. I don’t want to reinvent the wheel all the time, especially if people who clearly can do it better than me already did.
PS: Yes i know about cpplinq (does it play well with UE4? i dont know), UE4 does offer some reflection (this should be extended).
But UE4 do provide vast number of functions that most people not aware of, even those who do use C++ in UE4. For example on answer hub i had the case of somebody trying to include whole Qt library for XML parsing (i’m not sure if “just” for that), but UE4 provides XML parsing too
So talk about reinventing the wheel UE4 does not offers “some” reflection, it offers reflection, it a core for most of functions in editor and even in C# you will need to attach to it in order to fully use things made in C# in rest of the engine (Especially blueprints), which from reading your post, it’s what you actually do. UE4 APIs are rich and gives support for many things and all of them are designed to work together with the rest of the engine, you just need to dive in to API reference. Majority of time what i do in AnwserHub is searching things for people as they lack ability to do so.
UE4 is also quite extensible via plugins, main problem right now is lack good distribution platform for those plugin. Once it appears UE4 will be flooded with ton of extension products, including those that people use Unity.
And don’t get me wrong, i don’t mind C#, i’m happy that you work on plugin to implement it after other bigger project stopped (the faster you do that the faster people stop arguing about C# on forums :p). But it little annoys me how people are so obsessed with C# like game development ends without it, starting with infamous “Why C++” thread talking like Epic committed some crime for not using C# and ignoring fact that UE was C++ extendable (because you practically extend engine) way before that, just it was not accessible for mortals playing with free UDK, now we have access to it UE4.
As for Lambda C++11 (which UE4 it self using) provides lambda functions, problem is UE4 APIs are not friendly for this feature (it prefers using old-fashion function pointers), but if you use it in scope of your code, it will build and work.
Tried unity, then tried UE4. UE4 left the better impression on me (BP Material editor 10/10), quality of the Engine itself and the possibility to look at the engine code, the samples, the videos.
I dont want UE go full c#. It would hit performance and atm also the portability. But its nice to have the possibility.
I want to use c# for precalculations, level generation, such things. Mostly data-driven stuff. So performance is not an issue for me. Later on i’ll have to optimize the code, maybe even rewrite it in c++ (i really, really hope i can prevent this), but thats only after i get it to my desired quality level.
Hmm, have to read this ‘Why C++’ thread, i want a good laugh
It’s funny seeing people talking about the speed of C++. binary would be even faster, but what are the odds that you get it right?
if you can do something in half of the time due to a productivity boost you can spend the other half by tweaking it for speed once finished.
It would be even faster if we didn’t use UE4 at all, we could just build or own engine for each specific game.
C++ is used as a scripting language as you would do with C# and blueprints, of course you CAN do more if you want, but that’s not what 99,9999% of the community does.
Just create a new class and you will see that there is no need for a destructor, any guess why?
C# is way more testable and has a major advantages in terms of intellisense and that’s enough. There isn’t even the need of talking about linq.
Scripting must be fast, performance should be an engine problem
btw visual studio 2015 supports intellisense extensions, it would be great having an unreal extension for it
Well techniclally C++ in UE4 is not scripting language, you practiclly extendeing the engine just by using it, you just adding module in to pile of other modules that engine already have and they all equile to each other, whatever you place code in to project, plugin or even directly to engine it will work the same.
Lot of people now days misunderstands what engine is, they think it’s all about graphics, when in reality it’s main function is to provide fundamental game play code and render it state on screen, thats why not every engine is good for every game as some engines are made for specific kind of games, UE4 even thru Epic tries to make it more universal since UE3, is still easier to build multiplayer shooter on it then anything else.
If you making inventory system (which btw to UE3 had build in) it essentially becomes part of the engine as it blends with rest of the engine components. Thats why i believe in UE4 building fundamental of gameplay (like inventory system) for your game should be done in C++ and scripting for it (like invidual items) should be done in Blueprint or if you like C#, so artists can get involve, sometimes if you do that good they don’t even need to code anything in blueprint.
But they way people talking about C# is that they want to extend engine using it, rather then use it for just scripting.
C++ Compiles into Binary just like Assembly Language. C# compiles into Bytecode just like Java and Blueprints, and thus adds an extra interpretation layer in-between, hence it being “slower”.
A recent real-world example of the speed of C++ versus C# / Java - Minecraft. If nobody has tried the C++ version compared to the Java one, you will be amazed at the speed difference. It’s simply Blistering. Minecraft is a pretty simple game when it comes down to it. No complex physics simulations, no shaders or advanced graphics, just triangles and textures and some basic (but well-written) gameplay code. Speed / Flexibility is a very important factor.
are you against blueprints then?
there is no speed difference between C++ and C#, there would be if the ENGINE would be made in C#, and even then I would still doubt it.
What you are suggesting is that every game made with Unity engine is too slow to run properly, do you believe that?
I had made this assumption initially as well (because it would seems so “obvious” and make sense).
However, noope, the Blueprint system is a “normal”, turing complete, finite state machine.
The “compilation” of a blueprint is more a tokenization into bytecode…
Well, it is nowhere mentioned that BP would compile into machine code as well
If you get performance issues, you could replace critical parts with C++ code. For the “overall logic”, you still can use your BPs…
Not at all, Blueprints are great and as I said in another thread, if it runs at your target framerate it doesn’t matter. But to say there’s no speed difference between C# and C++ is incorrect. Unity games aren’t too slow to run, but I’m saying that Minecraft is a perfect example of how Binary runs hella-faster than Bytecode - but that doesn’t mean that Bytecode is unuseable (though it definitely would be at Engine-Level).
As somebody pointed out, Unity (The Engine itself) is written in C++, C# is merely a wrapper that talks to the engine. C# in Unity also doesn’t really resemble C# at all, it’s Unity’s own ‘Version’ of C# with their own functions and callbacks etc. Even if we had full C# in Unreal, it still wouldn’t look anything like Unity.
I should clarify this. Blueprints compile to Bytecode, but it still runs the C++ functions as C++. The ‘Bytecode’ layer is for things that you may do natively in Blueprint like math operations etc, and also for all the calls to the C++ functionality. Best way to explain this is:
You write some math in Blueprint using the native nodes, it runs too slowly.
Instead, you can write a C++ function that does all of the above, and simply expose that function to Blueprints. At this point, it should run faster.
I didn’t know I was suggesting to rewrite the entire engine in C#.
so we are at the point where C# cannot be used in making games therefore unity doesn’t exist and C++ is enough for everything therefore blueprints do not exist.
To be clear, I’m not pushing this C# thing, I think that the priority here is to make a more polished product, one that does not introduce breaking changes every release, and better integration between already existing features.
BUT the gap between C# and C++ must still be closed, and it isn’t a task than blueprints can accomplish.
If you want to expose just C++ you have to provide much more to the developers, I need a far better intellisense, a custom tooling to create new actors, etc…, more comments and snippets, and far more debugging errors instead of runtime errors. All these tasks can be made (expecially in visual studio 2015) but everything you can see in the roadmap are new features.
Just take whatever game you want, pick up unity and unreal, and you are always gonna finish the unity version in half of the time. I would like to switch to unreal, but atm It is simply not possible
Just wanted to say, what happens if your using Unity, and the engine doesnt have a feature that you want for you game? Maybe you make a request to the Unity Team, hope they see it weeks later, and then hope maybe months later they eventually implement it into the engine so that you can use C# to work with that feature.
In Unreal, you open up the source code, implement the feature in all the necessary places, maybe even make some blueprint functionality for it, compile, and there you go you have a completely new feature added to the engine, without having to wait for the people that produce the engine to code it for you, and having to wait months down the line when you needed the feature in the first place to continue building your game.
how many times did you do that? actually, how many times anyone have ever done that? the github repo is not even the primary repo, you may be able to pull something but I doubt it.
and btw, that’s not my job! I use a game engine, I do not make one.
if you mean overall support of langueges in Windows, it’s because you can implement any language as long as you can operate in machine code and from there you can call any system function, it’s common to most OSes.