Interview: Jeff Vavasour Feature - The Next Level

Interview: Jeff Vavasour

Bringing yesterday's classics to modern platforms isn't as easy as it would seem.

Article by Ken Horowitz (Email)
March 20th 2006, 04:00AM
 

Since 1994, Jeff Vavasour has been breathing new life into arcade classics through his work with Digital Eclipse. His work has appeared on just about every console of the previous two hardware generations, and you probably haven’t played a retro collection in the past decade that he hasn’t been a part of. Nowadays, he’s lending his expertise to Xbox Live Arcade, where many of the classics we’ve grown up with are making a big splash once more.

Recently, Mr. Vavasour sat down with GotNext and shared some of his experiences in keeping the heritage of video games in the public eye, a job that’s not as easy as some would think.


 

GN: Which was your favorite collection to work on?

Jeff Vavasour: That's a difficult question to answer. I'm really a fan of many different games from many different publishers. So, from the point of view of bringing back a favorite, it's hard to choose.

From a technical perspective, I did enjoy the opportunity to push things a bit with Atari Anthology. Not only does it have the classic games intact, but it also expands on them a bit with new challenge modes, and the like. It was fun to be able to think up new play modes to complement the classic game play. In that regard, I think the Midway games on Xbox 360 Live Arcade took the same concept and pushed it even further forward.

GN: Did any of the compilations prove more difficult than others?

Jeff Vavasour: With emulation, difficulty is largely a factor of how much more powerful the target platform is (or isn't) compared to the original platform. So, for example, when we contemplated doing some of the '90s games on the PSP, such as the Mortal Kombat series, that posed some unique challenges.

But, likewise, these challenges have come up through the history of our emulation, all the way back to trying to get Joust running at a decent speed under Windows 3.1 on 20MHz systems in 1994.

GN: Who has the say in what extras (art galleries, special modes, etc.) are included in each collection?

Jeff Vavasour: That varies from publisher to publisher, and depends on their inclination and budget. For example, in Atari Anthology and its predecessors, we were asked to put together a multimedia component, but were given free reign for its content. The only restriction there was that what we included had to be cleared by their legal department. (Unfortunately, that meant we couldn't include a classic Atari TV commercial, for example, since they weren't able to confirm that the actors' releases covered such use).

In the case of the first compilation for Midway Home Entertainment (then known as Williams Entertainment) in 1994, we came up with the idea of doing the supplement and the video interviews, which set the standard. For Arcade Party Pak back in 1999, it was Midway's idea to fly our team, their production group, a camera crew, and a host of interviewees to Chicago for an all-day interview event. For the more recent PSP compilation, how ever, the choice was made not to put multimedia in.

GN: Some collections occasionally aren't 100% spot on, as was evident with Sega's Smash Pack for the Dreamcast. Why isn't it possible to get arcade-perfect ports every time, given the power of today's consoles? Is it a hardware issue or a programming one?

Jeff Vavasour: I can't speak specifically of other compilations, so I'll answer the question in general.

First, the reason we prefer to use emulation is that it helps greatly with the accuracy. There are subtleties in the original game code that give it the character it has. Some game play strategy turns out to be a bug. In Robotron, the Brains all go after Mikey in Level 5 because of a level initialization bug. In Defender, the Smart Bomb may not detonate everything on-screen if the explosion buffers are full. Games used to slow down in the arcade, sometimes, due to strain of the original processors. All of this affects game play balance. If you're trying to reproduce the game as a port, how accurate game play feels is a factor of how good the port's programmers' attention to detail is. While the consoles might be powerful enough to do the job, it won't do the job if it's not coded correctly.

In emulation, one is reproducing the hardware rather than the software. With the timing and the processor accurately reproduced, the game will run exactly as it did. So, the first and most obvious discrepancies occur when emulation is not used. It can get even worse if the original source code is not available in a port. People have to play the games, note behavior, and try to reproduce the end result rather than the process that gets it there. This is a process prone to oversight.

In emulation, it can break down, too, though. Usually, if you have an error in emulation, it manifests as something egregious. Implement a CPU instruction incorrectly, and scores might turn into nonsense. Still, subtle problems can occur. I've seen freeware emulators that fail to pick up on some subtleties of the custom blitter in the Midway games. The fewer games that make use of a hardware configuration or feature, the harder it is to debug it, since you have fewer opportunities for robust testing.

One other way it can break down is, in our case, if we're trying to get an emulator going on a platform that doesn't quite have the horsepower. As a rough rule of thumb, your target platform needs to be at least 10 xs more powerful than the original to support the overhead of emulation. When you don't have that, you have to make changes to the emulator that customizes it more for the context of the game being emulated. That can lead to special case code, again. And, as I said, special case code is more susceptible to subtle error.

One last problem can be insurmountable hardware limitations. For example, in the emulation of the Mortal Kombat series on the PSP, there is not enough RAM in the PSP to support the emulator and all of Mortal Kombat's assets. So, those assets need to be streamed off the UMD dynamically. But, a UMD can only read one thing at a time, so if you're streaming a character map or a sound effect, you can't be playing the music at the same time. True, we could have reproduced the music by other means, but then it wouldn't have sounded as accurate. We decided the occasional interruption of music was the lesser of two evils compared to a lesser accurate rendition of the music that wouldn't require streaming.


1 2 > last ›

displaying x-y of z total