It was 1997, I'd just finished college, was really excited about getting my first job in the game industry, and I was a complete idiot. Luckily life was there to hand me a few lessons.
I'd always worked at name-badge jobs paying hourly rates, so when I was offered a whole 10,000 pounds a year, I thought it sounded amazing. It came out to around 550 pounds take-home pay a month, my rent was 400 pounds, which left me and my unemployed wife 150 pounds a month for food, transport and bills. The first lesson I learnt was to crunch the numbers on any deal, and not be distracted by a big headline figure.
The project, for Climax Inc ("Hi, I'm at Climax", not the best name), was to port Blizzard's hit game Diablo from the PC to the Playstation 1. I'd spent years obsessively coding in my bedroom, but this was the first time I'd done any professional work, so I was very definitely a junior Junior Programmer. I kept hitting frustrating problems just using the basic tools I needed for development (I'd never even touched a debugger before) and my code was so buggy I could barely get it to run. I was painfully shy, didn't know anyone else in the company, and they all seemed too busy to help. The only person who made time to help me dig myself out of my incompetence was the bloke sitting behind me, Gary Liddon. Over the course of a couple of weeks he was incredibly patient about hand-holding me through the basics of building and debugging. It was only after the team started getting organized that someone introduced Gary as the project lead, in charge of 20 programmers and with a decades-long career in games behind him.
The second lesson I learnt was that I wanted to work with people like Gary, willing to help the whole team, rather than hunting for individual glory. I've since worked with a lot of 'rock star' programmers, and while they always look good to management, they hate sharing information or credit and end up hampering projects no matter how smart they are as individuals. Gary used his massive brain to help make us all more effective instead, and I've always tried to live up to his example.
The code itself was a mess. There were hundreds of pieces of x86 assembler scattered throughout the code base, which was a problem since we were porting to the Playstation's MIPS processor. Usually just a couple of instructions long, and in the middle of functions, these snippets were pretty puzzling. Finally one of the team figured it out; somebody had struggled with C's signed/unsigned casting rules, and so they'd fallen back on the assembler instructions they understood! The whole team had a good laugh at that, and were feeling pretty superior about it all, until Gary quietly pointed out that the programmers responsible were busy swimming in royalties like Scrooge McDuck while we were porting their game for peanuts.
The third lesson I learnt was that you don't need great code to make a great product. I take pride in my work, but there's no shame in doing what it takes to get something shipped. I've seen plenty of projects die a lingering death thanks to creeping elegance!
After 6 months of spiralling into debt I finally managed to get another job, only 2,000 pounds more in salary but in a much cheaper part of the country. Not much of my code made it into the final game, and it was a pretty miserable time of my life to be honest, but sometimes the worst projects are the best teachers.
Comments