Xerra's Blog

Drunken coder ramblings

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.

 


General update —

Hi guys,

Sorry for going over a month without an update. I’ve been so busy with the new job that, while I’ve still been working on the game, I’ve not made time to blog about what I’m actually doing.

At present I’ve spent the last couple of weeks going back into the title sequence I started earlier in the year as we decided it was more important to get all that out of the way before getting the transfer game done. Our reason for this is that the transfer game is a self-containted, mostly scripted, room for the project so, as a result, will be easily ported into the main project once it’s completely finished, and tested.

The title sequence was pretty-much the first part of the whole project that I started working on before I dropped it half-done to try and put the transfer game in place so that Aaron wasn’t held up on his droid code. However Aaron rejigged his development list to work on other areas first and leave that fun part as the last part of the game to go in. He’s almost ready to make a start there but we haven’t tried merging projects yet so felt this was something we should get under our belt now both for future reference as to the difficulties, and so we can both modify how we start projects and handle cross-over elements, to make working as a team go even better with the next project.

So I’ve rewritten almost from scratch the old, poorly written title screen/attract mode sequence to pay tribute to what Andy Braybrook did, but give it a modern update. And it’s looking pretty good now, barring some graphics changes.

Some screenshots and a walk-through of what I’ve been doing will be in the next update – hopefully at the weekend.

 


Who knew walls could be so tricky —

The Paradroid transfer game is actually turning out to be a bit of a bugger to get in place. After a couple of rewrites I’m actually going back to basics and putting the code together on paper to try and get a proper build routine for random maps. At present everything is switched off apart from the generation of walls on one side of the playfield circuits so they can be tested. And retested. And then retested again.

I’ve been breaking it down into stages with this, as it’s so important to take into account other elements around an area before a decision is made to plonk a wall down there. Actually getting it on screen isn’t the problem but it needs to follow the rules so that circuits can be activated through it, and that multiple walls don’t screw each other bit.

Start on the left side of the play area and start reading the first line horizontally deciding randomly wether a wall should be put down or not.

If a wall is to go down then I need to follow this decision up by deciding if this wall will have two circuits leading into it, and one leading out. Or should I have one line leading into it and two lines coming out.

I will then need to check the surrounding blocks to ensure I’m not going to break another walls 3 blocks by creating it. I say will then as I’m not at that part yet.

Decide to build my wall and place the blocks.

Depending on which way round the circuits go – one wire into two, or two into one, I then need to clear either the middle line in front of the wall up until the end of the play section then plonk a closing zapper to tidy it up, or clear the upper two lines behind the wall as it should only have the one wire going in.

I will then need to decide if I have another wall to maybe close off the two sections and then put it into a single wire again, perhaps, just like the original Pardoid did. That will naturally mean rebuilding the middle line again from the wall and this time clearing the lines above and below this wire from the front of the wall.

This is all for just one of the 11 lines going horizontal, so I repeat for the other 10 and will need to make sure that when i put down another wall they aren’t too close to one already down so the circuit would be broken.

After all that it’s going to be running through the board again, looking at each location and deciding wether to put any blockers, zappers or switchers on, and ensuring they are in legal postions.

That all make sense so far? Probably not. It just amazes me how Andrew Braybrook did it back in 1985 – and in 2k of memory using 6510 assembler. I’ve been at this for over a couple of months now – allowing for a real life couple of weeks break I needed to take for work reasons. Yes, I have a day job, too.

The reworking of the walls will fall into place soon, which looks like it’s going to be the hardest part, so I’m hoping the rest will come together much quicker after that. It’s a good job Aaron doesn’t have those droids in the game yet as he’ll be needing the transfer game slotted into his project by then.

I’m actually almost looking forward to going back and completing all the title screen stuff once this is over. Next time I’m volunteering to do the maps or something ๐Ÿ™‚

Here’s a snippet of the terrible code that’s currently in there for generating the walls. I have a build script that can be called with multiple arguments for doing stuff like clearing the play areas and filling with wires, throwing random chars in the area to check I’m not overwriting the background display and testing animating pylons etc. That’s why it’s such a lot of lines at present.

As with other code I write, I often tend to hack it together to get it all working and then will go through it again tidying up the messy parts and optimising to an extent. I always comment the hell out of something when I first put it together in case I don’t finish that part in that session. I will then often tidy up the comments later just in case someone else does read the code, so they don’t fall asleep with too much information.

The code shown above will likely look nothing like this once it’s actually finished.

As it stands, however, I can just press a key when running to generate a different map which is how I’m testing if my walls work. As you can see from the screen shot below – they don’t. Ignore the vertical/horizontal text – that’s a hangover from when I put in the control pad code.

Work in progress, people…

 


Website update —

Thought I’d put myself out there a bit more with some social media buttons and add a lot of Twitter integration as it seems a lot more people are starting to get interested in our #ParadroidRemake blogs and tweets. While I was at it I also added in dedicated pages to some old games I’ve been involved with including a link to iDef, now it’s not currently mentioned on our website due to the Paradroid build up page.

Our developer licence for Apple is probably due to expire soon so may as well see if anyone else wants to download it from the AppStore for free before they take it offline – as they do for expired developer contracts.

On the right is also a link to another new page which is where I have been working on my kind of memoirs, for want of a better description, of my experiences being a teenager as the home computer revolution came in. I’m not sure where it will go if I ever finish it, but I put up a draft (read rough) copy of the first couple of chapters in case anyone was interested in reading it.

Progress on the transfer game for Paradroid is still ongoing. It’s pretty tricky trying to get random layouts that are always workable in a game.


Brief update —

Sorry, I’ve been a bit quiet of late. Real life stuff slowing down my coding a bit but I’m still beavering away. Aaron’s been a lot busier so today I’ve been testing out all the droid info screens that he’s been plugging into the console. Now that these are in and working – just a few cosmetic changes to be made – the actual console part is almost finished. Aaron has the icon for statistics plugged in as well, which is something that the original game never actually had but got added by another coder years down the line, along with other improvements, when a lot more was known about the C64 hardware. Not to mention compression improvements allowing a lot more data to be held in memory. Quite how this will be setup is yet to be decided but it will probably get done once there’s proper gameplay running near the end, so that there’s stuff to actually track. He’ll no doubt blog about how he’s done the console screens once he’s written up all the fun he had doing the lifts.

The links on the right hand side of this page if you want to catch up with what he’s been up to. Certainly more than me this month /guilty-look

 


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…