Why C++ for Unreal 4?

[anonymous_user_689e935a]

[=EruArnold;103892]
I agree that most language-debates are futile, but I am frustrated that most people here don’t even understand what is being debated here, and mistakenly think this is a language-debate - it is not.

Let me say it loud and clear so people won’t have the slightest chance of continuing to misunderstand:

…
[/]

Good lord, is everything alright on your end? You seem overly intense and this is only your second post. It seems your incredible expertise (or what you perceive as such anyway) is doing you no good at all.

Here’s a of Sweeney, you know, the founder of Epic Games. Nothing more needs to be said I think.

[= Sweeney;16252]
The first three generations of the Unreal Engine included a sandboxed scripting language, UnrealScript, which provided a simple interface for gameplay programming that was shielded from the complexity of the C++ engine.

The scripting approach is very welcoming to new programmers, but eventually it breaks down and becomes an obstacle to innovation and shipping. We experienced this over time as the Unreal Engine grew until finally, in 2011, we moved to a pure C++ architecture. The causative factors were both pervasive and general:

• As an engine and its community grows, there is increasing pressure to expose more of the its native C++ features to the scripting environment. What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.

• As the script interface expands, there is a seemingly exponential increase in the cost and complexity of its interoperability or “interop” layer where C++ and script code communicate through a multi-language interface for calling functions and marshaling data. Interop becomes very tricky for advanced data types such as containers where standard scripting-language idioms differ greatly in representation and semantics from their templated C++ counterparts.

• Developers seeking to take advantage of the engine’s native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell.

• Developers need to look at program behavior holistically, but quickly find that script debugging tools and C++ debugging tools are separate and incompatible. Seeing where script code had gone wrong is of little value if you can’t trace the C++ that code led to it, and vice-versa.

It is these reasons, ultimately, that led to Epic’s move to pure C++. And the benefits are numerous: UE4 is a unified and fully-debuggable code base, freed from Interop Hell and totally open to programmers to study, modify, and extend. There are side-benefits, too, such as increased performance in gameplay code, and ease of integrating other middleware written in C++.

Building Unreal Engine 4 as a unified C++ codebase has been very freeing, giving engine and gameplay programmers enormous flexibility to write code without unnecessary interop barriers.

This isn’t to say that C++ is the ideal language for simple gameplay code. It is more complex and more dangerous than UnrealScript, C#, and JavaScript. But that is another way of saying that it’s more powerful.

By making peace with complexity and writing code in C++, there is absolutely no limit to what you can accomplish, whether it involves debugging your entire codebase in-context, interfacing to low-level engine systems, modifying them, or talking to the operating system or advanced third-party libraries.
[/]

[VegasRich]

My favorite part of Mr. Sweeny’s post:

[]
By making peace with complexity and writing code in C++, there is absolutely no limit to what you can accomplish …
[/]

[anonymous_user_8bc0348b]

[]
That doesn’t jive with you saying it needs to have other bindings - most scripting languages are even slower than 10x less than C++. By a lot.
[/]

A link has been posted here, twice, showing how C# is roughly x2->x3 slower then equivalent C++, so by this calculation it would be about x3->x5 FASTER then Blueprints…

[=Gigantoad;103907]
Good lord, is everything alright on your end? You seem overly intense and this is only your second post. It seems your incredible expertise (or what you perceive as such anyway) is doing you no good at all.

Here’s a of Sweeney, you know, the founder of Epic Games. Nothing more needs to be said I think.
[/]

That’s just how I write when I’m ******-off… It’s not personal, or specific to this forum.

I have already read 's post (as I said, I have read this whole thread top-to-bottom).
What can I say, I am not convinced about his assessment…
To me, most of it sounds like a combination of after-thought-backwards-rationalizations and cleverly-disguised “marketing talk”.

Blueprints ARE a form of inter-op layer…
A blueprint-node, when executed, is “invoking” a call to the underlying API, and a game-logic code written in C++ wanting to call some blueprint-node, would probably also have to go through the data-model layer of a blueprint to get to it’s node, interpret it’s class-instance and then it’s corresponding API class-instance. And there you go, you already have an inter-op (albeit just a little shallower and more controllable).

I wouldn’t presume to know how binding to, say, Python, works, but it being done all the time for many libraries, with not much trouble.
The CPython implementation is very C-oriented, so it is considered “relatively” easy to bind-to, compared to other languages.

I agree that UnityScript was a very bad idea, but I believe it was more due to it’s immaturity compared to mainstream languages with decades of refinement on their back. .NET may also be an odd-ball in terms of breadth, complexity as well as licensing, I wouldn’t compare it with most anything else (except, perhaps Java…).

