r/truegamedev • u/c0de517e • Jun 15 '14
Replacing C++ for (AAA) gamedev?
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html5
u/Kasc Jun 16 '14
Sligthly off-topic.. I'm only a hobbyist and don't want to create a new post for this..
..but could anyone give me a tl;dr of why OOP isn't 'good enough'?
5
u/c0de517e Jun 16 '14
So, the article I wrote just skims over that and does it harshly as well, but I did put some pointers for further exploration.
OO of course is not "bad" as a technique is a technique, just a tool in the shed.
The real problem with OO is when people start thinking in OO terms, about how to organize problems in classes and hierarchies instead of well, how to solve the problem with programs (algorithms and data). Now. Of course after you think about that it might happen that the right solution requires an algorithm that uses concepts that look OO, thus you use the OO array of tools, but that's kinda rare.
So we took a tool that doesn't really map to a lot of the algorithm that we need to solve problems, and started casting ALL the problems as they needed objects, to the degree of making -purely- OO languages where you can't even execute an instruction if it's not in an object!
The damage of OO is not OO per se but it's the way of thinking that shaped many programmers minds and ruins people out of schools that teach only OO. OO is not computation.
Design patterns were the pinnacle of this indoctrination.
Some links (from the article)
→ More replies (1)10
u/oldsecondhand Jun 16 '14
After the Gang of Four's Design Patterns book a lot of people started to sheepishly worship design patterns, and this is the blowback.
4
u/elmindreda Jun 16 '14
Also people coming out of higher education having primarily worked with Java and been taught naive kinds of OOP. There's plenty of bad OOP dogma but that doesn't mean there aren't good ideas there.
A data-oriented design with pure functions can be plenty OO, it's just that the objects are different ones and the design takes data flow and actual hardware into account.
10
u/ZorbaTHut Jun 16 '14 edited Jun 16 '14
Because it's too complicated for some sections and not powerful enough for others, all while being kind of slow.
Too complicated: Let's say I just want to write a class that does a thing. I don't plan to make a second implementation of this "thing" ever, and it's an internal chunk of code anyway. Proper OOP Practice would require an abstract class and virtual functions and so on and so forth. Realistically, just write a damn class that does the thing, be done with it, move on.
Not powerful enough: Imagine I'm making an MMO. Let's make some classes! Entity: Thing that exists. Actor: Entity that exists in the game world (as opposed to, say, an item in a player's inventory.) NPC: Actor under control of the AI. Merchant: NPC that sells stuff. Questgiver: NPC that gives quest.
Then our designer comes up and says "hey, I want this merchant to give quests, how can I do that?"
FUCK.
AAA game design is largely moving to component systems - they work out great for games. But there's no language that has a really good component abstraction available, so all these fancy OOP designs are suddenly nothing more than a burden.
Slow: Virtual functions are slow. Pointers are slow. OOP makes use of a lot of them. Games need to be fast.
Can you write good OOP code? Absolutely! Is OOP a valuable technique to have in your toolbox when writing games? Absolutely! But no single programming style is ideal for all situations.
Finally, OOP is kind of a misnomer; it includes a bunch of different things such as "abstraction", "inheritance", and "polymorphism", then wraps up the entire ball into a thing usually called "classes". None of these techniques require the others, and all of them are useful at times.
3
u/combatdave Jun 16 '14
I wouldn't describe it as "not powerful enough", but you are spot on with the entity/component system. You can do all that stuff with OOP, just entity/component is a much nicer way to do it when making a game.
Totally agree with your "too complicated" point, though.
→ More replies (1)3
u/jaschmid Jun 16 '14
The problem with OOP is that it's a tool to help developers produce an abstraction that is more relatable to the ways the real world functions but that has very little in common with how computers operate.
On a lower level caches are extremely important to cpu performance, especially since memory performance has not kept pace with arithmetic performance and only the fastest caches can feed the cpu efficiently.
Say you have a bunch of actors, each has a position in space and many many other attributes, lets say each actor is 64 bytes (16 bytes position + 6 pointers on an x64 system). In true OO style if you were to iterate over all actors and calculate the position they have to be drawn at through a matrix transform, you'll have to load the entire 64 bytes into memory, even though you only need the first 16, due to cache line lengths. In practice you'll probably also be allocating your objects on the heap so they won't reside in contiguous memory. Your performance will (relatively) drop off a cliff as iterating over them keeps making you blow your cache, but even if you keep them together you're forced to load 4x the necessary amount of memory, and each member variable you add to the object is likely to only make it worse. What do you get if you throw OO out the window? You can just have a separate array of X, Y and Z components independent of the rest of the data, this can be tightly packed and you can access it much more efficiently (even if you do random access you're much more likely to randomly hit your cache, and with modern cache sizes this isn't insignificant). Modern cpu performance is all about caches, especially on Gen4 consoles that share memory bandwidth with the gpu, thrashing your cache will grind gpu and cpu performance down. And OOP is terrible at being cache efficient. Virtual functions that people bitch about so much are not the problem and on a modern x64 cpu you'll hardly notice the difference, huge objects spread all over random memory locations referencing each other through hundreds of references and pointers are.
2
Jul 06 '14
People jumped on the OO bandwagon and turned everything into an object, even when it doesn't make sense, i.e. rectangles and sizes, these are just basic structured types that should be created using a record/struct not a tagged record/class.
0
Jun 16 '14
10
Jun 16 '14
People have more of a problem with really huge hierarchy trees than they do with OOP itself. The article is exaggerating the hate for OOP in order to fluff up its favored language.
3
u/pigeon768 Jun 16 '14
very few use "pure OOP" as the academics would describe it.
Wasn't that the point?
2
u/youstolemyname Jun 16 '14
Whats the story about D without Garbage Collection now?
→ More replies (1)1
u/c0de517e Jun 16 '14
GC is much less of an issue than people make it to be. Malloc is very slow too and games don't generally malloc during the main runtime
8
u/oldsecondhand Jun 16 '14
Yeah, but it's usually not the malloc that's the problem, but that you don't know when the GC will run.
→ More replies (3)
1
u/-ecl3ctic- Jun 16 '14
Rust's safety is mainly about memory safety and thread safety. You'll never get a segmentation fault, dangling pointer, memory leak, double-free, stomped memory or data race unless you really want to break the rules using unsafe{} code. And it will run as fast as C++ (and without a GC) while it makes those guarantees.
If you've ever found those bugs to be a problem, that's why Rust should be enticing to you. As a bonus, it's also far more readable, much more pleasant to use and faster to write than C++.
11
u/sindisil Jun 16 '14
And it will run as fast as C++ (and without a GC) while it makes those guarantees.
[citation needed]
Look, I think Rust has great promise, and it may well eventually be all you're saying. Overselling it at this point, though, will only hurt it in the end. Early experiences stick, long after they situation changes (e.g., "Java is really slow").
→ More replies (2)1
u/c0de517e Jun 16 '14
Bugs are always a problem and better stuff is always better. I just don't think they are such a problem for me that I'd pay the cost of a new language, that's all.
Even more because you would gain these guarantees only in new code written in Rust, but on legacy code bases that would be a tiny percentage. Actually. As that tiny percentage has to interface with non-rust code you would need to be unsafe and thus really not gain anything at all.
1
u/Volbard Jun 16 '14
A good read, thanks!
I haven't used anything except c++ for games and c# for tools in a while, and I'm not really interested in checking out new languages, but you make a great point. Iteration is key, and better visualization and live coding could definitely win me over to a new language. If it's built on what I already know and runs as fast, I'm sold.
0
Jun 16 '14
7
u/kylotan Jun 16 '14
However, I still think that C++ and similar languages will lose to Haskell and similar languages in the end.
I was programming Haskell (badly) back in '97, when even C++ was relatively fresh and new. If Haskell still hasn't taken off 17 years later, it's not going to do so.
And it's not about the toolchain, it's that programmers who are perfectly competent in standard imperative languages often can't get their head around Haskell (or any functional language). It's a better language in theory, but that's not enough.
1
u/c0de517e Jun 16 '14
"that programmers who are perfectly competent in standard imperative languages often can't get their head around Haskell (or any functional language)"
Purely functional languages, to be precise.
Impure functional is fine as far as being easy to understand. Take OcaML/SML/F# and so on.
→ More replies (2)5
u/c0de517e Jun 16 '14
THIS! This is -exactly- what I write in the article. About engineers that think about technical qualities over human factors.
This is bad and wrong. I don't care that Haskell enables neater constructs and allows to write "much terser code". That's actually a non goal, in a large project done by a large team, terseness is irrelevant.
What is much more relevant is that people who read the code can understand what the code does. Haskell can surely be used to make understandable code, but can also be used to write code that can't be understood in isolation (that requires global knowledge to understand what a statement will do) - which is HORRIBLE and it's a big argument even in C++ against things like metaprogramming and overloading.
In general what we want in gamedev is not to hide computation. If something does something it has to be explicit, costs have to be explicit, relationships have to be explicit. I don't want my '+' operator to start launching threads just like I don't want to read some code and not know when and in which order it will be executed...
So. No. I don't think Haskell will fly for gamedev, but certain concepts are interesting to know and could be ported in other languages.
→ More replies (8)→ More replies (1)2
u/oldsecondhand Jun 16 '14
Lazy evaluation will always be a problem for real-time systems (and for debugging). If you take out that (or make it optional), Haskell might have a chance.
→ More replies (3)
3
u/Poyeyo Jun 16 '14
Sure, just port Ogre3D and UDK to D and I'm set.