Interview: Kevin Seghetti (2013-03-08) by Sega-16

This is an unaltered copy of an interview of Kevin Seghetti, for use as a primary source on Sega Retro. Please do not edit the contents below. Language: English Original source: Sega-16

The early years of the Genesis’ lifespan was characterized by a build up of internal resources by Sega, along with an aggressive campaign to sign up third party companies to make games for the fledgling platform. Razorsoft was one of the first to join the line up, and it debuted on the console with two highly controversial titles, TechnoCop and Stormlord.

Programmer Kevin Seghetti worked on both games, as a freelancer contracted to the Razorsoft-owned company Punk Development. From a quick start as a software engineer at Spectrum Holobyte, where he was part of the team that made Monopoly for the Master System (the first American-made Sega game), he also worked on the 8-bit Sega version of Rampart and Pigskin Footbrawl for the Genesis. Eventually, he moved on to form his own group, Developer Resources, which created game resources for both the Genesis and the SNES. He later worked for another company called Alexandria, where he programmed Sylvester & Tweety in Cagey Capers, and then started another firm called Cave Logic. Currently, Seghetti is a freelance contractor.

Mr. Seghetti was kind enough to chat with us about his time working on Genesis games.

Sega-16: You worked on Monopoly for the Sega Master System, the first  American-made game for the console. As no other Sega game had been developed in the U.S., this was a major step for the company. Did you feel like there was a chance to make a statement or that there was a lot at stake?

Kevin Seghetti: I was under the impression Sega considered it a trial run to see if American developers could do it. If I recall correctly, they weren’t getting the sales they wanted on American licensed content, and thought the problem was Japanese programmers didn’t capture the American aesthetic.

I was not on the Monopoly project when it started. There is some irony here, in that Sega hired Nexa to do the port. Nexa was founded by Gilman Louie, an Indonesian, and the team working on Monopoly were Chinese. So they weren’t really getting American programmers with their test. (I think what got them the contract was that Gilman had written 3D fighting Falcon on the MSX, a Japanese computer, and the Master System was based on an MSX).

Monopoly was my first entry into video game programming (really my first programming job). It was a project with a six month deadline. I was brought in when the project was three months in, and had little to show for it. Myself and a friend of mine (Scott Statton) were hired to save the project. From that point it took us about six months to complete the game (Sega was informed when we started, so they knew what was going on, and were pretty happy with the project we quickly began to show).

So for me, it was more about proving myself as a programmer, than proving the U.S.

Sega-16: You worked on both PC and console and were involved with several Amiga ports. What did you think of the Genesis compared to the Amiga?

Kevin Seghetti: They are very different machines. The Amiga uses a bit mapped architecture, then has some hardware support for moving data around (blitter) as well as manipulating the display (copper). It was originally designed as an arcade machine, so the design was able to set their sights higher in terms of hardware cost.

The Genesis is a second generation Master System/Sega MKIII, which was an MSX with some hardware removed. (the 68000 was a late addition to the Genesis design, it originally was just going to have the Z80). It doesn’t have a bitmap mode, it can only display character tiles. This makes it possible to rapidly update the screen, but limits what can be shown. (although it is possible to emulate copper style behavior on the Genesis using interrupts, see the spinning logo on the title screen of Batman, for an example).

So these two architectures lead to different styles of game design.

Overall I think the Amiga was a more capable machine. With careful blitter programming one could pretty much emulate a Genesis on the Amiga, but the converse was not possible (for an example, see Technocop, where the upper half of the screen during the driving scenes is being rendered as a bitmap, converted to character tiles, and uploaded to the VDP. It’s slow and looks like crap).

Sega-16: Was it capable of porting just about any game on the system or was the Amiga better in certain areas?

Kevin Seghetti: Some games would have been very difficult to do well. Stormlord was fairly easy, since it was a tile based game on the Amiga. Technocop‘s driving sequence was a rendered bitmap, so should have been re-engineered on the Genesis to better match its capabilities.

A fully 3D game on the Amiga would not have been worth porting to the Genesis. While possible, the frame rate wouldn’t be very good, and wouldn’t take advantage of the VDP well at all.

Sega-16: You spent a few years as a freelance contractor. During that time you worked on several Razorsoft games. What was it like working with the company?