The fact of the matter is, what I am hoping for is already being started to be facilitated - and by Epic itself, so apparently somebody somewhere had a change of heart since 's statement - and for good reason:
https://forums.unrealengine.com/showthread.php?3958-Scripting-Language-extensions-via-plugins

What really bothers me is that people seem to think we’re asking for an engine with no C++ access…
No one is asking that - not that I have seen - what is being asked is IN ADDITION and NOT INSTEAD, so all these arguments are mute…
Will you NEED to write some C++ code for your game? Most probably, yes. It is GOING to be beneficial AT CERTAIN POINTS (!)
People have this dualistic black-and-white simplistic kind of thinking, and can’t think in terms of “degrees” and “measures” and most importantly RATIOS.

Lets illustrate with a thought-experiment of a typical case-scenario, shell we?
You are developing a game.
Coding your game logic would take, let’s say, twice as much in C++ as it would in C#.
(don’t know how realistic this assessment, but to me it seems generous to C++)
Now, let’s say 90% of it is non-performance-critical, so that means at least 10% you are going to code in C++ anyways.
Lets assume that coding in C#, for the rest of the 90%, would cost you a performance-penalty of 300%.
Now, since it’s non-performance-critical, it updates infrequently so is spread-out across cpu-cores and time, which brings it’s “effective” penalty (meaning, how noticeable it is) by at least 2 orders of magnitude.

You got 3% of “noticeable” performance-penalty, but sliced your development investment in half.
Is it worth it?
YES!

And to me, this sounds like a very pessimistic-scenario, except for a very specific target-audience:
Big Game Studios ! (Here we go again…)
Why?
Because that 10% in THEIR case would probably be a pretty-substantial code-base by it’s own-right, that would explode into a nightmare of debugging for any custom-inter-op that would have to be implemented especially for it, as said.
That is the ONLY case in which this scenario fails - and it is for an extremely “rare” audiences - how many big game-studios are there? How many small shops? How many indies? You see the picture? Epic is targeting big game studios specifically and explicitly with this line of thinking, which means they care more about their own bottom-line coming from a few high-profile customers than for the rest of their entire huge and growing user-base.

THAT is why I hear marketing-talk in 's statement.

Sucking-up for you top-tier-only with such statements and leaving the rest of the user-base in the dust, is not a way to to run a business long-term, and would have to realize that at some point.

You HAVE to cater for the lower-level also, because that is where your long-term revenue will come from down the line - the bottom grows wide if you invest in it properly.

It might have been wise to not tie the core to a scripting-run-time for (like Unity did) so that your top-tier could work without it, but there is no excuse not to make it “optional” as a plug-in, if you can.

All the non-sense about language-performance is utterly irrelevant in this entire story - it just doesn’t hold to closer scrutiny.

If you want to talk “inter-op debugging overhead”, that is a very different story, but most commentators in this thread have not talked about that…
They just scream aimlessly “C++ is faster!!..” … “Games need to be written in C++!!..” and such mantras…
That is what frustrates me in this entire thread.

[anonymous_user_8bc0348b]

Here is a crazy idea for cross-language scripting-support:
Since ZeroMQ and MessagePack are writtedn in C++, and also both supported by many languages, and since ZeroMQ supports extremely-fast inter-process communication, and since MessagePack supports custom-binary-formats, you could theoretically embed these C++ libraries in a Ue4 , that hosts a socket to any external-language that supports both ZeroMQ and MessagePack. All you would have to do then is design an RPC protocol around them, that would do the inter-op.
Then, say, on the python-side, one just has to implement a thin-layer of translation as a c-extension that implements that protocol, and exposed a low-level API as a python-package. Since python as a scripting-language would be on the receiving-end of UE4 event-handlers, Python would act as the server, and UE4 as the client (2 separate processes). To make things low-latency on the Python’s end, Gevent could be used for it’s light-weight asynch-co-routines capability. From My experience with such an arrangement in python, it can handle thousands of requests per-second in a singe-process. And if Python gets CPU-bound, you simply launch more processes - and ZeroMQ could do the rest in terms of load-balancing (it can do that automatically in some topologies).
Similar solutions could be implemented differently for any language based on it’s strengths and weaknesses.

Debugging would then become rivial, and there is a standard and clear separation-layer between the 2 languages as they run on separate processes, and you could very easily have 2 IDEs (VS for UE4 and, say, PyCharm for Python), and put breakpoints in both, and watch the flow of data through it’s game-logic paths.

This may sound crazy, but that’s just an idea - spaghetti-against-the-wall if you like…

[furrykef]

[=Gigantoad;103733]

[=furrykef;103722]
The last I checked, it’s not 10 or 15 years ago.
[/]

If by that you mean to say that was written in C++, you’re wrong. It was done entirely in blueprint.
[/]

That wasn’t what I meant at all, and I’m a bit baffled as to how you could read my post that way. Now, remember, I was responding to this:

