« May 2006 | Main | July 2006 »

June 21, 2006

Awesome

Trying the online chat customer support for Quicken today, because it's after 5 and the live-human line is closed.

Excruciatingly slow.

The capper was this:

Me:  I just want to upgrade from Quicken 2004 to Quicken 2006.

Them:  James, what you're talking about is different feathers of Quicken.

All I can think is that they're outsourcing their customer support to people who don't even speak English, and they're running the chat through a translation program.

Maybe I'll switch to Microsoft Money.

June 15, 2006

More TDDs Pros & Cons

Pros:
* Just had my first "TDD caught a stupid mistake" experience!
* Easier to leave your code and come back later - assuming you got the test in place.  Running the test suite reminds you where you are.
Cons:
* I was getting kind of sloppy, because I knew I had the TDD safety net...

June 13, 2006

Notes on Tomb Raider Legend

Best Tomb Raider ever.  Which isn't saying much;  I went back and tried to play the first Tomb Raider the other day and discovered it's actually quite unpleasant.  This is the only Tomb Raider I've actually finished, in fact.
But you have to like this kind of game, the "Prince of Persia / Tomb Raider / Ico" sort of genre, let's call it the "you barely grabbed the ledge!" genre.  I absolutely love this type of game - (so why didn't I play more of the Tomb Raiders?  Shelf level events, I guess) - even though I don't like the more traditional cartoony platformer, and I don't know if it's because the sort of quantized environment appeals to me, makes me feel safe and comfortable, whereas a Mario or a Jak feels sort of mushy and loose.  Or maybe it's the color - how odd that the games with the more contrived gameplay mechanics (how convenient that there was a flagpole the perfect distance from the platform which is the perfect distance from that crack in the masonry) have the less abstract, stylized color - they try to be more simulationist. 
Since I haven't played a Tomb Raider since II (and a brief stint with Angel of Darkness at E3, "My God, Lara drives like a truck!") and I never played any of them very far I can't be sure but it seems that the clever mechanic they're introducing here is a grappling hook you can use to pull blocks to you.  (Wonder if that was Doug Church's contribution?  What does "original design" mean?)  And the blocks actually aren't quantized, they rotate freely, which was refreshing after God of War, where there was one silly puzzle that relied on the fact that Kratos could slide a block in any direction but he couldn't actually rotate it!
As much as I liked the game, the boss fights were annoying and I ended up playing the game on easy just so I could get past the bosses.  Which leads me to the eternal question:
WHAT IS OUR OBSESSION WITH BOSS FIGHTS?
From a producer POV, from a bang-for-buck point of view, boss fights are retarded.  The buck is quite high:  they are unproven mini-games;  they are excruciating amounts of work that often use very few of the assets and systems that have already been developed;  lots of special case coding and etcetera have to be put into them.
And the bang is usually low:  we move away from the tried-and-true staple gameplay of our title to some weird minigame;  and it seems we always make the boss fights frustratingly hard, because it just Wouldn't Do to spend a lot of resources on the boss fight and then have the player beat it in two minutes.
On the other hand, for drama, I do understand the need to have something different, something climactic, break up the action.  I ask myself, "How would this game feel if, after navigating all the ledges and poles and platforms, you simply put a bullet in the badguy's head and that was the end of it?"  You do want something more.  A conundrum.

June 12, 2006

TDD, weeks later

Working on the prototype has taken every disposable minute - so I haven't been blogging.  It is now much less buggy - it will run for hours and hours before an assertion fires, and the AIs usually have a reason for doing the crazy things they do - but it doesn't do much more than it did a few weeks ago.  But I am writing features again.  Yay.
It's still too early for me to tell if it feels like TDD is a win. 
Pros:
* it's very satisfying.  Writing the test before I make a change, seeing the test fail, and then seeing the test succeed, is like a drug.
* using tests to reproduce bugs is often easier and quicker than trying to reproduce bugs in the wild.
* I did a fairly massive refactoring, reversing a really stupid technical design decision I made on day one.  The old Jamie would either never have bothered out of fear, or would have done it one gung-ho attack and then spent the next few days finding and fixing (most of) the bugs I'd introduced.  The new TDD Jamie had the courage to do it, and did the refactoring one bit at a time, testing the changes as I went, and the program was less buggy when I was done. 
* TDD seems very well suited to gameplay and AI programming.  It's hard to TDD graphics and sound, but in the virtual world that the graphics and sound are just a representation of it's a good fit.
* TDD is forcing me to pay more attention to the code, and I've actually found bugs just from studying it.
Cons:
* It's a hard habit to get into.  Many times I'd jump in and start writing the code, have to stop myself, undo the changes temporarily, write the test, see the test fail, and then go back and redo the changes.  Sometimes I let myself slide.
* Hard to tell just how many tests to write.  You could write tests forever, checking every weird boundary case, entire tables of inputs and outputs, and on and on.  Or you could write no tests at all.  Somewhere between zero and infinity is the right amount, but where?
* Five minute fixes take a half hour.  I'm slower in general.
* I'm up to forty "tests" and hundreds of "CHECK" statements, and still haven't had that rewarding feeling of a test failing because I inadvertently broke something.  I've had lots of tests fail because of incorrectly written or arranged tests, though - part of what's making me slower.  On the other hand, I'm the only guy working on this:  in a multiple coder environment, it's fairly likely that guys could break each other's stuff, and then the tests would fire.

Bottom line:  still doing it.