Xerra's Blog

Drunken coder ramblings

Gamepads —

Aaron and I had a very important business meeting this weekend at our head office (cough) The Coach and Horses. Among the things we discussed were throwing ideas about on a potential next project after Paradroid, and debating wether we need to have gamepad support in Paradroid. As I’ve mostly just used keys/mouse on the games I play on the Mac, and just stick to playing most big games on the PS4, I hadn’t given it much thought until now.

The thinking is that it’s a C64 game we’re remaking that was designed to be played on an old cube-telly and a Competition Pro or Quickshot joystick, so it’s common sense really. Bonus points to the old farts who can remember both those joysticks. I had a Competition pro that lasted me through my Vic 20 and C64 years. Never used anything close to being as good, although the PS4 controllers I’m almost comfortable with now.

So I spent Sunday afternoon digging out my old wireless XBox 360 game pad as it turns out GMS2 does support either those or PS3 controllers. No PS4, otherwise I’d have just attempted it with that.

Another snag was that Microsoft (obviously) don’t provide drivers for using their XBox controllers on an Apple Mac. I mean, why would they?

Fortunately there’s a driver out there for people who’d like to use one anyway, and it was relatively painless to get the device linked up to my Mac and then start looking at the code side of things.

In the old days of programming a game to work with a joystick, it was pretty much just peeking a location to see if the number within had changed, which would indicate the switch was joined and the game should react accordingly. Nowdays there’s start buttons, back buttons, triggers, shoulder buttons, directional sticks and four flippin’ fire buttons. Only basic joystick use is really required for this game so I set up the transfer game in its current state with enough code to be readable and for Aaron to make use of the source to do the same with the main game.

Once the games finished I’ll probably take out all the joystick code and stick it into some kind of reusable script so gamepad support can be dropped in to anything else we write that follows Paradroid.

It was nice getting away from the workings of the board building routine that I’m still tinkering with , while still working on the game itself as that way I don’t feel that I’m wasting time when something needs a bit more thought. I just do another part of the game instead that won’t need much thinking, such as tinkering with sounds.

No new screenshots this time as there isn’t much new to see as yet. Nip over to Aarons blog via the link on the right and you can see an example of the in-game graphics being switched to heavy metal, original etc.

 


Transfer game progress update —

More work on the transfer game this afternoon.

I’ve been trying to keep the game handler down to fewer objects so it’s easier to work with all the elements without having to factor in with object calls as it could get kind of messy with all the sub-elements that are going to come into effect in this mini-game. I’ll rely more on scripting for the grunt code stuff such as drawing the game board as it’s easier for Aaron to read my work and understand what’s going on. There will probably be an element of tidying up and improving areas after the grunt work is done because that’s part of the optimisation process, although it’s probably not going to produce any noticeable improvement in the game speed as it’s not exactly hitting the hardware as it is. But one day maybe someone else may read the code so it’s nice to be seen as doing your job properly.

I got the mechanisms in place to have a toggle-able game state in so I could both implement the movement of the player selector for both sides, and also test out some random mapping. I don’t have it in place where the script actually does draw a proper playable game board yet, but it’s got test code in to throw out random tiles so I can check everything is being drawn in place and that my movement works correctly within the tiles on both sides. It’s a little strange working with a tile as the actual player controlled element rather than a sprite, but sometimes it’s cool to mix things up a bit as everything is a learning thing with a new development system.

So, having tidied up various elements of the other parts of the game controller for the transfer system, I’m unable to do anything else until I actually have game boards to work on so I can put in the code to actually start activating individual circuits.

It will be straight in at the deep end for my next blog entry.

As a side note, Aaron and myself have found a project management system we both finally liked, rather than hacking together some kind of shared spreadsheet. We created our project on EasyNote. This is a deliberately simple system of setting tasks and assigning them between people with the usual options to comment, set sub tasks, deadline dates and status of elements. Dead simple to use and invite members into each one so we’ve got all our development notes running from this now.

It appears to be free and has a gig of storage for what looks like both attached files and actual projects, so we should have plenty more space to use it for future projects after Paradroid. As I said, it’s free so this is no advertising plug. I just thought it’s worth a mention as we’re finding it so handy.

Have another screenshot. This one shows the board handler spewing out random tiles just to check the layout is ok. You’ll get one with an actual random generated map one day, I promise !!


Transfer game progress —

Creating the transfer game was always going to be a major task in Paradroid due to the complexities of having a random element to every game screen generated but having to make every one actually playable. I knew at the start that the actual routine to generate the screen was going to need to be written one element at a time to ensure each one worked on their own, before adding in the block stuff – which is where 3 lines are used to create an opening bar and the circuits from this can either progress into other bars, or close off into a single circuit again. This coupled with the other elements that can be part of this structure, such as colour swappers, reverse polarity switches or just plain dead ends, will make this require a lot of testing and map generating within the code to get it absolutely right.

So, progress on the creation, means building the other elements up first, such as the droids on screen with their respective class numbers, and sides selection implemented, so we can get the right amount of turns given accordingly.

Hence the screenshots shown here.

And another shot here shows us having the 999 droid under our influence.

Quite why we would want to drop down into a lowly 123 maintenance droid from this unholy beast of destruction is another story that I’m likely never to go into.

So our droid of choice is now selectable within the transfer game by us. You guys won’t be so lucky as I’ll disable the option to do this once it’s all working so you’ll need to find another way to cheat like me. If we let you …

We went to great pains to ensure that the layout is as close to Paradroid as we can get it, while obviously adjusting graphics size to fit on our predetermined screen size of choice – mainly for compatibility reasons as we would like the end-game to run on practically any old PC out there. DirectX restrictions allowing, of course.

So the markers can already be seen for each players movable circuit selector in black on each side. Once they move down from their parking spot they can’t go in there again and naturally can only fire into circuits that are available. If there’s a blocker in the next column to them then the original game would not waste a shot in such a pointless attempt to try and activate it so we won’t either, for example.

The circuits area which will be modified by the random map element are currently highlighted with yellow and purple animated elements to show conductivity across the line as they will show in the game once the circuit is lit up by the player or computer. You can’t see them animating in a screenshot, however, so you’re just going to have to take my word on this for now.

Creating the actual map is being done by using tilemaps rather than sprites, so a lot of my time has been spent working out how to actually put these on screen and working correctly. Fortunately I’ve had the assistance of Aaron in doing this, as he’s already been playing with that feature of GMS2 from the start in creating Paradroids many deck/map arrangements.

Where I’m currently at is putting in the code to control movement by the player up and down the line of circuits which shouldn’t take very long so I can get to the fun part of tying in the drawing of a random map every hit of the space bar.

The transfer game links in a timer to select a side to play and for completion of all your shots on the circuit board itself, but I’ve disabled all  this for now so that the testing can be done first as there will be a lot of map studying taking place to ensure there are no flawed circuits in any of the play areas.

It all sounds so easy when it’s written into a blog but you can be sure that the code element for this part is probably going to take me longer than all the work I’ve put into the title sequence so far.

Onward then…

 


Paradroid music —

While Aaron and I were looking into wether we could actually do our own clone of Paradroid, I also went looking for some alternative music as I didn’t fancy the idea of using the droid chatter system of the original game.

Luckily I found that a chap called P I N (Michael Pin) had done a techno mix using a background sound and some of the sound effects from the actual game. You can listen to it now on his soundcloud page. The track is called “Do you remember Paradroid”

Michael has agreed to let us use the music and could also compose something new for us if we need another track later on. Naturally, we are really happy about that as, due to the game Paradroid not belonging to us, we never planned on ever trying to sell it, so we were never going to be able to pay for anything we used that was created by anyone other than ourselves.

Aaron had been tinkering around recreating some of the Paradroid sounds in code downtime but we also have a large sound file that Michael supplied which he used for his music project that we may also be able to make use of. Hopefully this will make the sound effects part of the project a lot quicker to get done.

Here’s also the original YouTube video Michael did when he created the music.

Do you remember Paradroid?

 


The transfer game —

Even though the title sequence still needs some work to get it up to standard, we decided that it was something to come back to later as there will soon be enemy droids going into the game. Obviously, without having the transfer game in place, it’s going to be just the shoot-em-up aspect of Paradroid we’ll be testing and fixing, so it’s time to get that done now so all aspects of enemy droids can be set up in one go.

