Happion Labs GameDevBlog

Press

We're front page news on Gamasutra today.

http://www.gamasutra.com/php-bin/news_index.php?story=15970

Notes on *Portal*

My faith in gaming has been rekindled.  I think the last time I felt this sort of joy pleasure fun happy was...I don't know, Beyond Good & Evil or Prince of Persia: Sands of Time but this has surpassed them in various ways.  Add it to the list of games that cause postcoinal depression.  It's tempting to do some kind of critical theory analysis of the thing but...I won't, it would spoil it and be pretentious of me.  Here's a link, play it yourself.

Press

We're in the latest *Edge* magazine!  (October.)

Hmm...the last time I had my photo in a gaming magazine it was a CGW over a decade ago, for a game called *Gryphon Masters* that...never shipped.  I hope having my photo in a magazine isn't a harbinger of doom.

I Hate My Coffee Machine

My coffee machine, a Krups-something-or-other that I probably got for free with the purchase of some coffee, has my vote for worst designed thing ever.  But it's only marginally worse than most coffee machines so I haven't bothered to get a new one.  Consider all the possible ways I can screw up making my coffee.  I have done *all* of these, probably because when I need my coffee in the morning it's because I'm too tired to actually make it without mistakes:

* I can forget to plug it in. (That's the one I did just now, that prompted this post.  Sometimes Sofi plays in the sink so Cathy unplugs everything.  So if this post seems incoherent it's because I haven't had my coffee yet.)
* I can forget to add water.
* I can forget to put a filter or grounds in.  (If I remember the grounds I remember the filter, thankfully.)
* I can forget to turn it on.
* While running, the filter can sort of fold over in the chamber and then the water goes past the grounds entirely, making a really weak pot of coffee.
* And I can forget to put the lid on the pot, which causes it to do that back-up-don't-actually-make-any-coffee thing.  Oh - and when I pour the coffee - that lid often gets in the way and causes me to spill coffee on the floor.

That last one is the one I hate the most, because it's the most obviously fixable.  For a feature I never wanted (be able to take the pot out before your coffee is finished brewing and have a cup of overly strong coffee) they added this extra point of failure.  Alvin Toffler would disapprove.

Manager In A Strange Land: The Copper Bullet List

On the blog before the blog before this one I wrote a "Jamie Test" - my own version of the Joel Test, for games - thinking about builds and soak tests and smoke tests reminded me of it.   Unfortunately, that old blog - at fristrom.editthispage.com - has eroded over the years, and it's hard to even find pieces of it on cache sites.  All that wisdom lost to the ages.  The humanity.  I really should back up my other blogs somehow.

I later started thinking of it as "The Copper Bullet List" - yes, there are no silver bullets, but there are a set of copper bullets...or "best practices", a boring thing to call them.  These days, I think almost everything on here is common practice.  But without further ado, here's the copper bullet list reborn.  It occurs to me it comes in two parts:

1)  Making a great game

* The key to a succesful team:  people, people, people.  Try to work with people who are better than you.  There's a large body of literature on how to do this - too much to go into here.  But what's usually worked for us has often bordered on nepotism, working with friends and friends of friends - ]friends whom we know are very smart and talented.

* Don't spend more than an hour or so writing a spec for any given feature, level, mission, character, whatever. (Concept art and schematics can take longer...but don't necessarily have to.)  Instead:  proof-of-concept, spike solution, prototype - whatever you call it, do it.  I believe this is the most important thing, the key to having a spark or je ne sais quois that will make your game stand out.

* "Kleenex" or "Blind" test, early and often.  Not doing this will ruin your game.  Your spark will be buried beneath frustration and hate.  (But if you didn't have that spark in the first place, then this'll just give you a polished, um, you know.)

* Keep communication open;  try to involve everyone in decisions.  Sometimes you'll get a lead who'll say "You went around me!" or "You went over my head!" when two others on the team talk without consulting them first - they'll want to implement a chain-of-command and make sure they're always passing messages, the hub of a game of post office.  This is an attitude that must stop.  People on the team need to talk, and leads should only get upset when one of their guys actually go off task for someone else without permission.  Implementing a chain-of-command is just one of the many ways you can block communication, and this is a point about which whole books are written, so maybe that's a sign that the list has come to the end.

2)  Actually Getting The Thing Out The Door - (and this part's basically the Joel Test rehashed)

* Use source control - AND asset control.  This can be as simple as checking your data files into Subversion.

* Strive for readable, maintainable code first and fast code only where necessary.  (Corollary:  write as little as possible in assembly language.)

* Run an end-to-end build machine.

* Use a bug database.  (Lately we've been using Bugzilla.)

* Fix the real bugs (p1, p2) before writing new features.  Any bugs that wouldn't completely kill you to ship (p3 on) you can leave until later.

* Schedule.  But in Excel, not in Project.  (A 6-person or smaller team could even skip Excel and use file cards on corkboard.)  Scrum's backlog and burndown are my favorite way of doing it these days - we also lump our bugs into the schedule.  See my talk at the IGDA Leadership Forum in November for more on scheduling.

* The people doing the work make the estimates (try the Planning Game from *Long Term Estimating And Planning* for a robust approach to this)

* Keep your turnarounds tight.  Ideally it'll be 30 seconds or less between making your change and being able to see your change.  (A unit test scaffold gives programmers a new way of doing this.)

* Test internally.  Don't rely on your publisher for enough QA.  Depending on the size of the team and the reliability of your build environment, you might be able to get away with the producer, etc, doing it part-time, but probably not.

Whew.  Big talk for someone who hasn't shipped a game in a few years.  But there it is.  Anything you're not doing?  Anything I missed?