Xerra's Blog

Drunken coder ramblings

Envahi continues —

Some nice Airwolf music goes in today as I got permission from the composer to use it for this game. It certainly sounds good when I play it on the hacked together title screen.

Took the unusual step of putting together the screen that shows when the game first launches today. I wanted to use the retro-evolved logo with the website name and state that the game is an entry for the competition and it gave me the opportunity to work on the logo some more. Not totally happy with it but it’s a lot better than it used to be.

My better half took a look at the elements I’e cobbled together so far and suggests – tactfully – that it all looks pretty shit at the moment. I’ve done a piss-poor job on the two large helicopters that hog the front screen and she’s pretty adamant that something more detailed should be there instead. As I’ve been considering having maybe having one bigger helicopter moving back and forth behind whatever I do on screen anyway, I concur. I explain it’s placeholder stuff just to hold the title screen scene while I work on the actual game scene.

She then reminds me that nothing of the sparse game that’s currently there has changed in the last 3 days so what have I actually been doing. It’s background stuff like making sure the lives counter display works correctly and I’m working on having the scores all a certain number of characters and padded with zero’s so everything lines up neatly.

Think that all fell on deaf ears. She’s waiting for me to make the damn flood the city which is a long way off yet. I still have 9 weeks and a couple of days, right?

Anyway, background stuff is being written that will make things much quicker once they start being put in. The state machine I’m creating already works a lot better than Boulderdash and I’m using one hud element for all the scenes in the game now to make editing much quicker. Definitely going to lighten up on the amount of scripts I use this time as well.

After the honest opinion of how the title screen looks right now, and the fact that there’s not enough game to really show off yet, I’ll leave the screen shots out of the blog for now.

 


Envahi – Day one —

Tuesday January 30th, 2018

Boulderdash – as close as it is to completion – is going on hold today as I’ve decided to enter a competition to code a small game based on either a TV or Movie theme. This competition is being run by the Syntax Bomb website which is frequented by a lot of ex-Blitz programmers who moved on to other things.

The competition gives you 10 weeks to get your game completed and up onto the site where there is two weeks of judging before the winning three games are chosen. I love the idea of a deadline in this case because I need to push myself to get a game nailed down and this will do it. I’ll be back to finish the current project after April the 10th and I think a break from it is probably going to do me good right now anyway.

So, I gave it some thought with the competition rules, and am going with the theme of Airwolf the TV series and Dambusters the movie. This is because I’ve been itching to do a remake of one of my favourite Vic 20 games which has elements of both. I’ll go with Airwolf as the topic because I like the music and want to use a remix for the game, if I can get a decent version and permission to use it.

First things first was to get a basic framework together before I start actually coding it. When I define start it’s getting the project together, putting all the assets in place and going through previous projects to see what I can pull out to use in the new game.

Envahi is a remake of a Vic 20 game I bought and played in the early eighties. It’s not particularly well remembered, judging by the lack of solid information about it via Google, but I had only just got my machine back then and this was one of the best Vic 20 games for me. As this game is a remake, the basic game design is already there. I don’t want to really do much to change it too much so I don’t really need to plan too much apart from different screen sizing, what elements I want to carry over and where I’m going to get them from. Or if I can get away with coder art here – bearing in mind it’s a competition so would be judged on that.

The original Envahi was probably knocked up using VicMon or a very simple assembler back then – a credit to the author for what he actually got out of the Vic in 8k. Luckily, in this day and age, we don’t even have to think of issues like that, and I’ll be putting it altogether in GameMaker 2.

So what’s the game about? Envahi is a static screen shoot’em up where you have a helicopter that you are flying to try and defend a damn from aliens that are crossing the screen trying to take chunks out of it. I think there’s an element of Cosmic Jailbreak (another classic Vic 20 game) in there – possibly the author, Jeremy Walker, had played that game and was influenced by it. The damn naturally is protecting the city below from getting very wet should the wall get breached.

Luckily it takes 3 bites out of any section of the wall before the water can escape but if it does then it will flood down out of the damn and drown the city.

No pressure then…

As well as the Nibblers attempting to take chunks out of the dam you also had other aliens out to try and get you out of the way so they could destroy the city.

Grabbers – these drop straight down the screen to get to your y-axis and then move horizontally to your position. If you don’t go up or down pronto then you’re lifted off the screen and the dam is left unprotected until the nibblers breach it.

