Xerra's Blog

Drunken coder ramblings

Project Paradroid —

When creating Paradroid back in the early eighties, Andrew Braybrook created a masterpiece. A game consistently rated as one of the greatest games ever written on the C64, and also one of the most fun to play.

From a technical point of view, it’s also a master class in how to fit a huge game into a tiny amount of memory space – around 54k when using pure machine code, but you have to have all the graphics and sound data in there too. It’s no wonder it took him around six months to write the game because you somehow have to cram everything in.

Remaking the game for the modern age is, in theory, a lot easier. We don’t have custom built development systems banged together out of cereal boxes where you’re trying to squirt raw assembled code down a serial port and hoping the damn thing doesn’t crash, for example.

We have the kind of technology for development that the programmers from that era could only dream of. They had old 64’s held together by sellotape, and often with hardware faults such as the sound chips, linked up to Atari ST’s that had just about useable assemblers piping data back and forth because you couldn’t fit a development environment into the target machine itself due to memory constraints.

We have Unity so should have the edge right?

If only it was that easy.

Unity is a new direction for us so this is a learning exersize, rather than a game we plan to get out there and have people playing in the near future. If it doesn’t pan out, or we run into trouble trying to find out if we even can release it, then it’s probably going to end up nowhere. In our favour there have been many remakes of this game over the years, all free, which have never encountered issues, so we should be ok but it’s like going back to the stone age for us, in programming terms, trying to use this massive application to write what should be just a small, 2D game.

Got to start somewhere, right?

So Aaron and I have kind of set ourselves separate paths on how we would put this game together as I’ve been mostly tinkering around with the UI side of Unity while he has been having fun with tile maps. Logically I’ll work to start with on putting together the front-end side of the game, hopefully as close to the original as possible. Aaron will work on the actual gameplay side on his own scene and, in theory, we should be able to drop our sections together in Unity and update each others project fairly easily. We opted to use this project to work through the trials and tribulations of cross-party development as for a long while we probably won’t lock horns where we would both be working on the same part causing all sorts of headaches.

As a rough idea of splitting the project, and very likely to change later on, my side will consist of doing the following tasks. If I can talk Aaron into it then maybe he can blog about his side as the problems he has getting the gameplay side together are likely to be just as interesting as mine.

Title sequence.

Here I do want the same look as the original Paradroid – right down to the same scrolling text screens giving you information about the game you’re going to play. I thought the atmospheric element of that was wonderful when I first played the original game. Heaven knows how he squeezed in so much data as well as all that game.

End game sequence.

I may diversify here depending on how it pans out. That tv sequence with the scan lines jumping around could be replicated – maybe with a particle effect – but maybe something else could be done here as well.

Static screens.

These are the pages of information you used to be able to pull up by accessing any of the computer terminals in-game. Stuff such as the detailed robot descriptions for all 24 of the droids in the game – including your 001 unit.

Lift screen UI.

It’s not just a basic up/down floor system for the lifts in Paradroid’s maps. There were different connections to different floors depending on which one you actually used, and not all lifts could access every location. There was definitely an element of strategy and learning routes needed to navigate this and clear all the floors. Took me ages to get used to it.

In-game HUD.

How well I can work this into a scene being developed by Aaron will be an interesting test of dual development. In theory I can have an isolated object for the game HUD and a pause game menu system that can be written outside of his scene and then just dropped in and linked up. The in-game HUD will be for showing the droid unit in use, it’s command operation IE:Mobile, console, Lift, Transfer or whatever, and also the score.

Audio.

We’re not musicians or sound effect masters so it’s a case of either track down the original sound effects, get sounds that are kind of similar, or rip them out of the original game, if it’s possible. The randomised robot communication thing on the original games title screen doesn’t do much for me though, so I’m using some tribute music I found instead.

Lots to think about then.

I dug up lots of old images for research purposes which will be mostly redone in a very close style for our version, rather than try to re-use. The walls of text can be recreated manually as memory constraints would be the least of our problem this time and they work on a C64 size screen which is something like 200*160. Hardly practical unless you want to put your nose to the screen every time you played the game.

The original Paradroid font was my first challenge and I did look around to see if someone had already converted it into a useable font to save some time. Having no such luck, I started converting some of the characters myself before realising that it was a mostly pointless exercise as they looked frankly terrible when sized up to something that would be drawn on screen today. After a couple of hours trying to salvage something that was respectful to the original and wouldn’t put off any modern gamers, I gave up and just found an alternative Space themed font instead.

Braybrook had also made a couple of the chars in his original letters double width to make them readable so it would have been even harder trying to build up text walls that fitted correctly when automating some kind of display from a text file I typed into Unity.

Looking at the droid information screens I am tempted to try and reuse the originals. Our intention isn’t to try and make Paradroid 2, just a tribute to the original, honouring it as best we can by copying what it did. I’ll try to upscale them to a decent size and throw them into a panel in Unity to see how they look before deciding if they stay in.

One of the beautiful things about Paradroid is that you were looking down on your player object, and said object was rendered as a simple droid because you were basically only being shown a primitive top down view using the same droid design as the others, with just the droid model number to identify other hostiles because the game plot dictated it. You’re an influence device which is on the shop interacting with these other droids, but you, as the player, are on a different ship sending in the old stunt robot to do the messy work on your behalf.

So, I don’t need all those different robot images for anything other than the static screens from the terminals. Hopefully I can keep them as I can’t draw for shit so don’t want to redo them unless I can talk Aaron into it…

I did a quick mock up test on the original Andrew Braybrook Paradroid logo screen with the music to test that I had the screen setup right in Unity for the camera view so I could also colour it and test the music plays ok. Although we’re likely not looking at putting the project onto IOS it did compile and export through Xcode ok to actually build on my phone but there were lots of ugly yellow messages that probably aren’t too good. Maybe I need to check my build of Unity. Anyway, it’s a good starting point to move on from.

 

 


Categorised as: Development | Paradroid | Unity



Leave a Reply

Your email address will not be published. Required fields are marked *