[=;103719]
Well 10-15 years ago a style game was written in c, for a good reason.
[/]

My point was, 10-15 years ago you’d write it in C (or C++) – but it’s not 10-15 years ago anymore. It’s today. We don’t need to write it in C or C++ now (and indeed it wasn’t). So what relevance does this argument have to us today? We should be concerned with today’s concerns, not yesteryear’s.

I also think the performance wouldn’t have been that bad for a -style game in a high-level language even back then. I saw plenty of simple games written in Visual Basic, and that was before the .NET days.

[anonymous_user_689e935a]

[=EruArnold;104003]
A link has been posted here, twice, showing how C# is roughly x2->x3 slower then equivalent C++, so by this calculation it would be about x3->x5 FASTER then Blueprints…
[/]

[=EruArnold;104003]

Coding your game logic would take, let’s say, twice as much in C++ as it would in C#.
(don’t know how realistic this assessment, but to me it seems generous to C++)
Now, let’s say 90% of it is non-performance-critical, so that means at least 10% you are going to code in C++ anyways.
Lets assume that coding in C#, for the rest of the 90%, would cost you a performance-penalty of 300%.
Now, since it’s non-performance-critical, it updates infrequently so is spread-out across cpu-cores and time, which brings it’s “effective” penalty (meaning, how noticeable it is) by at least 2 orders of magnitude.

You got 3% of “noticeable” performance-penalty, but sliced your development investment in half.
Is it worth it?
YES

[/]

[=EruArnold;104003]

All the non-sense about language-performance is utterly irrelevant in this entire story - it just doesn’t hold to closer scrutiny.

[/]

I don’t get this. On the one hand you talk about performance of blueprints vs. scripting being relevant, on the other you throw out some random numbers showing that a performance hit of scripting vs. C++ would be worth it for none performance-critical stuff. So why then is blueprint not sufficient option for none performance-critical stuff?

Blueprints really sort of is the scripting equivalent in UE4. It works really well, allows for rapid iteration, visual debugging and easy sharing of ideas. The 10x slower figure only concerns the CPU aynway. With most games today having a bottleneck on the GPU it may not even be an issue. Why are you getting so worked up about missing scripting in UE4 when there’s blueprints?

I’m all for options and if Epic comes up with ways for more scripting languages to be used, I certainly won’t mind, but I’m not sure I would personally need anything in between C++ and blueprints if I’m going to do performance-critical stuff in C++ anyway. Is scripting going to be something just for people who would just rather type than connecting blueprint nodes but not go through the hassle of C++?

Besides you make it sound as if C++ access is a given in other engines with your “going to code 10% in C++ anyway”. What would you do in Unity with those 10%?

[=EruArnold;104003]

That’s just how I write when I’m ******-off… It’s not personal, or specific to this forum.

[/]

Why are you ****** off in the first place? Take it easy, this is only a forum and your life doesn’t depend on it. I think should be able to articulate their thoughts without condescension.

[=EruArnold;104003]

What really bothers me is that people seem to think we’re asking for an engine with no C++ access…
[/]

I’m pretty sure nobody thinks that, makes no sense at all.

[anonymous_user_689e935a]

[=furrykef;104017]
That wasn’t what I meant at all, and I’m a bit baffled as to how you could read my post that way. Now, remember, I was responding to this:

My point was, 10-15 years ago you’d write it in C (or C++) – but it’s not 10-15 years ago anymore. It’s today. We don’t need to write it in C or C++ now (and indeed it wasn’t). So what relevance does this argument have to us today? We should be concerned with today’s concerns, not yesteryear’s.

I also think the performance wouldn’t have been that bad for a -style game in a high-level language even back then. I saw plenty of simple games written in Visual Basic, and that was before the .NET days.
[/]

Apologies, my mistake. To be fair though I did say “if by that you mean”

[anonymous_user_689e935a]

[=EruArnold;104003]

Sucking-up for you top-tier-only with such statements and leaving the rest of the user-base in the dust, is not a way to to run a business long-term, and would have to realize that at some point.

You HAVE to cater for the lower-level also, because that is where your long-term revenue will come from down the line - the bottom grows wide if you invest in it properly.
[/]

Here’s hoping you’re not serious. Last time I checked UE4 was a AAA game engine available with full source code for 19$ a month. Epic’s attitude towards indies and newbies has been nothing short of stellar so far with help being thrown around in spades. They have recently donated 10k to Blender development because they realise how beneficial a free 3D production software could be for indies. Blueprints allow even artists to “code” like hardly any system ever did before.

What you describe there may happen with CryEngine from what I heard but certainly not here.

[anonymous_user_8bc0348b]

