Software Prototype

The Software Prototype

End of week update, activate!

This is gonna be a bit of a long one as there is so much to talk about. We as a team learnt a lot about Unity, creating assets and most importantly, how a working software prototype can give you so much more feedback compared to a static one. So go grab a cup of tea/coffee or another drink of your choosing.

Creating the prototype

The first thing to decide was what language we should create the program in and what engine. As we are using Unity on the course and we all need to build up experience using it, we decided to use Unity for the engine and C# as the language (Unity also supports Javascript however we prefer C#). For graphics, we mostly used Adobe Fireworks due to its vector tools however some assets such as the UI was created in Photoshop. As a baseline, we designed the images for a 1920 x 1080 screen as this will allow for high resolution in-game and no loss of quality if the game needs to scale up to that resolution. Creating the images as vectors also allows us to quickly and easily re-size them as required without needing to do massive tweaks to the art or suffer any issues so it is most likely that we will recreate the UI assets as vector images at a later date.

For my part of the prototype, I initially worked on creating the planes for the game including both the player and enemy ones. As we was creating assets for a prototype, I wasn’t focused on creating assets for multiple enemies so I only created one type which was a variant on top of the players plane design.

Player Plane

For the players plane, I just wanted to keep the design simple and clear for the moment. I wanted it so it can be easily seen as a plane that you control hence the lighter colour scheme compared to the enemies and the rounder shape. The grey is a standard colour of military aircraft, making it recognisable to the player that is an aircraft that can fight and has combat capabilities. However the design is very simplistic and can seem a little too “soft” with its rounded edges. The plane can be improved greatly by making some of the edges sharper and adding some shading and more details to the plane. Adding the extra details can make it feel more real and alive, immersing the player more within the game. We also received quite a lot of feedback regarding our art style however I shall analyse the details in more detail later in this post.

Enemy Plane

As can be seen, the enemy plane design is heavy based off the players plane design. This was mostly due to the limited time frame to create the prototype, I needed to create something that was different from the player and could be easily identified as the enemy. The most notable change is the colour scheme, I went for a dark grey body with red cockpit as these colours are often associated with villains and enemies. As we had no one during feedback ask about what plane is the enemy and what is the player, I can assume that this was quite successful. Another difference between the two planes is that this plane wings are more swooped back, making it look a little more agile. This is partially intentional as the enemy is someone who has beaten all other airforces so it would make sense their technology looks or feels superior to the players. It was simple to make this change from the players plane due to the use of vector graphics as I just had to change the path and move the flaps.

Using Fireworks to create the assets has both its advantages and disadvantages. The most notable disadvantage is that is not easily accessible as it can only be used when in the University and not at home. There are alternatives however such as InkScape which is a vector graphics program and also free so it can be installed on our teams machine at home. Another disadvantage of sorts is that vector graphics was not our original art style however due to time constraints, we went with this style for the prototype as it was simple and quick to do (an advantage). Some of our team members has expressed they like the vector style and our prototype feedback has shown that some players also enjoy it so it is something we need to discuss as a team.

After we created the assets for the game, we needed to create a prototype game in Unity so we could see it played. I was tasked with putting it all together so it could be played by the testers and we could gather feedback. Adding the assets and objects to the game was easy enough and only took a few minutes so I decided to take it a bit further by implementing a scaling HUD and having it so the players plane can move.

I started off with the HUD which was fairly easy thanks to Unity’s built in UI elements. I created a Canvas then spliced up our UI texture and added them as images. I ensured these images were anchored to their closest corner so when the screen aspect ratio changed, they would stay in the same relative positions to the edge of the screen. This makes it so you can still reach the buttons no matter what the device. However by default, the Canvas will attempt to keep a fixed scale so I had to switch UI Scale Mode to “Scale with Screen Size” so it would scale and reduced the reference resolution so the UI would be larger. The UI can also be expanded in the future too thanks to Unity’s component system as the images can easily be turned into buttons by adding a Button to component to it. We did receive some feedback on our UI design but I shall cover that under feedback later.

As for the controls, this was fairly simple to do as there is documentation in Unity’s manual on using the accelerometer and standard input controls. The first thing I implemented was being able to move the players plane left and right so I attached a script to the object then made it so if the left or right arrow was pressed, it would move in that direction. This was fine for a desktop preview however as our ultimate goal is Android, I investigated about using the accelerometer and found it wasn’t as complex as I thought. If I read Input.acceleration.x then times it by our speed factor and translated the planes position, it moved! The only downside with my implementation is that the speed wasn’t capped and you had to hold the device at a certain rotation however for a prototype, it worked well. As a final thing, I made it so the plane could only move within -5 and +5 on the x axis in the game world so it wouldn’t disappear off the side. This value will need to scale with the devices width and aspect ratio in the final game but it was good enough for a prototype. The code for it can be found below:

