A Game Dev’s Story, Part X: Racing Along

Posted by Rampant Coyote on April 25, 2012

We were all pretty exhausted by the time Twisted Metal and Warhawk shipped. Singletrac had a pretty liberal vacation policy, but few had been able to take advantage of it because we were all working 70 hour work-weeks. But we had two more games scheduled for release in less than a year, so we couldn’t rest for too long. But November and December saw people taking vacations and working shorter weeks. It was a good chance to rejuvenate.

Early design work on Twisted Metal II and Jet Moto had already begun. I had been involved in both meetings, but as we went from design to production, I found myself assigned mostly full-time to Jet Moto.  The weapon and AI code I’d developed stayed in the Twisted Metal sequel (except for the hover-cops… we’d decided to get rid of those for future games. I don’t know if many people missed ’em), and I felt I’d written a pretty good general foundation for others to build on.

For Jet Moto, we had some early troubles. I was assigned to do AI coding, and some general game logic for the race. The lead art guy had a very different vision of the game from the designers, however, and our ‘test track’ that we were using as the basis for developing the game (the all-important prototype) was radically different in style from what was expected. The rest of the team raised the red flag, wondering if we were making a game about how-speed hover-bike racing – more like Wipeout – or more like Motocross racing. Or both. I guess with both “Jet” and “Moto” in the name, it implied both. After a short but highly heated debate, the art team was re-directed to making the more technical tracks than the high-speed arena-style tracks.

Another issue we were running into was the floating point performance on the Playstation – or rather, the lack thereof. The lead programmer had done some work for his PhD (? I think?) on particle systems for physics. Not the same as visual particles you see in games, these were spring systems simulating the ‘mass’ and composition of an object with a system of heavy particles. Anyway, the calculations were intense, but it was a decent way to get some very believable physics out of low-end machines. And that’s what went into making the bikes. But that was a very intensive project, and during the first couple of months there wasn’t much to show for it or any way of really knowing how the bikes would behave when completed.

We watched a lot of videos of motocross racing, bike stunts, and the team even went to a supercross competition in Salt Lake (I missed that one, though).  I learned to appreciate the sport a bit. Even though the game was obviously pure fantasy, we felt it was important that we did the research and captured the feel and as many real-world details of actual related sports as possible. And of course, we played racing games – everything from the hard-core simulators by Papyrus, to arcade and console classics like Ridge Racer,  Mario Cart, Daytona USA, Wipeout, ExciteBike, Super Off-Road, and anything else we could get our hands on.  From those we tried to capture the conventions of racing games as best as possible, and also understand what they did to really make their games fun. And a couple of the people on the time actually did race motorcycles, which helped a lot.

As an aside, during the Christmas break, I threw together a little 3D space combat game. Just for grins. It was in DOS, using my own custom rasterization and 3D engine. I got the very basics of the game put together, with a planet and space-station, and three ships that would chase you and try to shoot you (although they’d mostly try to ram you). It didn’t look like much, and the program was lost a year or so later in a hard drive crash. But the experience – how much I was able to do in a week – was the seed of the idea that eventually became Void War, many years later.

After the Christmas break, it was back to full-on crunch mode. For me, it was just as rough as with the first games. I pretty much had a Mission Impossible thing going on. Besides doing the AI, I also had to write my own – vastly simplified – physics and collision system that somehow mirrored the work-in-progress for the player bikes. Because of the horrible floating-point performance on the Playstation, the processor simply could not handle more than about three of these physically accurate bikes in the game.  We were supposed to have twenty.

So basically, I had to get nineteen bikes all doing full physics, collision detection, and AI working in fewer milliseconds than two of the full player bikes with physics. And I was trying to simulate a moving target, as the behavior of the player bike was still a little bit in flux for several weeks. And my preliminary stab at it had been on a wide-open track that had been originally made for the game, not the more intense, bumpy, obstacle-and-tight-turn filled tracks that eventually made it into the game.

So if you ever played Jet Moto 1 and thought that the AI bikes weren’t playing quite by the same rules as the player – well, you were right. They weren’t. I spent a lot of time trying to get the bikes approximating player performance and movement in less than 1/10th of the time (including collision detection *and* AI calculations).  And they all had to mimic the characteristics of not just a generic bike, but their specific bikes – and come in at times more or less equivalent to what a human player of appropriate skill could achieve. For the sequel, they dropped the total number of bikes down to 10, and vastly improved the performance of the bike physics, which allowed the AI to play exactly as the player. But in the first game, we didn’t have that luxury.

There are some other bits of trivia about Jet Moto that I’ve written about before. And I wrote recently about an AI experiment I performed with genetic algorithms.

We worked on deals to get ‘real’ product advertisements appearing on the billboards in the game. I guess we all thought that real-world products would make the the game more realistic. The best deal we got, IMO, was with Nestle – which used a cross-promotion with their Butterfinger bars to promote Jet Moto. I think it worked out pretty good. Personally, I got a free candy bar out of the deal. So that was cool.

Since we had departed so far from traditional racing game “style” – in the direction more of a science-fiction ‘simulation’ of a racing game with a really weird way of controlling the vehicles – the initial reviews were a seriously mixed bag. Some were glowing, others savaged it. But over time, the game proved to have legs and it really grew on people, and turned into a slow-burn hit game. One magazine that totally ripped it to pieces later wrote a glowing review of the sequel, saying that it “manages to capture the magic of the original.” I always thought, “What, the magic that was worth 1.5 out of 5?”

The bottom line was – we did something really different, and focused on over-the-top fun. It paid off in the long run, though it met with some definite “WTF?” resistance at first. That’s the problem when you innovate – especially when you try to innovate and shake things up in a well-established genre. But our emphasis on fun was what saved the title and eventually made it a hit. There were a whole lot of ideas that ended up getting dropped in the game because we just couldn’t make them fun, or figure out how to make them controllable, or they didn’t serve the core ‘fun factors’ of the game. There were lots of ideas for things like weapons a la Wipeout and Mario Cart, and a bunch of ideas for using the magnetic grapple as a weapon. But in the end, it was about over-the-top environments, high speed, big air, and a massive concentration of AI bikes. And that feeling of being just barely in control, but always able to do just a little bit better and shave another second off your time.

Some things I learned from that experience:

#1 – The importance of research – not only for the designers, but also for the entire team, so they know a bit about what they are making. The research should include competitive games, but absolutely must not be limited to games. There are a lot of fascinating details in real life and history that can not only make a game come alive or provide good backgrounds or level ideas, but can be the source of really inspiring game mechanics.

#2 – You need a “keeper of the vision” – usually the lead designer – to really keep an eye on everything that’s going on and make sure that the development isn’t deviating (or deviating badly… some deviations are great) from the core concept. This is especially important in the early stages of development, when whatever is being done will probably end up being foundational.

#3 – Innovation by itself isn’t often immediately appreciated. It generally has to grow on people. The initial reaction is often, “WTF? Why did you screw with this?”

#4 – Always focus on your core ‘fun factor.’ A lot of ideas may very well enhance that core or add some variety to keep the core gameplay interesting, but a lot of ideas – in fact most of them – may pull attention away from it or undermine it. In Jet Moto, we were either lucky or smart enough to cut out most of the ideas we had that sounded cool but ultimately would have detracted from that core.

Filed Under: A Game Dev's Story - Comments: 3 Comments to Read



top