Droppers move slowly down the screen and randomly left or right. They are pretty simple to take out as long as you can avoid everything else happening while you do it. Your helicopter is hindered by only having the ability to shoot up so some pretty deft movement is required.

Clouds appear randomly in the top-center of the screen and start dropping acid rain which will screw your helicopter electrics up and destroy it. You can shoot them but you’re going to have to be pretty dexterous to do this while avoiding the acid.

UFO will go left and right across the top of the screen creating droppers with some kind of regularity based on how long the player has been playing so the game gets harder.

Nibblers are the little buggers that move from right to left trying to bite chunks out of the Dam.

Zoomers are enemies that ignore the dam and just move left and right while moving down a line at a time when they reach the end of each x axis. Kind of like Space Invaders do. However, these are a lot faster and are murderous to take down in the original game.

There should be enough there to keep anyone who plays it busy.

So, because we’re dealing with an already set game plan, I just need to convert it. This actually makes it easier, apart from getting a difficulty balance right, because, just like my last remake, Boulderdash, I’m copying what someone else has done. And then just modifying parts that I think could work better if done a bit differently – although I don’t think I’ll be doing too much of that as the original was so good.

One idea I have had to mix it up is to change how the helicopter is affected by the acid rain from the cloud. The original game just destroyed the helicopter if you hit it but I’m thinking some kind of energy shield system could make it a bit more interesting as tactically you may need to get through that cloud in a hurry. Like if a nibbler is about to take a third chunk out of a wall segment, for example. I’ll decide on this when i implement the clouds and collision but plan for it now when considering the layout of scores and lives data, just in case.

So today’s job was to get the project up and running and get as far ahead with the assets so that it will be mostly about the code going forward after today. I have mostly achieved this which can be seen by first screenshots further down the page. I have most of my sprites in place, the tiles for the water effect (not working correctly but it’s there), some of the sounds ripped out of the original game, a mocked up city built up of public domain building sprites and my helicopter is in place ready for battle. I also did a logo for the title screen, got the image in place there of the big helicopter I already planned to use and animate then finally the basic framework of the project. This means all my slap-dash Boulderdash code has been dumped into the correct object, scripts moved over and basic title to game to title transition in place.

In my head I’ve already mapped out how both the title sequence is going to go so I’ve got extra images for that. I plan on having some bullet holes mark the helicopter with appropriate sounds before the title screen music kicks in. I have the original jingle from the Vic 20 ripped out but I’ll just have that play once on game over or something as a tribute because it can get pretty annoying.

I’m sure posts on this project will be just as spread out as the previous because my working time tends to vary wildly due to work and other commitments but Envhi isn’t a game that should take long. It will certainly be nice to see this one take shape a lot quicker as it’s now my third game using the GMS2 development system.

 


Don’t speak too soon —

Warp butterflies have returned with a vengeance. I’ve worked so much on the AI for these things now that it was inevitable that I’d get the bug coming back as I’ve rewritten the bloody script so much. They mostly still behave, however, so I’ve left them as they are and not ported the script to get the fireflies moving as well just yet.

Going on to other parts of the game in the meantime, I started working on another major part of the game now that the level end sequence had been clubbed together. This was the start sequence where the cave appears at the bottom right of the map and scrolls up to where Rockford is going to appear. This also has some zany random tile effect all over the screen which I’ve attempted to rectify, with mixed results. Sometimes I’m happy with it and sometimes it just seems to look shit. At least the core code is working so fine-tuning can be done relatively easy.

It was murder putting the start/end level sequences into the main game state as I hadn’t planned them ahead and had all sorts of problems with the main game functions still being active and screwing up how they worked. I’ll plan well ahead next time with stuff like this.

Because they all work rather slowly at present, bonus countdown and scrolling stuff that is, I’ve set up the fire button to just skip everything so player doesn’t have to wait around between lives. A pet hate of mine as the game’s hard and frustrating at times already. Why rub it in?

Also finally looked up and put in a full screen toggle switch on the title screen. I used the space on the title screen where the function keys that never actually ever worked used to display instructions or credits sequences if you press them. Talk about false promises. Both of those parts still aren’t in the game.

If the AI problems go on much longer then there’s a good chance those will be written first as well.

Sooner or later I’ll run out of tasks I have to do from the road plan and then I’ll have to knuckle down on the AI or I’ll never be able to actually release the game.

 