We delegated a rough task structure at the start of the project and decided that I would be the one who would be coding the transfer mini-game. With us this doesn’t mean that I just get on with it and Aaron will look at it when it’s done. With all aspects of the game we spend a lot of discussion time making sure we have as much assistance as needed to get each section done, so the last weekend we both spent a considerable amount of time at Aaron’s working on the graphics for the game and working out how it’s going to be coded. As in either Sprites or a tile map system.

Common sense made us choose tile maps as we have the option of resizing to get everything fitting nicely on screen, and it will be much easier to actually keep track of them in game as it’s a map system.

So here’s one of several maps we’ve set up for both testing the graphics, getting the tile-sizes right, and being a useful reference for how to put the random element into code when generating a new screen.

This one functions as how the screen will be generated at the start. My code will overwrite the blank areas with the actual layout of the circuits, blockers and switchers. Not sure if those are actual names Andrew used but I need variable names for them so they will do for me.

Andrew stated in his original “Zzap 64” diary that it was pretty easy to get this transfer game working properly and did it over a weekend, as I recall. I have as much time as needed, realistically, and a much better development system. Not to mention I don’t have to worry about fitting it into 2k of memory either. And I doubt I’ll still get it done anywhere near as quick as he did but here’s hoping.

This is pretty much how it looked in my editor before I started working on creating it. I’ve not got Aaron’s handy C64 colour macros in the project yet and stuff like all the other graphics needed, like robot definitions in, but it gives an idea of how I’m working with GMS on this horrible Parallels environment. Can’t believe I was happy working with that when I first tried it…

The tiles we needed to make up the entire game turned out to be relatively low once we had put some through in to what could be re-used. We didn’t screenshot the original game and use GMS to tile a PNG image because we wanted to keep it tight so we could macro the tile map blocks and keep it simple to keep track of redrawing the map after every circuit is activated. Creating our own tile set also gave us the advantage of getting the dimensions right as we wanted to make it fit exact to our current fixed screen size but retain the original number of usable elements in the game. We had to play the original game many, many times and tinker with the graphics a lot to get this just right. Hopefully we did cover every tile actually needed but I’m not going to be totally sure on that until I actually start moving things around on-screen.

 


Bug fixing and text formatting —

Started ripping out the temporary text lines I’ve been using for testing the scrolling information. Had all sorts of fun and games creating a routine to load in a text file and then display the text using a DS_list. Because I’d been editing it on the virtual PC  it had inherited all sorts of stupid formatting codes that weren’t visible and caused the formatting to go all over the place. Eventually got that all sorted out and finally had reasonably formatted instructions doing what I wanted.

Got her indoors to help out choosing some colour combinations to swap around for the displays as the idea is to break up the routine by displaying the original Paradroid loading screen that Andy had on the C64 between runs. Due to the way the surface scrolling works, and how i’ve clumsily used two objects, I’ve got to streamline it all again back to just one system doing all the background stuff as things are going all over the place when I try to add little features here and there. Put that down to a job for next session along with some advice from Aaron about using two views to save constantly creating and removing objects while running the title sequence.

I’ve mentioned previously about using a file loading system to bring in the text so it’s easy to modify it on the fly and eventually turn it into internal data once it was finalised. I was hoping to just stick with the load system as it works pretty well, but it turns out that external files added to the project aren’t built into the main executable at compile time, so it would be easy for anyone to modify the text after installing the game to do all kinds of naughty stuff like changing credits, or potentially breaking the game with overloaded text lines. So I’m going to have to shunt the formatted text into data within the code, although it’s not something I plan to do right until the end.

The only external data for the game is going to be probably ini files for saving and loading configuration stuff, and maybe a save game system, if we decide to build that in.

Got another build of Aaron’s part of the game today. As well as already having all the maps set up, he’s now also got the lift UI and code in, so it’s possible to test all the different decks of the ship. There’s a couple of position faults, and wrong lift shafts highlighted issues still to get fixed, but it’s all working pretty well.

I talked him into doing a test run of double speed movement for your droid if it’s moving around on an empty deck. It can be quite tedious wandering around trying to find those last couple of droids when you’ve almost cleared the ship. Wether it stays like this, becomes a feature you can activate, or a hidden thing has to be decided as I like it but he doesn’t.

Time to email and see if i can get someones permission to use a tune of theirs for the game music now. Hopefully they will say yes and also help out with some of the sound effects as it seems they’ve managed to emulate loads of them within the actual music itself.


Project maintenance —

Busy doing other things today so, rather than attempting to write code in a short amount of time, I went through what I actually had to comment it all up so it’s readable by Aaron as well as myself. I have to remember sometimes that I’m working collaboratively now and this stuff has to be done for both our sanity’s. Hmmm, is sanity’s actually an allowed expression? Never mind.

In all seriousness, we’re both new to GMS. We’re approaching using the new system where anything we write could potentially be re-used at some point, just like most programmers. So, as well as writing routines with the mind-set that it could be taken out and reworked for another game, we have to make sure the bloody thing is going to be understandable by either one of us. Because I’ve done this scrolling system with surfaces to use here, Aaron hasn’t wasted his time going off and looking into how to do it as well, or what would be the point of both of us working on the game.

So, months down the line if he needs to do something similar, he shouldn’t have to waste time trying to do it all himself when we already have code to do it. He should now, in theory, be able to lift out this code from our project, and just refactor it quickly, based on the comments I’ve left in there for that exact reason.

Learning a new coding language is hard enough and I’ve deliberately not really looked hard at anything not directly related to what I need to do at that time just so I can remain focused. Hence Paradroid has a brilliant tilemap system coded into the game by Aaron, and I’ve no idea how he’s done it. But, if I look at his code, it should all make sense, once I actually need to do it.

I also started looking for a replacement spreadsheet template to modify for us to keep our development tasks in order. The one we’ve been attempting to use is frankly terrible. Hopefully I can finish modifying this basic one I’ve found and switch over to that before too long. Working as a team means you have to be organised about what needs to be done, and when. This will be our way of doing it.

Next up for me is to fix the inevitable bug I spotted which explains why my surfaces text have not been changing colour. I spotted it while commenting the code but it’s a bit more than just a quick line change so i’ve just made a note to fix it next edit for now. After this it’s going to be loading in the actual text that Andy himself used in Paradroid on the C64 and put that into the game to get the formatting right. I’ve done some editing but left the flavour as true to the original as possible, based on what else it’s going to need to show for our version of the game.

Argued again with Aaron about giving me my big robot. One of these days he’ll get it 🙂

Finally got an email from Yoyo games about the Mac beta of the editor. Beta testing starts 22nd March and I hope I get in at that time. I can hopefully ditch parallels completely then and be able to work much, much quicker.

 


Title sequence update —

Today was a day of pretty heavy research looking into the most effective way to do the scrolling system on the title screen. As mentioned previously, I’ve tried a few different ways with varying success but the general rule appears to be to use a surface to get it done properly. This did turn out to be true.

A development system like GMS 2 works similar to Unity in regard to having a lot of power to automate aspects of your games so you don’t need to manually code them. For example, I found images of the original Paradroid scroll text which had been hacked together probably by someone else who attempted a remake of the game. It was pretty-much the easiest thing in the world to just resize these sprites to the games hard-coded resolution (as it currently as, and will likely need rethinking at some point soon before it becomes too mammoth a task to adjust it) and then set an auto move flag on them to 90. This works in a degree system so 90 = move straight up so placing them on screen and setting the speed would get them moving without any further ado. But I was not in control of what text was built into that image, making sure it was removed from memory once it was out of the bounds of the visibility window, know when the next one had to be put in place and numerous other little things that were important.

So I didn’t like it, Aaron certainly didn’t like it, and that’s 100% “got to go” from the off.

I won’t go too much into what I’m trying to achieve instead, as I’ve documented it previously, but I need the scrolling area within a certain section of the screen, and I can’t cheat and hide bits behind the background as it’s all transparent around the layout as the game is going to be. The game will use all the screen real-estate behind the static sections for level display, score and so on, but scrolling text being visible anywhere but within the window designated would just look a complete mess.

So, a surface was created, a lot of – at present – hard coded areas were setup and temporary text installed so that I could make sure I get the scrolling system in place and working, before I start thinking about the asynchronous text loading and formatting that is going to be required next. Surprisingly, after a few minor bugs crashing everything, it actually fell into place pretty quickly. I had images of multiple draw text lines every frame and then try to pixel move them which, inevitably, it transpired that I was using a surface to actually avoid this whole process.

In a draw event, I just needed to create this surface, draw the text onto it with the correct font and colour, after colouring in the background, then the step event could just be used to draw a certain section of it into the title screen where I wanted it and not have any overhang by trying to cheat. Then I just put in a rough counter to loop the system, add in the routines to colour change the background colour and text colours later on like the original game does.

To me it was a thing of beauty, but it’s probably dead simple to do for someone who’s been using GMS before, no doubt. That’s programming for you.

I’ve implemented the scrolling pause and selectable speeds without going back into the game and checking if it actually did that. For a few lines of code that took maybe 5 minutes to get in place, there’s just no reason to not really have that option. Besides, being able to pause the text is ideal for people who don’t read as fast as the youngsters. IE: Me and other visually impaired people.

So the screen above is what it actually looks like. You can’t see the colours changing, or the actual scrolling, but it does show that a certain area contains the text so I couldn’t cheat and just throw it all up from the bottom of the screen with a black rectangle to hide it, as the border is a custom graphic itself. As you can see, Aarons font is rather nice, when used at the desired size of 32.

This image demonstrates that the scrolling is literally pixel by pixel. When you increase the speed with the cursor down key it does just increment the number of pixels it moves up by, but that’s only logical in a game that’s working of a fixed FPS. It also shows that I’ve got different background colours working ok but I still have a bug in the system that’s changing the text colour. Yellow on white currently looks horrendous.

Naturally the next job is going to be getting the loading of the proper scroll text in and reloading on the fly so I can work out the formatting, due to the different char sizes in width meaning I can’t just use 20 chars per line and expect it to work ok. I have formatting codes within the text I’m using as it is so I will need a rewrite on the hard-coded number of lines the system uses at present, when writing to a surface, or I can rejig the text itself to work round that.

The text itself also needs to go around 10 pixels in on the left and right side to make it look a bit nicer. This looses me some real-estate for long sentences on one line but the trade-off will be worth it. And the other thing I need to be considering now is wether I bring in some of the large robot images that Andrew Braybrook had on his title screen sections during one of the scroll texts being displayed. It would be a lot of effort just for one page but it’s perfectly do-able as long as I can format text around it when it’s on the screen. Maybe have that on the part where the high scores are displayed. It will also give Aaron something interesting to do while getting the right image for me, because I’m sure he’s not busy working on lifts or anything …

I’m tempted to have the title screen with the paradroid logo from the original game display inbetween each scrolling page of text. It will provide a transition between each colour change for starters. If they’re going to be long sequences with all the text in place then it will be a nice break between reading pages of text, for the die-hards who are likely to do exactly that. I’ll probably have a skip key to jump straight to displaying the high score table as that’s the only screen that will ever change once the text is properly set up.

As promised in the previous entry, I have supplied not one, but two pictures of what I’m up to. You lot are just so spoiled 😉

 


Scrolling the title screen with GMS 2 —

Hands up all of you lot that remember the original Paradroid? Quite a few, I suspect, so you’d be the people remember the attention to detail that showed up in the title screen with the scrolling screens of text, use of colour, and even formatting of the scroll text, within the limits of the font size Andy was working with. It’s down to me to realistically improve on this while staying as close as practical in feel to the original.

This isn’t proving as easy as originally expected.

As I mentioned in a previous post, I had all the information screens knocked up into a set of five large sprites for the prototype, and got them up and scrolling pretty quickly as GMS 2 has options for automating a lot of background movement tasks. Using a large sprite to cover the areas of the screen that were unused for anything visual, I would just position the sprites behind the transparent hole in that image, and then let it move off so it looked just like scrolling screens of information about the game. For prototyping this was just fine, but, on reflection, a bit of a waste of time, as I was never going to actually use this system for a few reasons. One is obviously the information on these screens is subject to changes. I was scrolling the original text dumped into sprites, but high-scores are dynamic for starters, so I would have had to have some kind of clumsy system in place to draw this on screen and move along with the sprites to try and maintain the visual effect. Might just as well have all of it as scrolling text, if I’m doing that anyway.

Another flaw with that system was how the original worked. There were several areas of inactivity during the sequence of scrolling these screens of info around, mainly to let the user catch up the reading. I’d have to double check because I’m not sure at the time of writing if you could pause the scrolling while reading but for some reason I am thinking holding up on the joystick actually did that too. My problem with the sprites would be that each one is different in size so there would be the issue of counting down how long they take to work through the text and then putting in the right pauses in the right places before they switched out to start scrolling the next page. Taking into account the screen could be paused too, then it’s a bit of a faff getting all this synched in.