[=Gigantoad;104032]
Here’s hoping you’re not serious. Last time I checked UE4 was a AAA game engine available with full source code for 19$ a month. Epic’s attitude towards indies and newbies has been nothing short of stellar so far with help being thrown around in spades. They have recently donated 10k to Blender development because they realise how beneficial a free 3D production software could be for indies. Blueprints allow even artists to “code” like hardly any system ever did before.

What you describe there may happen with CryEngine from what I heard but certainly not here.
[/]

I am fully aware of Epic’s contributions - I have read about them already. I was referring to 's statement in particular - I just struck a nerve, I guess.
I totally love all the benefits that UE4 already has, and I wouldn’t be so upset if I didn’t care…

[]
Take it easy, this is only a forum and your life doesn’t depend on it. I think should be able to articulate their thoughts without condescension.
[/]

Since I am in Israel, and having rockets explode over my head daily these days, and almost ended-up being recruited to go into Gaza, I think I know pretty well what my life depends on and what not.

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.
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.
I have been reading similar thread in the Unity forums, and let me tell you - they are very emotional.

[]
I don’t get this. On the one hand you talk about performance of blueprints vs. scripting being relevant, on the other you throw out some random numbers showing that a performance hit of scripting vs. C++ would be worth it for none performance-critical stuff. So why then is blueprint not sufficient option for none performance-critical stuff?
[/]

Don’t get me wrong: Blueprints I think is basically the best visual programming language ever made, it’s like something out of some long-wishing wet-dream of mine…
But I am still not sold on the idea that a programmer could make a living writing blueprints. A designer might, on occasion, for prototyping, but I doubt it’s going to be any further than that.

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 **

[]

[]
Originally Posted by EruArnold View Post
What really bothers me is that people seem to think we’re asking for an engine with no C++ access…
[/]

I’m pretty sure nobody thinks that, makes no sense at all.
[/]

The fact that it makes no sense, does not mean that nobody thinks that.
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 have recently watched a lecture from an Autodesk conference, about writing tools for 3dsmax - the pros/cons of scripting in say, MaxScript vs. writing C++ against the 3dsMax SDK, and there is a unanimous agreement that a hybrid-solution is almost always best.
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.
So, I find it odd that I am even put into a position in which I have to justify that approach, when it IS the standard-approach - If anything, the burden of arguing for the contrary should be put on Epic and the “C++ scripting” proponents here, not on supporters of scripting-language-binding such as myself - UE4 is the odd-ball here, not the other-way around. And no, I don’t buy the argument that the ONLY reason other game-engines have provided scripting-ability is that they don’t share their C++ code-base. Cry-Engine and Unity ARE providing C++ access to big-studios, so it’s not an either/or scenario - there are many benefits to be able to script in a scripting-language, REGARDLESS of whether or not you have access to the C++ code.

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:
The Rust language: memory, ownership and lifetimes

And “D” provides similar benefits, with probably the fastest compile-time on the planet:
Three Cool Things About D - The Case for the D Programing Language

So it’s not necessarily about “scripting languages” per-say, it’s also about not having to waist time on a tracking-down subtle bugs that result in poor memory-safety-enforcement by a language-compiler, by having a different language that prevents whole “categories” of such problems, by making them essentially “impossible” to reach to by it’s very design.

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

[anonymous_user_689e935a]

[=EruArnold;104238]

Since I am in Israel, and having rockets explode over my head daily these days, and almost ended-up being recruited to go into Gaza, I think I know pretty well what my life depends on and what not
[/]

Sorry to hear, hope you’ll be alright.

[=EruArnold;104238]

Don’t get me wrong: Blueprints I think is basically the best visual programming language ever made, it’s like something out of some long-wishing wet-dream of mine…
But I am still not sold on the idea that a programmer could make a living writing blueprints. A designer might, on occasion, for prototyping, but I doubt it’s going to be any further than that.

[/]

That’s probably true if we’re talking about jobs. Doubt there will ever be a UE4 developer job that does not involve C++. But since you do know C++, why not use blueprints as much as you can and then port the performance critical stuff to C++? Seems like the best of both worlds.

[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…

[anonymous_user_f54268a3]

@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.

[=EruArnold;104238]
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 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.

[anonymous_user_8bc0348b]

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++ 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 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…

[anonymous_user_689e935a]

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.

[anonymous_user_8bc0348b]

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

[=Gigantoad;104507]
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- 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 -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]

[=EruArnold;104853]
@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 !). 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++.

Scripting Language extensions via plugins

Read that thread. Start helping on . 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 ?

[anonymous_user_8bc0348b]

[=;104878]
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 !). 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++.

Scripting Language extensions via plugins

Read that thread. Start helping on . 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).

[anonymous_user_689e935a]

[=EruArnold;104853]
@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?

[=EruArnold;104853]

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.

[=EruArnold;104853]

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 -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: Is there a LINQ library for C++? - Stack Overflow
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?