We have been talking a lot about Scons recently at the Power of Two Games World Headquarters. MSBuild has proven to be quite a pain to work with for our asset builds and eventually left us dissatisfied (that’s material for a whole other entry). So we kept looking over to Scons as a possible solution. ...
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 burning questions will be answered here. ...
Mine is two seconds. Here at Power of Two Games, we write all our code with test-driven development. C++ tests use the fantastic UnitTest++ framework (no big surprise there :-) ) and we run all unit tests automatically as the last step of our build process. That means that every time we build anything, the tests for that library or program get executed. Every time. No exceptions. ...
So much for the new year’s resolution to write some sort of an update every week. That went out the window pretty quickly. Especially now that I’ve taken over the Inner Product column for Game Developer Magazine and that’s taking away some of my writing time (check out the May issue for my first column!). It turns out that Charles’ old article Stupid C++ Tricks: Adventures in Assert is one of our most viewed entries, even after all this time. So I figured I’d follow it up with a really, really simple C++ trick. It’s almost trivial, really, but I’ve totally fallen in love with it. At first, when Charles introduced me to it, I was kind of lukewarm. But now I’m finding myself going through refactoring rampages in the code changing things to be this way. Intrigued? Read on. ...
LeChimp has been rocking my world lately. I’ve been checking in code that passes all the unit tests, confident that everything was fine, just to find out the functional test fails loudly and obnoxiously [1]. The other day it even managed to put the game in an infinite loop (yes, my fault). It might sound annoying, but I love it how LeChimp keeps us honest and makes subtle problems immediately obvious. A couple of months ago something unusual happened: The functional test failed but I wasn’t able to reproduce the problem right away. The failure was not a crash, but an object in the world ending up in a different state than expected. That’s always tougher to track down. To make things even more fun, was object was affected changed depending on whether the game was run from the command line or the debugger. Oh, and did I mention it only happened in release mode? I’ve got a baaad feeling about this! ...
It’s no secret that I’m a big fan of unit tests. They provide a huge safety net for refactorings, double check the code logic, and prevent code rot. In addition, unit tests written through Test-Driven Development help define the architecture and keep programmers happy. They’ll even catch a bug or two along the way, but if you rely on them as your only way to catch bugs, you’re in for a surprise. ...
Yes, we’re a starving startup. There’s nothing wrong with that. It’s actually quite good: we don’t have any venture capital investment, and we’re running purely from savings out of our own pockets. On the flip side, we have full control over our company, and we can decide what do do and how to run it. Of course, we’re far from loaded with money, so keeping expenses to a minimum is definitely a top priority. It’s not coincidence that one of our most popular lunches is sharing a gigantic $5 sub at Manhattan Giant Pizza or the $3.50 Kealani’s chicken teriyaki sandwich (fortunately, they’re actually delicious too!). Whenever it makes sense, we’ve opted for the most inexpensive options[1]: plastic workbenches from Costco for our desks, lights from Ikea with unpronounceable names, an outdated P3 that became our file server given to us by a friend, or a free scanner/printer donated by my girlfriend. So when it came time to set up our office tools, we also looked for the most inexpensive solution that met all our needs. ...
So here we are, ready to start development of our first game. We have the time, the resources, and the game idea itself. Where do we start? Since both Charles and I are tech guys, we knew we could implement our game idea without any problem and make it sing and dance at a silky-smooth 60 fps. But would it be fun? Now that we have these brand-new designer hats, finding that always elusive fun factor is a big concern. The idea of waiting for a couple of months before we could tell if our game idea was fun seemed too risky, so we tackled that problem first and head-on by prototyping. We could start at the bottom, write some low-level input handling, some graphics rendering, a basic asset pipeline, and all the other usual suspects. The problem is that, even if we try to keep things as simple as possible, it would still be several weeks or even months before we can actually start implementing the game itself. And even when we do, we’ll always be running up against incomplete technology and having to spend time fleshing it out as we try to make a game come out of the other end. Instead, we decided to start with a prototype. This isn’t supposed to be a “prototype” that eventually morphs into a shipping game, or a prototype that uses the same technology as the production code, or even a prototype that’s used to impress the big-wigs to squeeze some money out of them (ha!). No, all that stuff detracts from the ultimate goal of our prototype. Our approach was very similar to what Chris Hecker and Chaim Gingold described in their GDC presentation. We had the need to answer one very specific question: “Is our game idea fun?” And we wanted the answer as quickly and cheaply as possible. Everything else was secondary. ...