So the sprites as they are have been dumped and, due to Aaron pulling out several of my fingernails, I agreed to use his new font and go with the scrolling text proper option. There are a few pro’s to this, firstly. I can use formatting codes within the scroll data so I don’t need to rely on timing how long things are going to take. I’ll be loading the data in from an external .txt file initially, but maybe putting it all into text strings within the editor once the text content is finalised to make it trickier for the hacker-types. That benefit alone means it’s super-quick to just edit and reload in the scroll text on the fly, within the game, for testing and formatting purposes. And it does give me complete creative freedom to jig any of the original text for readability as well. I’ve got around 8 function keys setup to use in the title sequence for various uses, and displaying that information will be much easier as well. Hopefully I can stick a lot of that into the top of screen information box just like Andy did in the original too, however.

So far, i’ve been struggling to find decent ways of throwing this much text around with GMS2 at any kind of decent speed so there’s been a fair bit of code written and then completely ripped out to try other approaches. I’ll get something right in the end but it certainly is proving a lot more challenging than initially expected. Luckily I’m not really on a deadline at present, until the main game gets closer to completion, and I need to start on aspects of that.

I promised a screenshot or two of how things are looking but Aaron has already made a post about the graphics-side of the game today, so I’d just refer you to the link at the side of this page to have a look at that post for some retro-paradroid imagery, and hopefully some of the dark stuff at a later date, as I know he’s ripped it all out and got it into tile maps ready for inclusion in the game … somewhere.

On a final note, I did actually manage to get a tweeted response from Andrew Braybrook regarding the transfer game that doesn’t really have much information to be googled about. I requested that he does one of his blog posts about the creation of it which, if he does, will hopefully help a lot when it comes time to start work on that area.


Paradroid ongoing —

Development is going pretty well on Paradroid at present so, pretty soon, I’m going to be posting up some work in progress of both development images, and the game as it is at present, running.

GMS 2 (Game Maker Studio 2) has proven to be a pretty good system for both of us to work on individually, but we’ll both be happy when we finally actually get a Mac version of the editor to save running under emulation to develop. My machine is quite old now, and I’m unlikely to get an upgrade any time soon because, even when Paradroid is finished, we’re not going to get any money for it. So I’m working with the IDE that’s a bit sluggish as it runs through Parallels, and also has a knock-on problem that having the system up and running for more than a few hours does start to make everything chug, even Mac applications. It’s doing some pretty impressive stuff, so I can’t knock it, but usually I can keep my mac on for days on end before a restart. Maybe once a week or something similar. But now I’m almost having to reboot before every editing session just to keep things moving.

On my system I do have all sorts of other stuff going on which probably doesn’t help. My back up system was a convulted, automated mess, until I got round to rejigging all that the other day. There’s also the QNAP linked up, that i’m ferrying stuff back and forth to that also probably hogs things a bit.

But enough of the woes. I’m making this post to update on the game progress itself.

Aaron and I get together once or twice a month at his house to work through tricky code problems together on his system and we always hold what we call business meetings down at the old local pub. That probably doesn’t sound much like getting work done but we find it vital for sharing ideas and discussing what we’re both going to do next. We’re now working our tasks for Paradroid between us and keeping it all documented on a spreadsheet so there’s an instant visual clue when we need to check on each others progress without constant phone calls, or emails. From our own perspectives, we also use this to keep in mind what needs to get done next as there will be highlighted areas of the game that Aaron might colour code to show me that he’s finished to a point with some area, such as mini-map graphics, for example, and that he needs me to code them into the console display routine before he can put that part into the console control code he has. Very rough example but it helps a lot with prioritising, so he’s not waiting to do something important while I work on something that can be done at any time.

With Paradroid there’s soooo many different intrinsic little features that need to be done to get it playing like the original that I’d bore you all silly listing everything here, but I can give an idea of the stuff that’s done, or almost done. If I broke it down into a percentage then I’d probably go to 40% because the major part of the enemy robots running around hasn’t even been started as yet, and there’s a transfer mini-game that I’m holding off working on until I get the other parts of my end finished first. I do suspect that’s going to be a beast to try and clone so I’d rather be more familiar with the syntax of GMS 2 first before I dive in.

