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.
