Why C++ for Unreal 4?

[VegasRich]

If you don't know C++, learn it.

Do. Or do not. There is no try.

Or go use Panda3D. It's pretty awesome, it's free, and it uses Python.
Or use Blender itself. It is not just a 3D modelling application - it's also a game engine. And it uses Python.
Someone hands you a half-million-dollar game engine for $19 a month and you complain about what flavor your Kool-aid is. If you really don't like it, add your favorite script binding yourself. If you can program in a script language then you can program in C++. Programming is programming. So we're back to "If you don't know C++, learn it."
I bet if someone gave you a million dollars in $1 bills you'd complain....

[mikepurvis]

@EruArnold

I can't speak to the 3DBuzz tutorial, but you shouldn't blame Epic for what other people put out. Follow the Epic tutorials instead. I haven't had the issue's you are having. I do use Visual Assist for Intellisense though.

https://wiki.unrealengine.com/Get_Started_with_UE4

[VegasRich]

Sorry, EruArnold - this is going to be a response to things you have said, but it's not directed at you. I'm not attacking you, or trying to imply anything about you as a person - you seem pretty smart and thoughtful, but since I don't know you I'm not presuming to judge. I am responding to the sentiments expressed in your statements - which seem pretty common across the spectrum of people who are unhappy with Epic's approach.

The reason I am getting upset, is that going back to C++ is something I was hoping never to have to do too much ever again, and because I like UE4 so much that it becomes totally frustrating realizing I might have to, in order to use it.

And if you want to extend the engine's underlying structure you would have to anyway. You'd have to add the necessary classes, add your bindings, then write your script.

Investing in a career-shifting move is a very big and scary decision, that might have long-lasting impact on my life, so excuse me for not taking it lightly.
Whenever one get's "invested" into a platform, and having that investment dictate one's future-livelihood, emotions run high when a change is happening in that arena - Imagine the reaction of experienced Silverlight-developers that have invested years of their lives in it, and being payed daily for coding for it, suddenly discovering that Microsoft is discontinuing the platform... Or how about Flash developers... Development-platforms are, for developers, "investments" that sometimes have large impact on their lives. So, it is obvious why emotions run high.

This is why professional developers are always learning. Part of being "professional" is being professional - instead of being emotional. When one of the "Big Dogs" decides to discontinue something it is usually an old decision made months or years earlier based on business factors that the end users' emotional outbursts just won't change. And a professional who does not constantly evolve to keep pace with his profession will not be a professional for long.

I can summarize my argument is one sentence:
In games-development, access to the C++ code is a welcome-addition-to and NOT a substitution-for additional scripting-languages

And it is. It just ends up that the provided "scripting language" isn't what everyone wants. And just like any other scripting language you might want to bind, you'll need to work in C++ if you intend to make any serious engine-side changes. Admittedly, adding a blueprint is considerably more involved than adding a binding in Lua.

Many people posting here that do not understand the concept of hybrid-development, somehow think that adding an external-binding to a scripting-language would somehow compromise/jeopardize their ability to access the C++ code (I have read several such reactions here, perhaps you missed them).
Why? Because they think that what is being asked in for an entire AAA game-engine to be written in another language - because they don't have in their head the concept of language-bindings.

I bind Lua for use in internal tools all the time. My main program is in C++ and I use Lua as a control language. Very handy. Torque 3D uses a proprietary scripting language for control and event handling - also very handy. Performance does not suffer at all. In both cases, if you want to extend the engine/program you have to work in C++.

LUA is being used as a scripting layer in many DCC applications as well as many game-engines for years now (even AAA ones, like CryEngine), and Epic is now adding it already, as has been shown here.

It's a neat language, it's fast, it's easy to bind. No surprise here.

And btw, other languages that are bound to a game-engine, does not necessarily have to be "scripting" languages, or be "slow" languages at all...
Just look at the work that is being done in languages like "Rust" and "D". There are many reasons not to use C++ if you can, that have nothing to do with even development-speed, such as guaranteed "memory-safety". Rust has a very interesting solution to a bunch of very long-standing problems that languages like C++ have been having for decades - take a look:

C++ offers a way to provide the "guaranteed memory safety" that Rust has - write your own memory manager. Once you have it done, it's done.

Should future game-engines be coded in D or Rust? Maybe. Maybe not. There are other factors to consider, like maturity and access to C++ libraries.
But could existing game-engines benefit from providing a layer of Rust or D for extensibility? I think the answer is "Probably yes".
And it has already been tried:
DConf 2013 Day 1 Talk 5: Using D Alongside a Game Engine by Manu Evans

The main thing here is to remember that you have the source to the engine. Since the engine source is written in C++, you'll have to work in it sooner or later. If you want to bind to Lua, Rust, D, C#, MyBananaBread, whatever, you can do it. Have at it. Seriously. If people want to be programmers then perhaps they should be programmers. Any serious programmer is very good with at least two languages and can work comfortably in at least two more. Anyone who insists that "one language rules them all" is a fool. Instead of crying all the time, people should just learn what they need to accomplish their goals and move on.

[EruArnold]

I am learning more modern-C++ every day, and it's on my list to learn to code in C++ for UE4 anyways, that's not the point - as I said "Hybrid-approach is almost always best". So again, don't think in terms of "absolutes" (Yes/No C++), instead, think in terms of "ratios" (how MUCH C++).
I am not worried that I would have to learn C++, I already know it pretty well (I'm just doing some quick-refresher courses, as I haven't used it for a while, and "modern" C++11 is very different, as it has tons of new stuff that deprecated/makes-legacy the "old style").

I think there is a terminological-problem in this discussion:
I know that "extending" the engine would require coding in C++ against the API, that doesn't scare me.
What I AM worried about is needing to do most "game-logic" in C++ as well - that is very different -I don't think that constitutes "extending the engine"....
Are Unity3D-developers "extending" the Unity engine when they are writing all of that C# code?? I just don't understand this perspective...
When I write MaxScript I am NOT "extending" 3dsmax...
If I write a C++ plugin against the 3dsmax SDK, and adding a new "Object-class" with it's own new and unique class-ID, and that's a very different story, with a whole can of worms of it's own. I have been very productive with maxscript over the years, and it would have been absolutely impossible to get that level of productivity if I didn't have maxscript, and would have had to code all tools in C++ - it would have been a complete nightmare.
Let's give a concrete example as an analogy:
There is a plugin for 3dsmax called "Genome", that is basically a custom-modifier that provides a node-based GUI that enables coding geometry-math visually.
It is a form of visual-scripting language. Other examples include the node-based material-editor, node-based render-pass-compositor, and more such tools like Thinking-Particles. They are all really cool and flashy, and a tech-artist can accomplish a whole-lot just connecting nodes around.
More examples:
Maya has many node-based editors (Hell, it basically "pioneered" this concept almost 20 years ago...)
Softimage has an almost complete visual-scripting language called ICE
Fabric-Engine (the up-coming 2.0 version) with have a visual-scripting language.
RealFlow has a node-based editor
Hudini is all node-base.
Nuke is all node-based.
Fusion is all node-based.