The maps are all in and 001 is happily moving around in all of them. They are actually all stored as part of one big GMS room so 001 can be shifted anywhere once he’s gone into a lift, without making things too much of a pain in the butt. There’s a lot of work still needed to control aspects of each deck itself, as they will need seperate data to keep track of what droids are still around on each one, and if the deck is cleared or not. But it has made it easier to get 001 to spawn in a random position over the first four decks which the original game does.

The front end title screen funky scrolling screens have all been prototyped and i’ve had them up and running almost like the original game. I used images for the whole text based on snapshots from the original game to build up the entire sequence, but after some lengthy discussions, Aaron decided that we could make things much nicer with our own Paradroid style font, and to build them up as actual text. This does mean that I get some freedom now to work in some changes to the original screens, even if it does mean a lot more work to build a whole new organised sequence. It also means the design of the title screen background itself is going to change but I’m keeping as much of the original text as possible. It’s just going to look better with Aaron’s new font.

One of the first decisions we made when we decided to remake Paradroid was to try and emulate the game as close as possible. We’re still going pretty close when it comes down to it but we’ve opted to negate the aspects of the game that were done in a certain way due to the hardware restrictions of the C64 itself. The most obvious one is the map viewing size. We’ve got that running over the whole display area, rather than half the screen, which it looks like Andy resigned himself to in the original, just to keep the speed up. We don’t have that issue so we’ve kept the big area with the paradroid logo, but it’s transparent in areas so you’ve got a bigger view area to look around for droids in. It makes perfect sense to do this as we can adjust the difficulty to allow for the minor player advantage this gives at the end, anyway.

The graphics for the project are mostly done. Aaron’s done most of his work on this and the tilemap system as it’s the biggest part of the game by far. The collision detection for static objects and location settings for lifts and consoles is all there ready for me to add in bits, and apart from some minor alterations on the maps to move them apart a bit, they’re all done. The only reason we have to move them is because we’re using the whole screen and there are certain areas on certain decks where you can move into a corner and see parts of other decks just creeping into view at the edge of the scroll. That’s an immersion failure right there and Aaron is far too much of a perfectionist to just let it slide. Another part of the graphics to do is minimap parts and emulating some of the look from other editions of the game that were made. Competition Paradroid for example. And there’s a lovely dark metal version out there with a modified intro screen that I want to stick in as either a hidden feature to unlock, or a random display in the title screen attract mode.

001 himself is moving around quite happily. This is probably because we haven’t got bad guys in there trying to destroy him as yet. All the collision areas have been tested and tweaked, and we’ve made it work better than the original game which sometimes moved into walls or appeared to bounce as if it had gone to far into something and had to shift back out. We shouldn’t have that in our game. Aaron has also got the horizontal and vertical doors opening and shutting perfectly. This has been carefully done so it will work with the enemy droids exactly the same so, like the original game, you’ll be able to see doors opening and shutting in visible areas of the map, but not the droids themselves unless they are actually in a location where the 001 can physically see them. This was a great system in the original game as you could know a droid was in a closed off room as the door opened/shut, but you wouldn’t know until you went in there if you were going to scrap with a 139 or a 999. That definitely made the game more exciting.

As for other changes to the original game, i’m taking the opportunity to make the game a bit more up to date with modern expectations. I’ll put in a 5 place high score table as the original game only had the best of the day, and the worst of the day to taunt you. As we can save/load data with ease, we can save this kind of data along with redefined keys, which I’m going to add in. That is mainly because Aaron’s got it running of WASD which does make sense, but for some reason I like playing this with the cursor keys. And we may as well cater for everyone on something trivial like that.

Paradroids title sequence also had options for colour corrections and some cheese mode which was for screenshotting. We’ll probably switch off the animations in pause mode anyway so screenshots won’t need anything like that. The usual options for sound/music etc will all go in too. Not that we have any media like that yet, apart from a paradroid tribute MP3 I found but I wont be using it unless I can locate the author and they let me.

As touched upon earlier, we’d like to possibly hide a few things in the game. I may expand on this but that depends if Aaron will let me. Doing something in a hard area of decks may make interesting things happen is all I’m going to say for now. But these wont be decided and implemented until the rest of the game itself is in place for sure.

Next post will have something visual, I promise. I’d have posted up a screen dump of my testing title sequence but it just didn’t look nice enough before we decided to change the whole thing anyway.