On Monday of this week (10/18/2010), my employer Krome Studios shut down. This is the mug that I used for most of my career in the video games industry. It seems wrong to have it at home, or to drink from it here. So it just sits on a counter and collects dust, now.
Maxis
My first job in the games industry was at Maxis, in the financially-gloomy days shortly before it was purchased by EA. I was working in QA there, about two meters from (and with clear line-of-sight to) Wil Wright’s glass-fronted office. In those days I mostly remember him sitting in his office, by himself, looking sad. I felt bad for him. I never went to introduce myself. I was, after all, only a temp in QA. To this day, I regret not having talked to him.
Wil Wright had a reputation for starting every company meeting with a shaggy dog story, which he would invent on the spot. I was told that sometimes these would reach a fantastic conclusion, and sometimes they would just eventually stop without reaching any sort of punch line. I only had occasion to hear him do this once, on board a ship he had chartered for the meeting where he told us about the possibility of the EA buyout. I don’t remember how that company meeting’s shaggy dog story ended. I wish I did.
In any case, I was a programmer, and QA work never really felt very rewarding to me. I well remember thinking, as I was walking to my car at the end of my second day of QA work at Maxis, “I can see myself eventually getting really tired of this job”. And at the end of my third day of work, “I’m really tired of this job.” But I stuck with it for six months, met some really neat people, made (what seemed to me at the time) an awful lot of money, and received the best single piece of advice that anyone has ever given me: to work abroad while I was young, if I had the chance.
During my time at Maxis, I was credited on “Streets of SimCity”, and also tested SimMars (never released?), SimSafari, and the infamous SimCity 3000 prototype which was the star player at the center of Maxis’s financial woes.
Trivia: In “Streets of SimCity”, on the date of our first release candidate build, I found a bug where if you created a new player and named him “*”, it would delete all of your existing saved games. I was a hero, that day.
Trivia2: I once snuck into Maxis’s network testing lab, and found that one of the Streets of SimCity coders had left some of the network code visible on the screen of one of the computers. I read the code to find obscure edge-case bugs, and then went back to my desk to file those bugs. Until now, I’ve never told anyone that I found the “a package which happened to be randomly spawned within the same grid space as the player couldn’t be picked up” bug (amongst others) not by having it actually happen to me, but by reading the source code to which I wasn’t supposed to have had access. Mea culpa!
At Maxis they had a network server (The “Toys” server) which contained installers for every game they’d ever built, whether actually published or merely prototypes, and everyone was encouraged to install and play these games during lunch breaks or after work. Amongst the fantastic games (I loved Marble Drop), there were a few particularly notable ones. One, “Fractured”, was a turn-based strategy game played on a procedurally shattered stained glass window. It seemed to be a fully functional prototype, complete with network play and AI. And it was fantastic and extremely addictive, but sadly (to my knowledge) has never seen the light of day outside of Maxis. Another, “SimDollhouse” was the game which eventually, post-EA was to be resurrected and become The Sims. When I saw it, it was basically Little Computer People, where you could build the house that a family lived in. One of my co-workers told me that it had been there on the server for more than six years; that it was just another failed prototype.
Eventually, my chance came to work overseas. A development studio called Beam Software, or else called Melbourne House (which name they used seemed to depend upon the day of the week) wanted me to come out and write the software 3D renderer for an oddly named racing game they were writing, DethKarz. However, due to the complexities of working out visas, by the time I got there DethKarz was already complete, and I was instead put onto a little shooter project called “BioTech” or “BioTek” (also seeming to depend upon the day of the week).
Infogrames Melbourne House
After a few months on “BioTek”, it became clear that Melbourne House was in financial difficulties, and the whole company was likely to shut down. However, at the last moment we were purchased by Infogrames, just one of a whole slew of development houses they were purchasing at the time. Infogrames cancelled “BioTek” very quickly, but took a lot of time to decide what we should actually be making instead. So during the down-time before work started up as Infogrames Melbourne House, I invented a scheme for doing real-time cel shading, and made a few demos of it. On the basis of that cel shading technology, Infogrames Melbourne House was given the opportunity to make Looney Tunes: Space Race (video) for the Dreamcast. It’s notable that this was the second released 3D game to use cel shading (reaching store shelves just a few months behind Jet Set Radio). So on the one hand, I’m disappointed that we weren’t first. But on the other hand, maybe that means I’m not entirely to blame for the glut of cel shading effects that were to follow in all sorts of unlikely games for the next several years. In addition to the cel shading algorithm, I also wrote the game’s animation system, wrote all of the character behaviours, as well as all of the weapon effects.
Together with the animators, I strongly argued for the “no directional lights” artistic policy which resulted in the characters being flat-shaded, making them look so much like the hand-drawn characters that Warner Brothers’ games division decided they weren’t qualified to approve the characters. To get our character models approved, we had to go through Warner Brothers’ cartoon and movie licensing groups instead. This led to some fun exchanges, such as when the cartoon licensing group objected that in our game it was possible for Bugs Bunny to lose a race, and that ever losing at anything would be completely out of character for him, so could we fix that please. And the single comment which they made about our Daffy Duck model: “Daffy’s knees should be 10% lower” became a catchphrase among the character modelling and animation staff.
While the game is now showing its age, and in hindsight there are some very obvious rough spots (that HUD; what were we thinking??), I’m immensely proud of what we managed to accomplish under the constraints.
After the game was shipped, I was (probably quite rightly) taken to task for having “hijacked” the project; having steered its design quite strongly, even though I was only a junior programmer. There was no raise for me that year.
Trivia: Space Race was the first game to use Melbourne House’s new “Vertigo 2” game engine. In fact, for the first half of development we used Sega’s game engine (which was supplied with the Dreamcast development kits), and only transitioned over to Vertigo 2 halfway through development. Switching between game engines in the middle of development is a highly unusual and often dangerous thing to do, but it was totally worthwhile in this case; our engine was both higher-performance and more flexible than the Sega-provided one.
Trivia2: Space Race was also one of the first video games to make extensive use of inverse kinematics, which allowed me to freely move the characters around on their vehicles, while still keeping the characters’ hands and feet on the controls. It even allowed me to give Marvin the Martian’s flying saucer real moving control levers, without requiring us to make special “steering” animations for him. Each character in Space Race had six sets of inverse kinematic information, and interpolated between them based upon what they were currently doing (some were relative to their vehicle for when driving normally, some were relative to their head for when carrying a prop, etc). More than anything else, it was the combination of inverse kinematics, advanced animation layering, and physics-driven animation bending that gave the characters such a fluid, expressive appearance.
Trivia3: We had a secret “instant martian” character built and working for the game, but couldn’t actually include it in the final build because it hadn’t been sent to Warner Brothers for approval in time. A fez and vest were eventually added to this character (for reasons that were never clear to me), and it was included in the later PS2 port (which I wasn’t involved in making).
Trivia4: Players often wonder about the odd frequency of “falling object” weapon pickups in this game. We actually had a large quantity of other weapon types designed, but toward the end of development we realised that these weapon effects were so involved and demanding in terms of animation and logic that I just wasn’t going to be able to finish many of those concepts in time, and so many of them were replaced by yet more variants of the “falling anvil” gag, which only required a new model and no new code, and so were much faster for us to create.
Trivia5: The introductory real-time cutscene (video) we shipped on the Dreamcast discs was actually using the wrong version of the cutscene animation data; the shipped version was about two weeks old, and my code managing the playback of that animation data was just silently coping with the errors in the data as best it could. This single incident convinced me that “fails early and loudly and with as much detail as possible at even the slightest provocation” is a far superior approach to programming than “robust and reliable, won’t crash no matter what,” and has guided my system design philosophy ever since. With that said, the difference was subtle enough that I don’t think I’d ever have noticed this mistake if one of the animators hadn’t pointed it out to me years later.
Trivia6: During development, I had a one week vacation in which I was supposed to be relaxing. But in fact, I spent most of that vacation writing what I called the “Bugs Bunny Ear Physics Simulator” on my laptop; an attempt to figure out the maths involved in making nice and responsive ear behaviour for Bugs Bunny, when he’s sitting on an object that could rapidly accelerate and decelerate. Variants of this code were eventually also used for Elmer’s scarf, Sylvester’s tail, Yosemite Sam’s moustache, and possibly a few other things that I’ve forgotten about. But Bugs’ ears were definitely the most difficult to get right.
Trivia7: During development, we inadvertently destroyed three Dreamcast development kits, due to a known (but never addressed) electrical issue with their video cables. Two of those destroyed kits were entirely my fault. Sorry, guys!
After Looney Tunes, we started work on a Men-In-Black-licensed game, “Alien Escape“, which was originally supposed to just be set in the same world as the Men-In-Black movies, but eventually became tied in with the Men In Black 2 film, with the same protagonists and some of the same villains. Which was tricky, because we had virtually no information about the film during development; only a few photos and character names, and virtually no storyline information. In this game, I was responsible for coding the visible player behaviour, and for scripting all of the boss encounters. I remember feeling at the time that I wasn’t getting enough design direction, and that I had to design the specifics of each boss encounter by myself, and I really wasn’t very happy with the designs I eventually settled on.
This was the first and only “death march” project I’ve ever been a part of, with mandatory 12-hour days and 6-7 day weeks for the last several months of the project (as I remember it — actual facts may differ). At the end of the project, those of us who were still with the company were given black “I survived” mugs.
Trivia: I took one of the final release candidate builds home to show to some gamer friends of mine. None of them could survive the initial alien encounter and escape the very first room of the game. The game was brutally difficult; a side-effect of having had virtually no gameplay tuning based on anyone but our elite QA department.
Trivia2: Most of the game flow was to block the player into a small area, fight some respawning bad guys until they stopped respawning, then unblock the player so he could progress, and then block him into the next section with more respawning bad guys, and then repeat until the player reached the end of the level. The mechanic we used to block the player was a magic blue ribbon with scrolling text on it, which was intended to look like a sort of futuristic police tape. From this point on, anything in any game which inexplicably blocks the player’s progress until the player defeats enough monsters became referred to as “mib tape”.
Trivia3: In the few weeks before release, when we were basically “hands off” from the game except for critical bugs, Thuyen figured out how to make the game really work. With a simple camera change from third-person to overhead, suddenly the game became an engrossing shooter, and being locked off in these little arena areas made complete sense when played from that vantage point. The game could have been awesome that way (or at least, far better than it was) — but sadly, it was far, far too late to make such a major change to the game.
Atari Melbourne House
At about this point, Infogrames acquired the rights to the name Atari, and switched their name, and so we became known as Atari Melbourne House. During this time, I worked on the 2004 PS2 game Transformers (video), where I was responsible for robot-mode and glide-mode player control, the camera behaviour, and I designed and implemented the final boss fight against Unicron (video). Apologies to everyone for that final boss fight; it was entirely designed and implemented in the last six weeks before shipping, and without much time available from the artists to create extra art assets or animations for it; I’m sure there must have been something better I could have done within the limitations I had, but I still don’t know what it would have been. (Thuyen came up with an awesome design for this final level; I wish I’d have been allowed to use it. This was a bit of a pattern for Thuyen — he was often the guy who figured out at the last minute how to make game mechanics really work, only to have management declare that it was too late to implement those improvements. Really, really disappointing for everyone when that’d happen.)
The most notable thing about Transformers is the visuals that we were able to achieve, thanks to our evolving graphics engine, Vertigo 2. The visuals it was putting out were favourably compared against even the modern XBox games such as Halo, which were coming out at the time. I can’t praise our engine team strongly enough; they pulled out some fantastic tech to support this game.
Trivia: I believe that Unicron is the largest boss in any video game ever made. He’s a little over 13 kilometers in diameter (In this level, Cybertron is a complete sphere, about 25 kilometers in diameter). This whole sequence would have been completely impossible without the amazing efforts of the engine team and our lead graphics coder, Simon. I’m in awe of you guys. But with that said, Unicron isn’t the large boss that people remember from the game. When people talk about the “huge boss” in this game, they’re quite rightly remembering the Tidal Wave boss fight, which was so epically implemented by Keir. Hats off to you, too, Keir!
Trivia2: When gliding in most levels, the camera never banks to the side the way that it would in most flying games. This is because our graphics tech for drawing trees was so highly optimised that it didn’t support drawing distant trees in any orientation other than perfectly vertical on the screen. This was a source of considerable disappointment to me. (Thankfully, there were no trees on Cybertron, so I could bank the camera there).
Trivia3: In the Unicron boss fight, the player is moving so fast that the player’s flight model needed to be updated 200 times per frame, just to keep from exploding due to the magnitude of the forces involved. Luckily, there wasn’t much game logic going on in that level, so the PS2 had plenty of CPU time available for updating the flight model so many times each frame.
Trivia4: Transformers used a technique we called “betwixt”, to make everything appear to be rendering at 60fps, while the game was only actually drawing 30 times per second. In effect, we were taking advantage of the common interlaced television signals of the day; televisions would first update half their scanlines, and then 16 milliseconds later, they’d update the other half of the screen’s scanlines. So when we drew, we’d draw half the scanlines as “16 milliseconds ago”, and the other half as “now”, and the television itself would automatically handle displaying those graphics at the right times. Sadly, now that everything has gone to progressive scan (that is, all screen scanlines get updated every frame), this sort of trick won’t work for modern games.
Trivia5: Transformers was our first game to include anamorphic widescreen support. It contained widescreen support because I had just purchased an extremely expensive widescreen television, and came in on the weekend to add support for it.
Trivia6: The related Penny-Arcade strip.
After Transformers, we started work on a sequel, imaginatively entitled “Transformers 2”. However, it wasn’t many months before we were informed that Atari had sold the game rights to someone else for a surprisingly large amount of money, and then shortly afterward we learned that Michael Bay was making a related film (which explained why the someone else had been willing to pay so much for the game rights). So with Transformers 2 gone, we were eventually given a game to do: “The Big One”. Not much to say about that one, except that we spent an awful lot of time and effort on it, developing lots of complicated technology and lengthy and intricate storylines, but never quite finding the game amidst all the technology. This game was eventually cancelled.
We were then tapped to make PS2 and PSP ports of Eden Games’ Test Drive Unlimited. Now, Melbourne House had long been known as a studio which made well-regarded racing games. I had never worked on one of them (and so I haven’t mentioned them in this post), but that’s just because I’m not really a racing game player, so always ended up working on the character-based games instead. But in this case, it was the only thing going on. The big fancy new features in “Test Drive Unlimited” on the XBox 360 were (a) open-world racing, instead of having pre-defined circuits, and (b) freeform networking where you would dynamically be paired up with other nearby players as you drove around. “A” has now become a fairly standard feature in racing games. “B” is still unique. When we started on this project, since I wasn’t really interested in racing game mechanics, I pushed for us to keep the networking features of the 360 build, and I (together with Ross) ended up being the networking team for the game, with me focusing primarily on servers and generic networking, and Ross primarily focused on the myriad PSP issues (including supporting ad-hoc server-less networking).
Trivia: The PS2 and PSP Test Drive Unlimited servers are still running, with a daily maximum of about 80 simultaneous users. Technically, I’m probably not supposed to know this. But they never removed my admin access to the servers when Atari took over responsibility for running them. In fact, even after Atari sold us to Krome (spoiler), I would still occasionally receive requests to check that the servers had come up successfully after a reboot.
Trivia2: Our servers logged a lot of interesting data. For me, the most fascinating data concerned the frequency with which people chose different starting cars. In the UI, players were presented with five possible cars to rent. Their cursor started on the leftmost car, and they could scroll to the right to select any of the other cars. In practice, twice as many people chose the first car as chose the car to its right. And twice as many people chose that second car as chose the third car. And so on, through the whole list. The further away the car was from the initially highlighted option, the less frequently people would choose it. Conjecture: This is why World of Warcraft, when asking you to pick a class, starts without any class selected, and without putting them in a list that you have to increment through.
Near the end of Test Drive Unlimited, we learned that Atari was in some financial trouble (sensing the pattern, here?), and wanted to either sell off our development studio, or else close us down. As it happens, we were rescued by long-time Aussie developer
Krome Studios
At one of our first visits with Krome Studios’ CEO, he asked if any of us had interest in working with this new console that was coming out, the Wii (or the “Revolution”, as we knew it then). We’d all already heard that it wasn’t a stunningly powerful machine, but it had this fancy accelerometer-based input device. I was the only one to put up my hand; most of the other tech-folks were more interested in getting their hands on the powerful hardware in the upcoming XBox 360 and PS3 consoles. As I’ve mentioned before, we had some really smart tech people who really wanted to get a chance to flex their muscles with a little more processing power. Whereas I was mostly concerned with on-screen motion and interpreting controls, and the Wii’s unusual control scheme was fascinating to me. And as a result, I was the one who was tapped to port “Star Wars: The Force Unleashed” from the PS2 to the Wii, and I was the first to get to try my hand at writing gesture recognition for swinging a lightsaber.
After a week arranging an initial port of the first level (very similar to the shipped version of the “TIE Fighter Construction Yard” level in the retail game), I was shipped off to San Francisco to meet up with our CEO and to pitch to LucasArts to let us do a Wii port of the game, in addition to the PS2 and PSP versions that Krome was already making. Now, the Wii was still generally unknown at this time, outside of the gaming industry. What’s more, Nintendo’s Wii development kit does not look like retail hardware; it’s a big black box with all sorts of exposed electronics, and a cheap-looking sticker labelled “Property of Nintendo”. So imagine if you will, what it would be like to take this ominous black box into the USA past the TSA and through international customs. The process wasn’t as bad as I had feared, luckily. I made it through customs without too much trouble (I was lucky enough to get a customs inspector who was a gamer, and so was fascinated to see a real development kit), and I spent the night refining the port in the hotel, coding on a laptop and with the Wii development kit hooked up to the hotel room’s television. And with the sound turned down low-low, so the neighbours wouldn’t hear me reflecting laser blasts.
Walking through LucasArts’ buildings at the Presidio in San Francisco was scary. Imposing. The design of the buildings’ interiors had clearly been inspired by Star Destroyers; they have the same sense of immense scale, although nicer carpeting. And there are beautiful (and huge) concept art paintings mounted all along the walls. But the most frightening moment came at the end of our pitch, when LucasArts’ very imposing director of development looked past my CEO and straight into my eyes, to ask if I personally was certain that we could complete the game within the time limit. I said that I was certain, yes. And I went to the bathroom, later.
I was made Lead Programmer for the Wii version of Force Unleashed (I think I was credited as “Lead Programmer (Melbourne)”), and that was my first time leading a whole development project. It was at this time that I learned that when you’re a lead programmer overseeing a group of six or more other programmers, that you don’t actually have time to write any code yourself; all your time is spent managing the other programmers. As a result of being unable to find time to code at work, I started this blog and started writing the VectorStorm engine, just to keep my programming skills up in my spare time.
Trivia: I wasn’t initially supposed to be the one to pitch the Force Unleashed port to LucasArts — it was supposed to be the company’s Creative Director doing that. But some sort of problem cropped up at the last minute (something to do with passports, I believe), and so as the project’s producer was casting about to try to figure out who they could send to do the pitch, I casually pointed out that as a US citizen, I have a passport and didn’t need a visa. Two days later, I was in business class seats, flying to San Francisco.
Trivia2: When I had a quick tour of LucasArts’ facilities, I quickly noticed that every single screen in the place was widescreen (which in retrospect should have been obvious). The most important modification I made to the port in my hotel room was to change the build to run in anamorphic widescreen by default, instead of needing to switch it after starting up. That’s not something you want to need to do during a pitch! (And that I had done this work at night in my hotel room apparently impressed the CEO a lot. It’s always good to be known and liked by the CEO!)
Trivia3: Despite being the lead programmer on the game, I’ve never actually played all the way through the Wii version of Force Unleashed. I’ve properly played the first several levels, and the last several levels, but there’s a big chunk in the middle that I’ve never played through normally, watching the cutscenes and actually progressing without using debugging aids. I’ll play it someday. Just.. I’m not ready, yet. It’s too soon.
Trivia4: We pitched to Nintendo about making a “lightsaber” handgrip to clip around the Wii Remote. We even prototyped one ourselves. Nintendo wasn’t interested; they were highly concerned about the recent reports of people causing TV damage by losing their grip on the Wii Remote, and didn’t want to even consider putting the Wii Remote inside another potentially failure-prone device for a game which involved swinging. In the end, it didn’t really matter; a third-party released a lightsaber grip, instead. And I believe that I saw an official one from Nintendo in the shops last week, for Force Unleashed 2. Regardless, the ones in the shop are heavy and imbalanced, and actually make it much more difficult to swing the Wii Remote accurately, due to the weight of the illuminated blade. Our prototype (which was only a grip) was much nicer to use, in my opinion, as it kept the remote’s center of mass in the middle of the grip.
Trivia5: The Wii version’s lightsaber attacks actually do about three times as much damage as in the PS2 version, to compensate for the extra effort required to swing your arm. (I got yelled at for making this change without involving the design department; only having checked it with QA and Production. I was used to working on projects with minimal designer support, and on Force Unleashed we had designers who wanted to stay intimately involved in these sorts of decisions. I absolutely deserved to be yelled at over this one. As it turned out, though, the designers did like the change as well, and it stayed in. And I learned a valuable lesson about including designers in discussions about design.)
Trivia6: The title animation that displays in the Wii channels screen when you insert the Force Unleashed disc was designed and put together by me, as a placeholder very early on in development, to demonstrate to LucasArts the sorts of possibilities that were available in that space. I never intended for it to be the real one that went out with the final retail discs, but nobody ever seemed interested in replacing it. I think I made some of our sound people cry, when I told them that I wanted the first dozen notes of the Imperial March compressed down to fit into an 8kb mono sound file for this purpose. Sacrilege.
Trivia7: My favourite thing in this game is the 3D lightsaber cursor that I implemented for interacting with the menus, instead of the usual 2D cursors used by most Wii titles. It was difficult to get people to agree to let me do this, but it was totally worth it. I regret that I never had time to implement interaction between the Player 1 and Player 2 lightsaber cursors.
Trivia8: I can’t tell you how soul-crushing it is to have Zero Punctuation cover your game. Largely because I can’t disagree with almost anything that was said.
Trivia9: During this time I also wrote the initial implementation of camera behaviour for the racing sequences in Viva Pinata: Party Animals. My initial implementation was substantially modified and improved upon by others later on in that project, but I still was listed in the credits. Thanks, guys! :)
Trivia10: Force Unleashed contained the worst single bug I’ve ever had to track down. It was a crash which would only occur if you played through the whole game up to a particular cutscene in the Nar Shaddaa level on a retail kit, playing from a real burnt EU game disc (not a North America disc), all in a single sitting, only if you were playing in German. It took about eight hours of intense scouring (and a lot of help from our heroic QA department!) to find the uninitialised memory bug which caused that crash.
Trivia11: We prepared an altered version of the Wii Remote Safety Guidelines screens that are displayed at the start of every Wii game which uses motion controls. You know the ones; the ones which show the silhouette of a guy knocking over vases and hurting his friends with his wild, uncontrolled flailing, with explanatory text advising you not to do that. Our modification was to exchange the generic guy’s silhouette with that of Darth Vader, with a red lightsaber blade extending from his Wii remote. I sent these altered images to Nintendo to get their approval, even though I was pretty certain that (since they were legal screens) they wouldn’t let us doctor them in any way. Usually when we asked Nintendo questions about this sort of thing, we would hear answers back within about eight hours or so. In this case, we didn’t get a reply for nearly two weeks. The reply eventually came from the head of Nintendo’s approvals team; apparently our question had been escalated up through every layer of management, with each person saying “I don’t think we can let them do this, but I don’t want to reject this”, and forwarding it up to their boss. In the end, they wouldn’t let us use it. But everyone liked the idea. Oh well.
Shortly after Force Unleashed (and my lengthy vacation after that), I was brought over onto a new Transformers game, this one to coincide with the second Michael Bay Transformers movie: Revenge of the Fallen. Or Return of the Fallen. I can never remember that subtitle. Anyhow, we were doing the Wii and PS2 versions of the game, and I was initially set to be Lead Programmer on that, but after some disagreements regarding scheduling and project scope, I stepped down from that position and took care of the game’s UI, instead. I also designed and implemented (and created about twenty levels for) the lockpicking minigame. And they even gave me a design credit for that! :)
Trivia: This Transformers game is probably the only Transformers game ever made where there is no “transform” button. You don’t want to know about the fights and bitter feelings within the team caused by this intentional omission. (correction: As Liam has pointed out, two secondary game modes did have a “transform” button. Only the primary game mode was missing it.)
Trivia2: The original plan was to provide a whole set of lockpicking minigame levels as a special “extra” game mode. But in the end, the time it would have taken to build a GUI for selecting levels and comparing high scores was just too much for an already tightly-scheduled game.
Trivia3: If work had rejected my design for the lockpicking minigame, I was fully prepared to ask for permission to turn it into a “Game in a Week” to be released for free on this site. Happily, though (or sadly, depending upon your point of view), they seemed to like the game. :)
Trivia4: Originally, each of the lockpicking minigame levels had a level name and a caption. Usually these were puns which only made sense to me, or in-jokes or literary references which also only made sense to me. And in the end, the names and captions were removed because they made the minigames feel too “gamey”. But all of my original levels are still in the game. For those who have played the game (anyone?), notable named levels include the one shaped like a sailboat under a starry sky (title: “And a star to steer her by”, caption: “Straight on ’till morning”), and the one composed entirely of north-south strips of floor tiles (title: “Vertical slice”, caption: “It’s like a cake!”). If you squint a bit, one of the level layouts looks a very little bit like a Decepticon logo. That one was originally titled “Programmer Art”. Later levels (created after the “no text” policy) were mostly created by our designers, and were more abstract, more intricate, more tricky, had more possible solutions, and were never given names.
After Transformers, I took an extended vacation. I put in for a full year off work, but ended up buying a car and returning after only (only!) four months off. That’s four months with pay, mind you. Did I mention that I had accrued an awful lot of annual and long-service leave during my career, and that I never used it? In retrospect, I really should have used a lot more of it before the company shut down. But back to the story. When I returned from my lengthy time off, I was brought onto a game which kind of floundered for a while, before being pulled off to work with the engine team for a while, and then being pulled off of that to work on another non-game project for a few months, none of which really bears talking about. And that brings us up to this last weekend, when we learned that Krome was in financial trouble. This third time, there was nobody standing in the wings ready to swoop in, buy the development team, and let us continue on as before. This time, we actually shut down.
I’ve said before and I’ll say again that I bear no ill-will to my employers. It was my honour to work with such fantastic, talented people for well over twelve years, and I would happily work for or with any of them again. It’s tragic that the last vestige of Melbourne House has now vanished; it was a bit of living video gaming history, a development house that had been around continuously since the days when games were distributed on audio tapes, with many staff members who had been there continuously, making games, for twenty years or more. I’d been there more than ten years, and I wasn’t in the top ten of longest-serving staff.
But it’s over now, and the people who were part of Melbourne House are scattering. To other companies, to other industries, to other places.
And I suppose that it’s also time for me to stop dwelling on what has been, and is no more. Time instead for me to look forward and begin asking myself: “What awesome things might I be a part of, next?”
Postscript
On the topic of “Kill Doctor Lucky,” as pictured on my mug. Kill Doctor Lucky is a traditional board game made by James Ernest’s Cheapass Games. The idea behind Cheapass Games was that much of the cost associated with traditional games is in the cost of generic components. For example, every board game you’ve ever bought has come with its own dice, even though you probably already own dozens of your own dice. Cheapass Games made games and would send them to you in little paper envelopes (or later, very thin cardboard boxes), only including the rules and any custom cards required. Dice, pencils, pads of paper, tokens, and any other required bits, they’d just expect you to already own and re-use (or they would sell to you separately, if you preferred). Cheapass Games usually sold their games for about $4-$8, depending upon their complexity and production costs. Or if you were like me, you just pre-paid with a subscription; you’d say “Here, have $60, and just send me everything new you make, and deduct it from that credit as you go.” They’d release one or two new games every month. I’d basically ignore their web site, and just magically receive a new game every once in a while, like unexpected little gifts. Many years back, when Mr. Ernest stopped designing games for Cheapass Games, he shut down the subscription service, and refunded any balance that people still had remaining in their account.
I keep wondering whether that sort of system would work for computer games. Prepay a certain amount, and automatically receive copies of all the new games, with money being pulled out of that account to pay for them as they’re released. I imagine that you’d need to have games coming out at least once per month in order for it to work. But it’s an interesting thought.
Anyhow, I still have my subscription refund check for $26.65 sitting on my shelf, Mr. Ernest. It’s been there since 2006. And no, I’m not cashing that sucker; someday you’ll start Cheapass Games back up again, and I’ll be there, waiting. Oh yes, I’ll be waiting. :)
