peterb hits it out of the park

peterb of Tea Leaves, in Game Developer To World: Please Revolve Around Me! summarizes the position taken by Tim Sweeny of Epic during an interview thusly:

  1. People aren’t buying expensive enough PCs.
  2. Even the expensive PCs aren’t good enough to run his games.
  3. People who buy cheaper machines with Intel integrated graphics are giving their money to Blizzard instead of Epic.
  4. This aggression cannot stand. The solution is that everyone except us should change what they’re doing and buy machines with more expensive graphics hardware.

This problem is endemic in the game industry.

The most recent example, I was going to buy my girlfriend The Sims 2 for Valentine’s Day to play on her MacBook. Oops! Her MacBook has the dread Intel integrated graphics and therefore can’t run it! Or, indeed, any of the other games ported to the Mac using the same technology! Thanks a bunch, it’s not like anybody has a MacBook! (Except, of course, everybody these days.)

But wait, what are the actual system requirements for The Sims 2 on Windows? 800 MHz CPU and a T&L-capable video card, or 2GHz CPU and non-T&L-capable video card. Her MacBook definitely meets those criteria, and it’s also a huge portion of the Mac customer base for a game like that. I wonder if the PowerPC build would run acceptably under Rosetta — the original Sims ran fine on an iBook DV a half-decade ago, after all, and it’s not like The Sims 2 is new.

I also heard a lot of commentary around the time the iMac G5 debuted about its “terrible” 5200FX video chipset. After all, it meant that a lot of games people were working on for then-high-end machines wouldn’t run! Except, uh, why wouldn’t they run? Because developers didn’t actually design for what users were buying! They were designing for some ideal system that very few people had, and beyond that they had the gall to complain that they weren’t selling many games. Hmm. I wonder why. If you limit your market to people with beefy dual-G5 systems with high-end video cards who are allowed to install games on them, maybe that’s not such a big market… On the other hand, if you design for the iMac G4, and the iMac G5 comes out, chances are you’ll be able to sell to a lot more people…

Game developers should be targeting the systems people are using rather than systems with every feature under the sun. No wonder casual games do so well — nobody else is willing to serve that vast majority of the market!

So if you’re writing a game, or thinking about writing a game, or any other performance-sensitive application, look at what the bulk of the users you want to target are currently using and design for that. Neither you nor your users are likely to be disappointed with the results.

The Design of Everyday Games

[Tea Leaves][1], [The Design of Everyday Games][2]:

> I’ve been playing a lot of *Advance Wars* lately. It is a
> perfect little gem of a game, and I’d like to use it to
> make some points about good game design.
> Good game design increase richness, but eliminates
> complexity. Good game design emphasizes content over form.
> And, all things being equal, good game design favors
> mainstream technology over the cutting edge.

**Read this.** Peter’s advice isn’t just for game designers — everyone designing software can benefit from it.


Making Better Games with Test-Driven Development

Noel Llopis (Games from Within) and Sean Houghton, Backwards Is Forward: Making Better Games with Test-Driven Development:

> One of the questions we had when we jumped into TDD is
> whether it was going to hold for high-level code. We had
> seen in practice from previous projects that we can
> certainly do TDD to create low-level and intermediate-level
> libraries (math, collision, messaging, etc). But would it
> really work for high-level code that would build on
> low-level code?
> The answer is an unconditional yes. We have developed a
> full codebase doing TDD from the start, and we had no
> difficulty writing high-level code with TDD. Things like
> character state machines, game flow, or specific game
> entities were done through TDD without any problems, and
> greatly benefited from the TDD approach.

Noel’s blog is great, and this paper is being presented at the 2006 Game Developers Conference.

Noel and High Moon Studios have been a lot of pioneering work using Extreme Programming in the game development space. Game development can definitely make good use of Extreme Programming to manage the development process, dramatically improve the quality of code, and do wonders for scheduling accuracy and schedule predictability.

Extreme Programming in game development also presents special challenges due to the exploratory nature of a lot of the work, as well as the highly-interactive nature of the software itself. As Noel points out, you wind up writing much more finely-factored code when doing TDD, which will be alien to a lot of game developers but will help greatly with maintenance, debugging, and the ever-more-important portability. (Not just between Windows and Mac OS X, but also between Xbox and PlayStation 2 and Nintendo GameCube and Xbox 360 and PlayStation 3 and Nintendo Revolution…)