GameDevBlog

The Saga Ends

Part 1
Part 2

So, finally got through to my case manager, asked him the status, and no progress had been made, unsurprisingly.  He told me that the receipt I had e-mailed in was the wrong kind of receipt.  (Something I didn't mention in the last post;  I couldn't find the receipt, which was weird because that's one thing I'm usually pretty organized about.  So I called Fry's and got another one printed up.  But apparently it wasn't good enough.)  Fortunately, since the previous call, I had found the old receipt.  This time I decided to fax instead of e-mailing;  apparently turnaround times on their faxes are much better than e-mails.  Go figure.

But I couldn't get my "fax machine" (which is actually a scanner+account with trustfax) to work!  Some days I think I'm cursed.  Running out of time before the day was out, I went down to Kinko's to fax the six-page Fry's invoice from there.  Take that, HP.  I fully intended to call to make sure that they got it but something came up and before I knew it, the day was over.  And I couldn't call the next day because I was out of town on business and busy the whole day.  I was certain that nothing was happening.

Here's where it gets kind of anticlimactic - even though I didn't pester them, the FedEx label showed up Monday morning, a mere two business days later - that was fast.  And they had made arrangements for FedEx to pick up the machine for me, which went very smoothly.  (The first time I sent it in, they forced me to make the trek down to Kinko's/FedEx, even though they said I wouldn't have to, one of many promises broken.) And, most stunning of all:  THE VERY NEXT MORNING MY WIFE'S NEW MACHINE ARRIVED, sent overnight delivery.  Which means they didn't even wait to get my old machine back - they just waited for the tracking # to confirm it was on its way, and then immediately overnighted the new machine.  For the first time in the saga, they actually trusted me - I could have sent them a box full of rocks.  Or at least stolen one of the RAM chips.  Not to mention, the new machine was an upgrade, with more hard-drive space and faster processors.  And...it worked!  I had gotten really good at reproducing lockups on the previous machine (trying to play three movies at the same time usually did it) - but this machine sailed on as if nothing was amiss...the movies didn't even skip.

In other words, in the last couple days, the company formerly known as Hewlett-Packard finally pulled its head out.

But it did take a while:

Date we first tried to use the computer:  12/25/06.
Date we first called support:  12/26/06.
Date we were finally able to use our computer:  1/30/07.

So...I suppose I'll relax my boycott.  I may even continue to buy printer ink from them...and that's where they make their money.  I won't risk buying another computer from them, because having to wait a month to use our PC sucks.  And there it is.

The Company Fomerly Known As Hewlett-Packard Saga Continues