public float speed = 100F;

void Update()
    float translation = Input.acceleration.x * speed;
    if ((transform.position.x > 5 && translation > 0) || (transform.position.x < -5 && translation < 0))

    translation *= Time.deltaTime;
    transform.Translate(translation, 0, 0);

Want to try the prototype? Download the APK here (Android only, make sure you allow "Unknown Sources" in Security)


Thanks to our functioning software prototype, we got a lot of feedback from our peers with both positives and recommendations on areas we can improve. This entire session was a team effort with different team members doing various tasks. I was mostly focused on finding testers and gathering their feedback on the game with help from Eliot who also conducted some testing sessions whilst Aaron typed up the feedback and formatted it (I'm surprised he was able to read my writing!). Shannon had wrote up our testing plan and creating a Google Form for feedback however unfortunately we found due to the fast paced nature of their feedback, it was better to ask them the questions from the form as they held the testing device and wrote down their responses. Charlie was attempting to implement the UI and having it semi functional but unfortunately wasn't able to in the timeframe (but he is focusing on getting bullets and missiles working this week).

In total, we got 6 testers feedback on the prototype which has provided us with a lot of insight on what is good and what also needs to be improved. There is also some feedback where some people like one thing however others didn't. We also have some feedback internally within the team of stuff we like and dislike. If you wish to see the "raw" (They are typed up and formatted) responses, you can find them here with the names removed for privacy. For the testing, we used a Nexus 5 running stock Android Marshmallow (6.0) and we had a build running on a computer in full screen at 1080p for reference.


A common feedback from the testers is that the UI needs an overhaul or to at least be modified slightly and we as a team also agree with that. One important thing that was noticed when holding the phone with the prototype loaded was that the shield, health and lives bars were covered up by the players hands and was not easily visible. If a player wanted to look at their health or lives, they would need to move their hand or change their eye focus from the enemies on the screen to the bottom right, distracting them and possibly causing them to lose in the game. There are a few ways that we can fix this, the easiest and simplest solution would be to move the bars to the top of the screen as that is where the players attention would be due to the enemies spawning there. We are mostly going to that for the lives bar however we are still considering putting the health and shield around the fire buttons still. They may suffer from the same issue though so it's something we will need to test and investigate further through further play testing. Another point that was brought up was that the gun button may be accidentally mistaken as a horizon indicator due to the horizontal placement of the bullets on it. This can be fixed by using a different graphic for it or just rotating the bullet texture.

The button placement was also mentioning in the feedback with some testers liking the current placement and others finding that the buttons are too small or too close together. From watching how the testers held the device, it is clear that the "Nuke" button needs to be enlarged slightly and moved further away from the "Missiles" button as it is too close and could be accidently pushed. The buttons also need to be enlarged slightly so it is easier to click them and see where they are, making it easier for people with smaller thumbs or who find it harder to see. It was also brought up that the buttons could be made transparent so you can see the game world underneath and make the UI less intrusive. We actually had the UI transparent at first but didn't like how it looked in the prototype as it made it hard to see what button was what but it is something we can investigate further by attempting to adjust the button colours and style to suit transparency.

Overall, people liked the UI despite it needing some minor tweaks and adjustments which we as a team agree with. We know what potential issues to look out for in the future so we can avoid them and improve our overall UI.

Art Style

The current style we used was mostly for a prototype as we originally wanted to do a pixelated style. However after receiving feedback from the testers as well our own thoughts, we are considering switching to using this art style. The current art style is simpler and easier to create whilst also making it easy for players to be able to see what each object is. There is some improvements that can be made to this art style however.

The biggest thing noted by our testers is that the colours are too bright and can be very overwhelming for the player. These bright colours also make it harder to see the planes (both friendly and enemy) against the background so it is something we will need to adjust. One way of solving this is reducing the brightness of all assets however this may not work for all so something we need to look into is creating a colour palette for the game. This palette can effectively set the theme for the game as if we used darker colours, it can set a more grimy/dark world compared to a lighter colour scheme which can imply a more "gamey" or less realistic world. There are quite a few tools that exist for creating a palette such as Paletton which even allow you to do different types of palettes (e.g. Monochromatic). Creating a palette is something we will need to discuss as a team as it will play a major part of the game and it is something we failed to do at the start.

Clouds were generally liked but there are some improvements we could possibly make that was brought up by various testers. One improvement would be to make the clouds a bit more transparent so they are less distracting. Reducing transparency is certainly one way to do it however we can also look into making the clouds darker. From past experience, I have found solid black or white is very distracting for the player and it can look out of place. Just darkening a white colour or lighting a black colour a shade or two can really make the art feel more in place and not stand out as much. This is one reason why I made the enemy planes a dark grey instead of a black so they wouldn't be overpowering and fit within the scene.

The option of a colourblind scheme was also mentioned by a tester and is something we had discussed internally before. This is something that is possibly within Unity and catering for colourblind people is something that we certainly need to take into consideration when designing art assets in the future. Creating a specific set of assets purely for colourblind use however would not be a productive use of our limited time currently so it would be better to design art assets to allow colourblind people to understand what they are for.


Although the controls were implemented quickly and on a short timeframe, a lot of testers liked the way they currently work. The only complaint with the control scheme was that the plane moved too slow and you needed to tilt the phone too much for the plane to move across the screen quickly. This is something that we can easily fix but to get the feeling "right" will take quite a bit of playtesting and tweaking at different speed settings. Something else that also needs to be implemented but wasn't mentioned by testers is we need to add a "buffer" zone so the plane only moves if the user tilts their device over by a certain angle as it currently moves even if it is tilted just 1 degree. A speed limit also needs to be added so the plane doesn't move too quickly if the user tilts the device by 90 degrees for example.


We had no functioning gameplay apart from the plane moving however we did receive some feedback based on the UI they seen and other elements.

The enemy planes using clouds as cover was suggested by one tester to encourage more challenging gameplay and surprise attacks by the enemy. This is certainly a rather interesting idea and something that we could implement however it something that we will need to test to see how fun it is. A different take on this idea would be to have a base cloud layer that serves as part of the background then an upper cloud layer that spawns clouds much less often but offers this cover to the enemy planes. It is something we will have to discuss as a team and create a prototype with this feature to see how fun it is to play with.

We had originally planned that the gatling gun would be continuous fire but a tester suggested we can make the gatling gun overheat after continued use instead leading to more strategic gameplay. If we make the gun overheat then it could make the game feel less "bullet hell" and also make the missiles more useful as the missiles will deal high damage but need to reload. Along a similar line, the same tester suggested that we start missiles off with being big damage bullets effectively than having it so they can be upgraded to heat seaking later which would fit inline with our upgrade system that is planned.

One final suggestion was for an alternative superpower that would call in a B-52 like plane that can clear ground enemies as we was planning on having some ground flak cannons. This may make the game a little easier as they could just wipe out a persistent threat however it does mean they have to sacrifice their nuke superweapon which would effectively wipe the screen. It can lead to an tactical choice for the player and allow for more depth of gameplay.


There was a lot of excellent feedback we got from our play testers and it's something we certainly need to take into consideration for the future to improve both current systems and new ones we create. I believe we did excellently as a team as we managed to create our prototype and had it functioning before the playtesting session. That being said, there was somethings we could improve on.

As I mentioned earlier, we should have decided on a colour palette and tried to design with that in mind. The way we created our current assets was we all said we needed to do a specific thing (ie creating the planes or the background) so there is some clash in art styles with the current prototype. Also tied with this is we should have tried to fully commit to our original art style however this is not necessarily bad as we have found a new art style we all like.

Something I would have also liked to get working for the prototype was some more basic gameplay such as bullets firing however many on our team are inexperienced with both Unity and programming in general so it may have taken too much time or not be implemented properly, leaving a bad impression on our testers. Instead, we can now implement those features whilst not rushing and ensure they are done right.

From a project management point of view, the assigning of tasks certainly helped us all stay focused on what we needed to do and get them completed faster. Everyone on the team enjoyed the task that was assigned to them even if they found it challenging. This will be something I have to keep in mind for the future as if I allow team members to choose their own tasks then some of the more experienced programmers may take easier tasks to reduce their workload and leaving difficult tasks to newer programmers. Currently I'm considering switching to assigning tasks to team members so everyone does their own equal share whilst they still find it interesting and challenging without being overwhelming.

But this blog post is finally over! Currently it's sitting at about 3.3k words so I do apologise for the long post but there was a lot to talk about this week. In the upcoming week, I'll be expanding on our timeline for game development, assigning tasks and team members skills as well hopefully having the first playable prototype at the end of the week 😀

One thought on “The Software Prototype

Leave a Comment

Your email address will not be published. Required fields are marked *