ataXous prime is my take on the arcade classic Asteroids with a few extras.
I wanted to make a shoot em up game for a while, so I started a mini project to work out how to use gamepads/controllers in Game Maker Studio. I wanted to do a twin stick shooter, so I had to come up with a simple idea of what i wanted. My coder art took me down the asteroid vector style graphics as they are simple.
To make a twin-stick shooter I either had to have a circular ship or have a turret, the turret won!
I also wanted to have a lot more bullets and a lot more chaos! So i took inspiration from games like Geometry Wars, the original Asteroids and probably a few others from distant memory.
Things are settling down with moving in to our new home and getting it how we want it. I have my office looking good and workable. It’s at that point where you are making fine adjustments here and there to make it just right, we are a fussy bunch us coders 😵 or it could just be me. I have also had a lot of other personal things to deal with (I won’t bore you with the details).
My nice new setup.
The Paradroid Remake is on hold; there is a few reasons for this: I started the remake on a new development system (to me anyway), so I was learning it on the fly as well as making the game. I will be the first admit that it probably wasn’t the wisest move that I have made, as I was finding issues with the development system and with previous knowledge of other systems, things were not working as expected. This led to a lot fudging bits and pieces until I forced them to work. As my knowledge of Game Maker increased, the code I was writing was getting better but I was still working around the code that I had already got working. Slowly it was becoming a bit of a nightmare so I decided to take a break and wrote iDef again in GMS. The whole process took around 6 weeks from start to finish with a nice holiday slapped in the middle of it, so all in it was just over 3 weeks of real time work. The core of the game was done in a few days, then adjusting the graphics from iPhone/iPad screen resolutions to working on a PC/Mac screen took a few days, then the dreaded last part (the flashy title screen) all the bits and pieces that happen behind the scenes taking the remainder of the time. I also tweaked the gameplay a bit to make it feel much better.
So with this in mind, and the fact that I had Christmas and the house move going on I decided to work on another new project. Project M. One of my other favourite games on the Commodore 64 was Monty On The Run: Partly because the music is amazing and as platformers go it was good fun, albeit very, very hard! I also looked at it as a nicely sized project that I could pick up and put down as time allowed.
Now Monty On The Run (MOTR as I will call it from now on), isn’t a small game to remake but its no where near is complex as Paradroid was/is.
What is MOTR?
Monty on the Run is a computer game created by the software house Gremlin Graphics and released in 1985 for the Commodore 64, ZX Spectrum, Amstrad CPC and Commodore 16, written by Peter Harrap for the ZX Spectrum with music by Rob Hubbard.
On the run from the authorities after his intervention in the Miners’ strike, Monty the mole must escape from his house and head for the English Channel and freedom in Europe. In traditional platform game fashion, along the way he needs to collect various objects and solve puzzles to complete his escape. Before the game, five objects must be chosen to form Monty’s Freedom Kit. Choosing the wrong items will leave the player unable to pass certain screens. This also acted as an anti-piracy measure, since the objects were only given numbers onscreen meaning the player had to refer to the accompanying manual. The final screen sees Monty boarding a ferry to France.
The Basics There is a Title screen and completion screen. There are 54 screens that make up the game map. Each screen is made up of multiple 8×8 pixel blocks (the character size on the Commodore 64), these characters can be:
Solid: Monty cannot pass through them in any direction.
Platforms: Monty can jump through and walk across the top of them, he cannot fall through them.
Climbable: Monty can travel in every direction on them.
Hazardous: Touching these hurts our hero Monty, the fate is always death!
Empty: Have no effect on Monty.
Each screen can have upto 4 baddie sprites which move either on the X axis (Up and down) or the Y axis (Left and Right). There are reasons for the baddie number, I will discuss this at a later date. There are also other objects in some rooms that Monty can collect, for points or lives. There are ‘Crushers’ that kill Monty on contact. There are ‘Objects’ that are there to trap/kill Monty. The are ‘Teleporters’ that can either help or hinder Monty’s progresssion.
Starting the remake
With the map in mind I set about trying to find screenshots for the whole game: I could try and play the whole game through and take screen shots of each screen to help build up the games map. This would obviously take a lot of time to do or I got Google to find a handful of screenshots and a play thru so was able to start thinking about the game and where to start. Meanwhile, Tony was able to find a fan site that had the whole map as an image, here. So a huge thanks to Andreas Goller for his hard work!
This gave me the whole map to play with: So I set about making the the map usable:
The first thing to do was to be able to get the image into a paint package; this turned out to be a lot harder than you expect! I tried handful of packages some just crashed others just became unusable or unresponsive! The image is 25504×4000 pixels in size, which is pretty big but come on a mighty little Commodore 64 had all that data and more in its memory! Eventually I wrote a little Apple Script to scale the image by a half. I then was able to load the image into Adobe Fireworks. /Phew!
Next I set about removing all the game objects and baddies, so I painstakingly cut them out and stored them in another image so I knew what else I had to get at a later date.
At the same time I started to create a image map of the unique 8×8 pixel characters. So I could build up the game in tiles. This process took a lot of time spread over a few weeks, in between packing boxes and dump runs ready for moving.
With the tidied up game map and the new imge map that I created I then set about recreating the whole game map as a tilemap within Game Maker. Again this process took some time again spread over a few days just before Christmas and while the house sale was going through.
The game map inside Game Maker Studio.
The individual tiles that are used to build up the whole game map.
I have just migrated to Mac-OS High Sierra, so I’ve had the fun task of re-installing all my applications from scratch. Normally I would have opted for a full Time Machine restore and gone back to how things were but I would have missed out on some new, lovely things that I have found.
One of these is the X-code default font “SF Mono”. I think it looks really good on the eye, so I went about trying to use it for Game Maker, as I’m not the biggest fan of its default font.
Weirdly enough the fonts are not actually available for selection in Mac-OS and you can’t just use San Francisco for editing a document in Pages, for example. Fortunately, if you have Mac-OS (High) Sierra, this font is included inside the Terminal.app.
Here’s how you extract the font from Terminal.app and install it on your computer for your own text editor, as an example:
Go to Terminal.app’s resources folder:
Right click the Finder icon in the Dock.
Click ‘Go to Folder…’
Enter this path: /Applications/Utilities/Terminal.app/Contents/Resources/Fonts.
You’ll see a list of fonts in the folder:
Select all of the fonts in the folder.
Right click on them and click ‘Open’
A window will pop-up previewing the font. Click Install Font.
You’ll perhaps get a window that says there’s problems with the fonts. I did too.
Go ahead and click ‘Select all fonts’
Click ‘Install Checked’
You’ll get another dialog box:
Font Book will show the new font as installed. You’ll now be able to select the SF Mono font in your editor, or set it up in Game Maker Studio like I have.
Most of my time at the moment has been dominated by life. My fiancée and I are planning to move so there has been a lot of upheaval and a change to my current priorities. As a result I’ve not had as much time as I would have liked to code recently. We have been looking for a new house and consequently making our current house a bit easier on the eye, ready to sell that. Also, just to add a bit of fun to all of this, we’ve just come back from a great holiday in Mexico!
However, despite all this, the #ParadroidRemake has still been progressing along.
For starters I have introduced a new element on the main game screen – the “Info Bar”. It’s a mini H.U.D that displays information about the game in real time. Currently it shows the Dreadnaught, deck you are on, the alert status and the players health (and maximum health). Additionally it adds a weapons animated cool down, control method selected (keyboard or joystick) and the usual sound and music icons. Some of the purists of the original game may not like this add-on so it will be made toggle-able in the released game.
Also I have made inroads to enemy droid creation code. I will write more about this and the Info Bar in a later post as there’s a lot to talk about.
Also, for a bit off fun, I decided to revisit my last game that was released on the IOS App Store – iDef. As my experience of Game Studio is growing every day, I decided to see how long it would take to rewrite it from scratch in the new development system. The original iPhone and iPad game (sadly no longer available) was written in Objective-C, using the Cocos2D framework. The revised version isn’t complete, but is currently playable, so I will be talking about this in a future post.
Apologies for the quote from Aliens (warning link has mature language)!
So, over the last few weeks, I have been working on rationalizing the data tables in the game.
When I started this remake, I made a list of jobs that were (SMART) objectives. This approach comes from my project management roles in a previous life! It actually does work quite well when you break the game into small, manageable chunks and then set a realistic timescale for them. Doing projects in this way means you get those little “Yes!” moments when you achieve completion of a task.
Additionally, I also broke the project down so that I could define the storage tables for the data required for each task. This allowed me to complete bits without breaking others – again, small “Yes!” moments.
As a final touch, I also added the game over screens to the game so here’s the “Trials and tribulations” of the static drawing and then shader system that was eventually required.
The original Game Over screen in Paradroid shows a static/noise animation when your connection is terminated with the host droid. This was followed by a message from the 999 droid saying “Transmission Terminated” and you then got to enter your name against the highest score of the day, or the lowest score of the day, if you’d not had a great game between!
When you watch the video:
The character frames animate by moving down a pixel or two downwards, my guess is about 4 frames to each one, and there are 4 different types of character.
Also, to make it worse, the blocks of animation are then changed randomly.
Below is a video of the frames animating in Tiled. Note that you can’t randomly change tiles with Tiled so the video just shows the downward motion of the 4 different types of character.
Horrible, isn’t it?
I really wasn’t happy with the way things were going, so I started to toy with other ways to create the static animation.
The static/noise animation, I assume, was supposed to be like in the old days of television, when you only had 3 channels, and, either the broadcast stopped, or your coat hanger wasn’t turned in the correct direction, causing static. Only people over the age of 30 will likely know what I mean here.
I tried to recreate the static by drawing black and white pixels across the screen looping around and down the screen but this resulted in strangely shaped blocks appearing and the effect wasn’t very random either. So, next, I tried randomly plotting black and white pixels on the screen. While this, in theory, should have worked, the randomness of the dots wasn’t as random as I had hoped and I would get large areas of one colour making it look totally wrong. After this I started reading up on why the numbers being generated all seemed the same and there is a theory on this here. Andrew himself used to use the sound chip on the C64 to get his random numbers but I don’t really have that option here. GMS does have an internal command to ensure that that the random number generator is supposed to be completely random but I came up with another plan.
I decided to try out shaders next, as I’ve heard a lot about them and GMS has support for them within the language. Luckily there are also a lot of great websites that go into great detail about how you work with them that helped me out.
In this post, I will be talking about the weapons. No shoot em up is complete without them and Paradroid is no exception. For a game back in the eighties, it was not often that you played a game which had multiple weapons – let alone different abilities, sprites, and sound effects.
There are five weapons in Paradroid, one of which is attached to the ‘Influence Device’ itself. This is so the player has the ability to use the host droids own weapon when controlling a droid that doesn’t have it’s own, such as the pretty useless maintenance classes. All the other weapons become available as and when you can successfully transfer into a droid that has that weapon.
Each weapon has been built with a set amount of damage that it can deal, a cool down and they all different sprites and sounds. Below are five of the weapons as they appear in Game Maker.
This is attached to the Influence Device and also a couple of the lower powered droids. This is the weakest weapon of them all. The cooldown is around 1 second but it is the fastest to fire with.
Droids with this weapon: 476, 615, 629, 751.
This is much more powerful than the basic, built-in weapon but the cooldown is slightly longer to prevent overheating. Not many droids have this weapon.
Droids with this weapon: 629, 751, 821, 834 and the 999.
Only one droid has this as its weapon and it does a lot of damage so, if you are in a low-class droid, you won’t last long. The cooldown is slightly longer than the twin laser above as a result.
Droid with this weapon: 614. If you spot him then the best strategy will likely be to take him out fast – or transfer into him for taking on the bigger droids.
This is the most powerful weapon and, naturally, it has the longest cooldown. It also belongs to a droid that looks almost identical to a famous robot we see on the BBC. Perhaps the catchphrase “Exterminate” may mean something to you??
Droid with this weapon: 883.
This weapon has no moving sprite so we use a visual clue to indicate that it’s been used by the screen flashing and jumping, which you can see demonstrated in the video below. Additionally, its sound is much more noticeable than any of the others. Interesting fact: the effect used to show a droid using this weapon took over half a day in man-hours to get just right.
This weapon does area damage and is the only weapon that can harm multiple droids with one hit. However, you shouldn’t consider this an “I-Win” button for dealing with the droids you don’t want to face head-on in a laser fight. Some of the droids, such as security class, are immune to this type of damage!
Droids with this weapon are: 711, 742
In the original game, the sprites strobe through three or four colours to give them a bit more of a visual presence. I have done this by adding extra frames to the animation rather than play around with colour cycling. I could have done this by changing colour over time but it wasn’t really needed as it was much quicker to just add in more sprite frames, as we’re lucky enough to not have the restriction of less than 64k of memory.
Additionally each of the weapons originally just had 4 images: horizontal, vertical and two for diagonals. Although it’s not ideal to have a bullet flying at a slight angle and being horizontal, it didn’t really matter. Memory constraints may well have been an issue with not being able to store more angles. It would also not be a realistic task to rotate the sprites by code on the fly. Luckily for me, I have plenty of memory and can just change the rotation of each sprite on the fly, with built-in animation options in the development system, so performance issues just aren’t relevant.
Below is a video showing the player firing each of the different weapons. This is a video I recorded just after implementing the actual firing so the position of lasers when they fire has not been tuned and the graphics are still subject to tuning. There will be no issues such as the droid moving faster than the lasers, or the laser actually firing from its back-end once the game is finished.
In my previous post, I talked about the Minimap screen and the Lifts screen which are both parts of the console display within the game. The console screen also has a wealth of additional information about the droids, deck plans and the layout of the current dreadnaught. You can access the in-game console by going in front of the terminal and pressing fire.
Once you access the Console screen you have five options:
Exit back to the main game. No explanation necessary!
Droid Database. This screen shows you various information screens about each droid. Note that you can only see data on droids that are the same number or less than current host for security reasons. So, if you want to see data on a 999 droid, you are going to first have to go out there and get one.
Deck Plan. This screen shows you a mini map of your current deck.
Ship Plan/Lift Screen. This screen will display a static version of the lift screen but with the current Deck highlighted. You should note the elevator bars between these decks as they give you a visual indicator of how you will be navigating through the decks as the layout is not a straight forward up and down in one elevator that you might expect. Space ships are not built as square blocks after all.
Statistics. These were not in the original game, but were added in the PARADROID REDUX version by TNT/Beyond Force. This screen is in place but it will be one of the last coding jobs adding in the data, once there is in-game action and scoring in place.
All of the droid data has been stored in various data structures, using look-up tables for descriptions. The information displayed on these console screens has been done using several different ‘surfaces’ with Game Maker, which is a way of loading in an image and then chopping bits out to display in different areas on the screen – like textures, in fact.
This blog will be all about the Console areas of Paradroid, which were accessed within the main game as a kind of sub-computer for information about what you were dealing with. This is quite a big part of the game that I “missed” – as in didn’t really take much notice of – when I first played back in the Eighties. Back then I usually went around just trying to kill all of the droids, or perhaps trying to take them over one by one using the transfer game. Neither of these tactics worked very well and I don’t recall ever completing one dreadnaught.
Inside the console is a wealth of information that was pretty-much wasted on me in my youth. When I returned to the game, while thinking about this remake, I started to see all the effort that Andrew Braybrook actually put into this game, and it still amazes me how he managed to cram it all into a Commodore 64’s memory. The amount of information information in the console alone, never mind the game, is actually staggering.
Firstly, the minimaps section of the console was a no-brainer for using tilemaps – especially as the decks themselves have already been created the same way. I started playing through the game by traveling to all the decks and looking at all the minimaps for each one. After a while it became obvious that not only do the charging-stations have animations, but also the location of the player. I also noted that Andrew must have struggled to get the maps in such a small area that the game is played in as this can be seen in the main image at the top and the image below. I am sure they’re not as neat as he probably wanted at the time.
My first thought was to recreate each level as its easy enough with Gamemaker, but a little labour intensive. However, I already had the game maps allsetupp, so all I really needed was to create a tilemap that was identical to the main games tiles, but using the smaller simple minimap styled graphics. This got me thinking about the original decks that we had back in the Tiles, Tiles, they‘re everywhere post. After a bit of rearranging of the decks so that I could identify with some starting and ending X,Y coordinates, I had the size of the map in tiles and the players position on that deck. With that it made calculations of what deck the player is on easy. This way I was able to write a routine to create the mini-map of the original map data using smaller graphics and lay down an accurate small view. A nice design idea here could possibly be overlaying that as a kind of radar elsewhere on the screen as a kind of guide, but the original Paradroid never had that, so no.
As you can see in the image above I now have two decks nice and tidy next to each other – with a big enough gap so that you can’t see one from the other if you hugged a corner to scroll the screen as far as possible. I then set up an area in the games room where I could dynamically draw the minimaps.
Here is the area in game where the maps get created. I have used the title screen logo for a bit of fun as well as using the small squares to work out how many tiles I could actually use so that all the decks were convertible. This is staying in the game but won’t be seen, as the area is cleared each time a map is drawn.
Once I had the area mapped out and knew the target tilemaps height and width, a quick calculation of the height and width of the target map against the decks height and width would give me my padding areas for the top and left. I could then loop around the deck copying in the tile numbers from the deck map to the corresponding minimap version to get the perfect recreation. Additionally, while in this loop, I will find the player and put an animated tile in the correct location.
With the screen shot above you can actually see the little mini section that you get to by using one of the lifts, as well as the main deck map. This is deliberate as that part of the deck is part of that deck but just can’t be accessed in the main area. I suspect Andy put it there and made it accessible via a different lift just so he could hide a solitary droid there to get the player running around for a bit before realising why the deck wasn’t showing as cleared when they had dealt with all the robots. He’ll probably deny it 🙂
Below are a couple of small videos that show the minimaps animating and changing colours.