Fry's has a part to play in this as well - they're the retailer I bought the machine from.  (If only I'd remembered that CostCo lets you return a computer within *six months* of its purchase date...)  I call them, tell them that HP is jerking me around, and they tell me to bring the machine in and they'll take care of it. 
"Taking care of it" turns out to mean after booting it and watching it hang a couple times with their own eyeballs, they run a diagnostic suite overnight which says the computer is just fine.  "The problem must be software," they tell me.  "Your service plan doesn't cover software.  That'll be seventy bucks."
So that's something to remember about Fry's "service plans" - they can just tell you, "The problem's software," and then they don't have to do anything.  Oh yeah, and they can charge you for it.  I did manage to talk them out of that, at least.

So, once more into the breach;  I call the company formerly known as Hewlett-Packard and manage to get through.  I tell them that the case manager never called me, I'd like to talk to him, and that I need recovery disks.
"I'll send you the recovery disks, but tell me, if you get the recovery disks, what do you need to speak to a case manager for?"
Fine.  Just send the recovery disks.
"Very good, sir.  There will be a charge of $29.95."
I go nuclear again.  Again, I'm told a case manager will call me.  I point out the number of times that promise has been broken already.  This time it'll really happen, I am assured. 
A couple days later, after the case manager hasn't called, I call and do manage to get in touch with one.  Hooray!  I manage to stay calm and ask for the recovery disks, free of charge.  He agrees to send them to me, and transfers me to someone to fulfill the order.
That someone says, "Did he give you his phone number?"
"No, why?"
"Well, he's got your case locked in the database, so I can't actually enter the order for you.  Tell you what, I can have him call you--"
"No!  That's not acceptable!" I say, on the verge of tears.  "They never call.  They never, ever call."
Perhaps he took pity on me, because he somehow managed to solve the problem and get the order in for me. 
The recovery disks arrive the next day!
I reverently put the first one in the CD drive - it takes ten minutes to boot, which is strange - and then partway through installing it says, "CD/DVD read error.  Press any key to continue."
I do.
The system reboots.
In the midst of my preparations for Hari-Kari I receive a phone call.
It's a case manager from the company formerly known as Hewlett-Packard.  And he speaks perfect English.  He apologizes for not calling sooner, says he was sick, and wants to know if everything was going okay with those recovery disks.

You know, it almost made everything okay.  BUT - it turns out this was just a trick.  You see, if he hadn't called, I probably would have just thrown the computer out of a moving vehicle and been done with it.  But this phone call gave me hope.  I told him the disks didn't work and he agreed that the media might be bad and he'd have new ones out to me as soon as possible.
Two days later.  The new ones don't work either. 
He offers to replace my computer, but I need the proof of purchase.  I e-mail him a copy of the receipt.
So, guess what - he doesn't actually get to receive his own e-mail.  It has to be processed by some other people first before they send it on to him.  "So, when are you going to call?"
"Tuesday at the latest," he says.  That's four days later.
I see if there's anything I can do to shave the turnaround time.  "You know, I have the box the machine came in, can I just pack it up and send it in, so I don't have to wait?"
No - he has to send me a new box.
So, despair.  But hey, they're replacing the computer.  How bad can it be?
Of course, guess what?  It's Tuesday night.  He didn't call.  I tried calling him.  I got this message:
"Your case manager's voice mailbox is full.  Goodbye."
Stay tuned for more adventures with the company formerly known as Hewlett-Packard!

Debugger-Driven Development

You know, when one of my coworkers and I were young turks we used to scoff at the senior programmers who didn't use debuggers.  "Printf debuggers," we called them.  We had read *Writing Solid Code* and knew that stepping through every line of code we wrote in the debugger was how to keep our code bug free.

In a strange turn of fate, now I'm the one being scoffed at, for *using* a debugger.  The scoffage comes from two sources:

- Guys with fairly academic backgrounds who like to talk about theoretical correctness.  *Writing Solid Code* is anathema to them because, "Code isn't a 'solid'!  It's a dumb metaphor!"  To these guys, I'm a "Von Neumann" programmer - I slap buggy code down on the plate and then survival of the fittest lets the correct code get through...but there could be all kinds of theoretical bugs in there on the corner cases and whatnot that I'm completely missing and won't find out about until QA (or worse, the public) gets it.  And, furthermore, with multiprocessing becoming a thing, these techniques simply won't work anymore - you can't step through MP code to make sure it's safe.  You know, these guys do have a point.

Truth is, debugger-driven-development does give me leeway to be sloppy, and sometimes I'll be sloppy, knowing that the compiler is there to catch one set of errors, debugger-driven-development is there to catch another, and (sometimes) test-driven-development is there to catch others. Coding this way is a little like the poor speller using a spell-checker - theirs a hole category of mistakes that don't get cot. Really, that poor speller should spend some time with a speak'n'spell, or whatever they use to learn spelling these days. 

Still, even though I (usually) try to be good and "think before coding" I'm not giving up the debugger-driven development.  Because even good spellers make mistakes and it's nice to have the spell checker there to catch them.  (I'm running a spell-check on this article right now.  'Scoffage' isn't a word?  Get out of here!  And 'turk' should technically be capitalized but it looks better this way...hmm, does Neumann have one n or two?  Right the first time!) 

 

- The TDD guys, who are the ones who coined the term debugger-driven-development, and are laughing at me because when I'm stepping through my code, checking values to make sure they're what I expect, that's really a process I should automate in test cases.  And these guys have a point, too.

But there's no way that I'm going to write one unit test per LINE of production code I write, and that's the kind of coverage DDD gives me.  I'll write tests for a couple of cases per function at most, and while those tests will catch a lot of the errors that DDD catches, I think it's still worth that marginal extra time (DDD takes a lot less time than writing a unit test!) to make sure each individual line of code really is doing what I intended.  DDD is clear-box testing whereas TDD is black-box testing.

Don't get me wrong.  I've really come to love TDD over the last year or so.  Caught a bug I never would have found myself just the day before yesterday.  I'm not giving up my old ways for it, is all.

Dave Packard Must Be Spinning In His Grave

HP...the company formerly known as Hewlett-Packard...one of the companies extolled in *Built To Last*...a company other companies look up to and admire...the founders, Dave Packard and William Hewlett, founders that other CEO's look up to and admire...these are the guys who invented Management By Walking Around among other things.  And remember when they made the best damn printers evar!? 

And they've got that allegedly award-winning tech support - it says so right on the box!

ARGGGGGGGHHHH!

I've gotten to the point where I feel physically ill as I contemplate picking up the phone for yet another round with their tech support.  (The last call, a few minutes ago - a busy signal.)  If this keeps up, simply hearing an Indian accent will trigger seizures.

So I bought an HP Pavilion a1540n for Cathy.  A Christmas present.  I'm setting it up for her Christmas Eve, after everyone's gone to bed, and it randomly reboots as I'm doing it.  Whatever, I figure, probably just a one-time thing.  When Cathy starts using her new PC on Christmas, it locks up.  It locks up more and more. 

So I'm pretty screwed here - I got my Christmas shopping done early, and therefore am already past the date I can return the machine to the retailer.  Note to self - procrastinate on the Christmas shopping.

I call the company formerly known as Hewlett-Packard's tech support.  They suggest it's a virus.  I just bought the computer!  I haven't installed anything yet!  How could it be a virus? 

Nevertheless, they suggest I do a destructive system recovery.  (An interesting thing about these PC's - the hard drive is partitioned, and one partition contains all the install software to reset your machine to factory defaults.  Seems kind of cool, at first, until you remember that hard drives aren't as reliable as good old CD roms.  Could my problem be corrupted install software?)

Didn't work.  Call them back.  Am put on hold.  Long story short, I go through this process four times as different tech support guys (all of whom try to sell me Norton Antivirus, assuring me that it will fix my problems.)  Finally, finally, they agree it must be hardware and will send me a box to ship my machine back to HP for repair.

"How long's that going to take?" I ask.  I guess Christmas is going to be late this year.

"Seven to ten days," they say.

Eleven business days later, I get the PC back and a sheet of paper claiming the motherboard's been replaced.

I plug it in.

"I'm scared," Cathy says.

"Me too," I say.

It doesn't even make it to the windows desktop.  It takes me three tries to get it to boot, and then it locks up when running Media Center.  It seems that the good folks at the company formerly known as Hewlett-Packard have somehow made my computer even worse!

So I call their tech support.  They suggest doing a destructive system recovery.  I go nuclear.  And, after ranting to their tech support people, they promise me the case manager will call me back within 24 hours.

He doesn't.

I call and rant some more.  Then they promise me he'll call Monday morning, at 10 AM sharp. 

It's 11:45 AM now.

What did I expect?  Dave Packard's dead.  His name's not on the box anymore.  The new chairman spies on their board of directors.

Building my wife's computer myself would have been less of a headache.

Anyhow, I beseech you, dear reader - if you're thinking of buying a product from HP, remember my story, and as a favor to me, buy from someone else.  (I'm even going to stop buying printers from them, out of spite.)  I've had good results from Alienware, so far.  Seems like the extra cost is worth it.  (Dell's okay - but they're why I had to buy my wife a PC in the first place.  The motherboard on our Dell burned out in less than two years.) 

