After completing the major backbone of ClickForge I was tasked with creating a second prototype that would follow a completely different genre which features both different mechanics and features. This genre being the classic Space Invaders. Following the Medieval Fantasy theme of the last one I’ve decided the physical aesthetic should go along the lines of a castle defence, for example an invading army of opposing soldiers and you are tasked with holding them off as a lone soldier with a crossbow; hence the name FortressFighter.
Early Stages
Similar to the beginning of the last project, it all started out by laying out the key elements of the game. In this case it was both the player and enemy sprites as the player sprite is to be controlled and the enemy sprites are to be destroyed. I decided to follow the traditional lay out of Space Invaders by placing the player sprite at the bottom of the screen and the enemy sprite at the top just to keep things simple. Example shown below:
Following up on this I needed to first make sure the player was capable of controlling their sprite, as this would be one of the crucial aspects of mechanics. In order to make this happen I had to write up a script in which I used a public class float in order to be able to adjust the speed of the player’s movement within Unity rather than having to go back and forth within Visual Studio, in addition to this I of course implemented another float, albeit a private class one, that essentially told Unity that this sprite should only move horizontally. This private float worked in unison with the transform code I had written that tells Unity that it should be even moving in the first place. An example of this behaviour script is shown below:
Building Up
Now that I’d gotten the basic form of movement to an optimal level and made the adjustments to speed that didn’t make the player fly off the side of the screen lightning quick, it was time to move onto the projectile side of things. This being the sprite that the player is going to shoot at the enemies to destroy them, for now it’ll just be the asset provided but in future it will be amended; the same changes will apply to every other asset within the game including the plain background. Besides that, I didn’t expect the bullet to need so much attention in order to function the way it does; for example I personally didn’t think it’d need it’s own sprite in the hierarchy but to my surprise this wasn’t the case. Shown below is the bullet sprite on the canvas:
What I’ve done here is placed the bullet sprite outside of the camera, as it shouldn’t be seen by the player and also so it doesn’t interact and kill any enemies upon launch. However this is the stage where I was introduced to prefabs, which are direct clones of a sprite that can be duplicated and carry the same properties but can also be adjusted using scripts. In this case the prefabs will be constantly cloned as bullets are fired and modified alongside the properties that are editable in Unity due to the public classes created in the code. An example of the code written for the bullets is shown below:
Although, it’s all nice to have a script all written up for how the bullet is going to behave and preparing all the modifications you can make to it, but how exactly am I going to shoot it? This is where I had to go back to the Player scripts and integrate lines of code that will actually mean that the bullet spawns the prefabs from within the player sprite and shoot upwards. In which initially I hadn’t configured the speed and fire rates properly so whenever I pressed the spacebar to fire a bullet it actually fired an artillery of around 11 prefabs all at once, but once I’d eventually aligned all the values to fire at a normal speed it worked like a charm…or so I thought. Code amended from the PlayerBehaviour script shown below:
After all the effort of getting the player to shoot the bullets I’d coded, I realised that the bullets don’t actually destroy the enemy sprite that had been on the canvas since the very beginning, which is the bullet’s entire purpose in the first place. In order to achieve this I had to add and configure 2D Box Colliders onto both the bullet sprite and the enemy sprite, in which I refreshed the prefab with this new collider in order for the bullets that are spawned to actually make contact. But before I went ahead with any of this I needed to move onto creating the enemy sprite’s code so that it’s actually classed as an enemy. The code for this is shown below:
Now that my enemy was a functioning sprite on the canvas I then took the step of it being able to be destroyed by the bullets fired by the player, which in unison I could also have the enemy respawn in a randomised location, to add a bit more challenge to the already barebones prototype. The way I did this was within the lines of code that tell Unity that the enemy should be destroyed upon contact with the bullet through a tag known as ‘Enemy’ which is applied to the enemy sprite and then all of the prefabs that clone after the fact. The code written for this process is shown below:
Polishing Things Up
See, everything I’ve shown leads to a working Space Invaders prototype; however I noticed that the player drifts off the screen when moving too far left or right. So using my own knowledge of colliders and rigidbodies I took upon myself to add two game objects that would serve as two unseen walls either side of the canvas, to prevent the player from leaving the scene and losing their position. The process for this was rather simple, and took some positioning and the addition of RigidBody 2D and 2D Box Colliders that was wide enough for the player to not pass through them at high speeds. Shown below is a screenshot of the canvas with both of these walls outlined:
Conclusion
Truthfully, this prototype requires more mechanics and assets in order to give it personality. But for now this is the foundation of a working game that can be played following the link below.
Additional Content
With some sprites drawn up in Photoshop I implemented them nicely into the game, with the enemies now appearing more menacing and the player having a body and weapon to immerse the player that bit more. In addition to this I implemented sounds for the enemies both dying and spawning, a soundtrack to go with it and a sound for the shooting of arrows.
Play Fortress Fighter here: https://sirdoormat.itch.io/fortress-fighter