[=Aderyn;117334]
I always thought AAA was defined by how much budget it was assigned.
[/]
It is. It’s also relative to the time the game was made, due to changes in team size etc. Now however that’s working backwards, teams are getting smaller and smaller instead.
I really think integrating something like Rust or D would be very interesting for Unreal Engine 4, and it seems I am far from being the only one.
Here are some quotes from the link above:
[]
It sounds like the problem was that UnrealScript was initially too simple for the applications it was pushed to, which led to more and more of the underlying system being exposed through the interop API.
[/]
[]
… C++ compile times will be a pain until a module system gets done.
[/]
[]
… D compiles much faster than C++, has limited C++ link compatibility (e.g. classes, but not templates), and overall has nicer syntax / language features than using C++ directly. Metaprogramming / compile-time introspection allow automatically serializing/deserializing data to allow updating data structures without restarting the engine.
[/]
[]
It will be interesting if any major game engines pop up using Rust as the core language, or even Go
[/]
[]
considering that Rust makes several classes of C++ bugs impossible at compile time, I’d be hard-pressed to imagine that a Rust version wouldn’t be less buggy.
[/]
[]
Rust’s type system eliminates the need to test for whole classes of bugs, because they are statically checked for at compile time.
[/]
[]
Rust emits LLVM IR, so that will make expanding to more platforms like iOS, PS4 and Enscripten much easier.
[/]
bjz_ 129 days ago | link
const)[]
I’ve discussed the issue of the “no decent programmer” fallacy in the past; yes, in theory if programmers were careful and alert, they could create flawless software, yet this never happens in practice because humans are prone to errors (i.e. not understanding a subtlety of the language or library, thinking that a validation is done at a different level of abstraction, failing to imagine what could be an error scenario and how it could occur, etc.). Languages like Rust offer the same capabilities as C or C++, while eliminating entire classes of bug sources.
[/]
[]
Although online security is more and more important in games these days, the real appeal of Rust in respect to game development is in providing an alternative to the ‘death by a thousand cuts’ that can plague large C++ projects.
I’ve posted a list of the things I consider the most relevant to game development: https://news.ycombinator.com/item?id=7587413 Any one or two of them alone wouldn’t really be a compelling enough reason to switch, but put together they form a very compelling value proposition.
[/]
[]
There already exists a subcommunity devoted to exploring Rust’s applicability to game development and computer graphics. The most active person in this department is probably Brendan Zabarauskas: http://voyager3.tumblr.com/post/82419271783/i-found-this-anc…
I also know of a few game development studios with R&D departments who have had an eye on Rust in the past…
[/]
In case you don’t know what Rust is, it’s a systems-programming language that compiles to native-code (using an LLVM-derived compiler).
It is developed by Mozilla for it’s next-gen web-browser (code-named “Servo”), but is an open-source project (dual-licensed MIT/Apache).
It aims is to be a viable substitution for C and C++ for performance-critical systems which require low-level access to hardware.
It is binary-compatible with C, and so has built-in interoperability with it (calling C library-members from Rust and vice-versa).
It provides a high-level abstraction that is very light-weight and “affordable” for performance.
It is much safer in terms of memory-management than most other languages - especially for concurrency (with “optional” garbage-collection).
It provides built-in primitives and language-support for concurrency that is similar to what languages like Go offers.
It draws inspiration from high-level languages like Python, Ruby and C# (as well as esoteric ones like Scala, Erlang and Haskell).
It is relatively-new (started being worked on in 2006), and is supposed to reach v-1.0 this year.
Here is a short video summarizing programming-languages and their trade-offs (and where Rust aims to be).
Here is a short video of an overview on Rust
Here is another short video showing small examples of the syntax and concepts.
Here is a somewhat longer video about Rust’s unique memory-management.
And lastly, here is a more exhaustive overview on Rust, it’s rationale/motivation, syntax and mechanics, with some C++ comparisons.
Here are some highlights from a very long thread about C++ vs Rust / Go:
[]
Consider that a lot of Python developers write most of their code in Python, then rewrite critical parts in C to speed it up. Python is not a speed demon, and that becomes particularly problematic with tight loops or heavy math—but writing entire applications in C is error-prone and tedious.
Rust won’t outright replace both of those, but it does offer a nice middle ground: it’s safe, it has some higher-level constructs, it does away with some boilerplate, it builds fairly easily, and it still compiles essentially to machine code.
[/]
[]
I’ve been under the impression that many people think that soon C and C++ will phase out and become obsolete(or that they have already done so), we go higher in abstractions, Python and Haskell are the future and computers are so fast that nobody has to care about optimizing their code. Then reality and post-PC era strikes back, battery life and software power-efficiency play higher role than ever…
My experience with Go and especially Rust is quite limited, but it would be really great if I could do my stuff(right now games and path tracing rendering, render times from 12 hours upwards) in either them instead of C++. I really like the ideas behind the languages and they fit my core domain just as well as C and C++ do.
[/]
And here is a about Garbage-Collection an game-development:
[]
Android games have been known to struggle with GC sometimes. However, garbage collection has gotten a LOT better on Android over the years. I wrote a small game in Android 1.1, back when GC pauses were anywhere from 100ms-250ms, and avoiding allocations was VERY important. Nowadays, most pauses are less than 5 ms, and the NDK is always available if you want to write native code and avoid GC altogether.
In general, the game industry seems to be moving towards a model where you have “engines” and “level packs.” The physics, graphics, etc. engines are developed by a small group of people in C or C++, and the level packs are in whatever scripty language you want.
[/]
And here is an article that tries to argue that C++11 will make new languages like Go and Rust redundant very soon - and the comments are pretty unanimously disagreeing with the writer.
Here is a from the article itself:
[]
“C++11 is out (has been for a while) and brings many things from Tr1 into the standard. Things like managed memory (shared_ptr) and lambdas and template meta programming (TMP) bring new paradigms to the beating heart of C++. So much so, I would argue, that C++11 makes some of the ‘new kids on the block’ (think Go and Rust) look pretty pointless.”
[/]
And here are some quotes from the comments:
[]
The reason we need new languages to replace C++ is because it is too easy to write C++ code that nobody else can understand. I have a Computer Science degree and 13 years commercial experience of C++ programming. You describe your example as “very trivial” and yet I find it baffling. I’d certainly understand a simple parser if it was written in C. I’d probably understand it if it were written in Java or C#, even though I have much less experience with those languages. I think the new C++ standard has made this problem worse. The Tiobe Index seems to agree with me. One thing C++ gets right is that it typically compiles to native code. I’d rather avoid Java and C# because they don’t. Therefore, I’m quite keen to see Go, Rust or D become widely used.
[/]
Memory-safety has been “bolted-on” as a library-feature in C++11, as opposed to a core-language features (mainly for reasons of backward-compatibility), so you don’t get compile-time help, and you can still soot yourself in the foot even with smart-pointers if you stray but-a-little from very strict usage-guidelines.
Here are some quotes from the first link, about C++11’s memory un-safety:
[]
here are a few things that modern C++ does nothing to protect against:
Iterator invalidation: if you destroy the contents of a container that you’re iterating over, undefined behavior. This has resulted in actual security bugs in Firefox.
std::vector v;
v.push_back(MyObject);
for (auto x : v) {
v.clear();
x->whatever(); // UB
}
“this” pointer invalidation: if you call a method on an object that is a unique_ptr or shared_ptr holds the only reference to, there are ways for the object to cause the smart pointer holding onto it to let go of it, causing the “this” pointer to go dangling. The simplest way is to have the object be stored in a global variable and to have the method overwrite the contents of that global. std::enable_shared_from_this can fix it, but only if you use it everywhere and use shared_ptr for all your objects that you plan to call methods on. (Nobody does this in practice because the overhead, both syntactic and at runtime, is far too high, and it doesn’t help for the STL classes, which don’t do this.)
class Foo;
unique_ptr<Foo> inst;
class Foo {
:
virtual void f();
void kaboom() {
inst = NULL;
f(); // UB if this == inst
}
};
Dangling references: similar to the above, but with arbitrary references. (To see this, refactor the code above into a static method with an explicit reference parameter: observe that the problem remains.) No references in C++ are actually safe.
Use after move: obvious. Undefined behavior.
Null pointer dereference: contrary to popular belief, null pointer dereference is undefined behavior, not a segfault. This means that the compiler is free to, for example, make you fall off the end of the function if you dereference a null pointer. In practice compilers don’t do this, because people dereference null pointers all the time, but they do assume that pointers that have been successfully dereferenced once cannot be null and remove those null checks. The latter optimization has caused at least one vulnerability in the Linux kernel.
Why does use after free matter? See the page here: Using freed memory | OWASP Foundation
In particular, note this: “If the newly allocated data chances to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.” This happens a lot—not all use-after-free is exploitable, of course, but it happened often enough that all browsers had to start hacking in special allocators to try to reduce the possibility of exploitation of use-after-frees (search for “frame poisoning”).
[/]
[]
You can return out references and still get dangling pointers with const values. For example, you can return an iterator outside the scope it lives in and dereference that iterator for undefined behavior (use-after-free, possibly exploitable as above).
Besides, isn’t “C++ is memory safe if you don’t use mutation” (even if it were true—which it isn’t) an extremely uninteresting statement? That’s a very crippled subset of the language.
[/]
[]
> If you declared most of the mutable types const (and the use cases for a non-const unique_ptr are few) you can avoid most of these issues
Mutability in Rust is perfectly safe because of the static checks built into the type system – the compiler will catch you if you screw things up.
> you could never implement that without colossal backwards compatibility breakage
I cannot express how important immutability as default is. This prevents the issues that C++ has with folks forgetting to mark things as const. There is also lint that warns when locals are unnecessarily marked as mutable, which can catch some logic errors (I say that from experience).
Also note that I said ‘immutability’ not ‘const’. Immutability is a far stronger invariant than const, and therefore is much safer. It could also lead to better compile-time optimisations in the future. I’m sure you know this, but just in case:
Another major problematic-area about C++ is how small it’s standard-library is in comparison with languages that are not designed-by-comity.
You got so many different options for simple tasks like threads, sockets, XML/ handling etc. that don’t inter-operate well, and have varying platform-support.
Then you got “some” cross-platform library-packages like Qt and Boost that have their own issues and non-standard style/behavior.
There is a very glaring lack of canonical go-to solutions that are standardized for even basic/rudimentary stuff, and that is a major problem that has existed for years.
Another problem with C++ is incompatible-compilers - this is horrible and largely un-fixable at this point - it is a product of historical-political/commercial factors, that sometimes caused different vendors to deliberately do the opposite things when implementing their compilers compared to what their competitors where doing, specifically for no other purpose then instilling incompatibility. Each vendor thought to lock-down the users of his compiler to his platform, as a means to dominate the market. This is horrid and means you have to re-compile code that is “supposed to have been cross-platform-portable” but isn’t, even when it’s not even referencing any platform-specific code whatsoever, only because some compilers implement things differently, either internally in corner-cases, or on the surface with incompatible pre-processor directives.
And so the promise of “cross-platform compatibility” is largely marketing-■■■■■■■■…
In a few weeks “CppCon 2014” is going to happen (the successor to the “Going-Native” conferences), and video-recordings of it will follow - we’ll see what they have to say then…
I’ll just leave this here.
https://www…com/watch?v=moSFlvxnbgk#t=58
[=;124203]
I’ll just leave this here.
https://www…com/watch?v=moSFlvxnbgk#t=58 : “Let It Go”
[/]
I’d love to use Go instead.
But, yes. 
C++ works right now. Despite C++ being a bleeding eyesore compared to Go (and presumably half-baked Rust and others), here’s some advice to some of you fighting it. Start learning and using C++. Now. Will it make you angrier than usual? It will. What wouldn’t? Unknown syntax is frustrating until you realize it’s simple. Then you’ll become a better human being and game developer. Half of the game, audio, and 3D libraries and tools out there still use C++, making it easier to integrate. Won’t that be nice? You might become less irritable. …ok, probably not. You will, however, be grateful.
I AM learning C++, and investing many hours in it (already went through 2.5 courses of Pluralsight, and another one by 3DBuzz that I bought).
I am practicing quite lot of C++ these past several weeks and will continue to do so - for exactly the reasons you mentioned.
That said, I don’t think I am going to be happy by the fact that I need to do this…
And it’s not a zero-sum dynamic - I can learn C++ AND ***** about it AND promote alternative languages for UE4 - all at the same time! 
That is interesting news, and not at all surprising - I am pretty sure that more languages will follow, now that Epic has paved-the-path with the LUA experiment and it’s related infrastructure work to facilitate scripting-languages integration.
However, I believe the whole point of having a standard-language, is that you can re-use skills that are also applicable in other domains, and if it’s a well-established language, it also would have a large (and growing) repository of libraries that accompany it that you can immediately benefit from.
Maya used to have only MEL support, now it also has Python.
3dsmax used to have only Maxscript, now it also has Python and .Net.
(you get the idea…)
Granted, Python may not be an ideal choice for Games, but other well-established-languages may…
What can you do with your SkookumScript skills that you would have to develop, I wonder, outside the confines of some small-number of game-engines?
And why should you have to pay to use such a thing? Especially with so many other royalty-free languages out-there…
Any domain-specific language would have to demonstrate some huge advantages over anything-else, to justify investing in it - at least in my book.
[=EruArnold;124380]
However, I believe the whole point of having a standard-language, is that you can re-use skills that are also applicable in other domains, and if it’s a well-established language, it also would have a large (and growing) repository of libraries that accompany it that you can immediately benefit from.
Maya used to have only MEL support, now it also has Python.
3dsmax used to have only Maxscript, now it also has Python and .Net.
(you get the idea…)
Granted, Python may not be an ideal choice for Games, but other well-established-languages may…
What can you do with your SkookumScript skills that you would have to develop, I wonder, outside the confines of some small-number of game-engines?
And why should you have to pay to use such a thing? Especially with so many other royalty-free languages out-there…
Any domain-specific language would have to demonstrate some huge advantages over anything-else, to justify investing in it - at least in my book.
[/]
You got to be kidding. Here you are advocating the use of the right language for the right job, and then this? A scripting language specifically made for game logic doesn’t tickle your fancy because you can’t use that language anywhere else? Suddenly all the gains in productivity that this might provide over a more general language like Python are all but irrelevant?
I just spent some time reading about SkookumScript, and I think I might really like it after all.
I was worried this was some spin-off of some coder trying to capitalize on the emerging UE4 market and the lack of quality scripting-languages…
I stand corrected - I take it back - SkookumScript looks like the real-deal - this could be awesome…
I still think that a major value that must not be underestimated in ANY language, is the “ecosystem” around it.
So far, from what I have read, even though SkookumScript’s developer(s) have had tons of industry-experience, and it seems like he knows what he’s doing, from what I can gather so-far it has only been used in very few projects in very few companies - this does not mean that it’s no-good, necessarily, just that the ecosystem around it would be a tiny-fraction compared to general-purpose languages.
Granted, my first enthusiastic support for Rust is odd in this regard - since it is not even out yet - but it IS an open-source general-purpose systems-language that compiles fast and is very low-overhead, with safety-features, concurrency-features, etc. So it might have a larger ecosystem in the future.
It seems that SkookrumScript has most of the benefits of Rust and then some, so this is very interesting indeed.
My only reservation about it at this point is that it is proprietary, and licensed.
I think something like this could go much further as an open-source project with a large/growing community that shares ideas and code for the language-itself as well as it’s standard-library.
Moreover, there is a problem that wheels would still have to be re-invented, if game-companies don’t allow their coders to share code out on the open - but I guess this is not a function of language-openness and could easily happen for any langue…
But if you have an open-source standard-library, contributions could happen outside big game-companies, or from people working there that have their own repository that they work on in their spare-time and contribute it to an open-source STL.
In short, what I was saying is that an openly-shared repository of standardized-code that inter-operates with many parts coming from many sources, is a more beneficial model for all developers - in any language, and in any industry - and open-standard-languages tend to have more then proprietary ones.
For the record, I have been programming with MaxScipt exclusively for many years now, and though it is a very good language for what it does, I would have been much better-off had 3dsmax had supported Python say, 5 years ago…
It’s just that programming-skills in any language take a long time to master and are a big investment - and if these skills are not transferable to other domains/applications, then the value of that skill-set is much lessened.
This is why I have mixed-feelings about super-cool things like Fabric-Engine and their KL language - sure, it can run on both the CPU and GPU at the flip of a checkbox-switch with the same-exact code, sure Maya, 3dsMax and many others are now supporting it, but still - he thought of locking yourself into a proprietary language just leaves a bad taste in my mouth… Still, it could be a better investment then MaxScript, though, given it is transferable/reusable for other applications…
This is why I like Python, QT and PyQt/PySide so much, I can re-use so much code for cross-application AND cross-platform, AND it’s a general-purpose language and toolkit that is not tied to any industry/application - it’s just a better future-proof investment then say, learning WPF for writing GUIs for 3dsMax…
That is my general-outlook, if I wasn’t clear enough.
When I am tasked with having to evaluate option of embarking on a long-term learning-investment, I worry about future-proofing it…
If there was a way to demonstrate that SkookumScript is bound to take over the Game-Dev industry by a storm, I would have much less reservations about it - and if it was an open-source thing, this would have been a much more likely scenario, in my view…
[=;125633]
C++ is very unambigous and as result is very clean, readable and simple for human brain, which is very limited.
[/]
C++ is anything but unambiguous. C++ has a lot of language facilities like operator overloading and template metaprogramming that can completely destroy the ability of a human being to effectively reason about a given piece of code. Hell, the simple act of using the const keyword can have some rather drastic unintended sideeffects.
Don’t get me wrong, I love C++, but it’s not the cleanest and best language in the world.
[]
I would like to see few features of C# in C++, but only few, in general C# and other alike languages is totally unacceptable for complicated systems like game engine, and also for complicated games and gameplay programming, other than chess or tetris.
[/]
I think the Unity folks would disagree with that.
C# has its uses. Those uses being in areas where correctness matters more than speed, and if you think those areas do not exist in game engines, you’ve got a lot of learning yet to do. I mean, I wouldn’t want to do my physics code or my rendering code in C#, but gameplay implementation? That’s an area where the speed differential between the two languages basically doesn’t matter.
@The_E
Have to disagree with you.
If you know C++ well you don’t have problems with reading nor reasoning what code does. But if you don’t then you don’t.
C# maybe has its uses but not in gaming industry where performance is at premium.
Anything you can do (in C#) I can do better (in C++). And at least 200% faster. At least.
I think most people comment about the difficulty of C++ in UE4 without actually using it. Because of the macros and the engine API it is quite different to do game-play programming in UE4 then making a game from scratch in C++. A basic understanding of pointers and how to iterate collections is about all that would be needed to start if your coming from C#.
Unity is a C++ engine. Most of it’s users ignore that fact when discussing it. C# is one of 3 scripting languages they use on top of it for game-play coding, I believe it’s being compiled with it’s own version of Mono just for Unity.
[=mikepurvis;125872]
I think most people comment about the difficulty of C++ in UE4 without actually using it. Because of the macros and the engine API it is quite different to do game-play programming in UE4 then making a game from scratch in C++. A basic understanding of pointers and how to iterate collections is about all that would be needed to start if your coming from C#.
Unity is a C++ engine. Most of it’s users ignore that fact when discussing it. C# is one of 3 scripting languages they use on top of it for game-play coding, I believe it’s being compiled with it’s own version of Mono just for Unity.
[/]
Yep. And as I said, I agree with the idea that if you want full performance, you have to use C/C++; I just disagree with the blanket assessment that languages like C#/environments like .NET/Java have no place in game development.
[=;125862]
If you know C++ well you don’t have problems with reading nor reasoning what code does. But if you don’t then you don’t.
[/]
Even if you know C++ very well, reasoning about C++ isn’t easy. Consider this simple statement:
a = b + c;
In order to know what that does, you need to know:
-the types of a, b and c
-how + is defined for b and c
-how = is defined for the result of + and a
C++ is a wonderful language. It is also a wonderful collection of guns aimed squarely at the user’s feet.
[]
C# maybe has its uses but not in gaming industry where performance is at premium.
Anything you can do (in C#) I can do better (in C++). And at least 200% faster. At least.
[/]
It’s this kind of blanket assessment that I am allergic too. No, C# isn’t useless in the gaming industry, or in creating game engines; It’s a perfectly valid tool to implement the bits of your game in that aren’t your main physics or render loops. In gameplay programming, the extra nanoseconds you get from doing it in C++ just aren’t that important.
Also, be wary of using hyperbole. No, you can’t do “anything” 200% faster. That’s ■■■■■■■■, and you know it. You can do some things dramatically faster, yes. Others, you can do a little bit faster. The areas where you can profitably use C#/.NET in an engine fall squarely in that latter category, and the minuscule performance gains aren’t necessarily worth it if it means that the person implementing the stuff has to keep all the little caveats and pitfalls of C++ in mind while implementing.
[=The_E;125912]
In order to know what that does, you need to know:
-the types of a, b and c
-how + is defined for b and c
-how = is defined for the result of + and a
[/]
Actually it’s just:
[=;125943]
Actually it’s just:
I completely agree! But good code, especially good code in game projects, is the exception, not the norm; 6 years of working on an old game engine has taught me that much.
[=The_E;125912]
No, you can’t do “anything” 200% faster. That’s ■■■■■■■■, and you know it.
[/]
No, it is not a ■■■■■■■■. It is proven time over time over time that C# is at least two times slower than C++ and that is best case scenario. Worst case scenario is close to 10 times which gives:
a) Best case scenario 200% slower so when you say “Others, you can do a little bit faster” is at best you can be 200% slower using C# and that is best what you can get and there is simply no way that you will do better.
b) Worst case scenario 1000% slower
Why on a God’s earth I would want that if I can use C++? Why?
C++ gives you:
a) Portability
b) Performance
c) Level of abstraction IDENTICAL to C# so those dudes who claim that they cannot write high enough code in C++ are simply weak programmers, that’s all.
C# on the other hand takes everything above from you and is NOWHERE as expressive as C++.
In view of that why would I want to use it? Now you tell me.
I think it is amusing how some are bashing C#, considering how languages just like it (and Java) were invented for the very reason to illeviate the headaches of C++. Producitivity is worth more than performance - even Sweeney himself has said so.
Not that performance is a huge problem anymore, considering how technology compiling byte code to machine code equally fast as C++ is maturing and making its way into the pipeline of development tools.
[=DancingPeasant;126373]
… technology compiling byte code to machine code equally fast as C++ is maturing and making its way into the pipeline of development tools.
[/]
Any chance to actually support this with some reliable data? Because I know for a fact and I’ve provided link to research done by Google, that Java is at best 370% slower than C++ and at worse 1260%. Why would I want that?
Also C# nor Java for that matter DO NOT INCREASE productivity and that has been proven too.
So please provide some data to support your opinion.
[=DancingPeasant;126373]
Producitivity is worth more than performance - even Sweeney himself has said so.
[/]
Tend to disagree with him on that one. There is little point in producing whole lot of software which performs poorly.
Another point I’d like to make is that QUALITY should be the ultimate factor and C++ gives you better quality of virtually everything: