A couple of months ago when I was meeting someone who's flight was more than a little delayed I wound up in a music store and impulse bought Out From Out Where by Amon Tobin. I absolutely love it and everyone I've played it for has really liked it. Lots of complex rhythms all perfectly put together. It's stuff that's interesting to listen to on it's own and still perfect for putting on in the background and while you're coding for hours and hours.
A big thank you to Tim for his wild party in NYC.
Learned a new word: Muddle
It's what you do to the mint leaves in order to make a Mojito... which has the interesting property of sneaking up on you and leaving you in a highly intoxicated state without you realizing how you got there.
I'm having fun monkeying[0] with linker scripts. This is the kind of thing that makes console programming a total pain in the butt. We're using a 3rd party linker (SN Systems) with gcc (2.95 series[1]) and everything had been working fine until I had to add in libraries from the publisher. This produced lots of complaints from the linker about the global pointer. After searching through documentation and trying to rationally analyze the problem I did a diff between some linker scripts and cut & pasted a chunk of the old one into the new one. It works. Now I just have to wait for an "I have no idea what I'm doing" change to bite me in the ass.
[0] Monkeying, because I can't find the documentation and I haven't done this before. When things go right I only have a vague hypothesis on why they went right.
[1] Yes, we should probably rev this, especially as we are using templates in our codebase and the gcc 3.x series compilers are supposed to do a much better job reducing bloat[2]. On my last project the code bloat wasn't as big of an issue because we were using the .cpp #include trick[3] to reduce compile times which should (theoretically) prevent the much of the bloat because of the (vastly) reduced number of .o files.
[2] The PS2 is exceptionally cache poor and can easily wind up major performance hits due to memory thrashing.
[3] You can have a .cpp file #include other .cpp files which will dramatically drop the total build time under gcc. The trick then becomes to group the .cpp files into mid sized groups that provide a good balance of rebuild times in the general case. Also, this can cause some very weird behavior due to #defines and statics having very different scopes from what you think they do. Note: clear the compile warnings out of your codebase before attempting this. Finding errors sandwiched between thousands of warning messages is a waste of your time.
I suppose one of the grand ironies in my life is that while my primary method of stress relief is exercise[0], my body's primary responses to stress (craving carbohydrates, insomnia, illness, death[1]) are things which make it difficult to engage in exercise, which prevents me from reducing my stress... enter vicious cycle.
Which brings me to today where I'm slacking off a bit and writing a blog entry instead of trying to fix the movie player that's supposed to be hacked in for the milestone before we rip it out[2]. My observation of the day is that the Lemon Echinacea Throat Coat from Traditional Medicinals is pretty good stuff, but you shouldn't use your checkbook following the instructions to cover your cup while brewing.
[0] Yes, I do things besides write code all day. I strongly encourage all potential games programmers to go out and do things besides writing code all day. Social skills are what keeps overtired programmers from doing Very Bad Things(tm) to you when you break the build.
[1] Apparently when I was an infant (being born is a stressful thing... I think) I stopped breathing and turned blue for a while. After some panicked percussive resuscitation on the part of my mother I resumed breathing. I think of this as my attempt not to inherit the earth.
[2] Publishers are insane. They also pay your bills. Deal. It's usually faster to take the day or two to implement the stupid feature they really want then to try to talk them out of it.
First off, let me say that the most impressive thing at the show was the guy at the PlayLogic[1] booth who was throwing t-shirts... while wearing a waist length helmet that weighed about 50lbs and rested on his shoulders (I saw two girls[2] helping him out of the helmet after the crowd had dispersed). If it had been me in that outfit I would've surely fallen over while attempting to throw shirts.
Overall, the show seems to be a bit more subdued this year. The poor economy and threat of SARS probably had a lot to do with that. Kentia hall seemed particularly hard hit (Kentia is sometimes referred to as the "gaming ghetto", and tends to feature a lot of strange products from Korea that you'll never see again).
Now some random games that stand out in my mind:
Gran Turismo 4
GT3 with more polish and network play. If you liked GT3 (I did) then you'll like GT4. I won a hat for beating three other people in a race. Too bad I don't wear hats, I would've preferred another run without having to wait in line.
P.N. 3
(Product Number 3) Beautifully animated, great art. My friends pulled me away before I could play the game, so I can't say anything about the controls. Looks good.
Kill Switch
Very nice. One of the few good things about having my project canceled is that we won't have to compete against this. I'm not entirely happy with the feel of the dive roll and the controls take a while to get used to, but the blend between action and strategy is spot on. Lots of action that rewards smart game play.
Ratchet and Clank 2
A couple of my friends are working on this. Nifty weapons, platforms, and explosions. I liked it. I especially liked that whirling disc weapon.
Wallace and Grommit
It's a GAAAAAME Grommit! The brief peek[3] I got looked good. The game looked to be consistent with Nick Park's artwork. Seems to be a platform/puzzle game.
Neopets game
Regardless of your opinion of neopets, their ability to sell to the lowest common denominator and remain in business is impressive. I talked with someone who refuses to work on flashy titles ever since he worked for 5 years on a game that sold 15k copies. The fishing game that he worked on recently (project length was between 6 months and a year) sold 400K copies and is still selling. The Neopets game is coming out for PS1 (no, not PS2, the venerable PS1). For a while I've been of the opinion that a $50 price point on games is a huge mistake, so it'll be interesting to see how this pans out.
Nokia's N-Gage
Neat concept. That $300 price point is a killer.
Spy Hunter 2
Um, please tell me those physics are going to be heavily revised before that game hits store shelves. For that matter, Midway's entire lineup is beyond disappointing[4]. Perhaps with a new CEO they'll start producing something that isn't crap.
Nintendo licensed products
(All the Mario/Wario/Zelda/etc stuff)
Everything looks polished, brightly colored, and highly addictive. It's kind of like a sitcom or an action movie: You'll have fun, just don't expect a profound experience.
Eye-Toy
A camera based controller. Neat! It's suprisingly satisfying to smash ninja by waving your hands.
[1] Note to the people at PlayLogic (not that I expect any of them to see this entry): the windsurfer control scheme was neat, but please god, if you want to do a unique control scheme you should set up the HUD to prompt the user.
[2] E3 has a large number of very pretty girls in exotic costumes, generally they're dressed as one of the characters in the game. If some reporter talks about how one of them was doing something lewd he's lying and trying to impress his friends.
[3] Um, was I supposed to be able to get into that room upstairs?
[4] At least with no lines at the booth I didn't have to stand in line to be dissapointed by their products.
After work I was playing volleyball on the beach. It was sunset and I looked over at the waves and saw dolphins playing in the surf. I've never seen dolphins in the wild before.
Maybe it's time to break down and buy a camera.
Nothing quite like starting the weekend off by having your project canceled. Ah well, at least now I don't have to fix that ugly bug I just discovered in the way my asynchronous loading code interacts with the collision system.
Note to our (former) publisher: I'd be cashflow positive too if I didn't have to pay my bills.
One week until E3.
It appears that Google's 9am games marketing seminar has changed locations due to too many people signing up. I also notice that the new announcement now features the word "coffee" where the last one listed "cocktails"... perhaps they won't need all that space after all.
The cornerstone of any project is having a reliable build process[0]. For a game this includes the code as well as any art assets that need processing. The goal of the build pipeline is to build everything the same way on everyone's machine every time. In order to get this to happen the build pipeline must properly check dependencies and there can't be any user intervention during the build process.
If the build process fails to check dependencies or requires additional user steps then it's possible to throw your code & assets into an undefined state. This is Bad. Bad like using variables before setting them. Bad like driving your car while blindfolded.
Tracking down a bug that's only there because Joe Beanbrain clicked the wrong button during the art build only serves to waste the time of the development team. What's just as bad is if Joe Beanbrain clicked the wrong button and a bug doesn't show up until much later when the problem is harder to track down and correct.
Even worse is if the dependencies are improperly detected and bugs are introduced that go undetected because assets weren't rebuilt when a file changed. Typically these bugs are tracked down late at night while looking through source control logs after discovering new ways of arranging four letter words in conjunction with the name of someone who left hours ago and is now unreachable.
I've had good luck setting up build pipelines using gnu make under cygwin. I've talked with some people who have had good luck using perl scripts for asset processing. Some tools are not well suited for use with make and so using perl (or python, or ruby, or whatever) might be a better choice. The point is that you need that reliable build process.
Now, assuming you have that reliable build process that works without assistance, you suddenly have the option of doing automated builds late at night. On my last project our night build was set up to modify a .h file to increment a build number[1], wipe the directory tree[2], build everything for all platforms, and then put .zip files up to the network. This lets everyone run with latest assets and it produces a series of snapshots that allow for fast rollback testing to determine when bugs were introduced.
So, please, take the time to make that build pipeline work correctly. It prevents developers from trying to kill each other.
[0] Technically, having electricity and non-collapsing floors might be more critical, but I'd categorize those as "management problems".
[1] Having on screen build numbers eliminates 75% of phantom bugs from QA.
[2] This helps to track down problems where files had been deleted from source safe were still lingering on local drives.
One of the dubious pleasures of working with console games is porting a codebase to more than one system. This not only involves dealing with wildly different hardware architectures, but often involves writing code that works with more than one compiler. GCC, MetroWorks, and Microsoft Dev Studio each have a significant number of quirks (e.g. different scoping of variables declared in a for statement).
The initial move from one platform to another is often painful, but tends to shake out a couple dozen bugs that are often difficult to find any other way.
This same pattern seems to occur when you take a system and use it in a way that it wasn't originally designed for. New tasks stress the code, finding new bugs and highlighting areas in the program that need improvement.
A properly structured piece of code that's maintained through this process seems to be strengthened, whereas a badly structured code suddenly sprouts #ifdefs and bizarre mutant data structures that should never see the light of day.
Not too long ago I was working on a baseball game (yuck) that had bits of header files with comments dating back to 1992. The project was a short timeframe (6-8 month) project that involved updating the game and porting to a new console. Significant parts of the game were awful, badly designed, crufty, and should've been taken out and shot long ago. However, the game ported to a brand new system without anybody ever shouting "rewrite". A lot of the credit for the smooth port does go to the publisher's awesome tools group, but the port would've easily taken twice as many hours if the core codebase hadn't already been ported so many times.