The company formerly known as Hewlett-Packard must be destroyed.

Manifesto Games

Manifesto Games (www.manifestogames.com) has been up and running for a while now.
If you're reading my blog, you probably read Greg Costikyan's blog too, so you probably already know about it and have been there.
But for the few of you who haven't - go there.
Enjoy.
It's a candy store.
One game that I discovered, thanks to the good folks at Manifesto, is *Lugaru* - sort of *Watership Down* meets *Crouching Tiger, Hidden Dragon*. 
Ben Cousins once studied a bunch of succesful games and decided that the optimum time for a jump in a videogame is half a second.  I, personally, enjoy games with big, delicious jumps.  *Galleon*;  our very own *Spider-Man 2*;  *Hulk Ultimate Destruction*.  You can add *Lugaru* to the list.  The knowledge that there are people out there that consider big, delicious jumps "incorrect" adds to the sweetness for me.
There's more to *Lugaru* than that and you should really just try it out rather than listen to me talk about it.
But this post is about *Manifesto Games* - I really hope they succeed, but I worry.  Greg Costikyan hopes that Manifesto is going to survive by earning revenue from the "long tail" (Google it if you don't know what he's talking about.)  This is the same thing MP3.com hoped to make money off of;  but because they didn't have any big names to draw people to the site, they floundered.  Not that I care if Manifesto has a "Half-Life 2" or "Prey" for me - I'll go to Manifesto anyway. 
If only I had more time, so I could play more of their games!
I just want to make sure enough other people go to make it profitable and keep it around, so when I do find some time it'll still be there.