Warp mode butterflies are extinct —

Finally tracked down a nasty bug today which has been in the game since I first added the butterfly movement routines. Due to me using tiles for all the game play objects in this game, I’ve had to write a particularly long and cumbersome script to handle the movement pattern of the butterflies in-game. Currently it’s the only moving enemy in the game, even though fireflies are still present where they should be.

According to research on the original game, the fireflies used an almost identical movement pattern so my plan was to get the butterflies right and then copy the routine for fireflies, just changing the object references and tweaking them to work slightly different. As I’ve had this bug with the butterflies, the code isn’t working right, so there was no reason for me to move it over yet so the fireflies just sit there right now.

This is very noticeable, even playing the early levels, as you actually encounter the fireflies in level 3, one before the butterflies.

So, the bug was a problem with movement in two directions, where the butterflies decided to not move one square at a time and actually warp straight in that direction until they could not go any further. Effectively, they cheated and it was flippin’ obvious.

The code is rather large for butterflies movement,as there’s so much  to keep track of. The only collision system I can really use with tiles is to have the same tile image but have four different ID numbers so the routine can work out where it’s meant to go depending on which way it’s currently going. If you’re moving up then check left and go that way if there’s an empty tile. If you’re blocked going left and up then you need to switch the tile image to the new id number for moving down and let the script start checking for the next butterfly.

I expanded on my already powerful in-game cheat mode to allow for butterflies to not be able to kill Rockford and then ran the butterflies all over the screen to watch their AI movement and look for further errors. Apart from randomly coming to a stop for no-good reason the AI does currently seem to be working as intended. So, hopefully it’s just that one glitch to fix and I’ll have another major part of the game in and working.

 


Boulderdash the 96% finished project —

Time for another update as I’ve mostly slacked since Xmas but have still been beavering away at Boulderdash to try and get it finished. Suspect I’ve taken longer to work on my version than the original game was coded now but I’ve added elements to the project so that’s my excuse for being at the almost-finished line for at least two months now.

Since the last update I’ve put in a couple of the key systems which I’d been dreading due to the way I’d set up my game state system. I’ve gone on about this before but Boulderdash is the first time I’ve ever tried to code a game using this method and I don’t think I’ve done it as well as I could have. Coding is all about working on something, getting it going and then making it better the next time you do it, so I’ll definitely be doing that.

As it currently stands – and I won’t change it for the game as is now or I’ll never get it completed – Boulderdash is built on a huge amount of seperate files. I’m using GameMaker 2 so this is by no means unusual, but I think I’ve taken it to extremes with how I’ve put the project together. I’ll elaborate to make it easier to get an idea of what I mean here.

Firstly I have four main objects in the project. There’s a few others for incidental things, like the stars animating over the title screen and things like that but the main objects are the Game Handler, Title Handler, Game Hud Handler and the Title Hud Handler.

The huds are self explanatory and are used to draw text elements over the screens for both rooms. Both the title screen and the game levels make extensive use of tiles. All the gameplay elements, for example, are tiles, hence the blocky nature of the game and why I’ve not actually put in pixel scrolling as yet. And possibly actually won’t because it’s not working right with how the game works and feels way too slow. Anyway, I digress. Where text elements are needed to be drawn on these screens of tiles, I’m using the gui layer and I’ve found it’s easy for me to have all the text printing stuff in the handler and just have conditions to dictate what elements are drawn and when.

In the title hud handler, as an example, all the code is in the step event to display the high score, score and stuff like “press fire to start”, level, selected map and so on. Naturally it’s not all displayed at once but the code is all in that one big step event for anything and everything that could ever need to be drawn. Like cheat mode active for example. I’ll have a keypress event in the title handler object to process the level has incremented and the step event in the title hud handler already has the code to take that info from it and display the correct level accordingly.

As it’s an object handling all this background text stuff I just have to drag it onto the title screen to have it working.

There’s an argument here that says I could be using the step event in the title handler and setting up the gui overlay within there but I haven’t done that here because I’ve always done it the other way but I can already see that it’s probably easier to use one object so cross-referencing isn’t required. Or even have a global hud that draws all the game text data regardless of wether it’s used on the title room or game room.

