We were thinking our house move wasn’t going to happen until next year sometime – probably early March or April – as we’d had no promising viewings for around 6 weeks. Then, almost out of the blue, an offer came in. We played the usual bartering game and came to a price that both parties were happy with. Following that, a weekend later we found and had an offer accepted on a property to replace it. Happy Days!
In the meantime, #iDefLite is coming along nicely. I decided the game was working well and felt that it was time to finish it. The actual gameplay was already in, and around half the title screen was working, so the game was approaching the dreaded last 10%. Any programmer will tell you that it’s often the hardest and longest part of a project to finish.
For those wondering about our #ParadroidRemake, that’s currently on the back burner for a bit. Once I get iDefLite out, my intention is to get back to finishing it but. with Christmas coming up rather rapidly, and the move to a new home in the new year, I can’t realistically see me getting enough time to finish my part of it before the New Year. But we shall see.
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.
With the doors all working, as I explained in the previous post, the next logical step was giving the player the ability to move around the whole of the dreadnaughts area. This involves having the lift screen and the lifts on all the decks linking into the respective areas on the huge map that are the separate decks. So firstly I had to work on graphics for the lift screen. When I started this I wanted it to be as close to the original game as possible but, as we have increased resolution to work with, the lift screen didn’t look that great. I even tried placing some fancy background graphics to make it look a bit more appealing but it needed something else.
So I went about creating a set of new graphics that were much friendlier on the eye but also as close to the original as possible.
The image above shows one of the first attempts at the lift screen.
The image on the far left represents the lifts and decks in an “off state” whereas the image to the right shows the lifts and decks in an “on” state.
The left is basically one big sprite drawn to the screen and the image on the right is made up of 16 sprites for each of the different decks, along with 8 sprites that we are going to use for the lifts.
The current lift and the deck the player is on is actually overlaid on the complete deck map image on the left screen giving the player a visual clue as to where they are on the dreadnaught, and where they can move to from the lift shaft they are on. This is presumably the same system that Andrew Braybrook used although he would have been made up of character graphics.
The video at the bottom of this post will make it all a lot clearer if you have never seen the game before.
The next step was to work out which lift to highlight when you ‘enter’ a lift from within the main game. Each lift has it’s own location internal numbering system so the code then runs through a list of possible places on the other decks where the player needs to travel to. Some decks only have one lift, while others can have several, so keeping track of where the player is, and where they need to move to, while also overlaying the correct deck sprite over the map does start to get quite tricky.
And so, to cut a long story short;
Each lift has a list of decks it can visit.
Each deck has a list of lifts that can access it.
Each lift has an x and y coordinate of its position within a deck.
So when we enter a lift, we can work out which shaft we are on as the player moves up or down (assuming there is a deck to travel to in the given direction) and we can also work out what lift position on the deck they will be using to exit that lift. We then place the player on that x and y coordinate on the huge map to give the effect of switching to another deck on the dreadnaught.
The next major hurdle with Paradroid was implementing one of the most iconic parts of the game which was the opening and closing of the deck doors using simulated proximity checks when any droid approached them. Just like the automatic doors, you find in shops which detect a person coming into the sensor area and open until the area is clear. The doors in Paradroid were designed to work the same way for both the player and AI controlled droids.
The first idea on how to do this in the code was to use the same tilemap I built for the wall collisions and to adapt it to also trigger for collisions with doors, terminals, lifts and the charging stations. With a controlling object handling all of the collisions within the game loop. Not a hard thing to do but it did end up being much more complex than I felt it actually needed to be.
The better idea was to place a hidden object in the area that was to act as the switch to open the door and this would be triggered by the player or an enemy droid when they collided with it, even though, to the player, nothing would be seen. When I first started coding the map and droid handler system for this game, I was using Unity and it turned out to be actually a lot easier than in Game Maker Studio. Unity has built-in events for collision start and collision end areas so that made it very simple to start the door opening and closing at the correct times.
After we switched development systems to GMS, I started hunting around for a way to do this again but soon found that, while I could work out the collision start – there is an event for collisions – there’s no actual event tied into it. A timer was out of the question because either the player or an enemy droid, could still be in the door when attempting to close it. For example, if the player is being pursued by one of the more security conscious droids. While it could make an interesting gameplay mechanism, it’s not what this game ever actually had.
After a bit of RTFM – read the <cough> manual, for the uncool kids – about events in Game Maker Studio, and a question or two shot out to Mike Daily via Twitter, I went with a solution that works on four different events that are attached to one Object. Not as scary as it may sound if you’ve never used Game Maker Studio before.
When a collision occurs between an object and the “hidden object” a flag is set. The door hidden object is shown below as a circle with rectangle going through it. In total there are actually three types of door objects. Horizontal, Vertical and what we’ve come to call “Stupid door” – mainly because it doesn’t seem to actually serve any function. *collision_event*
At the start of every frame, the Door object has a flag set to say I’m not being activated. It doesn’t actually say that because doors can’t talk. I’m sure you get what I mean, though. Right? Erm, yes. Ahem. *begin_step*
At the end of each frame, a check is then made to see if both of the previous flags have been set. If they have then we set another flag which activated the code that does the animation of the door this collision is linked to. *end_step*
Finally, in the frame event, we check if the door we’re looking at is animating, and what direction the animation is using (open or close). We then play the next frame of the appropriate animation. The extra collision tiles are added, or removed, depending on the doors direction *step*
Once we have played all animation frames we then set the third flag back as the door has finished animating.
The door affected naturally is made to stay in the open state until the collision state does change.
It does sound a bit complicated when you write it down but, believe me, its a lot harder trying to explain it, than actually getting the code in place and working!
As you’ve only seen still images until now, below we have a video showing the doors opening and closing as the player droid is moving around. A lot of work for something most people will barely notice, unfortunately. But there are people who do and will appreciate that the effort has been put in to make sure it’s working right.