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. ...
A lot of people have a particular moment or experience that defined their future. It can be anything: reading a particular book, traveling through a different country, meeting somebody special, or going through a very painful (or happy) experience. For me, the future crystallized on a Fall afternoon in 1985, when I sat in front of an 8-bit computer at a friend’s house. It was the beginning of a long personal journey. ...
In the past, I’ve given presentations about agile game development to two distinct groups of people: game developers without much exposure to agile development, and agile developers who were unfamiliar with game development. This morning I realized how interesting it was to explain the goals and reasons behind agile development to someone completely outside those circles. ...
Spring was supposed to be the season of flowers, new leaves, and good weather returning. Here in San Diego we don’t get much of that, or rather, we get it all year around. So Spring can really sneak up on you, and before you realize it, it’s already gone. Spring also seems to be the season for game-development conferences and travel: just a few weeks apart we get Sony’s conference, Microsoft’s, and, of course, GDC. I’m not even going to count Dice and E3, also happening around the same time. ...
We grabbed the best features of each framework and created what we think it’s the best C++ unit-testing framework out there (for our needs anyway). We took the results and put them up in Sourceforge under a veryunrestrictive license, and that’s how UnitTest++ was born. ...
We have all experienced how development slows down to a crawl towards the end of a project. We have seen first-hand the difficulty of squashing insidious many-headed bugs. We have wrestled with somebody else’s code, just to give up or fully re-write it in despair. We have sat in frustration, unable to do any work for several hours while the game build is broken. Code can get too complex for its own good. See how doing something so apparently backwards as writing unit tests before any code can help with all those problems. ...
High Moon Studios is an unusual company in the games industry. We’re applying agile methodologies for all of our development. My team in particular is using both Scrum (an agile management methodology) and Extreme Programming (an agile engineering methodology). And yes, that means we’re doing pair programming, test-driven development, and all the other often controversial practices. I expect that in a few years, these practices will be a lot more common than they are today. ...
At this point, we have been using CppUnitLite2 for a year at High Moon Studios doing test-driven development on Windows, Xbox 360, and some PS3. It has been used to unit test libraries of an engine, pipeline tools, GUI applications, and production game code. ...
Jumbo shrimp. Instant classic. Military intelligence. C++ refactoring browser. Spot the pattern yet? Up until recently, there have been more sightings of Nessy and Bigfoot than of working C++ refactoring browsers. After months of using refactoring intensively in C++, my fingers are screaming for mercy and threatening me with repetitive stress syndrome. Fortunately, things seem to be changing a bit. I recently learned of SlickEdit’s support for C++ refactoring, so I couldn’t resist taking it for a test drive. ...
I’ve been following the discussion on the evils of assert started by Len Holgate. Poor old assert was getting beaten up from every side, so I’m going to have to step forward and defend it. Yes, I do find assert useful. Yes, I’m doing full-out test-driven development. Yes, I’m a hardcore C++ programmer. ...
A couple of months ago I looked at various build systems in the hopes of finding an ideal one for C++ development. In particular, the most important criteria I was using was iteration time for incremental builds. Jam was the clear winner and things looked good. Fast-forward a few months and one aborted attempt at implementing that build system, and there are now more unanswered questions than answers. It turns out that Jam and its successors were far from the perfect solution I had envisioned, so I was back to square one. I took this opportunity to look into all the build systems I had left out of the first article, plus all the ones that other people asked me about since then, to come up with a much more comprehensive evaluation. ...
The SIGGRAPH conference continues to evolve with the times. Ten or fifteen years ago, it was very academically driven, solving problems that nobody had solved before just for the sake of doing something different or more realistic. Today, SIGGRAPH has a much more pragmatic character. Most solutions and techniques presented have been developed out of a need for movie rendering, model authoring and manipulation, or even real-time graphics applications. At the same time, SIGGRAPH has retained the same rigorous background that it always had, making it quite a change from what we’re used to in game development. ...
First there were punch cards, and people somehow managed to write software. Then came interactive computing with mainframes and personal computers, and people wrote even more software and become even more productive. There is no doubt that our development environments today are light-years ahead of what the computer pioneers had half a century ago. Yet I constantly see projects suffer with horrible environments that force slow iteration cycles on programmers. ...