The lack of a scripting language is a concern for me because I’m developing a strategy game and having a fairly extensive modding system is a must-have in my opinion. That means exposing a programming interface that is friendly to novice programmers. Blueprint is not an option because, if I understand correctly, you need the Unreal Engine SDK to use the Blueprint editor, and I’m not going to make people shell out $19 just to make a mod.
Of course, I don’t necessarily have to expose any direct UE calls in the modding interface anyway, and nothing prevents me from simply embedding (say) the Python interpreter. But I’ll admit it’d have been nice to have something I could use out of the box.
[=;18346]
The performance of C++ will always beat C# or Java. And yes, you can write **** in any language but **** written in C++ will always be faster than **** written in C#/Java.
[/]
This will probably be entirely irrelevant for 90% of the people here. I have written an entire game in Python, engine and all, that ran at hundreds of FPS on my old computer from 2006, to say nothing of today’s computers. I will grant that it was a simple sprite-based game and not some fancy AAA first-person shooter, but I’d wager more people here are making something closer to the former than the latter. The game I’m working on now will have a high budget by indie standards (I’ll need to raise at least $100k), but it will most certainly not be AAA. I’ll probably be lucky enough if it’s even one A.
Also, remember that 90% of the time will be spent in 10% of the code. If your code is too slow, and if it is due to your choice of language and not your algorithm, you still have the freedom to rewrite that bit in C++ at that time.
[=]
I genuinely don’t want to hear about python, javascript, java nor c# where games (AAA games) are involved.
[/]
In other words, “La la la la la I’m not listening!”
You said AAA games can’t afford scripting languages. Somebody pointed out a counterexample. Now you’re burying your head in the in the hopes the threat to your little worldview will go away. This means you have lost the argument.
[=vblanco;19516]
I dont think C++ is THAT complicated, after all i learn the basics in a week without prior knowledge.
[/]
C++ is a language of deceptive complexity, and my experience is, the more of it you know, the scarier it is. I have known and used C++ (albeit not constantly) for about 15 years and I would consider myself an intermediate C++ programmer at best, whereas I’d consider myself an advanced Python programmer (possibly even an “expert”, but certainly not a “wizard”) even though I’m not sure I’ve used Python more than C++. For example, I still have no idea what the hell C++'s .* and ->* operators are for. I’ve looked them up before, and I could do it again, but I’d just forget again because I simply have not come across a case where I’d use them. Also, if I look through the code that makes up, say, the Boost library, I might as well be reading Greek. I do have a basic understanding of templates and I use them myself when I find them appropriate, but that stuff still goes way, way beyond my understanding. By contrast, I could probably understand all the code in any well-written Python module.
I am far from a unique case. I’d wager at least 90% of C++ programmers with at least five years’ experience cannot understand the code in Boost.
[=;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.
[/]
These are all very good points, of course, but why doesn’t the same logic apply to Blueprint? What makes it so different?
(What am I speaking?) In overall, C++ has pros than cons for commercial development projects.
