Games from Within

A few days ago, Tony Albrecht posted the slides of his presentation titled “Pitfalls of Object-Oriented Design” [1]. Even though the title is really broad and could easily be misinterpreted, it’s not just a general bash on OOD. Instead, it’s very much focused on how object-oriented design is not a good match for high-performance apps [...]

Picture this: Toward the end of the development cycle, your game crawls, but you don’t see any obvious hotspots in the profiler. The culprit? Random memory access patterns and constant cache misses. In an attempt to improve performance, you try to parallelize parts of the code, but it takes heroic efforts, and, in the end, [...]

I've gotten a lot of questions about how big our codebase is, how fast does it build, how many tests we have... Fear not, Gentle Reader, all your pressing questions will be answered here.

Mine is two seconds. For many months, our unit tests ran under one second. Each library has its own set of unit tests, and so does the game and each tool. So even though we were writing lots of unit tests, we weren't always running them all at the same time. There was a definite snappiness to coding: write test, compile, fail, write code, compile, pass, move on. Go, go, go.

C++ enums are great in practice, but they're a bit lacking once you really start flexing them. Don't get me wrong, they're definitely a step up from #defines, but you can't help but wish for more.