Ask HN: They say no one knows all C++ so what parts do Game Devs need to know?

https://news.ycombinator.com/item?id=1956552

by metacontent • 16 years ago

13 8 16 years ago

news.ycombinator.com

I recently heard the expression: "If you think you know C++ then you don't know C++". I take that to mean that C++ is sufficiently large and complex that it is not very common for someone to be deeply familiar with all of its facets. So this made me wonder what parts of C++ are really essential to know to become a solid indie game developer. Are there any dark corners that a developer would do well to learn?

maximilianburke• 16 years ago

For game development you can safely avoid dealing with exceptions and RTTI. You can probably avoid most template magic, too.

Most game developers use C++ as C-with-classes and generally keep the inheritance and OOP-ness fairly simple.

_delirium• 16 years ago

This is my experience also, especially with indie games. The crazy dark corners of C++ tend to come out more often in larger teams than at indie-game studios.

One approach to finding out more details is to pick a specific engine and see how it uses C++. For example, take Unity3D, and figure out what parts of C++ you'd need to know to use and understand its API (by reading the docs, looking at example games, trying out a small project, etc.).

Ogre• 16 years ago

Virtual methods are widely used, though heavy use of inheritance seems to be on the decline.

I'm a big fan of const, including const methods, though the places I'm especially fond of using it are more MMO specific, (probably) not quite as relevant for a "solid indie game developer".

It's good to know the basics of templates, for things like lists, hashes, trees, and maybe vectors, matrices, etc. Using stl or boost is probably fine, though larger developers always seem to invent their own libraries. I think that's mostly due to historical lack of support on consoles.

Like another poster said, exceptions and RTTI are virtually unknown in game development due to performance considerations.

corysama2• 16 years ago

First, go read "Inside the C++ Object Model" so that you can have a firm grip on how the compiler implements everything under the hood.

But, you are looking for dark corners full of gold... Here's where to look:

Policy-based design using templates can make generating optimal code for lots of different situations only slightly harder than hand-writing optimal code for a specific situation. "Modern C++ Design" is full of examples that take this to the extreme. Don't go that far. Just figure out why std:sort with a functor solidly outperforms qsort (or std:sort) with a function pointer. Also: type traits are tasty when applied sparingly.

Knowing how to override and augment malloc, new, etc... is critical for instrumentation and segmentation of allocations. In-place new and destructors-without-delete can be handy occasionally.

STL's algorithms are great, but the containers are often overkill. binary_search() and insert(lower_bound()) on a sorted array will often beat a std:set because most common datasets are small enough to fit in cache when stored in a contiguous array. Similarly, a sorted array of key-value structs is usually a better idea than a std:map. If you are on the PC, it is possible to write large amounts of fast, beautiful code using only pre-reserved std::vectors (rarely needing new or delete). Boost is soft, warm quicksand.

Don't get wrapped up counting instructions. Memory accesses and cache misses are 20-200X more important. Most algorithm educational materials ignore this. Data-oriented design trumps OO. Component-based design trumps inheritance --it leads to better composability and it is easy to get good Data-OD by batch-processing arrays of uniform-typed components. Most load screens are 90% disk seeking. Not reading. Not processing. Seeking...

As a systems programmer, I'm a big fan of C++0X. static_assert is my best friend. I'm loving auto and lambdas. Move semantics are great for libraries, but if you need it you might be being a bit too liberal with your allocation patterns. btw: it's easy to make a pre-c++ox

#define staticAssert(x) typedef char[x:1:-1] _assert_type

that you can use anywhere.

Multithreaded design is important. Done well, it can make everything simpler. I greatly prefer share-nothing + message passing. Semaphores are handy, but mutexes usually smell bad. If you think you need to call sleep() you are doing something wrong.

http://www.codeproject.com/KB/cpp/FastDelegate.aspx is handy. Just don't look under the hood. Scary...

Return value optimization is nice. Compiler intrinsic functions (and out-of-order execution cpus) are slowly making writing assembly unnecessary (reading assembly is still important). Getting functions to inline away in optimized builds is nice, but getting debug builds to run fast is nicer. RIAA can be nice. Dependency injection can be worth it to not depend on globals (singletons are self-deception). Careful project structure and #include design can mean a 10x difference in compile times. Short (preferably instant/continuous) iteration time is the key to quality.

There's a dozen doors for ya. Take your time stepping through each one. Just be aware that elegance makes it easier to ship, but shipping is the goal. I've seen big, awesome games full of gross, bloated code. They were horribly painful to ship, but they shipped like hell and that's why they won.

deathflute• 16 years ago

I like your point of data oriented design. Do you have any suggestions/links on how I can learn more about it? Thanks.

corysama2• 16 years ago

Unfortunately, not much. The first page of google hits are all pretty good, but short. Also, Mike Acton of Insomniac has ranted about it a couple of times.

http://cellperformance.beyond3d.com/articles/2006/04/perform...

http://cellperformance.beyond3d.com/articles/2009/08/roundup...

There are a lot of component-design links here: http://stackoverflow.com/questions/1901251/component-based-g...

I don't know if any of them address batch-processing though...

newobj• 16 years ago

Everything except exceptions and RTTI.

STL/boost are debatable.

checoivan• 16 years ago

True. So true.

The thing is c++ is a vast massive monster. Most likely whoever deeply worked on it, knows there's so much stuff left to learn, and so many deep dives, that whoever claims expertise is likely to be a newbie who hasn't been close enough to the edge to see what's ahead.

I remember once, spending like a couple full days along with a graphics researcher, who worked on that stuff full time, trying to get to work some rendering done with OpenGL on c++ which just didn't behave when compiled in MSBuild. Only on MSBuild. We found way later the solution from a guy in a forum, which was hacking the opengl implementation , overriding some macros ,and doing some other obscure thing on the library as well.

Even today we're both baffled at how that dude came up with that hack.

Ask HN: They say no one knows all C++ so what parts do Game Devs need to know?

Related Stories