Friday, January 30, 2004

The love affair is over


It's been a while since I've written about coding. Scott Miller told me recently that I could increase my blog readership if only I'd focus, but I just can't seem to stick with one discipline. With game development in the state it's in today, this is okay, as I discuss in the latest Manager In A Strange Land.

So I'm going to write about coding!

I think it was item 50 in The Pragmatic Programmer that said, "Learn a text processing language." I chose to learn some perl, and after I had learnt a sort of pidgin perl I was thrilled - I took on some rudimentary text processing tasks for people in the office (turn this screenplay into a .csv file, rename all the files in this directory) and was impressed with how easy it was to do these tasks. Then I took on a nontrivial task (compare this file with these three files and n sets of directory listings to make sure they match) at which point I required arrays of arrays and the language turned on me. Like the time I dated a hot girl who turned out to be a recovering junkie, what started out great turned into a nightmare. Most popular perl idioms are completely alien to my brain, which has been thoroughly indoctrinated in the structured programming ways of C. Operators that also set the values of global variables...regular expressions which compress a ton of functionality into a single unreadable line of garbled punctuation...defining functions as you need them in the middle of a line of code...arrays of references of arrays...

500 lines of code (a real perl programmer could probably have done it in 50) and a few days later, I did complete the task...and if I had to do it again, I'd still use perl. But the magic is gone, and I wouldn't use perl for anything except text processing. Our automated build scripts are in perl, and I don't like it.

disappointment #2: test-driven development.

I've been trying harder to write more unit tests, eagerly awaiting the time when one of these unit tests is going to catch a bug. I've maybe written a couple dozen of these things. Although they've been useful in helping me write the code correctly in the first place, they have yet to flag bit rot. Just as an example, there's a train that follows a rail in Spidey 2. I wrote unit tests to exercise the follow-the-rail code, and left them in the code to make sure nobody broke it. Recently, we changed the train model, and had trouble exporting it from Max to spec. So I gave up and changed the code to work with the new train. This broke all my unit tests. But now it was the tests that were wrong - not the code. I'm thinking it's likely that most of the time a unit test fires, it's because the assumptions it's asserting are no longer true. I'm not giving up on unit tests yet -- mostly because I get coder-pleasure from writing them -- but they have yet to truly prove their value to me.

Wednesday, January 28, 2004

Hey, how about that!


There's actually a page there, now, at least. I'm now 99% sure it does work.
I have no idea what I'm doing


Installing NewsMonster on my desktop machine destroyed Mozilla so deeply that uninstalling and reinstalling it didn't bring it back from the dead. I still have my laptop...but I'm not trying that again. So I am without a way to test if this "atom feed" thing actually works. I'm 99% sure it doesn't, but you might try:

http://gamedevleague.blogspot.com/rss/atom.xml

Let me know if it magically works. I'm going to assume it doesn't, and give up. I'm going to switch to typepad soon.


Tuesday, January 27, 2004

Feed


Okay, I just attempted to turn on the RSS feed. Could somebody tell me if it worked? I don't actually use a newsreader, myself.

Sunday, January 25, 2004

More Notes On Deus Ex: Invisible War


I've found I can alt-tab between DX and my blog. I'm on my second playthrough, seeing how far I can get on hard without killing anyone. (Side note: this is an example of metagame. The game itself gives no recognition for pacifism, the way Ultima IV or a Bioware game might.) So, in no particular order:

* Crates have glass lids. You can look inside and see if it's worth spending a key on, before you waste the key (AKA multitool). Escapes the necessity of a quicksave. Very clever.

* I think games like Deus Ex and GTA3 are what lead designers and publishers into thinking their game has to do it all. A couple of particularly unfocused games came out of Activision last year: True Crime and THUG, and I think the rationale behind the designs was, "GTA did it." The thing designers should remember is that this lack of focus is the focus of these games. Deus Ex is all about choice and GTA is all about freedom, so by necessity they have to be toaster cars. But if your game is about skating, keep it about skating. I stand by what Mark said earlier in the blog: no toaster cars. Another example of the "toaster car that works" is Halo, famous for adding vehicles to the FPS. A couple things to remember there: Halo had such a long dev cycle that they had the time to make two games in one, and the driving has issues - putting FPS controls on driving is very counter-intuitive. It feels squishy and weird. Although it is interesting and satisfying in its own weird way.

* There's (at least) one section that plays differently if you choose a male or female character. Nice touch. A choice with consequences. Which brings me to: consequences. "perceivable consequence" was one of Doug Church's things, and I think what he meant was the player has to be able to learn what the consequences of their choices are going to be, although I've also seen him interpreted as meaning the consequences have to matter. The glass lids on the crates create a perceivable consequence. Choosing a female character in Deus Ex means you have to pay 300 for a key that the male character can get for free. A consequence, but not perceivable. If you don't have some idea of what the consequences of your choices are going to be, the choices are less interesting: you may as well flip a coin. On the other hand, even choices with invisible consequences increase replayability and the breadth of the game space we're exploring.

* More on the "just because somebody else's really cool game has this doesn't mean you have to" front: interesting choices are not necessary for a game. Many, many people consider rail shooters and linear brawlers and DDR good fun. Some people hate linear games, though, and those people can play Deus Ex and Civ.

* Why are there security bots guarding the toxic waste spill on the inclinator, again? To protect people from the toxic waste by shooting them? And how come everybody knows what I'm doing and radios me at just the right time? Can anybody spy on me at will? And if a tavern can send a safety code that turns my gun off, why doesn't a heavily armed installation? These little plot holes were introduced to make the gameplay better - circumventing robots is fun, knowing what your goals are is fun, killing all your vital contacts is not fun (well, it's not fun after the initial thrill wears off, anyhow). I'm willing to concede these points. Call it poetic license.

* Although Max Payne 2 bust Havok's cherry, Deus Ex really lets you play with it, because you can pick things up, throw them, watch them land. This is a mini game all by itself, although it's rare for the physics to create any meaningful gameplay. You *can* trick guards into exploring the wrong area by throwing things, though...

* The story points seem like noise the first time through. You listen to the news, you talk to people, you don't know which faction is which, it's all a bunch of unconnected dots. The second time through things make sense and feel part of an organized whole. It really takes more than one playthrough to appreciate this game, I think.