Diary of a Game
Power Drift: The Butler does it again!
Once again Activision have jumped into the licensing business in a big way in preparation the Second Coin-op Conversion War this Christmas. The big gun in Activision's arsenal this time around is the mammoth Sega coin-op, Power Drift. Robin Hogg takes a look at how programmer Chris Butler is set to 'achieve the impossible'.
Following the massive success of Out Run and Afterburner in the arcades even Sega jumped onto their own bandwagon in 1988 to create the ultimate rough-ride racing game. Power Drift combined all the graphic techniques and sheer speed that Sega could muster for one rollercoaster of a ride which dominated the arcade scene. For the 64 version Activision signed up one of the most accomplished coin-op converters around: veteran programmer Chris (Ghosts 'n' Goblins, 720°, Space Harrier, Thunder Blade, Commando) Butler.
How on earth did you get involved in tackling the 64 conversion of this monster coin-op?
Well, at the time. around early '89 I was engaged in freelance work for US Gold. I'd finished Thunder Blade and was being offered Ghouls 'n' Ghosts when the software manager for US Gold, Charles Cecil, suddenly left to join Activision, poaching me in the process. The license for Power Drift surfaced soon after - I wanted a big title to work on and it was all that was available. Thus in February I was given the task - the end of September being the deadline with a penalty clause written in of £250 lost for every week it over-runs.
When you first went about tackling the game what were your priorities? Something would have to be thrown out from the start, but what? Don't you feel it's pushing it possibly too far?
Well the slanting road effect as the car skids round corners has had to go, it all depends on memory which is as ever very tight indeed. If I've got the memory then it will go in. I like to tackle the Sega coin-ops head on, to my mind there's no other way about it. I've always believed that if anything's possible then it's worth having a go. Although I have to compromise almost all the time with my games, deciding what can and can't be done, I always try to capture what it is about the subject matter that attracts the gameplayer.
And this is multi-load, right?
No, no. [My jaw drops upon hearing this]. I've weighed up the pros and cons of it all and I wanted it to be fast paced and easy to get into which always points to a single load. Why should I write fast games where the player has to wait for the multiload? It's even better appreciated if you can squeeze the game into one load. Trying to work in the restrictive memory of 64K has been hard: I've run out of memory quite a few times but at least I've had a lot of practice.
How is the game being structured (without giving away any trade secrets)?
At this moment it's made up of 32K of graphic code including all the track data, bends, length of straights, position of hills and so on.
After this comes 20K of actual code and after that comes 6K odd of music. I don't do the music myself but give a set amount of memory to Dave Lowe who's done sterling work for Activision. I've already had to cut down his allocation but he seems happy enough with 6K. He's concentrating on one main theme to capture the spirit of the game. A summer theme? Yes, probably. Although I haven't heard anything yet.
After all this I have around 1K to 3K for emergency backup purposes - sorting out colour buffers, handling screen memory and so on. This memory allocation is all rather flexible but at the moment it's basically a case tidying up of code.
For development I use an old Amstrad PCW using Word Star to edit the source files. Code assembly is performed using Avaset X-ASM and luckily takes no more than a few minutes as the code is downloaded from the PCW. I have my own customised graphics designer which can scroll backgrounds as well and create very large multiplexed sprites.
Graphics have always been important in Sega games - when it comes to the conversion have they been first priority or has it been gameplay?
The graphics came first with the track routines following. The gameplay is usually the last thing to go in and is very easy to implement, change the speed of a car here, the gravity of a bend there - no problem.
It's not been a problem either to incorporate the spinning car effect (when the car hits an object and spins off the road) - it's cheating really but I simply shift characters left or right depending on the direction of spin.
The graphics are made up of 230 images based around 23 objects. The main sprite of your car and the rival cars takes up 16 of those 200 odd images and incorporates the distant cars and the positions of turning cars, climbing cars and the like.
I was meaning to spend two to three weeks on the graphics but it turned out to be six weeks.
What was the toughest part of the conversion? Many late nights?
To answering the second question first. Well, yes there's plenty of the old 'burning of the midnight oil' as most of my time programming is at odd hours - a mid-day wake and afternoon just doing general things is followed by a late night session from around 8pm through to about 3am.
There's been one late night till 7am session which involved getting the clouds of smoke on the wheels of the car just right but otherwise it's been fairly straightforward coding.
The main problem (the lack of memory aside) is the track; getting it to move correctly, curve smoothly and creating the ride-over effect of the hills. Yes, as in the coin-op the car doesn't move. instead the road moves to either side.
Trying to keep the side graphics parallel to the road edges has been a task as well. I'm storing the track shapes in memory with individual track curves and hills all in there - a 3-D line routine is applied to the shapes to create the 3-D effect.
Gaps have appeared at the edges of the screen and I've filled these in with set character blocks. The speed of it all hasn't been a problem as the sprites are tracked in character mode. Certain objects come past perpendicular to the road, like the bridges. It's a bit of a cheat but it works.
The actual illusion of movement and track algorithms have turned out better than I thought. I've copied the arcade method but the Sega programmers are very lucky as all the hard work has been done for them already. Overall I'm pleased with the result.
You've obviously drawn on past experience for this conversion.
One of the major criticisms of previous games like Thunder Blade has been the wobble of the oncoming 3-D graphics and I've gone out of my way to eliminate that problem.
Other problems that have been corrected have been the half-on sprites of Space Harrier which was basically printing a character block on screen and just flashing it past.
I've used a high level of interrupts in Power Drift to keep speed up and get around the problem of it not being a sequential game like Thunder Blade - after all you can choose any course you want which makes my preplanning difficult.
The techniques in use now are nearing perfection and are about the most efficient I can get on the 64 now. It's approaching the limits but then again they've always said that.
Have you been following the coin-op and computer scene recently? Make us sick and tell us whether you had the Power Drift machine for 'research' purposes.
No, I don't often get the chance to visit the arcades. When visiting my parents in Southend, which is an arcade player's paradise, I do see them then. I find Capcom's Strider very impressive and the programming techniques behind Hard Drivin' are excellent although the game itself can be tedious. I did have the Power Drift machine for around four months but that's gone onto another developer.
Are YOU interested in 16-bit?
It's all a matter of finding the time. I like the 3D polygon effects of 16-bit programs nowadays but again I don't have the time to buy (and play) games. I've worked with the 64 for quite a few years, learnt a lot with it and there's a good few years of 64 games to come. Yes, 16-bit is interesting but there's life in the old dog yet.
Five years on, has it all been worth it?
Undoubtedly. I still love writing games; it's a boy's dream after all, and me straight out of school. A dream career even if I'm not incredibly wealthy.
I'm now committed to buying a house and settling down. I don't intend to be writing games when I'm 50 but it's been worth every moment.
This interview was originally published in Zzap issue 54 (October 1989) on pages 24-25. Power Drift received a rating of 94% (and a Sizzler award) when reviewed the following month in Zzap issue 55 (November 1989) on pages 68-69.
Starting out creating graphics for early pioneer Steve Bak, Chris moved into programming games and went on to create one of the Amiga's flagship characters - James Pond.
Well known for his slick Amiga games Midnight Resistance and RoboCop 2, Ian Moran worked at Special FX from mid 1989 until 1992 when he was one of 5 founding members that formed Rage software.
John was one half of the formidable Random Access/Sales Curve programming team that worked on some of the Amiga's most fondly remembered games. John worked on Silkworm, Ninja Warriors, SWIV, Rodland, Saint Dragon and Indy Heat.
Copy protection expert and creator of the copylock, Rob Northen's system was the primary measure to prevent casual software copying for around 500 commercial Amiga games, the majority of which were protected between 1989 and 1992.
The programming legend responsible for the superb games Silkworm, Ninja Warriors, SWIV, Rodland and Q-Bic, Ron answers a plethora of technical questions about his games.