The game hud handler does the same thing obviously and all elements of the game are run from the game handler itself. So, due to the game being made up of caves, I decided early on , after a little advice from Aaron, to create a different room for each cave, rather than have the game handler do the cave creation stuff itself. So Boulderdash currently has 20 rooms for the game levels, a room for the title screen and an empty room that’s never seen but runs at the start to create all globals and set up loading/save data and all that other stuff nobody ever thinks about.

I’ve just had to drag the game handler object and the game hud handler object onto each of these rooms as I’ve built the levels with tiles based on the map layouts of the original game. Again, this shows another area where possibly I could have made things easier with one global hud handler object but, even if I’d done that, I would still have had to drag both objects into each room.

The problem I’ve developed – if I can call it a problem – is that I’ve had the idea in the back of my head from when I started that I should seperate as many elements as possible of the gameplay and put in scripts for each one outside of the handlers to make it easy to work with the problem elements. For a game with multiple different enemies and objects (walls, Amoeba , rocks, gems , borders etc) this made sense but as i’ve built more and more into the game, it’s become a few objects and something like 30 scripts – most of which are to do with tiles processing. I did originally try to write one big object handling script which was a disaster, so it’s easy to see how it got this way, but the temptation to throw it all back into one now the elements work seperately is very tempting. It does put me in very good stead if I ever followed this game up with a sequel. The original Boulderdash has had loads over the years. I could literally just pull out the scripting and build a whole new game around these learning from mistakes made this time and incorporate the construction set element that Boulderdash on the C64 finally got in the fourth game. I could do it now but opted not to as I have used seperate rooms for the maps for this game.

I possibly got off track with what I was originally waffling about but to me it does seem that there’s valuable lessons to be learnt at every stage of game development rather than assuming most mistakes would be spotted early. I could go back through the project now and redo the whole thing massively optimising it with my new-found knowledge but it would take me just as long to recreate it much tighter. Nobody would notice any difference either as the game would run at the same speed regardless. And I’d probably break half the stuff that does now work by trying to do it.

Aaron had a similar situation when he was building the decks for our Parardroid remake. Once the work was all done and working well, he had a revelation on how it could be improved in the project to make it much easier to work with but the code was already there and working anyway. So why reinvent the wheel? Just hold the thought for when you maybe make the sequel.

So Boulderdash now has the transition from title screen to starting the first level working. I’ve got to put in the scrolling/tile warping thing that the original did still but I’ve mentioned before how I wanted to change the logo into rocks then drop them off screen when the game is started and that’s what’s now been implemented. Again, it’s knowing where to stop when doing stuff like this. You can keep adding fun stuff forever but in the back of your mind there’s always more important stuff to get done before you should be playing with those bit. Like getting the AI right, in my case.

Ending a level does the bonus countdown now, which can be skipped with fire if it’s a bit slow for people. It’s now more obvious that having the timer on is going to make a nice score boost for the people who want to get better highscores. I put in code to save the config settings and high score / last score now too. Just for those guys.

What I’m looking at now to call this thing done is still the AI fixing, magic walls, Amoeba and the credits page, which I’ve already got drawn ready to slice onto the screen, once I think of how I’m going to do it. Mustn’t forget the level loading in tile/scroll system. Apart from the AI, that’s the bit I’m hating working on the most as it’s not come together yet.

So version 0.23 – as I have it at present – builds, plays and feels almost like a complete game now. If it wasn’t going to have enemies in it then I could throw it out there now and move onto the next game but it’s never that easy.

As I said last update – almost there…

 


Getting near Xmas —

It’s getting near Xmas now and, like everyone else, there’s lots of stuff going on that has made Boulderdash development a bit slower than i would have expected.

So, time for an update, so everyone can be sure I’ve not actually fallen asleep.

To start with this month, I’ve been mainly working on the AI issue with the Fireflies and the Butterflies. They work a little better now but are still prone to cheat by accelerating to warp speed for no logical reason. Additionally, there’s still some problem with the game processing that lets them sometimes get away with a rock on the head.

I’ve also had to work a lot more on the sound as, while it sounded crazy and mad to me, Aaron thinks it’s too random and distracting from the game. Looking further at the original, I could see straight away that some sounds should have been impact only, not constant when events are in progress, such as rocks falling. I’ve tightened a fair bit of this up now but am also playing with sound editors so I could possibly go to sounds far more consistent with the original. There’s also a couple of game elements not in yet which are sound-enhanced so I was using stuff when it wasn’t the right time as a result. So there’s a bit more work to be done on this area.

