The History of Starball

Written by ST Graveyard

A screenshot of the shooter (inspired by Thunderforce III) on the Atari ST. The game sadly never got released. This eventually started the whole Starball adventure.

Visual History screenshot 1 - Version 17 (early '92) - Check article for more info

Visual History screenshot 2 - Version 28 (July '92) - Check article for more info

Visual History screenshot 3 - Version 34 (August '92) - Check article for more info

Visual History screenshot 4 - Version 49 (January '93) - Check article for more info

This article was written by Dave Oldcorn in 2011 for the website Way Of The Rodent.



Where do computer games come from?
At least in one case, I have an answer. And it's an odd mix of random leftover code, a bunch of other people's games, a Japanese puppet series and a very tedious physics lecture.


Chapter 1

I had, for a long time, been messing about with horizontally-scrolling shoot-em-ups. Conventional wisdom was that the ST really couldn't do these. Blood Money had done a very good job of proving this wrong, albeit without any parallax scrolling. Having gorged myself on Tecnosoft's brilliant, beautiful Thunderforce III over the summer before I went to uni, courtesy of the Megadrive at the shop I worked at (that did books and RPGs and comics and console imports), that clearly wasn't going to do.

I had some very early code that implemented the weapons system from Nemesis that I'd done a year or so ago, and I took that and started working out some theories for doing parallax scrolling. Using a prerotated background, I was able to do something pretty reasonable, at least over a window a bit below fullscreen. Arbitrary parallax fell out of that pretty much for free, so I was able to copy TFIII's sine-distorted backgrounds and that looked really impressive, albeit at 3 frames per update. (Blood Money was slower, 5 frames or even more, but fullscreen - very cleverly, it updated the player's sprite every frame which made it look much smoother. Genius, that).

(I’m crazy enough to have archived all this stuff – and surprised nobody more than me by managing to get the code to assemble and run under an ST emulator, so here's what it looked like. Trust me that the background is fully animated, with parallax!)

I also had some fairly devious ideas about how to make a more console-y experience. One thing I'd developed some years previously was interrupt disk code that could load stuff in without needing any significant CPU intervention at all, and I planned to use this to stream the levels in while you were playing and give a completely seamless experience, no loading screens or pauses at all.

This was also important because the only way to do fast horizontal scrolling on the ST was to prerotate everything, needing up to 32x the memory for each frame of each sprite or background tile, so streaming the buggers in and prerotating in realtime (using unused sprite time, during gaps between waves) was the only way even a single level was ever going to fit in even a 1 meg machine. Between those two, I developed a memory manager and timeslice management system where when I knew there weren’t many sprites on screen I would use spare CPU time to do some prerotating of sprites or the terrain tiles.

Andy drew up a bunch of graphics and we started trying to put a trial level together but I was having conniptions over managing the enemy waves – they had a tendency to look a bit rubbish at best, and it wasn't very interesting to play against. The code was also becoming fiendishly complicated. There were tables of movement patterns, tables of wave contents with tables of movement patterns, tables of waves with tables of wave contents... in C it would all have been easier to manage but in the days before I properly understood data structures and in the reasonably primitive assembler I was using (no structs) it was very hard work, and all before I started to work out the even more complex logic that was going to be required for the streaming and prerotating. By the time I ended up with the table table table table, I was getting a bit fed up of it.

I was messing about with emulating Spectrum tape recorders, spending an increasing amount of time doing charity and events things at the student union and we were moving into first year exams; it all kind of fell into disuse and never got restarted, although after a friendly argument in the bar with ST demo legend Tim Moss (who was on Andy's course) I spent a good chunk of the end of 1991 trying to make it work at 50Hz and prove I could do Enchanted Lands without sync-scrolling. Came fairly close, but he was right, it wasn't actually possible.


Chapter 2

I went back to working at the shop in the summer. During it, Tecnosoft shot back with the fabulous pinball Devil Crash. Now we'd played a lot of Alien Crush on the PC Engine in the shop, but DC was another thing entirely and we spent a lot of time on it. I'd played pinball computer games before but they were mostly a bit tedious because they just duplicated a pin on the screen. The clever thing with DC was that it did things that you couldn't do for real - like wandering targets and bonus screens. In addition I’d started to get into real pinball, on the modern, video-and-sound heavy 90s pins at the Student’s Union and so the whole thing was in my mind.

Early in 1992 I was in an extremely tedious solid state physics lecture and instead of trying to understand phonons I was fiddling with the maths of pinball collisions. Given the collision point of the ball, you can resolve the velocity into components tangential and normal to the surface, and by reflecting the normal component you get a bounce. You can also choose to boost the velocity of the normal component, which acts as a kicker, and cut it, which absorbs the energy of the ball. You can also create various roll-type effects by mucking about with the tangential velocity a bit, without actually having to worry about the spin.

Sadly, the page of lecture notes with the algorithm scribbled in the margin cannot be found. I suspect it was with the huge pile of my old papers that were stored in the garage at my parents and eaten by mice.

I worked through a high performance method for finding the collision angle (have a 'solid' bitmap, which shows which bits of the table are actually solid, overlay it with a ring representing the ball, and average the angles of the two extreme contact points to give a collision angle) and coded it all up. Initially I let the ball bounce about a bit and then added some flippers. I then found I could reuse the fast blitting and sprite routines I'd developed for the shoot-em-up and get a table that scrolled smoothly, and I had the basics of a pinball engine.

I'd been watching a video of some old Star Fleet episodes that a mate had bought me for Christmas, and playing with using the interrupt disk code to stream little windows of FMV. It seemed to me that you could build a _really_ good pin table around Star Fleet, with the various modes and characters already present in the series providing plenty of depth for a pin. And from that point on it sort of snowballed.

The Star Fleet idea didn't really last too long, for obvious reasons (although something that resembled the Dai-X Junction survived in the middle screen ship). In addition, the interrupt disk code trashed a disk badly and that scared me off continuous-loading (and hence the FMV) a lot.
A replacement name seemed obvious - Starball!


Chapter 3

Over the next two and a half years this expanded into a full main table and four bonus screens, in fits and starts. None of the university distractions ever went away; generally I achieved the most during the summer holidays, where I spent long days at home listening to Radio 1 Roadshows and coding. More than anything else, I was distracted by silly little ideas, some of which grew out of control; one of them started out as cloning a starfield routine from Tempest 2000 and ended up as the intro to Starball (rather a pointless waste of space), another became the LED bonus board (that I was quite proud of, it’s a simple but pretty devious bit of code); later, after I got a Falcon, a third grew vastly out of control into a truecolour JPEG viewer that ran on the DSP at incredible rates (and eventually ended up about the same size as Starball, at least in source code).

Games were also a distraction; the Megadrive, in the holidays; in the fourth year, Tempest 2000 on Andy's Jaguar and UFO, Doom, X-Wing and UFO on another housemate’s PC. I don't think it's a coincidence that it finally went out of the door the month after everyone else left for the summer and I had little to do except my thesis during the day and Starball in the evenings.

Rarely, I know a surprising amount about Starball's later development, because I intermittently kept a programming diary at the top of the main source file. It's spotty through about August 1992 (by which point it had reached 2500 lines of asm, 46K) but then it started to become almost as important as the code itself. While it's rather too embarassingly immature for me to consider disclosing it in full, here's a few choice excerpts...

Coding report 20/7/92

31K source 5K object

Some bloody stupid problems bodged to death... see 'angtnv:'

Odd assembler problem encountered

Flippers and ball finished... table design under way

6/10/92 Concept of bonus screens introduced - by extensive modification of structure and access to all the table routines etc. Unbelievably this didn't shaft the entire program and it actually cooperated after a brief kicking (version 42)

31/3/93 - Assembly time now a really irritating eight seconds.

1/2/93 - sound fx incorporated into game. Seem to be working alright although a lot of the sounds that 'seemed a good idea at the time' seem much less so when you actually try to use them. They all sound like everything you heard before but from all different games... not all DW or Wizball or whatever. Did Archer MacLean or Pete Johnson ever do this?

20/2/93 - Briefly suffered from the Dreaded Lurgy which has put me a week behind on both this and the Project. March 1st will be tough but may still manage it. Started installing Eggball, going groovy, will take total about 6-8 hours work. Broke 100K of disk source. and 21/2/93 - in memory too.... aargh! 101Ks, 5550l, 17.8Ko, V52. Oh for a modular assembler. Bet that wouldn't have a 9 second compilation time though. Must spend more time on it this week. I mean like at least 5 hours every day. 51 weeks down, one to go... eek!

Fixed the free trembler too. Finished Eggball more or less.

(11 days to completion? Hmmm. Maybe not.)

23/3/93 - OK Into the 'finishing off' phase - I've got ALL the graphics so it's just down to me now. 2 bonus screens it is, so all the bonus preload memory has been lapsed... I need it now!

(Oh how overoptimistic I was. Not even half done yet, Dave.)

30/3/93 - I forgot how much I hate doing movement patterns. Have found I need some more graphics. We're going to try to do Llamaball as well if we can.

14/4/93 - it works on the Falcon! It ran at about double speed, so I reckon the cache is breaking down during the MOVEMs for the table blat. The sprite routines go incredibly fast though!

21/4/93 - Have finished the support stuff (and written an auto loader/decompact handler, which will go in here as well) and am now viciously crowbarring in the support control routines. Surprisingly enough, it actually works OK! The multiple vector-handling routines are a bit annoying.

V56, 131Ks, 25Ko, 7300l. Plus of course the support code, which is now on V13, 37Ks, 9Ko, can't remember how many lines. And the sound effects...

Source now on disk 10. Disk 9 is the support code, 8 is the pre-intro, 7 and 6 old source disks, 5 the table source DEGAS pics, and 4 the run-time data library (plus one old version of the source I think)

Joystick messages have been hard disabled to prevent mouse movements slowing the game down.

It's definitely going to sit on top of the OS now, I want to maintain that Falcon compatibility and can't be bothered rewriting all the keyboard handlers and stuff. It will be tricky to fit it into the memory on the 512, and there might be a few problems if there's much memory fragmentation! The 1 meg version won't be much different, it'll still do some disk access, but they'll only take a couple of seconds so that should be OK. And it will be HD-compatible (because Andy would complain if it wasn't)

23/4/93 - Creating first stand-alone version. Introduction of AFL use for bonus file format.

FIRST EVER DEMO VERSION!

Wow! It works!

26/6/93 - Exams all over, now let's get this thing finished. Bought a Falcon, partly to play with and partly to speed up the assembly time. It's much better for playing with. However, 6 seconds is still a big improvement. And at least I don't need to worry about the memory for the other two bonus screens

7/7/93 - Falcon version now runs at 50fps - all the sprites and things still move at 25 frames, but the ball movement and scrolling are at 50.

24/9/93 - Scoring. Bit of a tricky problem this one, will have to be thought out logically. 8-digit scores give 99 million as the absolute top score, so about 2 million should be a GOOD score. Bonus pts first: max multiplier is x9, so a really good bonus (around 600k) gives bonus pts around 60k, for which a ball would need to last about 5-10 minutes, giving scoring rates around 6-10k a minute bonus points IF a good variety of targets are used. Points score should be faster than bonus, but high multipliers should make bonus comparable size to points scored in same time - probably about 500-600k for a good 5 minute ball. Just a few ballpark estimates.


(Yes, I didn't think about scoring until more than half way through the project!)

25/10/93 - Best guess is about 15 hrs work to go. Bonus screen entry system set up properly, including ball status save so link to BS only involves changing one variable. V60, 190Ks, 36Ko, 10840l, bloody hell.

(Ahaha. Yet another miserably inaccurate estimate. It was about 70% complete at this point.)

24/4/94 - this is getting embarassing, actually, so I am going to get it finished (rest of world goes 'oh chinny rec on Jimmy Hill'

(Well, at least I was starting to realise it myself)

1/5/94 - OK now we hit a problem I've been waiting for for a while, the program is now big enough that even long branches don't stretch across the code anymore. A mix of 'jsr's and reorganising stuff should fix it. V62, 219Ks, 42Ko, 12486l. Lots of little extra bits added recently to improve things, and it can now do a lot of impressive little tricks. In fact I'm going to start version 63 now I think. It may even be the last!

30/5/94 - Well I've played an awful lot of T2K, watched a Bond Movie, a GP, slept a lot and actually just about got the main table sorted for good. V63, 236Ks, 47Ko, 13400l.

1/6/94 - Got meself somewhere to live over summer, and decided that the movepattern synthesiser can stay, because saving disk space is slightly more of a priority. Fixed up some top screen big sprites BUT they could probably do with moving about a bit! I'll wait on this one until I think of something... OK Sod It. This Is the Official End of the Test Versions.

V0.63, 242Ks, 47Ko, 13685l. Version 1.00 Starts Here.

Righto then first job is to link in all the twiddles Andy's done. Unfortunately Andy ain't here, he's on project, which leaves me temporarily up a certain creek without a certain implement.

8/6/94 - Top Screen Big Sprites: Well It's A Movement Pattern. It's not funny, and it's not clever. And I can't find anywhere for bonus mults. And I am beginning to run out of things to do. And I'm still not at all happy with it playabilitywise. But there you go.

9/6/94 - Basically after having spent a million goes on some bonus screens I'm now convinced the flipper logic is totally useless. It's unplayably bad in the form it's in now. The question is what I can do about it.

11/6/94 - Fixing up the flippers has worked well, but actually made the game a bit easy for a while, it was a little over-tolerant of quite blatant errors. After a little tinkering it is now not quite so friendly.

(The main problem, really, was the lack of flipper angle. More on that later).

Today is the end of Starball. Or it would be, but since Ken has decided to leave his PC at UMIST it means I can't do a last check on a VGA monitor... so it will be held off until I can do this test. Basically it's finished, but I'll keep playing and fiddling until I've checked it on VGA. So ends version 1.00, 252Ks, 48Ko, 14091l, crikey!

(The following week I released version 1.10 via various FTP archives and a post on comp.sys.atarist on Usenet. Over the summer Andy and I fiddled with a beat-em-up game, but even after the ST Format coverdisk splash the returns from Starball were looking, let’s say, “unencouraging”, and after a lunchtime drinking incident which resulted in me writing the same bit of fighter shadows code completely wrongly twice I turned the machine off and never went back to it).

11/9/94 - well have got most of the samples sorted. I'm not happy with all of them, the quality is terrible, and the Falcon's sound subsystem is appallingly put together. But the phrase 'sod this for a game of soldiers' springs to mind so this is the end of it! The other annoying thing is I couldn't find a Traci Lords sample for the oooh, because I wanted to credit her in the readme as well as Jimmy Hill.

Astonishingly it still works fine on the STe too although I had to modify the PSG effects a little to make them quieter relative to the samples. Think it's about right now. I think recompress the support code, watch the Grand Prix, do some thesis work, and some extensive playtesting this evening and we are sorted for a release tomorrow and this is REALLY it this time.

The week after that I bought a PC – and hardly touched the Falcon again.


Summary

My own personal final score was:
• Game: 14574 lines of code, 271KB in size
• Bonus Board: 3200 lines and 50KB
• Mod player: 2200 lines and 48KB
• Sound FX: 700 lines / 10KB
• Intro: 2000 lines / 31KB

... and a few thousand lines more of various graphics preprocessing and data compilers. Altogether, I reckon the coding was between six months and a year of full-time work, so an average of 100-200 lines of code per working day, which is supposedly about par for the course for a good software engineer.

While I'd heard Jeff's experiment with Llamatron had gone reasonably well financially, Starball certainly didn't – while a number of people did take the effort to send something in and to those I am eternally grateful, total money in was under a thousand quid (nearly half of it foreign, which in those less enlightened days the bank took a hearty chunk out of to change it). It wasn’t even slightly enough to support another game, and with uni drawing to a close, something more profitable became a requirement.

There wasn’t a lot left to do creatively with the ST anyway - maybe the Falcon, but a market that small was never going to be worthwhile.


Visual History

I managed to get some of the old versions running too - here's a bit of a look.

Visual History screenshot 1 - Version 17 (early '92) :
This was the first one I could get to show me something useful. There's nothing to definitively date this early version 0.17, but this is a very early test which shows the collision model, table blit and the start of the idea of flippers. It probably dates to within a month or two of starting the project in Feb 92. Note that a couple of things are even already recognisable in the final version; the flipper itself (one of my few graphical contributions), and the colourscheme; the greenish-grey background block and the orange on the flippers I think got stuck in Andy's head when he drew up the "space tennis ball". Also note the angle of the flippers never changed, of which more in the post-mortem.

The coloured background stripes are timing bars. If you changed the background colour register you could get a visual display of how much time a given bit of code was taking - so there were colours for table blit (green in this case), sprites, collisions, ball movement and wall interaction and so on. Many, many hours were spent with bits of blu-tack stuck on the 14" telly I used to program on while optimising routines, to see if the colour bar was smaller after recompiling with various tweaks.

Visual History screenshot 2 - Version 28 (July '92) :
From now on the diary provides some dating, in this case version 0.28 comes from late July. Scrolling is now working. Again, a surprising number of recognisable things are cropping up; the aforementioned tennis ball - and the table layout, which didn't really change an awful lot from this date - here, the only big change was the back passage on the left side being plugged up.

Visual History screenshot 3 - Version 34 (August '92) :
This was over the summer and there was a lot of time going into it. The bottom screen gets an outing here; note that Jimmy Hill hasn't taken his place on the right yet, but the gem blobs would survive with the very same slightly rubbish movement pattern until the end.

Visual History screenshot 4 - Version 49 (January '93) :
Because I tended to replace the graphic files as I went along until we changed disks, it's hard to say exactly what date this is representative of, but since the sprites were all present in the graphics I think this probably fits OK.
By this point, Andy has drawn up the table background - tearing his hair out in places because the palette changes weren't aligned neatly to whole screen heights in the art package. One of the main reasons Starball looks so colourful for an ST game is that it changes about half the colours on each of the three play areas - if you look closely in the game, you can see black lines that were left on the background - which gave it a lot more pop, much more console-like.

The background changed very little from its first arrival. This is the Bitmap Brothers-inspired top screen, with us still searching for gameplay elements to stuff into it.

From that point, it was mostly adding details and there's not a lot worth seeing screenshots of. We never went back and threw anything away (since we didn't feel we had as much content as we wanted anyway, it didn't seem wise). Combined with the lack of intermediate versions in the graphics, screenshots aren't really interesting from here on in. I suppose this is one defence for my continuing lack of foresight as to how much work there was left; really, things were looking pretty good inside the first year of the project, and that it dragged on so much was certainly a classic example of the old rule that the last 10% of the work takes 90% of the time.


Conclusion
So, what do I think, just short of 20 years on from its inception?

I suppose the biggest disappointment at all has to be the financial failure. I was hoping this was the stepping stone to running my own company and turning into Peter Molyneux. How phenomenally naive I was - the business plan for the first couple of years of Volume 11 was, with hindsight, the biggest mess of all, and it didn’t get an awful lot better during our remaining games career. Of course, in the long run the failure there – by a roundabout route – landed us in our current jobs and left me a happy man, so really I can't complain.

Funnily enough though, it was great practice for work. I've worked from home my entire working life, apart from the odd week or month onsite. Nearly two decades on I'm still sat at a desk in a room in my house (albeit now not one I have to sleep in) with the radio on writing code in my own bubble. Although Radio 5 has replaced Radio 1, the cricket is still a major component. To be certain, my work ethic is a bit more highly focused now, although I do miss someone banging on the door and saying we're off to the pub at 2pm.

Right at the off we made two big mistakes that only really became apparent with hindsight (mostly, while we were revisiting various design decisions when working on the PC version). The first is that I didn't tilt the flippers enough. The angle I was using was set in that very first test program and we drew the graphics up based on it. By the time I started trying to tune the thing for playability we'd have had to relayout the whole thing; lots of work for Andy doing the redrawing (mostly pixel-by-pixel in those days, and in particular anything that involved table overlays - like flippers - tended to mean having to draw everything by hand for a dozen animation frames), at least as much for me changing the infinite number of hard-coded, expensively tuned X and Y locations in the code and repeating the playtesting. Similarly, as a placeholder I'd drawn the levels up much like Devil Crash, except for the top screen, and we were similarly stuck with it, leaving our inspiration a bit too apparent.

It also almost certainly wasn't bug free when it went out. If I learned one thing above anything else, it was not to write 10k-plus lines of assembly language, particularly game logic where there are lines of code that only run once per few games. It was a valuable lesson; with the PC version, I was able to design a deliberate strategy to make bugs much more likely to be immediately apparent or not exist (mainly, by coding the tables in a custom programming language; albeit that I would say afterwards I learned not to do that either).

I had some other things so very backwards too. I wasted a bit of time and effort and far too much disk space on a ridiculous intro that achieved nothing except compatibility problems; in contrast, scoring was an afterthought and the game was a touch superficial, without the depth of strategy of a great pin. We had the ability to make really dramatic changes to the table if we'd wanted to and we never made much use of it. The abortive sequel looked like it would have more meat on it because we plotted it out more thoroughly and had a better idea of what we wanted to do.

But in the end it was astonishingly well received, my brief moments of ‘fame’ were lovely, and I'm still terribly proud of it.

Some of the time it never even really felt like work.


Dave Oldcorn, 2011, Way Of The Rodent.


For more info, check out the following links:
- Atarilegend's video Starball, console quality pinball on the Atari ST - Full history - Dave & Andy - Volume 11 Software
- An old yet amazing interview with Dave & Andy by Richard Karsmakers @ ST-News