Ways To Screw Up Preproduction

Here's the Reader's Digest version of the talk I gave in Singapore.

Preproduction and prototyping used to be considered dangerous and risky - make the game already! was the money-guy's cry - now, as far as I can tell, it's an industry standard practice.  I've seen how effective a good, long prototyping phase can be with Spider-Man 2 - so I endorse the change. 

Still - there's a lot of ways you can screw up prototyping. 

Here are some things not to do with your preproduction phase:

Use it as an excuse to coast or slack

Preproduction can turn into slack-time for a couple of reasons:  one would be because it's the beginning of the project, and it seems like you have all the time in the world.  The other would be because it can become a "fuzzy front end."

You need to timebox your preproduction.  If you're inventing some kind of revolutionary game mechanic, you should have a rough draft in 1-4 weeks.  You should have something promising in 2 months.  You should have an actual game you can kleenex test in 2-3 months.  You should have something you'd be willing to show executives in 3-6 months.  Or sooner.  On Spider-Man 2, we hit that timetable--and lots of guys were putting in voluntary overtime to do it--and we came up with something loved by many.

There's a corollary here, which is you can't write an engine from scratch if you want to hit these time tables.  Mark Cerny suggests "dual tracking" it - one team prototypes using the old engine;  the other team refactors the engine, but keeps it backwardly compatible so you don't lose too much of that prototyping work.

 Throw your prototype away

The immortal words of Fred Brooks "Build one to throw away."

I'm pretty sure these immortal words were wrong.

But here we get into semantics.  There are your "proofs of concept" - one of your quick iterations with placeholder graphics and whatnot, with levels that are "grey mesh" or "orange mesh" or "sheet" or whatever you call it at your studio - and then there's your release-quality "prototype" or "vertical slice."  You throw your POC's away - your vertical slice should be kept around, and one day go in the box (with changes, sure, but basically the same thing).

Why not throw it away?  First of all, it's probably got half an hour to an hour of gameplay in it.  If you throw it away, your game will be half an hour to an hour shorter.  Second of all, when you throw it away, you jump headfirst into the dead zone.  You go from having some game to show and iterate on to nothing. 

For example, on Spider-Man 2, our first E3 demo was our vertical slice.  A lot of it was smoke and mirrors, and a lot of it changed, but it basically went into the box. 

Have extended preproduction on an evolutionary, rather than revolutionary, sequel

If you're making a Tony Hawk 2 out of a Tony Hawk 1 do you need to do prototyping?  Sure, if you're adding something new, but that work can be done in parallel with constructing levels that use the same mechanics as the previous game.

Let People In Power See The Prototype Before It's Ready

This is something Mark Cerny warns us about:  "The Stench of Failure" - if you show off your prototype too soon, you create a first impression that will be nearly impossible to shake.  Word will spread, morale will plummet, you'll have to kill it.

Something I learned the hard way is that it's not just executives who can create the stench of failure:  if you're on a big team with multiple prototyping efforts going on simultaneously, anybody who's not working directly on a given prototype can create the stench of failure if they see it before it's ready.  They may check it out with the best of intentions - "We're going through everybody else's prototypes and providing feedback" - but a prototype that isn't ready isn't ready.

I had to kill one of my own prototypes because of this - to this day I don't know if we could have made it work or if it was just a plain bad idea.  If I'd managed to control access, or, once "feedback" was given, I'd told those helpful other team members to keep their mouths shut to the rest of the team, maybe the prototype would have gotten a fair shake.

It's Not All Doom & Gloom

All that said, I am a super-huge fan of prototyping.  Sure, sometimes full production gets short shrift because you spent too much time working on the core gameplay - but I'd rather have that core gameplay than a polished turd.  And sure, sometimes you have to kill a questionable idea that might have worked - but without prototyping, you never would have tried that idea at all. 

Time and again I've seen a quirky "nobody believes in this" idea gain momentum and turn into something great simply because someone sat down and spent a week or three making a rough draft.

A screwed up prototyping phase is better than any Big Design Up Front phase.