Another major part of the original design has now been mostly finished – apart from maybe some slight tweaking – and that’s the transition from the title screen to game start. I always had it in mind to change the logo into rocks and have them drop using the game script for processing rocks. In the end I had to modify it a fair bit to get it doing what I needed, as the background has to scroll up the opposite way. This sequence will also be used to clear the title screen logo area so the credits can scroll through it so it was worth getting done now as I’ve finally built the credits screen image to run through it. I’ll be using Paradroid’s surface code to get that running before the next update.

These changes have shortened the to-do list nicely and I’ve got my mind-set that the game is feature complete so I won’t be adding to it. There’s still the magic walls and Amoeba to put in and the start/end level bits to go but not much else apart from more testing. Once the AI has finally started behaving then the end is definitely in sight.

Happy Xmas one and all.


Boulderdash is coming… —

As mentioned in my last post, I’ve been quietly working on a remake of an absolute classic C64 game – Boulderdash. Before I go into what’s been involved in remaking this with Game Maker Studio 2, it’s worth you firing up an emulator – Vice is perfect – and playing the game itself. You’ll learn a lot more about it than I could ever explain here – and it’ll be fun too.

Boulderdash came out around 1984 and was probably one of the most addictive games I ever played. It wasn’t very easy – certainly not for me – and I never got that far into it. The playability of the game, however, was damn-near perfect.

In execution the game was simple enough. Use your extremely well animated main character, Rockford, to move through scrolling maps, collecting gems, avoiding falling objects and sometimes participating in little puzzles built from the game object. These usually consisted of manipulating rocks into magic walls to turn them into gems, and destroying fireflies while converting butterflies into gems, while avoiding them killing you.

There were only 20 caves in the game – four of them being intermission levels that came up every 5th map, but the design of these caves were merciless. A great example was the punishing third cave, which required very careful movement to not block yourself in, and you needed to collect every gem on the map or you couldn’t exit. Not to mention probably my favourite level, eleven, appropriately named Greed. Here the opportunity to collect gems en-mass was so tempting that you mostly ended up either trapping yourself, or getting killed, just because you had already picked up more than enough gems to complete the level, but you just had to push your luck.

A wonderful game and it didn’t take Aaron much effort to persuade me to at least have a crack at doing a remake of it. The idea at the start being to learn about using tiles while our #ParadroidRemake was on hold. More on that at a later date but we will be finishing it soon.

So, in my last post, I did mention that I was mostly there. I was probably around half done at that point, as I’d finally got the main background processing working correctly, which translates to objects all moving correctly based on circumstances around them, such as gravity, and where they are. It’s harder than it sounds – trust me.

Where am I at now?

I can be a bit of a perfectionist with game development, and there’s always the tough decision on deciding just when you actually are done that I struggle with. Luckily I’m not quite at the point where I need to start thinking about that with Boulderdash just yet. I’m currently well into the last 10%, and any game developer will tell you that it’s 90% of the work to get that bit done. This is definitely true for this game so let me go over what I’ve actually done so far.

Firstly, the background engine that’s driving the game is all in and working lovely. I converted all the images for the original game into 16 * 16 tiles, put in a screen resolution of 320 * 216 to match a C64 and then put the window for the maps into a width of 640 * 368. This is consistent across each game screen as the smaller levels use steel squares that are unbreakable to stop Rockford going into places he shouldn’t. From the start of the game I opted to use every moving part as a tile, rather than use sprites, which has been good for some parts but, right near the end of development, caused more than a few problems developing the AI on Fireflies and Butterflies. More on that later on as well.

Cave 1 was then created using an image of the original as an overlay so I could replicate the original design into my own level. After this I got the code in place to put Rockford on the level and move him around so that scrolling and other stuff could be implemented. I did toy with the idea of pixel scrolling as per the original game, but I found it a bit slow, so left it as blocks to make the game pace feel appropriate. I’m still in two-minds as to revisiting that and changing it again.

Now I had Rockford in place so I turned to one of what ended up being the hardest parts of development so far, which was putting in the gems and rocks processing. It was a fantastic feeling when I finally was happy with that, as it took over a month, and I had all sorts of curious bugs along the way. The way the game now works is mostly on a script system which are all executed via the main processing loop that is already handling stuff like variable game speed based on the skill level selection.