Kevin Seghetti: Razorsoft was headquartered in Oklahoma. Working with Jeff Spangenberg they opened an office in Mountain View under the name Punk Development, which is where I did the Stormlord port. After Jeff & I had a falling out, I switched to working with Razorsoft directly for the tail-end of Rampart (Master System) and for all of Pigskin Footbrawl.Working with Punk was strange. I didn’t realize it at the time, but Jeff was intentionally delaying milestone submissions to make everyone else look bad. It happened to others more than me because I was always communicating with Razorsoft directly, so they knew when I said a milestone was complete. Once I broke away from Punk, Razorsoft was pretty good to work with. I did make a mistake on Pigskin; there was a penalty for failing to make the final milestone date, and in the middle of the project we made some design changes which I cautioned would extend the development time and got a verbal agreement, but not in writing. At the end I did not receive full payment because of that (short $25,000, which was about 1/4 of the entire contract). So there was some lack of honor there. (Since I had sub-contractors for art and sound, I spent the next year paying them off, since it wasn’t their fault.)

Sega-16: As one of Sega’s first third party licensees, Razorsoft saw its fair share of controversy over its first two titles, TechnoCop and Stormlord. Did this seem to be by chance, or was the company trying to make an impression early on?

Kevin Seghetti: I don’t remember any controversy over Technocop, other than it just being a lousy port. At that time, I was focusing on coding the sound driver and supporting the development system I helped design that it was being written on. So maybe there was some and I just don’t recall.The controversy I remember over Stormlord was that Razorsoft manufactured their own carts instead of paying Sega to do it. (They paid the licensing fees, just didn’t have Sega make the carts). Sega was not happy about this (I suspect much of their profit came from cart manufacturing), and a lawsuit ensured. I was long gone by the time that finished, and the settlement is sealed, so I don’t know any details, but later Razorsoft titles were manufactured by Sega. I suspect Sega didn’t want bigger fish to figure out they could make their own carts, so gave Razorsoft a deal on cart manufacturing.

Sega-16: Stormlord was a controversial title due to its fairies being covered up on the Genesis. It seems kind of silly now, but the decision to cover them up made major news back in the day. Contrary to what many people think, Sega didn’t censor the game, and the decision to dress the fairies came from RazorSoft itself. If Sega had no problem with the content, why did Razorsoft decide to make the change?

Kevin Seghetti: If I recall correctly, Razorsoft was worried about bad publicity or not getting on the shelves at the major toy stores, since the Genesis was a family platform (remember, this was before video games had ratings and during the time of the violence in video games hearings at the federal level, so developers were worried about what was going to happen).

Sega-16: Were there any other Amiga titles you would like to have ported?

Kevin Seghetti: Not specifically. As part of the Genesis libraries I released with my development system, I wrote a demo of a simple Defender-style game which I never got around to finishing.

Sega-16: You worked on software libraries for both the Genesis and SNES. Which did you prefer? Why?

Kevin Seghetti: The Genesis had the better CPU by far (the 65816 is an abomination), but the SNES has better video hardware. HDMA is very similar to Amiga copper lists, and one can do pretty cool stuff with it. I think the SNES has more potential for interesting hacks, but programming the Genesis is easier and more straightforward.

I got to actually use the development system I made more on the SNES than the Genesis (just circumstances, most of the Genesis work I did was before the development system), so I enjoyed working with my tools quite a bit when doing Ballz.

Sega-16: Tell us a bit about the real time sound driver you developed for the Genesis.

Kevin Seghetti: My goal was to turn the Genesis into a midi synthesizer that a musician could use to compose directly on the platform. I did this by connecting a nine-pin joystick cable between a joystick port on the Genesis, and a joystick port on the Amiga (or maybe it was the parallel port, not sure). Then I connected a Midi interface to the Amiga, and wrote code to listen to the midi device, and send that data over the joystick port link to the Genesis. Then on the Genesis side it would trigger the sound driver. The driver itself ran on the Z80, and manged the FM chip, as well as the DAC to do sampled playback. It parsed a custom music format I created (which looked a lot like Midi File format), ran instrument envelopes, etc.I also wrote a patch editor on the Amiga for creating FM patches. Since the Genesis uses four operator FM, we copied a lot of patches from the Yamaha FB01 (also a four operator synth). They didn’t usually work directly but required some tweaking.

Sega-16: It’s been used in several games, correct?

Kevin Seghetti: It was used in Technocop and Stormlord at least. I don’t recall if later Punk/Razorsoft games used them or not. If I recall correctly, there was some guys from England punk brought in who were porting an Amiga tracker to the Genesis, so they could have multiple channels of digital audio. (by using the 68000, my driver could only support one, since the Z80 just wasn’t quick enough to do mixing while doing everything else). I wrote the music for Technocop using this system. My friend Lars did the Stormlord music, mostly composed using his FB01, and then copying patches and tweaking them.

Sega-16: A software company called Alexandria worked on a Road Runner game that never shipped and your own project, Sylvester & Tweety in Cagey Capers, was delayed because of cash flow problems at TecMagik and had to eventually be financed by Warner Bros. Did the company ever exert any pressure to complete these projects or did it leave everything in the hands of the developers?

