The Starquake Remake Story

The Starquake remake story

The Game

The Starquake story starts way back in 1986. Many events took place that year, Kodak (beaten by Polaroid) left the instant camera market. Spain and Portugal entered the European Community. Such worldwide events however bore little significance to me compared to the excitement of receiving my very first computer, an Amstrad CPC 6128 in December for my birthday. Aside from the obligatory CPM Plus and demo discs, the CPC happened to ship with what was to become one of the most important discs I’ve ever owned – a very special compilation of four games called the Amtix Accolades. Usually new computers ship with free games that are utterly awful. Since awful games make next to no money in the first place, they’re very cheap to acquire. In this instance however, this proved not to be the case. Side one of the compilation contained the fantastically frantic Monty on the Run and the bizarre but brilliant Sweevo’s World, while side two contained the challenging puzzler Bounder and perhaps the greatest video game ever made – Starquake.

Released in 1985 by Bubble Bus software and written by Stephen Crow, Starquake contains all the ingredients of an instant classic. Part arcade, part adventure – it sees you taking the role of a robotic lifeform called Blob whose job is to rebuild the unstable core of a planet before it explodes, taking the universe with it! A dramatic story line indeed, and while it may sound serious, to lighten the mood, the game is absolutely packed with humour and nods to other games of the time. A read through the instruction leaflet confirms that Mr Crow has a healthy sense of humor.

Taking place in a play area consisting of 512 screens, even today, Starquake’s size is truly epic. When you consider that it was converted to a number of machines including the BBC micro, which only had 32K of RAM, it’s an astounding achievement. Back in the day, Starquake received some great reviews. Crash gave the Spectrum version a near perfect 96%, with the reviewer stating that it “is one of the best games I’ve seen on the Spectrum for one hell of a long time“. Amtix equally raved about the Amstrad version, giving it 91% and a well-deserved accolade. They summed it up by saying “Stephen Crow deserves the hit, and you deserve to treat yourself“.

When I loaded the game for the first time in 1986, I knew nothing about the reviews and had no idea that it was already considered a classic. Remembering back to my first impressions of the game, I recall how I was totally blown away by the look, the atmosphere and the sheer size of it all. For the first few months, I spent all of my time just exploring without actually caring what Blob’s mission was. Due to its sheer scale, there was always something new to discover and it was a wonderful feeling to wonder down a corridor and come across a totally new area.

The graphics are extremely varied, with many different areas. At the beginning, you start off in rocky terrain. As you dive deeper into the rocky caverns you discover areas that are built from molecular structures then as you explore further you find places built from blocks which morph into locations constructed from jungle plants. The variation really is astonishing and part of the fun is trying to discover what’s going to come next.

Starquake Original Image Starquake Original Image
Starquake Original Image Starquake Original Image

As time went by, I continually improved at the game and finally completed it after two years. It was the first game I’d ever completed without a cheat and very proud of myself I was too! Sadly in the years that followed, first the disc wore out then finally the Amstrad died. Indeed it wasn’t until the early to mid-90s that I saw the game again and that was all thanks to emulation. Back in the early 90s, I heard about the possibility of being able to emulate old computer systems – that is to run a program on a modern machine that would trick software written for a much older/different machine to run on it. At the time I had an Amiga 1200 and came across a Commodore 64 emulator (its name escapes me), but unfortunately with the 1200 running at a mere 14Mhz, everything ran exceptionally slowly and at that point I gave up.

It wasn’t until a few years later when I’d upgraded to a 486 PC that I came across another emulator. This time it was a program called CPE and the best part was that it could emulate the Amstrad CPC systems. I quickly downloaded the program and was delighted to see the familiar old Amstrad yellow welcome message for the first time after more than a decade. Of course I now had an emulator but no games to run on it. Fortunately I learned of a french ftp site (which still runs to this day) that was archiving all Amstrad CPC software. Hardly able to contain my excitement, I opened up the site and was delighted to find that someone had uploaded a disc image of Starquake. A few moments later and finally – after many years – I experienced a very special moment, seeing Starquake running once again after so many years.

Playing through the game again, I was amazed to find that it had lost virtually nothing with the passage of time and was still as enjoyable as it had been more than 10 years ago. The only real problem was that computers had moved on, graphics had advanced, and as enjoyable as it was, I could stop thinking how great it would be to be able to realise the game once again but in a more modern reincarnation…

 

The Remake

Back in 2002, after a break for many years, I decided to start game programming again. I’d previously done some work in Z80 assembly on the CPC and had played around with 68000 on the Amiga. It was while I’d owned an Amiga that I first encountered Blitz Basic. Here was a platform that allowed you to develop arcade games quickly and easily without all of the time-consuming complications inherent to assembly languages. Playing around with Blitz Basic gave me the opportunity to figure out how to code arcade games. I tried my hand at many different genres – an Arkanoid clone, various platform games, a point-and-shoot in the vein of Zombie Apocalypse, all of which helped me to understand what made arcade games tick.

Back to 2002 and I’d just picked up a copy of Blitz Basic for the PC. Despite being a seasoned C++/C programmer, it was again the time-saving and indeed power provided by the Blitz platform that encouraged me to use it to start a project that would see three different versions and a development period of over a decade – a remake of my all-time favorite video game, Starquake.

 

Take One

The first version of Starquake, written in Blitz Basic, was a more-or-less straight conversion of the original home computer version. Using graphics taken from the Amstrad version, recolored somewhat crudely in Paint Shop Pro, I finally released a version that looked like this:

Starquake Take One Image Starquake Take One Image
Starquake Take One Image Starquake Take One Image

Version one was completely playable, but it wasn’t possible to complete the game in the demo release. I was planning on finishing it, but just wasn’t happy with the graphics. Around this time I met an excellent chap called Phil Emerson. He was also writing a Starquake remake, but in C++. We chatted for a while about the challenges of working on a project alone and I managed to convince him that a switch to Blitz instead of C++ would dramatically increase his productivity. He did just that and soon released an Alpha version of his remake which had some very nice graphics (drawn in 800 x 600) and some excellent additional game-play ideas:

Starquake Take One Image Starquake Take One Image

You can see some more of Phil’s artwork here.

Unfortunately, like me, even with the increased productivity offered by Blitz, Phil also found that he just didn’t have the time to work on the remake alone. It was with this in mind that we decided to join forces and work on a Starquake remake together.

In the meantime, it was the 2003 Retro Remakes competition and before starting work on Starquake, we decided to hone our collaborative skills and work on something for the competition. As Starquake was already WIP it didn’t qualify as an entry, so we decided to make a remake of SpellBound instead. In the weeks that followed, we got the game 95% done but sadly due to problems with our internet connection (and a disagreement with the then administrators of Retro Remakes) we were never able to enter it into the competition. Having put several weeks of effort into Spellbound, we both felt dejected and decided to take a break for a few months.

 

Take Two

Unfortunately, due to personal commitments, Phil was never able to work on Starquake again, so I found myself alone to work on the remake. I was inspired by Phil’s artwork though and having gained some art qualifications myself back in the day, I toyed with the idea of drawing all of the graphics myself.

The year was 2005 and a company called Media Chance had recently released a very interesting vector drawing package called RealDraw. RealDraw was unique in that not only did it allow you to draw images using vectors almost as easily as drawing bitmaps, it also allowed a number of effects to be added to the vector shapes such as 3D bevels, light sources, etc. I found that it was easy to build nice-looking graphics and use the program to give them a convincing 3D look. I played around with a few graphic ideas in a demo version and quickly decided that this was the package for me. Fifty pounds worse off later and I had the full version in my hand.

Armed with RealDraw, I spent the next few months redrawing all of my Starquake graphics. The resolution was increased from the original 320 x 256 to 640 x 480, which allowed me to add a lot of additional detail to the graphics and bring it a bit more up-to-date with modern PC systems. Eventually Starquake version two was born and it looked like this:

Starquake Take Two Image Starquake Take Two Image
Starquake Take Two Image Starquake Take Two Image

 

It was more version one with a graphical face-lift than anything else, since the code was still written in Blitz. Unfortuntely I was beginning to discover problems with the structure of the game I’d written in Blitz and it was becoming apparent that it would be very difficult to iron out all the little bugs and finish everything off without a major reworking. Around the same time, like Phil’s, my life suddenly became very busy.

It was mid 2006 and I’d just accepted a job as a developer with a company writing software for the film and TV industry in Soho, working on a product called ContentAgent. The software was written in C# (a Microsoft language borrowing much from C, C++ and Java) with some C++ plugins. While having a few years of C# experience in a previous role helped, coupled with some years working with C++, it was almost certainly the demonstration of my Blitz version of Starquake that I have to thank for finally persuading them to take on as a developer (I think my boss just wanted to see it finished if I’m honest!).

Over the next few years, I threw myself into developing ContentAgent, which gave me the opportunity to hone my object orientated language skills. C# quickly grew as a language, passing through version 2.0 to 3.0 then 3.5, 4.0 and now 4.5. It also grew as a multimedia platform and began offering DirectX support via the Managed DirectX API. It was at this point that I thought back to Starquake and realised that if I was to switch the project to C#, I would be able to use the benefits of the object orientated system to organise the project in such a way that it wouldn’t suffer from the problems that had plagued my Blitz version.

I had considered using C++ in the past and had even knocked up a demo using C++ and Allegro. Unfortunately, C++ development is time-consuming and I was never able to find sufficient time to develop something properly. Managed DirectX looked like a perfect fit, so near the end of 2006, I started writing the third version of Starquake using a combination of Managed DirectX and C#.

 

Take Three

Over the next year or so, version three developed at a reasonable pace. I got to the point where I had Blob running around the complete game map. However, progress was quite slow and it was becoming apparent than the Managed DirectX wrapper was little more than a wrapper for the C++ libraries and it was going to take considerable time to create something using this combination. Fortunately, around the same time Microsoft released a little something called XNA. XNA was a suite of tools that would allow indie game writers to develop arcade games quickly and easily for the XBOX 360 and Windows PC.

The system is based around C# and consists of a set of libraries that target DirectX. Unlike Managed DirectX, many helper classes are provided which take the pain out of writing ‘boilerplate’ code. This allows would-be game developers with restricted time to get things up and running quickly, while at the same time giving you power to control virtually every aspect of the system should you need to. XNA also has a number of plugins that allow you to create all sorts of special effects – such as the excellent Mercury Particle Engine. It can also program the graphic card shaders directly using the High Level Shader Language, which allows you to do virtually anything imaginable.

With a pretty advanced version three of Starquake coded in C#, it was a relatively easy task to move it all over to XNA. At around the same time, I’d gained a lot more experience with Real Draw and at that point, I decided to ditch the graphics again and redraw them from scratch. This time the resolution was upgraded to a much more modern 1200 x 800 (though the game for the most part is faithful to the original 4 x 3, so runs at 1024 x 768). I was keen to redo the graphics, not only because of wanting to go for a higher resolution, but also because I wanted to make use of Alpha. Unfortunately the Blitz language back in the day didn’t support Alpha transparency, which gave the game a very solid look and restricted the sorts of graphical effects available. The full Alpha support of DirectX allowed me to produce some graphics that could look very nice and blend far better with the background scenery:

Starquake Take Three Image Starquake Take Three Image
Starquake Take Three Image Starquake Take Three Image

 

Work began on the XNA version of Starquake in 2010. It’s now late 2012, the game is now 90% complete, the code is structured well and it finally has graphics I’m pleased with. I’m aiming for a release in autumn 2013 to coincide with the Replay Expo show, but it may be sooner. So there you have it, the complete story of the thrills and spills of the last 10 tears developing my Starquake remake. Starquake is a game that has been with me for nearly 25 years now and with work on the remake continuing, it doesn’t look like it’s going to leave me anytime soon!