I read some great tutorials about using a state machine which seemed to be the best idea of doing Boulderdash, because there’s a lot of the game background stuff that is always happening, regardless of what the player is up to. For example, the rocks and gems carry on doing what they’re doing when Rockford dies and the game is waiting for you to press fire to restart map. So I’ve used different scripts to parse the map for each game object just so different behaviour can be adjusted for each one. As an example the rock and gem movement patterns are almost exactly the same, so once the rocks were working correctly, I could just copy the script and change the identification macro to implement them as well, and just modify their behaviour when they hit a magic wall, compared to how rocks reacted.

Technical types here are probably now mumbling to themselves about processing power and how this isn’t really an optimised way to do it. You’re right, and originally I did have the gigantic wall of code that attempted to do everything. A great wall bigger than China’s, filled with if / else conditions that was both a nightmare to read and format, and more trouble than it was worth. Especially as I never had it working 100% anyway. So, after breaking it all up into seperate object scripts and testing, it didn’t make the slightest difference to the game speed, even though i’m technically reading through the entire map at currently six times each frame.

What people tend to forget when writing games is that modern machines can handle so much more than people realise. Game Maker Studio 2 – which some developers probably wouldn’t even take seriously – can do a shed load more than what I’m currently asking of it. Games throw infinite amounts of polygons, data, textures and processing than my little Boulderdash remake. And this is based on a C64 game which ran in around 54k of machine code on a computer built in 1982, which it was designed specifically for. If I tried to process the game loop on an actual C64, where I run through the map 6 times on each frame, then I’d be running out of scanlines at the very least, I’m sure. But this kind of thing is just something we don’t have to think about any more and I’ve struggled before accepting that, so maybe this is my way of finally getting on-board.

What I will say is that I’ve got four difficulty levels built into my game, as it stands, and even the hardcore mode doesn’t let it run at the fastest speed it can, because it would be almost impossible to play. The way the game has been written is so much easier to debug now as a result of being looser with the code. Before I would compare debugging that great wall of code to actually getting a toothbrush and going to China to clean the real thing.

So, I digress. Rockford was finally now digging his way through the map, rocks falling when they should and gems were being collected. That’s almost the whole gameplay built in at that point, if I had the enemies in as well, but none of them feature in the first cave so I worked on the exiting level conditions, putting in systems to handle the scoring, extra lives and some kind of display of the game information for the player.

I took a bit of creative licence with the game timer and made it configurable at this point. Although most of the levels don’t really get that affected by the timer in the original game, I’ve always felt you could play it two different ways – if the facility was there to make it optional. Strategy players that just want to get through all the levels and don’t like being rushed into making mistakes can turn it off. And the guys who like it a bit more challenging can leave it in and then race through the levels as quick as they dare, because they know that there is a timer bonus applied every time they hit the exit, if it’s switched on.

By this point I had put a basic front-end on the game as I had the level selection and timer toggle as flags already so wanted to get them built in the game with some other options, such as cave selection. At present I let the player choose any of the 20 caves to start in but I will probably flip that to make it run like the original game, where you can start after each intermission screen instead. So Cave A, F, K and P will likely be the only selectable ones. I did mention that K (number 11) was my favourite, so I’m glad that makes the cut.

After this it was time to put the rest of the caves in. This was another couple of days of work and I’m still finding little bugs of the data-entered-incorrect variety even now, in play testing. I’m pretty sure they are mostly debugged now, however.

Entering and exiting levels has been implemented now, which really was the final part to do to actually have it as a working game, even though I did have my hidden level skip cheats to use until that point. This is probably the main area I still need to do some more work on, as I’m hoping to emulate the scrolling, random tile cycling effect that the original did for transitions between caves.

Next up was the smaller bits which I had listed as I worked, such as high score recording, the animation of Rockford, such as the delightful animation he does when you don’t move for more than five seconds, and other little bits in the background.

I went to the title sequence then to start trying to improve my coder art as well as emulate the scrolling background characters that the original had behind the logo. This took a lot longer than expected due to trying so many different background graphics. I’ve also got it in my head to switch the tiles of the logo out to rocks and collapse them all when the game starts – another reason why I kept the rocks processing script separate. I’m still unhappy with the whole title screen look as it stands so this is another part of that last 10% which needs addressing. I don’t have a credits or instructions screen in yet, which were always on the cards to put into the game at the original design plan I had.

