Sega Master System / Mark III / Game Gear
Sega8bit & SMS Power! 2013 Event - 10th August 10 weeks and 6 days from now
See the scans: STheSegaMagazine-Magazine-Issue08?gallerypage=16
Publishing office in Bath (groan)
This future sports simulation first surfaced on the 16-bit machines, the ST and Amiga, where it caused something of a storm, due to it's gorgeous graphics, fast two-player gameplay, and... erm... because it was good fun.
The game revolves around the attempts of two teams of heavily-armoured thugs to get a large metal ball into the opponent's goal. You can tackle the enemy by various methods, most of which involve hitting of some description, and then you hurl the ball around the 'pitch', bouncing it off the walls and large pinball-style bumpers.
There are power-up tokens to be collected during the game, which can then be traded for extra stamina, strength and skill, not to mention bribing the timekeeper...
Player select menu showing (from top) the finished screen, the basic character graphics and the frames of animation which run when each team is selected.
This little gem is being converted to the Sega as you read this, and the man at the keyboard is Tim Watson, who worked on the 3D graphics shell for Starglider 2 on the PC, and finished an Archimedes/PC interface before taking on the Speedball project.
"It was sort of a retrograde step back to programming the Z80 chip" confessed Tim. "I'd much rather do something with a really big machine, but it's also nice to think that your stuff's being sold worldwide. I mean, I could do a really nice game on the Archimedes and it only gets sold to three people!"
So just how do you go about programming a Sega game? Tim gave us the low-down: "All the main versions of Speedball were coded by the Bitmap Brothers, down to the PC version. I already had the PC version's source code and it was just a question of converting that to run on the Sega. I spent the first week playing Speedball quite a lot. I've also got an open phoneline to the Bitmaps - they know who I am and what I'm doing, but I haven't had an awful lot of problems.
"I began by sitting down to work out approximately how long it would take, and then started converting the code blindly. I worked first on pieces of code which didn't need any knowledge of how the Sega operates, then I started writing Sega routines that I knew I'd need; I started investigating sprites routines, sound and how to do the graphics. Then came the point where I had to put things together.
"Eventually I got to a stage where I had a screen scrolling up and down under my control - that's the most important part of the game, the scrolling screen. Then it was a case of implementing that lovely scrolling screen in with whole game, so it would automatically shunt the ball round. The game tries to keep the ball in the middle of the screen at all times, until it hits the top or bottom where the goals lie. It clips the ball's speed so it doesn't ever disappear, but I didn't actually worry about that - it was all in the ball routine. I just implemented my scroll routine with the ball routine, and most of the routines practically worked first time after I converted them.
Punchy title screen, eh?
"It hasn't been plain sailing all the way though: we have had to rescale the screen slightly because an ST screen is 320 pixels across and the Sega's is only 256, so the graphics have had to be redrawn. And since some of the intelligence works off the screen, the ball tends to go round rather quickly - on a larger screen it would have more time to slow down.
"The reason it's not quite as advanced as it should be at the moment, is because the last week or so I've been converting the game logic, and they're pretty big files - between them there's around 100K. I might have to start playing around with banking (the Z80 can only address 64 K of RAM at any one time, so you have to start switching to different banks of data, allowing the 280 to access different parts of the memory).
"I then had to do the team logic - how the team works - and then the intelligence, which is everything else. All you're doing is making every individual thing think of all the possibilities: is the ball over there? If yes, then head towards it. Is another one of my players over there, nearer the ball? Then switch control over to that player.
The individual frames of animation for the game intro sequence. Moving from top left to bottom right, the armour-clad player puts on his glove and then taps his thigh.
"You also have tackling strategies for the computer controlled players. Another player's got the ball: if he's facing away, I'll go and swipe him. There's lots of little things like that, but they're all fairly obvious when you think about them. AI (Artificial Intelligence) is thinking of all the different options, and saying which one is the most likely to occur."
So is it tough to get the computer to play a good game? Tim explains, "There are lots of different teams with different strengths and values, and the game decides certain things on how much strength and stamina each player has got. That's all done for you - you don't really have to think about what the difference between teams is, but you do have to work out a system of how it all fits together so when someone has a certain amount of stamina, their strength will deplete by a certain amount. The more stamina they have, the less their strength will deplete over a given time.
"Skill offers a value to work out who will win a tackle. There is a still a random factor, but it is biased to the player with the higher skill level. There are also built in team strategies - the computer knows how to score goals, and it can work out how to ricochet the ball off a bumper, or off a wall in an attempt to try and score."
For anyone who's interested in the techy aspect of making a Sega game. Tim explains the development set-up he uses, and how he uses it: "The Z80 chip resides in the ICE (In-Circuit Emulator) unit - the Sega alongside is basically a dead machine simply used to display and run the game. You tend to find you're developing not on the ROM/RAM board plugged into the Sega, but on the 64K on board RAM in the ICE. because it's easier, faster and you can do more debugging. You can debug the program while it's running in the ICE, but you can't when it's in the Sega's user memory.
"We've actually by chance got NTSC (American TV standard) machines, so we're doing everything to NTSC. We needed NTSC monitors, but we had to go and get some multi-standard TVs in the end. In comparison to the European version, the NTSC version will be the less good one; it will be the one with all the limitations on it.
"The same cart will plug into both systems, though, and there's a very simple routine I wrote which works out which machine the cartridge is plugged into. If you know the clock speed of either machine, you can just work out the time certain instructions will take. The program does a swift check when it is first installed. If the Sega counts to a certain number in a given time it's an NTSC machine, and if it counts to another number its a PAL machine. It's essential that it knows this for the sound, otherwise you get fast sound on the NTSC machines, and slow sound on the PAL machines. And also the game would run that much faster on the NTSC machine - unusably fast, maybe."
"I work on a PC running a cross-assembler which goes down to the Z80. You download finished binary or hex (hexadecimal) files into the ICE, which is run from the PC. It's linked in parallel so it's very fast. It has a 64K RAM buffer, so you don't necessarily need a RAM cartridge. It replaces the Z80, and has logic comparators next door to the Z80 in the ICE so that they can tell what's going on. You can then break into any position in the program and set up long routines called 'macros' which will do all your debugging for you. If you want to test something that comes up only rarely, you can actually define exactly what you think that problem is and where that problem occurs, and then just wait for it. The program then stops automatically when it reaches that particular point: it's extremely flexible like that.
"You use lots of specialised interrupt routines in the code. Every time the screen scan reaches the bottom you have a time lag called a V-blank or frame flyback where the screen gets turned off for a certain amount of time, while the scan heads back to the top of the screen ready for the next frame. During this time, when there's nothing happening on screen, you do things like update the sprite positions, or change the frames of animation. Anything that has to be done to the VDP so it's ready to show the next frame is done during the V-blank.
"You can also grab bits of character data and put them into a certain area of the screen map. This is useful, but the faster your game is the less you want to do it, because it takes up all your V-blank time and you might have other things to do. I'm doing it at the beginning with the rotating ball-launcher sequence, which is OK, because there's nothing else going on - the players are static and the screen isn't scrolling.
"We've actually found several undocumented commands in the VDP, basically by playing about with the registers and just seeing what'll happen. There's a mode which allows you to zoom the sprites so they are twice as big. It works, but only in part. This is a throwback to the forerunner of the Sega's VDP which would only let you have four sprites on a line. On this one you can have eight sprites on a line, so what the zoom does is to zoom only four of them. And when you have double height sprites, it doesn't always zoom them in the right way - you can get rather strange appearances on the screen. It might be useful though - I might be using the double sized sprites for the goal indicator, when someone scores."
Alan produces frames of animation for the players on a package called Art Studio. Here you can see a couple of frames blown up showing the individual pixels.
This is an ST mock-up showing the game as it will appear on the Sega. Finished frames have been saved as 'brushes' and pasted onto a completed playing field.
Alan Tomkins (ex-ArtyFacts guru of Zero magazine) is handling all the graphics. "Working with the Sega is frustrating," claims Alan, "because of the restrictions of the machine. To make it a fast game it has to be a single load (ie. getting all the graphics it needs into the VDP at the start of the game). If it loaded graphics in during play, it would slow the gameplay and everything down, so we've had to fit all the sprites and the backgrounds in 256 character blocks. There's quite a lot that had to be dropped out just to keep the game fluid. For instance, there's only two frames of animation on the players. I've had to redraw them so it looks like more, by animating far more 'move' than you would normally in just one sprite."
Tim agreed: "This is a bit of a problem, but we just couldn't fit them in. Because there are players moving in totally random directions, there's no way you can just keep downloading dozens of sprites all the time - the machine is just not quick enough: it's a fast game.
"There are certain things where we don't have to worry about time, though, where we can just load things into the VDP as we need it. For example, you're going to get a very nice effect when the rotating ball-launcher appears."
The central section of the 'pitch', where the ball launcher appears.
One worrying thing was the boot-up Sega logo which Tim thought they would have to recreate for the cartridge. "What they do is scroll the Sega logo and have black sprites overlaying the letters, which are reduced in thickness as the logo moves across. The solution as to how to find out how it was done, was very simple - all we did was turn off the sprites and suddenly we just had a scrolling Sega logo. "It's a nice effect, and we were a bit worried that we might actually have to do it, but of course it's on the ROM, and kicks in when you turn on the machine.
"I'm going to have a slight problem with all the options sheet, not because it's a large or complex program, but because the menus are all going to have to be different sizes. You can't do complete full letter characters, because I've only got 32 character blocks across the screen. And I might want a message that's 32 letters long - I can't have message that takes up the whole width of the screen! It needs to be a little menu at the side, so I've got to rescale that, and write it in a different way.
"Speedball is going to be a 1 Megabit cartridge, and we're also debating whether to have a battery back-up so you can save leagues and things, which would be nice."
If you haven't seen the film not only are you a plonker, but you also won't have a clue as to the plot of the story, and thus the game. So here's a brief low-down on the how the game follows the movie...
At the end of the first film, Marty Mc Fly gets back to the present, just as his whacky chum 'Doc' Emmet Brown hovers up in the De Lorean time machine telling him that his kids are causing trouble 30-odd years in the future.
Doc, Marty and Jennifer go into the future to successfully prevent Marty's son getting thrown in pokey. There's a hoverboard (skateboards that hover) chase, which is where the game opens up. You have to guide Marty through the streets of Hill Valley, avoiding Griff (Son of Biff from the first film) and his gang, while picking up bonus items. You can expect lots of smooth scrolling and fast action here.
Marty on hoverboard in stage one.
In the next sequence, while the Doc and Marty have been off doing hero-type things, poor old Jennifer has been picked up by the police and taken to the home of her future self. You have to get her out before she meets herself and causes major disturbances in the fabric of space/time - or something.
By moving a pointer around the screen, you can open doors and guide Jennifer around the house, trying to get her outside before she makes contact with the middle-aged Jennifer or any of her family.
Meanwhile, Marty has spotted a sporting almanac listing all the major game and race results of the last few decades. Figuring that he could take the book back to the present and get incredibly wealthy by some heavy betting, Marty buys the book.
However, an aged Biff (Griff's dad) overhears Marty and the Doc arguing about how it could alter the course of history with disastrous consequences. Reluctantly. Marty dumps the book in a trash can. At which point, Biff swipes the book nicks the De Lorean, goes back in time and gives it to himself.
OK, now this is where it gets complex. The threesome return to their present (1985) only to find things have altered drastically. A somewhat bewildered Biff took the almanac from himself and got rich in a big way. He's now the most wealthy man in the world. He's married Marty's mum and he practically owns Hill Valley. Which explains why it's now a slummy dump, populated by all sorts of deviants.
In the third sub-game, Marty has to battle his way through the violent streets and avoid other sorts of hazards on his way to meeting up with wrinkly Biff who's got a gun. Basically, it's a Vigilante-style beat 'em up. with a few collectibles along the way.
Biff spills the beans about receiving the almanac from himself (spook!), and so Marty escapes and goes zipping back to 1955 to try and recover the book from Biff the younger (with it so far?).
The fourth section takes place at the scene of the 'Enchantment Under the Sea' ball, where Marty played Johnny B Goode in the first flick. In this alternate time line, the band has lost another member and so the fourth section takes the form of one of those sliding tile puzzles where you have to 'put the band back together'. Hmmm.
After taking the almanac and finding that it isn't the almanac after all (it's a nudey prod mag!) Marty goes after Biff again in another hoverboard sequence. This time. Marty chases Biff and eventually has to hang onto Biff's car in the final high-speed climax!
There'll be more screenshots of the game as it progresses!