A few days ago I went out to lunch with some friends and they brought up an interesting thought: Will 2009 be the year of the indie developer? I loved the sound of that! I’ve been an indie developer for a year and a half, and I’m seeing more and more people taking tha route. I think indie development is necessary for a healthy game development industry. Where else are people going to try weird ideas, experimental development techniques, an commercially unproven designs? I think it’s a sign of maturity that we’re seeing a need filled by independent development next to the Maddens and Worlds of Warcraft and other chart-toppers. ...

I have a feeling I don’t fit the profile for the average iPhone developer. I bet a lot of them come from Mac or Web development backgrounds. On the other hand, I come from over the years of professional game development on consoles and PCs, which gives me a different perspective on things. When I hear developers complaining about Apple’s approval process to put something on the App Store, I can’t help but laugh and wish they had a taste of submitting an Xbox or PS3 game for approval. Now, that’s a real bitch! On the other hand, long-time Mac developers will be throwing around all these API names and classes like everybody learned them in kindergarden. I’ve only been doing iPhone development for a few months, so I don’t claim to know everything. But they have been some intensive couple of months, that’s for sure. This is my attempt to share my experiences, and hopefully encourage more game developers to take the leap and consider this really fun little machine. As I explained in a previous post, I was a Mac-virgin. Sure, I had used one here and there, but never as my primary platform. Not only was I able to get up to speed and functional in a matter of days, but I totally love it and switched to it as my main computer. So, with that out of the way, how about the iPhone development itself? Over the next few days (or weeks, depending how busy I get), I’ll try and cover the major areas of iPhone development that I’ve experienced so far. Let’s get the most obvious one out of the way: Objective C. ...

You’d think that things would slow down around Christmas time over here. And that I would have lots of time to catch up and write about all the things I keep jotting down in my overflowing “to write” list. Right? Unfortunately that’s not the case. I do want to catch up and share my iPhone development experience with everybody, but it’s hard to make time, even during the holidays. To make things worse, I have a pretty hard deadline I set myself to have my iPhone app ready by early February. ...

Have you ever given some thought to why you decided to become a game programmer? I’m pretty sure it wasn’t to do mundane, repetitive tasks. Yet sometimes we find ourselves spending a significant portion of our time making sure that the code compiles for all platforms, or that there are no potential bugs lurking in the depths of the game, or even building the assets for each level and running them to make sure they load correctly. Clearly, those are all things that need to be done, but if they are so repetitive and mindless, couldn’t we put some of the computers around us to good use and have them do the job for us? A build server will do all that and more, much faster and more reliably than we could, and it will free us to work on the thing that made us fall in love with this industry in the first place: the game. ...

I’ve worked with many operating systems over the years: from the humble CP/M, to early versions of DOS, to Windows 3.0 (if you can even call that an OS), along with many different versions of Linux since 1993, a smattering of VMS, and, of course, all the recent flavors of Windows. But somehow, I always managed to avoid Apple operating systems. Starting iPhone development was a bit of a change since it required me to work exclusively under OSX and use a new IDE (XCode). I had talked to people who found the change very cumbersome and found the new environment got in their way, so I approached it with a bit of trepidation. ...

I hate driving. You have to deal with crowded roads and people who seem to be doing their best to get in your way. Worst of all, it’s dead time: you can’t read, you can’t write, you can’t use a computer, or even take a quick cat nap. So I really try to minimize how long I spend on a car and try to do everything remotely, or walk or ride my bike instead. ...

I’m lost without feeds. In the last few years, my mode of operation with teh itarwebs has gone from poll to push. I used to have a set of bookmarks that I would visit every week. As the rate of change picked up, I started visiting every day, but it soon became overwhelming. Now I’m 100% feed driven. Content is pushed to me, and not the other way around. Interestingly, the number of sites I keep up with has gone up significantly (over 100 by last count) so it’s still as time consuming as it was earlier. I just get a lot more information during the same amount of time. ...

I know that things have been very quiet over here for the last few weeks. Lots of stuff happening and it’s hard to find time to write sometimes. But now I should be getting back into the swing of things and updating Games from Within more regularly. The big news is that we decided to call it quits on Power of Two Games. It was an amazing experience and I learned a huge amount. I’m sure we’ll write a postmortem with some of the gems we learned along the way sometime soon. Unlike most postmortems, we really don’t have any office politics, bosses to suck up to, or publishers to keep happy, we’ll be able to be brutally honest. ...

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 really enjoy a good cup of tea. On the surface, making tea is really easy: take some tea leaves, pour some hot water over them, and wait a few minutes. In practice, the difference between a bitter, undrinkable brew, and a perfect cup of tea is all in the details; the type and amount of tea, the temperature of the water, and the steeping, time all make a huge difference. A playback system for a game is very much the same. As we saw last month, the basic idea is really simple: Record all game inputs, make the game deterministic, and you get the same playback every time. Unfortunately things aren’t quite that simple in real life. Just as with tea making, the secret to a perfect playback system is all in the details. ...

Insanity: doing the same thing over and over again and expecting different results. – (attributed) Albert Einstein How would you like to be able to reproduce every crash report that QA adds to the bug database quickly and reliably? How useful would it be to be able to put a breakpoint the frame before a crash bug happens? You can do all that and more if your game is deterministic and you feed it the same inputs as an earlier run. Sounds easy? It is, if you implement it early on and you keep it that way during development. If you choose not to make your game deterministic, your team will go insane by Einstein’s definition, and maybe by a few other definitions as well by the time the project ends. ...

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! ...