Another major part was then approached and I spent a creative afternoon playing with BFXR coming up with some suitable sound effects within the game. I’m a bit unsure about some of these, as is Aaron, so I may have to revisit here when I do the final polish on the game. I did have an mp3 of the original theme tune but with no author details so I’ve opted to use a little alternative tune instead, which does have author permission to use elsewhere – just in case.

So, after all that, what do I realistically still have to do? I’ve mentioned some of it but there’s still further work to be done to get to a state where I’m happy to put the game out there.

Enemy AI:

I have the butterflies moving by looking at information researched on the internet. They are not working correctly, though, and tend to cheat a bit, so I’ve got more work to do there. The Fireflies movement is almost the same, so it will be a copy of this code with some small changes to have them running too.

Magic wall:

This is used in a few of the maps – especially the level 20 intermission screen – where you have a puzzle based on one of these. A magic wall basically converts rocks into gems and vice versa, so there’s strategy involved in using them. Especially when they only activate for a short time. I have the walls in place on all the maps but no code yet to get them working.

Amoeba:

These are also only present in a few levels and are the pulsing green goo that expands to a certain point and then converts into rocks. The gameplay element of this was that fireflies or butterflies touching it would turn into diamonds, so the level had to be opened up enough by Rockford so that the enemies could reach it. That way he could get enough diamonds to complete the level. I still have this to code into the game.

Start/End level sequence:

At present game just jumps between levels instantly. As I mentioned before, I need some kind of decent transition between caves, which I need to implement with the state machine in the game.

Credits/Instructions screens:

I’ll be putting these into the game near the end as I’ve got some friends testing the game, and I also don’t know if I’ll change anything regarding the AI, so don’t want to write an instructions screen until the gameplay is all finalised. It will probably be good to wind down with these tasks as the last bit of the game before final polish.

It doesn’t seem like a lot’s left to be done but remember what I said about the last 10%. I’m not putting a timetable on this but progress is steady so I’m optimistic I can give it away pretty soon.

 


Another quick update —

Sorry for the lack of posts over the last couple of months. I didn’t realise it had actually been this long since my last post on the #ParadroidRemake we’ve been working on for what seems like years now. In reality it really hasn’t actually been that long, but my partner and I have gone through the dreaded moving process, which meant all the equipment packed away, and all sorts of “more important things to do” than tinker on the computer as soon as my desk was setup again in the new house. And I do as I’m told 🙂

 

So I’m at the point where I consider the title screen stuff finished, bar adding in any controls to adjust options, which is going to depend on Aaron’s final design. What I’m currently doing, short of revisiting the transfer game, is waiting for the last big part of the game to go in.

 

Aaron is handling the major job of getting all the droids onto the maps, and moving about. I’ve been doing some play-testing with the latest build to see them in all their glory, but there’s a lot of AI work to get done before they actually behave like robots. At present they just sit there while you shoot them. Not exactly exciting gameplay there, at present.

 

Aaron is trying to do his best to emulate similar conditions in the game to how the droids worked on the original, thanks to some help from Andrew Braybrook himself, when he blogged a lot of very useful information after we asked him. If you’re not following him already on Twitter then look up @UridiumAuthor – and there’s also a link to his great blog in my sidebar.

 

Before going back to the transfer game, we decided that it would be fun for me to visit an old classic C64 game to do a conversion using just tiles as a learning exersize as he was on holiday anyway. So I’ve gone and had a go at Boulderdash – just for the hell of it. I plan to put up a proper post about my work on this along with some other stuff I’ve been doing as well over the last two months, as they deserve more than a quick paragraph. At present my conversion of the C64 original Boulderdash is around 95% complete so, as any game developer knows, I’m at the hard bit now where it’s got to all kick together.

 

True to Aaron’s conditions, I did indeed make the whole game run from just tiles. I’ll be putting it up here with my other games just as soon as it’s finished. Current deadline – imposed by my partner in crime – is end of this month so I’ve got five days left… Thanks for that !!!

 

I am quietly confident the game will be complete by then, if lacking in some polish, but I can always revisit at a later date to sharpen it up. I’m not looking to get sued either, so you lucky people get to play it for free, so I’m not getting any money from a game that still has new versions released by the original publisher themselves, every so often.

 

I also have a pretty good idea what game I’m going to do after I’m finished #ParadroidRemake and Boulderdash. More on that once these two projects are behind me, of course. Naturally it’s a remake of an old classic. As I love retro games and the challenge of recreating them. This time, however, it’ll be from the Vic 20 era, so again a chance to play with tiles as the Vic 20 had no sprites.

 