Kevin Seghetti: There was lots of pressure on the Road Runner team. Part of the problem was that the industry hadn’t matured enough yet to realize that programming games and designing games are separate activities. There wasn’t really a game designer for those games. There was a “producer,” who ended up doing some game design, and we had writers, who did some of the narrative, and some level design work. But there wasn’t a person or team who were directly responsible for designing the overall game. So what commonly happened was the producer would make some design decisions, the programmers would make some, the managers would come in and dictate some, and without that central authority, the RR game went all over the place.

Over the course of its development the character the player used switched from Coyote to Road Runner and back again. A fundamental problem with that license is that the Coyote can never catch the Road runner. That makes it difficult to design a game around it. If you play the Road Runner, how do we stop you from just standing still and letting the Coyote catch you? If you are the Coyote, how do we keep the game interesting when we can’t let you catch the Road Runner?So over on the S&T in Cagey Capers side, we started later, and so we were able to recognize that problem, and made sure to solve it early on. (we identified that in the cartoons Sylvester does catch Tweety from time to time. Tweety just always manages to escape afterward. So we made that our level ender: you finally catch him, and the level ends and he escapes your grasp.

Sega-16: You ported the 3D fighter Ballz from the Genesis to the SNES. Were there any major differences in the game engines, given the capabilities of the SNES?

Kevin Seghetti: We did our best to make the engines the same, even though we had to re-write it from scratch. In many circumstances there were bugs in the Genesis code that were adjusted for in the character data. So when we wrote the SNES version, the data would behave differently until we understood the Genesis bugs and added those same bugs to our version (we called this “re-bugging the code”). They didn’t want to fix those bugs and change the data; too much tweaking time had already gone into the data.

For example, in the code to throw some balls across the screen (Kronk spitting, or the clown bowling his head), it was originally written for the Kronk spit, which was just one ball. The code used a pointer into a position table to keep track of where it was in the animation. It used this pointer to calculate how far it was into the animation by subtracting the base of the animation table from that pointer. So, what happened when the clown head bowl was animated was that there were more balls in the animation table, so the pointer moved further for each animation step, and that subtraction yielded much larger numbers, which changed the timing of the animation. Since the animators didn’t know about this, they just adjusted the offsets in their data to look correct. So when I coded a correct version of that function (which would play at the same speed regardless of how many balls there were), it didn’t behave correctly for the clown head. We got the basic engine up in a couple of months, and then spent a few weeks digging into all of the places the data misbehaved.

Sega-16: How close were the two versions in terms of performance?

Kevin Seghetti: The 68000 far outperforms the 65816. The 68000 has 16 32 bit general purpose registers (eight data, eight address) and built in multiply and divide instructions. The 65816 has one 16-bit data register (A), two 16 address registers (X & Y), and no multiply instruction.There were a couple of factors in us being able to make Ballz work on the SNES:

We used the external DSP (same as in Pilot Wings) to do most of the 3D math
The Genesis code was not very efficient. It was written by Keith Kirby, who was really more of a game designer than a programmer. He coded out of necessity to get his ideas made, but never claimed to be good at it.
I believe the final frame rate between the two was about the same (pretty much had to be, since a lot of the logic was framerate based). At one point we were going to remove the Mode 7 floor since it was slowing us down (which is why the screen shots on the box don’t show a mode 7 floor), but we were able to optimize enough stuff to get it back in.

Sega-16: How did you feel about moving to optical-based platforms?

Kevin Seghetti: It changed how games were architectured. With cart-based games, one has nearly instant access to all of the data in the game. So, one can re-use elements from one level in another. One doesn’t have to worry about load times.We were excited by the prospect of more data, but we had to start considering managing load times and seek times. Actually, settle times are the killer, back then the CD actually changed the speed at which it spun as one moved across the disc, so it took a while for these speed changes to occur. This led to doing things like placing commonly accessed data in multiple places on the CD, so one could grab a nearby copy without having to change the disc speed.I have never actually shipped a CD-based game. After Ballz, we spent a few years created a 3D game engine for the Sony Playstation, with its first game to be Velocity. We designed that engine to be able to stream portions of the level as one went through it, so that worlds could appear to be far bigger than fit in memory. That engine is now open sourced as World Foundry, if anyone wants to play with a textured polygon engine which runs at decent framerates on a 33Mhz R3000. After not touching for about a decade, last month I started porting it to OpenGL ES 2.0 so it could run on smartphones, which have a similar level of compute available to them as those old consoles did.

Sega-16: How did the industry-wide transition to newer hardware affect you project-wise?

Kevin Seghetti: It meant I couldn’t really build my own development system for it. (we did consider building a CD emulator, but we never embarked on that project).

We would like to thank Mr. Seghetti for taking the time for this interview.