But are these all "substitutions" for scripting?
HELL NO!
Maya has always had MEL from the get-go (most of it's interface and tools are actually MEL-scripts), and in recent years is also added Python as well as .Net.
3dsMax still has MaxScript as well as .Net-integration, and now finally Python as well (As of the 2015 release)
Softimage still has many language-bindings, including ,Net and Python
Fabric-Engine still has KL and Python
RealFlow is adding python support
Hudini has built-in python support
Nuke has built-in python support
Fusion has both Python and LUA
...
(You get the idea)

All of these above-mentioned "platforms" are written in very high-performant C++ AND have awesome node-based editors, much like Blueprints.
None of them considers that fact reason-enough not to include scripting support.
Why?
Because there are multiple-tools for different-needs/use-cases.
I bet at some point the UE4 editor will also have python-support, if nothing else, just for the editor-itself and not the engine - just for better pipeline-integration capability with DCC applications.

And no, C++ access is NOT a substitution also:
Maya has had full-access to it's C++ API for decades.
Same for 3dsMax
Same for Softimage
...

I know that these are different type of applications, and that they are not expecting to run python within a real-time execution-environment, but still - given that we're talking non-performance-critical stuff here, there is really not much difference...
Everybody else are doing it for a reason - they do not invest in adding scripting-support "just for the heck of it" - it comes from user-demand.

And don't tell me about Pandas3D or the Blender game-engine - these are toy-examples, they are not in the same league as UE4...

[Gigantoad]

Do any of those come with full source code? No. Seems obvious that they need to put a layer or two on top to make things scriptable.

Are you not the least bit excited about being able to develop and debug right in the engine source code? And of course, again, there's blueprints as an incredibly convenient way to do visually what you would have to normally type with way faster iteration times and live visual debugging. Think about it, you can actually see the execution path right there graphically while you play the game. Try that with step by step debugging of scripts.

There's a reason why even hardcore C++ proponents recommend to use blueprints as much as possible. It's just so sweet, and porting stuff to C++ later is much more straightforward if the functionality per se is already established.

[VegasRich]

Nevermind - As I said, I use several scripting languages in my daily work. I understand their uses and applications pretty well. As I also said, if you want to use your favorite scripting language with UE4 just implement the binding and have at it.

[EruArnold]

@Ginatoad: I'll answer one-by-one

Do any of those come with full source code? No. Seems obvious that they need to put a layer or two on top to make things scriptable.

You don't need FULL source-code in order to really extend an application - all you need is FULL API-level "ACCESS".
I have written C++ plugins for Maya and Mudbox, that adds custom user-interfaces. You could also write new geometric-operations, UV-space modifications, custom-lights, custom render-engines, custom rigging-algorithms - the sky is the limit, really. (Same goes for 3dsmax and Softimage plugins-development)
This whole "full source-code of everything" is really just useful for very-large studios with very large teams of coders, that have the time to study more deeply and broadly what the engine is doing. That comes with it's own-cost also, though. Braking-changes to an API that enforces you to refactor your plugins for newer releases of an application is one thing - but imagine what a nightmare it would be if your extension modifies/relies-on lines of code that no longer even exist in a new release, because they decided to do things differently... Oh, the nightmare of dependency-hell you would get into then - good luck with that...
Really, it's not for the general-population of UE4 developers...

Are you not the least bit excited about being able to develop and debug right in the engine source code?

Exciting?
Perhaps in theory...
In practice, you wouldn't want to go that rout if could avoid it...

And of course, again, there's blueprints as an incredibly convenient way to do visually what you would have to normally type with way faster iteration times and live visual debugging. Think about it, you can actually see the execution path right there graphically while you play the game. Try that with step by step debugging of scripts.

As I said, Bluprints are totally awesome and all, and the visual-debugger is the coolest of all - but what about, say, version-control?
I know they are working on visual-diffing tools, but really, can you compare that with working with a REAL version-control system like Git?
And how would you do code-reviews? Contentious-integration/deployment? Life-cycle-management?
No. I'm sorry, it is not a feasible development environment unless you have professional-oriented workflows like the ones I mentioned, that have been refined and perfected over the years - it would through you decades backwards if you don't have them.
And as for graphical-debuggers, Visual-Studio has had that for years if you're that excited about it:
Debug visually with Code Map debugger integration
Understanding Your Code Using Code Map
And it works in many different languages, you could even try-it out with UE4's code-base, see where you go with it (provided that you have VS-Ultimate)

There's a reason why even hardcore C++ proponents recommend to use blueprints as much as possible. It's just so sweet, and porting stuff to C++ later is much more straightforward if the functionality per se is already established.

And all of this will still be true and possible if they added scripting-support.
Main difference is, you would get a much more iterative-workflow if you transfer a blueprint into a scripting language than if you do it for C++, perhaps with not even having restart UE4, not even once...

And another note people seem to forget:
The argument for different languages is not just about syntax and semantics - these are the easy things to transfer - No, the REAL benefit of any programming-language comes from it's "ecosystem" - The libraries/packages/modules/frameworks you get, that may have a very convenient expressiveness of the problem-domain. I have been using a Python server-framework called web2py for a very large studio-management project we've been developing, and I an't imagine getting anywhere near the simplicity, cleanliness, ease and speed of development in any framework in any other language - "especially" not C++.
And this is just one example. People from the .Net world would be missing/crying-out for things like LINQ or Entity-Framework, etc.

[iniside]

@Ginatoad: I'll answer one-by-one
Exciting?
Perhaps in theory...
In practice, you wouldn't want to go that rout if could avoid it...

In practice, it is better to have access to source and don't need, than need it and don't have it.
Access to source code more than few times saved me from tedious figuring out, why something is not working, or how to do something similar but different to engine functionality in my game.

And there are already more than few people adding more common functionality right into engine (Hi Rama!). Why would I trade it for not having sources is beyond me.

Anyway. Funny drama. Have good laughs here.
For all complainers about scripting languagues and that they are feel terrible because they are forced to use C++.

https://forums.unrealengine.com/show...ns-via-plugins
Read that thread. Start helping on plugin. Quit complaining. Every idiot on planet can write post on forum. If you want to have something, start working on it and help other people who already are working on exactly the thing you need.

I'm not interested in other things than C++ and Blueprints. Do I complain that people should stop working on other languages bindings, and tell them they are wasting their time, because they should work on things I need ?

People from the .Net world would be missing/crying-out for things like LINQ or Entity-Framework, etc.

LINQ ? Yes I miss it. Somewhat. Entity Framework ? Why would I use it for game development, where there are better solutions ?

[EruArnold]

In practice, it is better to have access to source and don't need, than need it and don't have it.

Agreed. But even if you don't have, you usually don't need - that was my point.

Access to source code more than few times saved me from tedious figuring out, why something is not working, or how to do something similar but different to engine functionality in my game.

Your mileage will vary, but most applications that support extensibility via plugins/API-access, have closed-source-codes, and usually don't have problems in that domain - when there are problems, you are probably better served by customer-support and talking to an engineer who actually wrote the thing, and can explain to you better and faster how things are designed to work and what is the best way for you to refactor your code to make it work in the best way possible, given many other variables/factors you may not even consider or would probably not be aware of from just looking at the source code. You CAN go through the code and try to reverse-engeneer it and figure it out yourself, but you might end-up shooting yourself in the foot by not taking into consideration hidden factors - you code will work, but cause unexpected problems in other areas - this is very common.

And there are already more than few people adding more common functionality right into engine (Hi Rama!). Why would I trade it for not having sources is beyond me.

Again this dualistic either/or type of thinking...
Tell me, where in this entire thread has it ever been suggested the Epic would close their source-code??

Anyway. Funny drama. Have good laughs here.
For all complainers about scripting languagues and that they are feel terrible because they are forced to use C++.

https://forums.unrealengine.com/show...ns-via-plugins
Read that thread. Start helping on plugin. Quit complaining. Every idiot on planet can write post on forum. If you want to have something, start working on it and help other people who already are working on exactly the thing you need.

Thank you, I will look that up - but my argument is not that things are not being done - my argument is targeted against the argument that it is not needed.

I'm not interested in other things than C++ and Blueprints. Do I complain that people should stop working on other languages bindings, and tell them they are wasting their time, because they should work on things I need ?

Look, it's a debate about mind-share - if more people get into believing that they could do just as well without scripting-support, there would be less user-demand for that, and less people working on that. I am arguing here in an attempt to mitigate that trend that has evolved in this thread.
I am NOT telling people not to code in C++, I just point-out the shortcomings of doing that, and how it would be easier WITH scripting support then without - and again, as an "addition", NOT a "substitute".

LINQ ? Yes I miss it. Somewhat. Entity Framework ? Why would I use it for game development, where there are better solutions ?

I am not too familiar with that space - I just through-out some example to make a point - which is:
"Programming languages are more then just syntax and semantics - they are ecosystems of existing reservoirs of usable code-bases"

And not all frameworks are created equal across languages (hell, not even within ones...). Some are more expressive and easy to use then others, and some have capabilities then stem right out of language-features that don't exist in other language (I can further elaborate on that, but I think you get the point).

[Gigantoad]

@Ginatoad: I'll answer one-by-one
As I said, Bluprints are totally awesome and all, and the visual-debugger is the coolest of all - but what about, say, version-control?
I know they are working on visual-diffing tools, but really, can you compare that with working with a REAL version-control system like Git?

UE4 already supports real version control. I use Perforce, so does Epic. Blueprints have visual diffing already. Granted, I work alone currently so I don't know how much of hassle it is in a team. Seems to work for Epic though. Maybe it's not even necessary that several people work on the same blueprint? Certainly not simultaneously?

And all of this will still be true and possible if they added scripting-support.
Main difference is, you would get a much more iterative-workflow if you transfer a blueprint into a scripting language than if you do it for C++, perhaps with not even having restart UE4, not even once...

Well, they are adding scripting support right? You know, actually I'm not even sure why we're still taking about it

On your second point, you'll just have to explain why you would port from blueprint to scripting. What's the benefit? I think it would be more likely an either/or situation, because if you do end up porting blueprint to code it would be performance-critical stuff. Some door firing an event one time when the player gets close to it would hardly be worth it to port at all. If you're doing per tick heavy math stuff you may want to port it, but would anyone really then port it to LUA or C# instead of C++? It doesn't seem to make much sense.

And another note people seem to forget:
The argument for different languages is not just about syntax and semantics - these are the easy things to transfer - No, the REAL benefit of any programming-language comes from it's "ecosystem" - The libraries/packages/modules/frameworks you get, that may have a very convenient expressiveness of the problem-domain. I have been using a Python server-framework called web2py for a very large studio-management project we've been developing, and I an't imagine getting anywhere near the simplicity, cleanliness, ease and speed of development in any framework in any other language - "especially" not C++.

And this is just one example. People from the .Net world would be missing/crying-out for things like LINQ or Entity-Framework, etc.

LINQ is nice but for complex per tick stuff it may be too slow and you may end up removing it. Games are just a different beast than business applications. But sure, having the option would be nice. I doubt we'll ever have all the nice options of other languages in UE4 though, better to just get over it and work with what you have. The faster you can get over the "oh I could do this so much faster in that tool", the happier you'll be in the long run. Otherwise it's an endless circle of wishing and hoping when in reality, no tool will ever get everything that all other tools have.

This may be of interest: [url]http://stackoverflow.com/questions/232222/is-there-a-linq-library-for-c[/url
Or this: http://www.drdobbs.com/cpp/linq-like-list-manipulation-in-c/240166882

Entity framework is irrelevant for game development. It's an ORM, not sure you'd even get it to run inside a game engine, along with a lot of the .NET Framework functionality. I don't even know how that would work. Would people who want to play your game have to install the .NET redistributables first?

[EruArnold]

UE4 already supports real version control. I use Perforce, so does Epic. Blueprints have visual diffing already. Granted, I work alone currently so I don't know how much of hassle it is in a team. Seems to work for Epic though. Maybe it's not even necessary that several people work on the same blueprint? Certainly not simultaneously?

Well, that's not really a satisfactory answer, now is it...
Perforce is not free (as opposed to Git/Mercurial/SVN etc.), and is not exactly a common tool for version-controlling scripts...

Well, they are adding scripting support right? You know, actually I'm not even sure why we're still taking about it

Well, afaik, what Epic is currently doing is facilitating the infrastructure for implementing external-language bindings - they are just using LUA currently as an example so they have something to work against, and since it's one of the easiest ones out there to integrate into C++ runtimes.
To extrapolate from that to say that they are implementing/plan-to-implement any other language would be erroneous (at least at this point in time).
And again, this thread is not just a shout-out for Epic, it is mainly about swaying public-opinion about the UE4 user-base in that direction, opposing the notion that having JUST C++ source-access is enough.

On your second point, you'll just have to explain why you would port from blueprint to scripting. What's the benefit? I think it would be more likely an either/or situation, because if you do end up porting blueprint to code it would be performance-critical stuff. Some door firing an event one time when the player gets close to it would hardly be worth it to port at all. If you're doing per tick heavy math stuff you may want to port it, but would anyone really then port it to LUA or C# instead of C++? It doesn't seem to make much sense.

The way I see it, Blueprints are not a programmer-tool, mainly - their main target (and Epic has stated that on many occasions) is artists, game-designers, generally people that are less heavily-technically-inclined. Given that, and given that Blueprints would probably never get the level of expressiveness as mainstream scripting languages have, it is safe to bet that he Blueprint-code that is generates would more-often-then-not be better treated as not-much-more than a "prototype", a "proof-of-concept" by some designer/artist. That is also a perspective that has been publicly expressed by Epic personnel on many occasions.
The blueprints that would end-up being generated might end-up being much more convoluted to decipher then what an experienced-programmer would be able to express in code. Moreover, once there is scripting-support, much logic will already be developed by programmers in a scripting-language, and it should be more convenient for them to translate blueprints into their native-languages, if nothing else for re-use and extensiblity, bypassing any inter-op layer between a compiled-blueprint and a written script.
Plus, as noted before, scripts would probably be still faster then compiled blueprints in many cases, and though that may not be an issue a lot of the time, and while C++ would be even faster still, the script-version would be a sweet-spot that gives a nice performance-boost that would probably be sufficient for most cases. Heavy math stuff, yeah, those would probably be most fitted to be coded in C++, but those would be few and far between. This is scripting-optimization land, as is already being done in scripting-environments for many years now.
Case-in-point: C-Extension variation of the "simplejson" package in python (for decoding/encoding JSON formatted text), as an alternative to the default pure-python one (measurable performance-boost - believe me, I've checked it extensively). What percentage of a code-base is JSON-decoding/encoding represents in this case? That depends, but if that is "the main" bottleneck in your code-base (given your properly profiled your execution, and are not just "following your gut" which be wrong in most-cases), then once you solve it, the rest would be futile to convert to C++ (there is a point-of-diminishing-return on that performance-graph...)
So, say you have a function in your code-base that is doing ray-trace/ray-cast computation implemented within a complex algorithm. You probably wouldn't even prototype that using blueprints, and start-off having a script-function. Later, this function gets more and more used, on many occasions in your script-code-base, and it becomes noticeable at run-time. You THEN convert just this function into C++ using UE4's extensibility-classes, and have direct-access to it from your scripts. You just re-factor them all to use that variation instead of the scripted one you wrote initially, and voila - you are benefiting from both worlds, and had solved your bottleneck - with just a minimal use of C++, just where it's appropriate.
This is what is called "Hybrid/Heterogeneous Development", and often provide the best trade-offs all around.

[Gigantoad]

Perforce is free for up to 20 users. Also we were talking about blueprints not scripts. I don't know how well it works for code, never used it for that. If you do have code then you can just use whatever you like anyway.

As for your other points, I think we're just repeating ourselves at this point. Let's hope that scripting support will come and allow people like you apparently unhappy with the current situation to work with UE4 and have fun. Instead of waiting until that days comes though, maybe you could just start using the engine now, play with the many features it does have, and who knows, when scripting arrives in the future you won't need it as much as you initially thought.

[VegasRich]

Off in the weeds much? What codebase is not "compatible" with revision control of any flavor? That has to be the weirdest thing I've ever read......

[LcSweeper]

I think this is important for many to understand, one can find public complaints about this on other frameworks going back some time. For Epic's sake, sometimes feel as if this particular issue is directed wrongly at them. Otherwise...

Seems like there are plenty of arguments to go around no matter which side you prefer. I have my preference and it's not C++, but what's the point of complaining if we are using UE4? It's not like programming games is easy in any language. If those here are looking to build in UE4, then C++ is what you have and blueprints which IMHO are about as innovative and advanced as it gets. There was some talk from some developers about adding more language interfaces, I'd recommend finding those threads for those who are interested to lend support and suggestions since the debate over languages will never be settled. In an effort to be neutral on the subject, there are probably better outlets in helping to add new features than an attempt to change another's opinion.

Could be that this thread may have a happier home under General? Maybe it's more fitting in this group, but this is a topic that generates more anger than being informative.

Thank you!!

[furrykef]

Off in the weeds much? What codebase is not "compatible" with revision control of any flavor? That has to be the weirdest thing I've ever read......

Revision control usually doesn't work well with binary files. If blueprint files are binary, then a special tool of some kind is necessary to diff them and merge changes properly.

(Disclaimer: I don't know what blueprint files are like nor if such a tool exists)