Finally, as you may have noticed, this site has been moved. We’ve moved away from the commercial side of our company for this work, as it’s non-profit making, so I’m using my own domain for my stuff. All the links and stuff should have been fixed here by now but feel free to report if there is something broken with the change.

 


Title screen —

So finally I’m getting around to talk about the title screen work I’ve been doing over the last couple of months. In all I think there’s around 10 – 15 hours or so I’ve devoted to this part of the game since I shelved the transfer game to come back to it later.

You may recall that this was initially the first part of the work I was doing for Paradroid which I half did before deciding the transfer game needed to come first. Minds change and all that and it was a bit depressing coming back to the code I’d written and finding that it had been pretty poorly written. It did what it had to do but it was the first code I’d ever written with GML and I literally had bashed together the main event and kind of thrown bits on ad-hoc, when needed, without rewriting the core to make it all work together better. I had loops within loops and sub conditions to branch into doing other stuff and the synchronisation of everything going on was turning into an absolute nightmare.

So the best thing I though to do with it was to take the core scroll routine – which was originally an external script – and rework that into an event so I could build the redesign Aaron and I had come up with around that.

The scrolling system works around using a surface so the original routine had just read the text from an external text file and then written it all into the surface and I then drew it in the display area on screen at a constantly moving location to simulate the effect of scrolling, just like you see in credit sequences in a lot of games. This was smooth enough when actually properly compiled, rather than running through the yoyo games project player, but our redesign called for some imaging to go in as well.

Now this isn’t actually a problem. You can draw a sprite onto the surface and it will show up on screen where it should when you’re dynamically changing the view position. The trick, as with the layout of the text, is to format everything correctly so it looks neat when it’s displayed. I toyed with the idea of working some kind of text/image parser which would work out the width of whichever letter/sprite was being displayed and compare to how much space was left to the right side border of our display area before switching to the next line. In the end I chose not to do this as it seemed overkill for a routine that I’d likely only use once so I moved all the text data into an external script, positioned the sprites by trial and error, and just modified the text lines manually so we didn’t lose any lettering as it chugged along.

This design also used some icons in our console area display for indicating controls like controller/keyboard as well as music/sound and choosing the graphics set – something that will be locked out of the game initially until unlocked. Here’s an image of it as it was then because I’ve now bolted on a seperate options screen for choosing this stuff instead due to Aaron creating a mini-hud for in the game itself.

 

Naturally you can’t see any movement there – mainly because this numpty hasn’t looked at how to insert a video into a blog post yet. The number used for score there will be very familiar to anyone who ever programmed a C64, by the way.

So, since this screen shot was taken I’ve been talked into dumping the icons again so there’s another screen in the cycle which is switched between on the F1 key. It’s a work-in-progress, and ugly as anything right now, so I’ll post it when it’s finished.

The rest of the sequence has also changed to incorporate some of the colour switching that the original Paradroid did at the end of the scroll sequence. I’ve tried to match the colours as best I can do based on emulating it via Vice on turbo speed to see how many combinations there are. Not that many it turns out, probably because C64 colours were limited and Andrew had to make sure that the text was readable on whatever colour was the background. On the image above you can see the mixing of sprites and text as the Dexterity Design logo and the Paradroid text are both sprites. Here’s another screen I saved at the time that shows mixed sprites and text.

 

I’m using one of the droid images here that are in the droid data that’s accessed from the terminals in the game because why not? It’s tempting to use some more of these to do flash stuff with the options screen, perhaps some movement patterns but I’m already toying with the idea of some kind of transition between the options screen switching on and off, so not sure where I will go after that.

At present the main Paradroid intro screen from the original game is shown. After this we jump to the scrolling sequence which presents the entire data from the original game, some of it rewritten to both give a little bit more information, or just for formatting purposes. From this I went with a static screen to show just the best and worst score of all-time which are recorded for prosperity now. People who played the original will know that it used to be scores for the session because most people loaded the game from tape with no option to store scores. That’s no longer a issue so there’s no reason not to.

So, to summarize, I’ve got to put in the save/load scores function, put in commands to change the options and then basically improve the look of both high score and options screens. After that I can remove any bugs and jig the code so it’ll slot seamlessly into Aarons project. If I have time then I can think about doing some more creative stuff just for the hell of it.