Comments
8 Responses to “The Starquake Remake Story”
  1. Phil Emerson says:

    Hey hey – thanks for the mention on Twitter and of course here – I’m really pleased that Starquake is making a come-back in a form that you’re happy with! I love the particle smoke at the crash site. I think the enemy sprites look awesome – really true to the original.

    To be honest – I always wanted to work on Starquake but it seems I’ve never had the chance. Maybe sometime soon. I’d offer a hand with the graphics but it looks like you’ve got it covered. ;-)

    Now I just need to find the time to play it… or any game for that matter! o_O

    • endangermice says:

      Phil you’ve read my mind, the graphics are nearly done but I could do with some help with the nasties (I think I have about half of them done – I’ll check and let you know). Funnily enough I got your Alpha up and running today and I really like the nasties you did for that. Unfortunately I don’t have the graphics only your compiled executable. If you still have them and could reconstruct with an Alpha channel that would be fantastic!

      It would be great to have some of your work in there, we came a long way together and it seems only fitting that you’re in the final version!

      Update: Damn I thought I didn’t have those nasties in your Alpha in my remake but it looks like I’ve already dome them! If you fancy bringing any others to life, I’ll let you know which ones I need!

  2. Jon says:

    Great looking game – can’t wait until it’s finished. I recently listened to your podcast on Retro Asylum and decided to check out your site. I too grew up with Amstrad but before that I had a C64. I learned quite a bit from what you were saying about hardware accelerated sprites in C64 and how the Amstrad lacked them. I always loved the Amstrad for the range of colours and got the 6128 plus in 1990. My cousing owned a 464 and since I played ChaseHQ on that machine I knew I wanted an Amstrad. I myself, am looking to do some game remakes but as you said, programming games is very challenging and you need some sort of a plan before you begin. It is very easy to program yourself into a black hole!! It’s also extrememly time consuming if you want to do it well – I can see you have spent alot of time on this game and it does look superb. Dean Swain from Retro Asylum is currently helping out with a remake of Double Dragon which also, for the ZX Spectrum, looks awsome. Although I like today’s games there is something very special about them in those days which we just don’t see anymore!! Best of luck with the development and I hope it will be ready sometime next year (I think that was what you said…)

  3. endangermice says:

    Jon, thanks for the kind comments and glad you found the podcast show interesting. Hardware sprites really do make the whole game creation process much simpler on the older machines. On modern hardware it’s dead easy to simply redraw the background sixty or more times per second without even breaking into a sweat, but on the older machines this just wasn’t possible. Hardware sprites made this a doodle since they don’t occupy the screen memory but are added later and then combined to make the final image. This means they don’t erase anything that has already been drawn onto the screen i.e platforms, ladders etc. Software sprites have to occupy the screen memory and overlaying them onto the background will interfere with what’s already there. You basically have two choices, XOR the sprite with the background which will allow you to remove the sprite by XORing the sprite again (this has the effect of restoring the background to its original state). The problem with this approach is that you get strange colours appearing where the sprite and screen data overlap which you can see in a number of CPC games such as Jet Set Willy. The alternative is to copy the area of background that will be covered by the sprite to memory before you draw the sprite, draw the sprite, restore the background move the sprite, draw it again etc. the problem with this is that it can be quite complex and things get even more difficult when you have to factor in masks for transparent pixels! This combined with an extremely odd screen layout makes programming for the CPC quite a challenge though often a satisfying one!

    Totally agree with your comments regarding the challenge of games writing. What has helped me immensely is working as a commercial developer. The skills I’ve learnt over many years of product development have really helped me plan the structure of the remake properly. As you know this isn’t the first version of the remake I’ve attempted, and I’ve screwed myself in the past to the point of aborting previous projects but this time it’s all structured well thanks to the use of an object oriented approach! One of the keys is to write modules that are easily extendable and not to try and skimp too much or you’ll end up finding yourself having to rewrite an entire routine because it cannot work the way that you now want it to and as you say find that you’ve programmed yourself into a corner!

    I know Dean well from our association with Retro Asylum – we’re actually currently working on the site redesign. His work on Double Dragon is superb! We have mulled over the possibility of working on something together in the future but this as always will depend on how much time we can find – Dean, who in the past week has become a father for the second finds this in short supply!

    Definitely aiming to complete Starquake next year. I’ve been doing a lot of work on the remake recently and plan to keep this up until its done. This is quite a challenge with all the other stuff I have going on but I have found that I’m able to make some real progress in the little time I generally have (usually on the train into work) so I’m confident of being able to get it done in 2013. I’m taking my time simply because I want it to be awesome rather than nearly awesome!

  4. Dopey says:

    That’s awesome ! Keep up the good work, I hope to play it in 2013 ! :D

Trackbacks
Check out what others are saying...
  1. [...] here’s a new update showing off the new “spiky nasty” movement routine for my Starquake remake. But wait… There’s more! As an added bonus I’m also demonstrating the first new [...]

  2. [...] week’s Starquake Update is a little morbid. You see I’ve been working on the routine for Blob’s death which is [...]

  3. [...] been mainly bug fixing some of Blob’s interaction routines and improving the nasty AI in my Starquake remake. Sadly none of that gives you anything to look at so I decided to finish the week off by adding a [...]



Leave A Comment