Near Final Refinements

Idea:

In this iteration I will fixed the enemy spawning bug I mentioned my previous post. I will also improve the player attacking the enemy responsiveness as well as other responsiveness tweaks. I may also adjust the internal economy to a degree to fine tune what I have.

Implementation:

Laser Blast Improvements:

For both the player's and the enemy's laser blasts I decided to add a light component to the prefabs. I made sure the light's range was not too large (no more that 10) in order to not have any over spill and cover all the surrounding items but large enough for the player to see the actual item. I tested this in game and it still did not do the trick, so I went back and raised the light's intensity to about 4. This is half of the range allowed by Unity's light component. I also make the light component the same colour of the line renderer that was attached to the laser (red for the player, green for enemy). When I tested it myself, I noticed a stark different between the old and new versions of the laser. It was defiantly a lot easier to see in the game and the same goes for the enemy's laser.

Enemy Muzzle Flash Scale:

For the enemy's muzzle flash I decide to up scale it to make it easier for the player to see. Initially I doubled the size, but it was still to small. Then I multiplied it by four times it's scale, to about 16, and this nearly worked. After this I decided to increase it to 20 and this appeared to do the trick.

Enemy receiving damage responsiveness:

o made it clearer to the player they had damaged the enemy through firing a laser, I added a sound clip, so when the enemy it hit by the player's laser, a sound plays. This sound is of metal receiving an large impact, but I have modified it increase the bass and I have also increased the pitch slightly to make it fit in with the game more and so it sounds like it came from the enemy ship. This was the player will get both visual and audio feedback that they hit the enemy by shooting them. I obtained the file from http://freesound.org by alienistcog (alienistcog. Web. 29 May 2014. <http://freesound.org/people/alienistcog/sounds/124711/>.).

Fixing the spawn bug:

With the enemy re-spawning bug, this took me roughly a day to find out what was going wrong with it, and still don't fully understand but I have an idea.

I tried debugging the enemy's script and the value's were all matching up. I tried commenting out various pieces of code and setting several game objects as inactive, but I couldn't see what was doing it. I checked in a variety of different scripts to check if the variable was being set some where else and it wasn't. However after several hours I noticed that when the player destroyed the enemy, there was a null error. I checked this out and it was at a 'GetComponent' statement in the OnTriggerStay function. I looked it up on the Unity answer forums and it suggested I make sure the script it was trying to access was actually there. The bug read "The Collider Player has been destroyed but you are still trying to access it". I became more confused by this. After a few minuets of reading my code, I noticed I had an if statement inside of the OnTriggerEnter statement that was a trigger for the tutorial script for the level. I decided to cut the if statement from the OnTriggerEnter to the OnTriggerStay function, and this some how fixed everything. It may have occurred because the function needed longer to run the statement or just because it was in the wrong lace by mistake. Either way it is fixed now.

With this bug I fixed it about two iterations ago and it baffled me as to why it arose again and I could not remember how I fixed it, but as least it has been sorted now.

Critical Damage Screen:

With the critical damage screen I decided to get a variety of different cracked glass images, modify them and scatter them around the edge of the image. I decided to do this because since the player character won't receive any damage but his ship will and the screen for the cockpit will probably be made from glass, this seemed more logical and will show the roughness of space. Also it will be more aesthetically leasing because the ship will be damage and not actually the pilot.

The image below is what I currently have I took several images of cracked glass screens, manipulated them and added them together so it looks a little random. Because there are multiple large crack around the edges this shows the player's show has sustained much damage and is nearly falling apart unless they get a health pack soon. Also I made sure the image was coloured white because I already had the code in place to change the imaged colour, therefore if I ever needed to change it's colour I can do this dynamically.

The image below is what the new damage over lay looks like. The grey bit will not be seen, it's jut a screen capture for this blog post, the parts in grey will not be seen in game.

I have reference each imaged I have used for this screen over lay in my bibliography.

The three images below are what I used to create the screen overlay above.

Unknown. "Unknown."Unknown. Unknown, n.d. Web. 26 May 2014. <http://cdn.geckoandfly.com/wp-content/uploads/2010/04/15333_2d_broken_glass.jpg>.

 Unknown. "Unknown."Unknown. Unknown, n.d. Web. 27 May 2014. <https://s3.amazonaws.com/colorslive/png/509299-PqhI_Cl78RheIJQS.png>.

Unknown. "Unknown."Unknown. http://wallpaperpanda.com/, n.d. Web. 26 May 2014. <http://wallpaperpanda.com/wallpapers/die/jA8/diejA8qik.jpg>.

Camera shaking:

As well as the orange orb and critical damage screen I managed to find a script that could make the camera shake when an enemy laser hit's it. This was suggested by player's last iteration and I wanted to include this feature in the last iteration but the package I bought (where the blood splatter screen came from) used the nGUI camera and C# scripts I was not able to use. It took me several hours, I went through manny script and online tutorials on how to achieve the effect I wanted. I eventually found a simple script by GALAWANA (GALAWANA, 17 Jan. 2013. Web. 31 May 2014. <http://www.galawana.com/unity3d-camera-shake/>). I had to make a number of adjustment to the script such as putting the camera back into it's original position and making sure it shook enough but not too much but I found the correct amount of shakiness and the time the effect should last for. This too a decent amount of time but I found it.

Enemy receiving damage responsiveness:

I added a metal impact sound to the enemy ship when the player hits it with a laser to make it more responsive. I found a sound file by alienistcog (alienistcog.  22 July 2011. Web. 29 May 2014. http://freesound.org/people/alienistcog/sounds/124711/). I manipulated the file in audacity to make it more bassey and sound like the laser it a large dense piece of metal by increasing the bass and powering the pitch slightly. After this I imported the sound into Unity, added it to the enemy and made it player through the damage function. When testing it first time round, the audio didn't play, however I remembered it was automatically imported as a 3D sound, so the further the player is in range to the enemy, it will hear it less. I unchecked this box, and afterwards it all worked perfectly.

As well as this I decided to add multiple points where damage sparks (particle systems) would spawn. Initially I used the "Sparks2" prefab that comes built in with Unity3D. I added multiple spawn points for each spark to spawn from on the ship. After I did this I tested it out. It worked but the sparks were not obvious enough. After this I used a slightly different one that also comes built in with Unity3D. It looks a little more like a fire but I think it's just the texture it uses. After I replaced the old spark with the new park and tested during run time, I defiantly noticed a start difference between the two. The new spark that spawns when the enemy received damage is both larger and more noticeable.

Fuel Low Power Down Game Over Audio:

During previous play tests players asked why the game over screen suddenly appeared whilst they were getting into the game. To fix this (as well has giving the player a warning when their fuel is low, player's liked this in the last iteration) I have made a number of adjustments. I have delayed the game over function using a yield statement, then blue text appears above the player that reads "Fuel Empty", as this is occurring, an audio clip of a engine shutting down plays. This is in order to give the player more feedback on what is happening. The audio clip I have used I obtained from 'freesound.org' by peridactyloptrix (peridactyloptrix. 9 Jan. 2014. Web. 31 May 2014. http://freesound.org/people/peridactyloptrix/sounds/213384/). Because the file was longer than I needed it to be and included other bit of audio I did not need, I modified it by removing what sounds were not appropriate. When the audio clip has finished playing the game over screen appears and the play can click the restart button on the screen.

There was another audio clip I found on the same site, however I decided not to use it because the shutting down sound was not noticeable enough for the player (club sound. Web. 31 May 2014. <http://freesound.org/people/club%20sound/sounds/103687/>.).

Player Dead Game Over:

For the player death game over sequence, I have increased the amount of time in the yield statement. This delays the game over screen so the player can see their ship explode due to having no health. Also they will know why they dies because they will see their ship explode and the damage over lay will have warned them before hand to get more health. As well as this the explosion audio plays during the explosion particles of the game over sequence. This will help with the responsive ness and show the player what has happened.

Player feedback:

The new laser blasts:

During play tests many players liked the combat. Because it was less static than in past iterations. However a number of players noticed how some times an enemy ship would go through a planet. Unfortunately I don't know how to fix this and I don't have the time to find out how to fix this. This only occurs when the enemy is patrolling the play during combat.

With the laser blasts, many people liked the changes I made, i.e. adding a light component to them because they found them easier to see in the game. Meaning the player could see where the lasers they shot were traveling to and they could more clearly see the enemy's laser blasts to more easily avoid them during combat. I have added light components to both the player's laser blast prefab and the enemy's one as well.

Player damage overlay:

Another thing player's liked during their play test was the new cracked screen over lay, because it made them feel more like there were in a space craft's cockpit. This also made the damage more visual and helped fit in with the space theme. Player's also commented on how when they were low of health it made it easier to tell that their was critically low and needed a health pack with out looking at the pulsing health bar so they could concentrate more on playing the game and engage in combat.

Tutorial level bug:

During this play test several players noticed a but where in the first tutorial level when the player is being taught the core mechanic and how to move and so fourth, the player is unable to use the trader ship. During this tutorial I made it so the player can't move away from the trader until they have been refuelled. I did this only in the tutorial so the player doesn't wander around the tutorial level. However, the refuel function for the trader does not work, and because the player has not been refuelled in the tutorial they cannot progress to the end of the tutorial. This is quite odd because during my last iteration everything worked perfectly in the tutorial level.

I will track down the bug, but if it takes too long to do then I will get it from the game and give the player's a set of instructions.

Camera Shaking:

Many players noticed how the camera shakes to a degree when hit by incoming enemy fire. The majority of people liked this feature because it add to the responsiveness of the hit, and helps the player be immersed in the game. It's like the ship was actually hit and the player was inside of it. Another thing was, player's also liked how much it shook and the duration it shook for. It was not too violent but violent enough to notice, and not too long so the player still has their bearings on where they are in the game.

Enemy Damage sound:

Many player's thought this sound did the job and liked that I added it because it gave them a signal that they actually hit the ship, rather than just waiting for visuals making it more tactile. they said it also made the game feel a little more natural.

For Final Iteration:

For the final iteration I may make a few minor adjustments. This is because I have not got a lot of time left therefore I will not be able to do anything too drastic. I will attempt to fix the first tutorial level, but if I am unable to I will cut if from the game and give player's a document with instructions on it.

If I get the chance I will add a light so that when the player gains health, the orange light glows and the player. This is so, when the player is re-gain health, they will look at the orange light, then look at the pulsing health bar so they can relate the two together.

Another thing, if I get the change I will improve the enemy tutorial but my highest priority is polishing the game. I may add a slight feature, where is the player shoots the enemy, the player gains more health of fuel storage so they can either take more damage or travel further.

Re-doing the enemy tutorial, polishing and improving responsiveness

Idea:

For this iteration I need to link up the remaining player actions to make them more visual. 

Specifically:

• Make if more obvious when the player is damaging the enemy.

• Make if more obvious when the player is hit by the enemy laser.

• Foreshadow when the enemy is attacking to allow player more time to react (e.g. particle system for laser charge).

• Make laser blasts larger so they can actually be seen.

• Add muzzle flash to both the player and enemies, so it's more obvious to to the player they have fires a laser (like a real laser).

• Change it so, when the player mines a planet, their score raises (other wise what is the point of mining planets, the player will forget about the mechanic).

• Make the score more visually obvious and when player gains points from planet mining, link it up to the front end more clearly.

• When the ship is stationary and receiving no player input I need to make the ship engine lights pulse as one play tester pointed out that because the lights do not move people will think the game is broken.

Implementation:

Laser Blasts:

A few players pointed out to me the laser blasts form both the player and enemy were too small and barely visible to the player and considering how fast the blasts were traveling in game I had to fix this. Because the visuals of the laser blast are done with a lineRenderer component built into Unity this was quite an easy modification. All I had to do was increase the size of both the start and end width of the line renderer positions. Initially I doubled the start and end widths, but this was still barely visible, so I doubled it again. By the end I decide to increase both ends to 0.8 since this will not take up half of the screen but is still decently visible.

Mussel Flash Player and Enemy:

Many players suggested I add a muzzle flash to the ships when a laser has been shot to make it clearer to the player a laser has been fired. At the moment a small laser beam can barley be seen and the player has no idea what the object is if they are able to see it. When a gun is fired or a laser blast from a film has been shot, there is often a muzzle flash at the end of the barrel of the gun when the bullet shot out from due to the amount of heat energy needed to fire the projectile at a great speed.

I decided to purchase such an item form the Unity Asset store by msgdi (msgdi. Web. 29 May 2014. <http://u3d.as/content/msgdi/sci-fi-muzzleflash-laser-pack/3Rr>). The pack came with a variety of different muzzle flash prefabs in varying colours. I went with a red one for the player to match the laser and green for the enemy ships again because the enemy ships lasers are green.

With the player I increased the size of the prefab to make it visible to the player when they are firing, and the muzzle flash switches it self off automatically in order to not break the player's immersion of the game.

The image above is the player's muzzle flash in action. I have increased the scale of it several times to visibility to the player. The enemy's muzzle flash is the same apart from it's green.

Making player damage more responsive and visible:

With the player damage (when the enemy damages the player) I have implemented a number of new features.

The first one being, when the player has been hit an orange light orb around the player with briefly light up and then deactivate itself. This is because during an encounter with the enemy, the player will probably be too engrossed in combat they will probably not look al their health bar that often even though the bar pulses when they are hit. I made the light orb orange so the player can easily link it to the health bar because both are the same colour (colour coding).

Another feature I have added (I'm sure about this one), is another damage indicator. The damage indicator is like something one would see in Call of Duty or in a space sim. When the player is hit the Texture will appear above the player for a short time, usually indicating where the damage came from. Because I do not have the time to reprogram my damage code I cannot tell the player where the damage has come from. However I will experiment with just placing it above the enemy near the glowing orb using OnGUI.

The last thing I will bring up is the blood splatter HUD cover. It's like a blood splatter across the screen in the players vision, so they know with out looking at the GUI stats that their health is low and they could die very quickly. I have added this into my game because it may help players work out when they are low on health with out having to look at their health bar whist in combat. I purchased this from the Unity Asset store made by (Ninjutsu Games. 12 Dec. 2013. Web. 24 May 2014. <https://www.assetstore.unity3d.com/en/#!/content/8797>). It is compatible with nGUI, and it has a camera shake script for when the player is damaged. I thought this was great because the camera shake had already been done. I wanted to add the camera shake to add to the responsiveness of the game on the visual size. However I quickly discovered, because it integrates with nGUI, it can only work with the nGUI root and the camera attacked to it and not the Main camera following the player.

To get around this problem I decided to get the .PNG files from the folder in the project where the UIDamage Folder was located and copy these images to a different folder in the project and delete the UIDamage folder to not take up more space. Basically I decided to use the blood splatter and damage indicator files on their own but in a different manner than using the it with the UIDamage Package with nGUI. I used them with Unity's "OnGUI" function for the player, this way the player will be able to see if from their perspective.


This blood splatter over lay, it's coloured white, but with the package that works with nGUI it can be tinted any colour and the image can be replace with something else obtained of created by the user. This image is white so it can be easily tinted to any colour for the users needs. I have added to my game in the OnGUI function of Unity. The idea is when the player's health is at or below a certain value (when the play has a quarter of their health remaining or lower) this appears in the over lay and it's alpha channel pulses in and out. This is a way of showing the user that their health is dangerously low with out then having to look at their health bar, and this should especially help during combat with an enemy ship. I have tinted this image orange through code so it matches up with the orange health box dropped by an enemy ship and the orange health bar in the front end. This way the player can easily relate the two items (orange blood over lay is the same colour as the GUI health bar). Also because the image is a .png and it has alpha channels, where there is no blood splatter on the image, the player can clearly see through it and their view of the game is not obstructed.

The image below is the damage indicator, for when the user has received a normal amount of damage when their health is at a normal level (e.g. above 50% health). I have also coloured this orange for the same reason at the image above. For the record I have taken screen captures from a picture viewer of both images because if I upload it directly form the source file, it could not be seen on this blog since the main part of it is white, with a transparent back ground (this could not be seen on this page). In the game I have placed it directly above the player's ship so it can be easily seen and it pulses in and out organically. Although I'm not sure about it because generally when these are used, it points to the direction which the damage came from and I do not have the time to implement this feature so it may be a little misleading, but I'll test it out any way.

Health Bar pulsing:

Along with the items above, when the player's fuel is low, the orange health bar also pulses when the players health is low (when it reaches 1/4 of the maximum health value or lower). I have added this into the game to give the player as much warning as possible and grab their attention when their health has dropped to a critical level.

Fuel Low:

With the fuel low I have added two new features. The first one being the blue fuel bar will pulse when the player's current fuel resources fall to 25% of their maximum fuel level (critically low) or lower. Like the pulsing health bar this is to grab the player's attention again. I would have used the blue refuelling light for this function as well but I thought this may confuse the player since this only activates when the player is refuelling at the purple ship.

As well as this a blue piece or 3D text appear above the player's score playing "Fuel Low". This is there to give the player more of a warning and hopefully grab their attention form the game. When the player's fuel has been replenished above the critical level, the pulsing stops and the blue text is removed.

Laser Gauge Icon:

For the laser gauge bar I found an icon of a ray gun which is widely recognisable. This way when the player looks at the laser heat gauge bar in the HUD they will be able to work out what the bar is for via the recognisable icon. I obtained the icon from "game-icons.net" and edited the graphic so the icon is red like the bar and there is no black back ground (Lorc. Web. 29 May 2014. <http://game-icons.net/lorc/originals/ray-gun.html).

Enemy laser charge particles:

I wanted to warn the play when the enemy was going to fire their laser at them. Initially I did this through text in the tutorial, however it was suggested I do this visually. I implemented this using a ready made assets pack I have already purchased from the Unity Store (the same one I have used the warp gate in the first tutorial level and the enemy spawning particle system). When the enemy ship is in firing mode (to fire a laser blast at the player) the particle system emits and the green orbs spawn from the enemy laser cannon. When the enemy fires, there is a green muzzle flash to make it more obvious a laser has been shot. After the enemy has ben killed or the player is out side of the enemy's range the particles switch off. This should hopefully give the player enough time and warning to work out they will be shot at with a laser blast. The particle system I have used for this is from the same one as the tutorial warp gate particle system (ghdalstjr130@gmail.com. Web. 12 Apr. 2014. <https://www.assetstore.unity3d.com/#/content/13998>).

Player Feedback:

Player Damage Responsiveness:

During play tests for this iteration, I had several play testing my game for general responsiveness of it. The first thing they noticed was how obvious it was when the player's ship was hit by an enemies laser blast. This was because they would see the halo drawn by the light component on the ship model, and how the health bar pulsed when the player was hit.

When the player's health was getting low players' could see that the health bar was pulsing and was attracting their attention mildly from the game. All players from this play test thought this feedback was very responsive along with the light orb around the player since both are the same colour to help the player make the link between the two. This was the player has two indicators that they have been hit by a laser.

Damage indicator:

I also added a health indicator to the HUD using the OnGUI function in Unity. Because the health damage indicator was placed directly above the orange light orb and there was no space between the two, most player's barely noticed it was there. Those who did notice it was there confirmed one of my thoughts, because it is fixed in one rotation (it has a little arrow at the top of the semicircle) most player's thought it was buggy and they couldn't see any enemy's in front of them if the enemy was attacking from behind. I could have modified the code so that if the damage hit a collider on the side it would show an indicator pointing to the left or right, but this would take too long to do and I don't have the time. To state again the damage indicator (I'm not referring to the blood splatter is at a fixed position and rotation.

Low Health Indicator screen (blood splatter):

Whilst play testing this iteration, not many players could see the blood splatter, because it's alpha channel kept pulsing too quickly. However when I explained it to the player, they thought it was a good idea in general, along with the pulsing health bar, but they thought it needed to stand out more, to be more visible.

As much as people liked the idea of the blood splatter low health indicator, many players's thought it was strange having a blood splatter across the screen, then the player's ship is being damaged rather than the polite themselves. They commented the glass screen of the cockpit should have cracks in it and other damage in order to make it more immersive.

Bugs:

A number of players noticed a bug in my game, as soon as the player shoots an enemy, the next enemy spawned from that planet would automatically head towards the player and start attaching. This happens even though in the script when the enemy dies, all of it's variables should reset to the default value. I will debug this in the next iteration.

Muzzle flash and laser blast:

A number of player's suggested that the muzzle flashes (especially the enemy's one) should be larger because they could hardly be seen. It was also suggested I make the blast slightly more visible by possibly added a light to it to make it brighter.

Next Iteration:

In my next iteration I will remove the damage indicator because many player's did not notice it in the game when it was there because it was too close to the damage orb. Also those who did notice it found it to be confusing because it mislead player's be making them think the enemy's laser was coming from the front when it was not.

With the critical damage screen (blood splatter) I will replace this with images of cracks in glass to improve the immersion of the game. I will make the the image is in white in order so I can change the colour of the image to orange to match the health bar. Also it should fit in with the game more naturally since the player is inside a space craft's cockpit.

I will also add the look at statement to the tutorial in order to point the player in the direction of the spawned enemy ship when it appears. This should help guid the player in the game.

The other things I will do is increase the enemy's muzzle flash size, add light components to the laser blasts so they are lit up and brighter and easer to see by the player. I will also make the damage to the enemy more responsive. Possibly by changing the particle effects to some thing larger, added more particle system to it when it's receiving damage and added a few sounds to it so the player knows they have hit the enemy.

I will also fix bug the enemy bug, and find out why it is happening. Another thing is that during the enemy tutorial, after the player has mined the planet, text at the top of the screen reads "Warning Enemy Ahead". The enemy comes fro the left side of the planet, but I can't assume player's will be looking to this side. To fix this, during the tutorial I will use a transform.LookAt command to make the player look in the direction of the enemy ship, regardless of the direction the player is looking in the game.

More refining of the enemy tutorial and more feedback on Responsiveness

Idea:

In this iteration I want to try out the new combat system which makes the enemy less static during battle with the player. As well as this I would like to text out new HUD warnings and the organisation of the front end in general.

Implementation:

Enemy:

With the enemy movement I created a new array of nodes surrounding the player and it follows the player. I applied the camera follow script that I have used on the main camera for this. I parented the nodes to an empty game object, and attached said script to the empty game object that the nodes are a child of. When the enemy is near the player is switches the node array it is following to the player nodes. When the enemy has been killed it returns to the planet node array and starts going back to orbiting it's original planet.

With the enemy I encountered a bug. The new spawned enemy would attach the player straight away. I did not know why this occurred, but I eventually discovered why this happened. Another function in a different script was interfering with the enemy scripts after it re-spawned the enemy at the spawn point. I foxed this by making sure the player was not inside the enemy attack trigger collider and by modifying the if statement so it automatically reset the enemy attach mode. Before hand it worked fine but another piece of code was over writing the new code so I fixed it.

Player Laser:

During my last play test I notice a small bug. If the player swerves to the left or right when moving and firing the laser. When the player did this, the laser blast would lag and drag behind the player ship. To counter act this I increased the force applied to the laser bead rigidbody making the object travel faster. By increasing the speed from 10 to 50 this minimised and nearly erased the dragging problem during fast paced battles with the enemy.

Tutorial refine:

With the tutorial the player starts in front of the trader in the centre of the level, when they get close to an enemy that's when the tutorial starts. When the player is near an enemy, text appears at the top of the screen saying "Warning Enemy Ahead", the enemy travels towards the player and then starts patrolling around them. A small piece of text appears above the enemy (I reduced the size because players could read it because it was too large to fit on the screen originally). Also as seen in the image below (although it's not that easy to spot) above the enemy ship there is red text saying "Enemy Ship". I decided to colour it red because it matches up with the radar and again red signifies danger.

Just before the enemy starts to fire at the player, the enemy warning text is replaced by "Alert Incoming fire" then the enemy attacks.

After this the health bar is revealed to the player, and text above it says "Your'e losing health", then text appears above the player telling them how to fire their laser.

After the player fires their laser, another bar appears above the health bar saying "Laser Heat bar". When the bar fills up, the text changes to "Laser Cool Down". After the enemy has been destroyed the tutorial is over, a health box spawns where the enemy ship was killed, and the enemy is re-spawned at the starting node and the text at the top of the screen reads "you have killed the enemy".

As a separate note. In the middle of the level where the trader ship is, there is a huge sphere collider. When the player exits the collider, this activated the radar and text above it reads "Radar". I have done this to gradually introduce the new feature.

Player Score:

When the enemy is killed by the player, 3D text appears that reads "+1". Promptly after this the players Score "Ships:" is revealed to the player. The 3D text that spawned from the enemy "+1" moves towards the score, when it collides with the player's score, the score value raises and the text from the enemy is destroyed. This is an attempt to link up the player's actions with the new part of the front end of the game.




Player Feedback:

Player Actions need to be more visually responsive.

Need muzzle flash for laser blast.

Laser blast beam needs to be bigger.

player doesn't know why the laser blast suddenly stops working, this needs to be more obvious.

Player doesn't know why the game suddenly ends and they loose.

Player's are too engrossed in enemy combat to look at the score.

Replace "Incoming blast" text with something that shows the enemy's laser is charging up.

Player does not notice the score.

When enemy appears in level beside planet, the player does not know where it comes from since it just appears from no where. Perhaps more visual feedback like a large particle system like the warp gate when enemy spawns.

Next Iteration:

In the next iteration I will completely re-write the mini enemy tutorial. The intro screen will emphasise the importance of gaining a high score and how the player gains points (mining planets instead of shooting ships) and briefly mention enemy ships will get in the players way. I will place the player in front of a planet at the start and when the player has mined a planet the enemy will spawn. Along with this I will improve the game's responsiveness. This is because many players found things like they didn't know if they had hit an enemy and they didn't know why they had died when their ship's fuel was low an s o fourth. Along with this I will make the player's score more obvious when they gain points, so they have less to think about during the game.

Further Polishing, Player Score, and Enemy Intro

Idea:

This iteration I will slow down the fuel drains, the speed the mini enemy tutorial moves at and try to link up the score with the player in game actions because there were the most requested and are an important part of the design. The other changes I will implement are fuel low warning signs, health low alerts and adding more icons to the HUD mini map.

Implementation:

Reduced fuel drain speed:

Initially I halved the drain rate, but I found even I couldn't make it back to the trader from mining a planet. Then I tried halving the value again, but it wasn't quite enough. After this I decide to reduce the value form 1 fuel per second of movement to 0.25 fuel per movement (about a quart of the original value).

Added trader and enemy Mini Map Icons:

I have been meaning to add these new icons to the Mini Map for a long while but other things like game play refinements have distracted me form this. With the icons I created them as bitmap images in PhotoShop in single block colours. With the trader I used a bright purple colour, with two rings and a dot inside the rings to resemble the actual shape of it.

With the enemy I created a pointy looking ship that had two wings to vaguely resemble a top down view of the model. I used the colour red because that colour is associated with danger, and most enemy's on radars are coloured red. This should help the player link up what is on the radar to what is happening in game. The imaged used are shown below. ( the image on the left is the enemy radar symbol, on the right is the trader ring ship radar symbol).

Added Warning Text in the HUD:

At the top of the screen I have added several pieces of 3D text. These are to alert the player when something is going wrong. Many players did not know when their fuel was low and wondered why they the game was over so quickly. To help with this I added some 3d Text to the top of the screen in a blue font, so the player can link up the colour to the fuel resources and the GUI bars. The player should see this in game as relate it to the fuel bar.

I have done the same thing for when the player's Mass cargo storage is full and cannot mine a planet, I made the text green like the Mass Resources and the HUD bar for it so the user can relate the two.

By the way, only one of the pieces of text will be show at a time. In the picture I have just screen captured both to ease of use in this blog.

Just to repeat my point, all of the text only appears when a certain condition is met, i.e. the blue 'Fuel Low' text only appears when the player's fuel resources are at 25% or lower. When the fuel raises above that value, the text disappears. When the player's mass storage is full the text appears, but disappears when the value is lower than 3/4 full.

Added Debris into the level:

A comment I got from many players (mainly on the art and aesthetics side), was that the game level itself was too bare and empty. I partially agree with this as well because I did not want to clutter the level, but the level needed a little something to lake it seem less empty.

I looked at many images of space and space games so see what I could include in my game. I also looked at various web sites and the Unity Asset Store for items I could use. I noticed in a number of space games, asteroids are used as well as satellites and abandoned space stations and lab equipment.

Firstly I created an asteroid in 3Ds Max by creating a low poly sphere (about 400 polygons), then I added a noise modifier and altered it's parameter values, as so it did not look too bumpy or spiky (or too little so it still fitted in with the games style). After this I looked online for an asteroid or space rock texture, but I could not find anything suitable. I looked to one tutorial that show how to create space rocks and it suggested finding a texture of the 'Moon' and applying it to the model. I quickly went of Google and promptly found a good Moon .jpg image to use as a texture and it was royalty free too.

With the Moon texture I resized it to a 512 by 256 texture and it got it from (Hastings-trew, J. 2006. Web. 26 May 2014. <http://planetpixelemporium.com/earth.html>.). For the record I have not got the wrong reference despite the page title, it just happened to be on the same page as the Earth texture Map. Coincidentally I found this on the same site that I found the Mars planet texture.

I also tried to find a satellite because this fits in with the theme too. I found a low poly model of this on www.turbosquid.com/FullPreview/Index.cfm/ID/337131. It was 368 polygons and does my make my game drop frame rate so I am happy with this. I decided not to texture this because as far as I am aware the model is not UVW unwrapped and I cannot afford the time to texture the model, also I texted it out and people can see what it is in game and prefer the colour of it since most satellites are black and grey with the metals colour, very much substance over style.

I placed these assets near the outskirts of the level as to not distract the player too much and clutter things up, but still make the game level more interesting. All of the assets have colliders and rigidbodys but as the moment they don't damage the player and they cannot be destroyed by the player. However I may include this feature if I get the chance before the dead line. It is mainly there for aesthetic reasons, also I don't want to over load the player with more stuff to think about considering there are enemies in the level. Again the satellite is there in the level, and has both a collider and rigidbody, but it does not harm the player if they collide into it.

New Audio:

Button clicks

I have added two new audio clips into the game. The first one is the button click sound for the menus, level intro screens and game over screen. Because my game is space and sci-fi themed my menus looked either like holograms or pains of glass, therefore I thought a button click sound may not fit the game well.

I decided to go for a sound that was noticeable, but sounded lighter than a proper clicking sound. I settled for 'btn050.wav' by junggle on www.freesound.org/people/junggle/sounds/28860/. This sound does what I want it to because it gives the player audio feedback when they click a menu button as well as the colour tint of the button with the help of nGUI (Tasharen Entertainment, 24 May 2014. Web. 26 May 2014. <https://www.assetstore.unity3d.com/en/#!/content/2413>).

Tutorial Level Complete Sound

Many player requested a sound effect when they complete the level when the warp gate appears. This way they get more responsive feedback other than just visual feedback when they complete the tutorial level. I obtained this audio clip from Sweeper. "SoundBible.com."(Sweeper. 28 Apr. 2011. Web. 19 May 2014. <http://soundbible.com/1795-Electrical-Sweep.html>.).

Player Feed back:

Fuel Draining Slower:

Many players liked the how their ships fuel lasted a lot longer then in past iterations. Player's found they could make more than one trip to a planet before having to go back to a trader for more fuel. In face many players found they could actually travel back to the trader after a single trip.

Mini Map Icons:

When I introduced the new mini map icons many players liked the change. The player could tell that the purple ring with dot in the middle was for the trader because it was the same colour and shape. They could also tell where the enemies where on the map and in the game world so they could work out how to avoid enemy ships.

One person suggested either making the enemy graphic smaller or just a red dot so it doesn't take up as much of the mini map. Provided I get the time I will do this.

Firing button:

Most players thought the new firing button was OK because I tried out the middle mouse button and players found it uncomfortable to use.

Player Warning HUD Text:

The majority liked the idea of the HUD warning text at the top of the screen but on a practical level, most players did not notice it. They also said they couldn't see how it linked up to their in game actions as well as the resource GUI bars because when in battle with an enemy ship they did not look up at the screen and did not notice the text most of the time. I thought about moving the text nearer to the front end items such as the fuel bar and so fourth, but then I thought that this may confuse the player because instructions during the tutorial are in the same place. I will think about where else to place these text warnings for the player.

Asteroids and satellite:

A few players wondered asked if they could shoot the asteroids and possibly if would damage their ship. When I asked if they would like this feature to be in the game they all said, they thought it would be a nice addition since it would be another item to avoid and add to the game play (both the stationary asteroid fields and the moving ones in the level). In general thought the new debris in the game added to the immersion and made the space feel less empty.

Next Iteration:

In the next iteration I will concentrate on slowing down the enemy tutorial because player's still thought it explained the new enemy mechanics too quickly. I think I will make the timer take longer between the different triggers so the player has more time to digest the new new information.

I will attempt to make the player's actions more obvious, such as when the enemy is taking damage and make the warning text relate to player actions more in the game, like the Fuel Low Text.

Play testing the refined Enemy tutorial again.

Idea:

In this version I will add a an object above the player with an icon texture. This will only be visible on the mini map, so the player can tell where they are in the game world. I will also fixed various bugs and tell the player when fuel is low and when their cargo is full.

Implementation:

Player Icon Radar:

I added the player icon to the top of the player but I added it to the "mini map" layer. This means it will not be rendered by the main camera but it will only rendered by the mini map camera and show up on the radar.

Planet Icons Radar:

I noticed that the game lagged a bit when I reintroduced the mini map. Although because I know my own game well I have have just over though it. Either way, I decided that it wouldn't hurt to improve the efficiency a bit.

With the planets they are about 500 polygons each. On the mini map, only a small amount of detail an be seed on each planets texture. With this I decided to make a small circular plain on top of each planet object (not viewable by the main camera). ThenI rendered each planet with it texture from a top down orthographic view. I cropped the images so they could be applied to the circular plain correctly as a 32 by 32 texture. Not much of the detail could be seen so I kept it low resolution. I did this for each planet model.

It appeared to do it's job and people liked the aesthetic so I will keep it.

Fuel Low & Cargo Full Text:

With this I created some 3D text built into Unity, using the "Quadangle" font to maintain a consistent style in the game. Firstly when the player's Mass Storage is nearly full, text appears at the top of the screen saying "Take Mass to Trader", the font of coloured free to link up with the consistent style and so at a glance the player sees green and links it to the Mass resources. When the player's collected Mass resources drop to 2 or lower, the text disappears.

I also added another piece of text at the top of the screen that says "Mass Storage Full" when the player tried to mine a planet when their Mass Storage is full. This is because many players were wondering why they couldn't mine a planet when their Mass Storage tank was full and thought the game was broken.

With the fuel, many player in the last play test commented on how they wanted some sort of warning for when their fuel was low. This is because the player would be engrossed in the game and interacting with the enemy, then suddenly they would find they had ran out of fuel and died. To fix this, I created some text and made the font blue to link it to the fuel resources. It appears in the same place as the "Mass Storage Full" text. Again it appears when the players fuel drops to '5' of lower, and disappears when it is above '5' fuel.

Bugs encountered:

Enemy firing:

With the enemy firing I hit a few snags. Firstly I over complicated the script for it. Initially the line renderer does it's job and that is fine. Then I used a recast to hit the player and deliver damage. However some times the rayCast would miss the correct collider to hit. I.e. it would shoot thorough the player's colliders.

The reason I used a rayCast is because initially I tried giving the player damage through the enemy the wrong way. I initially used a box collider to hit the player, the collider itself was quite long. It would adjust it's length according the the rayCast "hit.distance" command. Sometimes it would also hot register the player and be frustrating and it would surpass a maximum length I had set for it.

After a few hours I reached a "Duh!" moment. I should have just set the box collider to a maximum length and if the player enters it, it delivers damage. The collider does not need to rescale it self.

Thinking about it, the number of times I have had to re-create and re-program the enemy laser code is in double figurer and I should have done the simplest approach. Oh well, I know now I shouldn't have drilled down and over complex things for myself.

Enemy explosion & Health Box Spawning:

From the last play test several players noticed that after they had destroyed an enemy, the later enemy's could not destroy the player because the players health would not drop after the first kill. Another one noticed that after they had destroyed an enemy, their health would shoot up back to full, with out touching the spawned health box.

This was a strange bug. Firstly I checked to see if the enemy was hitting the player through code and it was. I checked to see incase the player or enemy had changed layer, and it hadn't. I check incase the enemy laser damage value had changed to zero and it hadn't.

Some how when the box had spawned, it was like it was in the enemy collider and or the collier must have increased. I couldn't work out what was going wrong, but some how with the health box spawning in the place where the Enemy Ship had exploded it was carrying out it's health regeneration function for the player. I tried using a 'yield WaitForSeconds' statement during the enemy death function, but this only made the frame rate drop massively and the game lag.

I then tried making the box spawn above the enemy explosion and gently drop to the player's level falling in the 'Y' axis. When I tried this out in game, it worked quite well, also because it gently appears about a second after the enemy explodes, it gives the player time to digest what has happened, before introducing something new.

Enemy Intro:

When the player goes near the enemy (about 70 in game meters) the enemy automatically goes towards the player, text appears above the ship saying "Enemy", then the text disappears after a second. After a second the enemy starts firing at the player, the health bar is revealed to the player, after 0.7 seconds text above it says 'You have taken damage', then 2 seconds later, text appears above the player ship with instructions on how to fire their laser. After this the laser heat up gauge appears, the enemy explodes, and a health pack appears and the tutorial ends.

Another thing with the enemy. When it gets too close to the player (there are two colliders attached to the enemy) by the player entering the inner collider, the enemy stops moving forwards. When the player eaves that collider the enemy continues to move forward.

Player Reaction:

During the play tests many players found many areas the game needs polishing.

Diego:

• Needs level completion sound
• Need to be able to make a complete trip around solar system
• With laser, there needs to be a second sound for when it loops - ?, maybe no need now
• Player damaging enemy is buggy
• Add enemy icons to mini map
• Shooting mechanic is too stationary
• Does not like the space bar to fire
• Perhaps the enemy could fire bullets
• Possibly a suicide bombers - ?
• Possibly have a laser as a blast like bullet
• Reduce fuel drain
• Button click on tut level 1 needs t be the same as start menu.
• Make first planet closer or drain fuel slower

Good points

• He likes the bar
• Jonathan Play test

Martin:

• Fuel drain is too fast

Good points

• I like the enemy. if I want it to be an actual threat, it needs to be faster

Dominic:

• Need to tell player about kills ships for higher score
• He can't see the planets on the radar
• Need a Full Tank sign
• Needs more fuel!!!
• Doesn't know where to go after planet

Good Points

He loves the bass like thruster sound

Bradley:

• Maybe have a battery icon above the trader
• Need debris in the background
• Laser background bar pulses when mining planets

Good Points

• Sounds are cool

Next Iteration:

With how things have gone I and most other play testers feel that the planets are the correct distance away. Therefore I will slow down the fuel drain to something like 0.3 per second. Also along with this I agree the combat is a little too static. I may try creating a new node path around the player, adding ti to another array, so they enemy can automatically swap to the player path nodes and curcle around the player ship. This is because in most space sims and space shooters the enemy ships always seem to be moving around to keep the player engaged in combat.

As well as this I will slow down the new enemy tutorial since many player still thinks it explains the new shooting mechanics too quickly. After this iteration I will add more debris to the game to make it feel less empty and make the game more responsive like with giving the enemy damage from shooting it and vice versa.

My last point, I will create a new graphic for both the grader ring ship and the enemy ships for the radar mini map. This is because many players confused the purple planets on the mini map for the actual trader and quickly became lost in the level. I need to create a small graphic and add it to the game soon to make lower the difficulty barrier for the player. I need to so the same thing for the enemy ships, because many players also became confused about this and could not see them on the radar. This caught many player by surprise because they were not able to anticipate the new enemies.

Adding some more sounds

Idea:

For this iteration I would like to find some sounds to make my game more responsive on an
audio level.

Implementation:

Apart from the backing track for the game itself I have found founds for the laser and for the ship being damaged.

I have spent several hours trying to find the correct sounds for the laser since most of them sounded either very old fashioned or horrible. The sound I found for the laser can be heard but it's not in the player's face, so the player will recognise the sound as being a laser.

With the damage sound, I initially tried to find a sound of metal being impacted, and this difficult because most sounds available were of metal being propped or machines operating. After some times I realised, unless I have a plasma shot or the player fires bullets this is not needed. With this in mind and the fact I am using particle emitters to produce sparks, I decided to find some spark sounds. After some time researching I found a good spark sound that was loop-able if needed and was loud but not too loud.

Player Reaction:

Laser:

Several people liked the laser sound and thought it was very responsive, but a few commented that it wasn't looping properly because the sound was for a single laser blast like a phaser rather than a constant beam.

With this in mind most people liked the sound I had implemented, however if more people ask for it to be changed, I will modify it.

I found this sound at freesound.org (mckinneysound. Web. 9 May 2014. <www.freesfx.co.uk/soundeffects/lasers_weapons/?p=2>.).

Spark:

With the spark sound, I mistakenly kept the audio source at full, meaning when the player or the enemy was receiving damage, the audio clip was too loud . A few players commented on how if the player uses a constant beam, the audio clip players two sparks bursts (that's just how the audio clip works) and there should just be one spark sound burst. Considering only a few people asked for this to be changed, I will alter these audio files when I get the chance, but if the comment recurs I will do it more promptly.

I found this sound at freesound.org (Connum. 3 Oct. 2005. <www.freesound.org/people/Connum/sounds/11709/>).

Non-audio related feedback:

Radar:

Several play testers play testers commented how how they liked how the planets showed up on the radar, meaning it performs it's task well. Player than said they could roughly work out where they were in relation to the world. However several people commented how the player, the trader and enemy's don't show up on it. Several players even thought the purple planets were the trader due to the colour and shape similarity.

They asked for a player, enemy and trader ship icon to make identifications of body's clearer.

Player Mass resources cargo hold:

A large number of players thought they pointed out a bug when they tried to mine a planet, but it turned out their Mass resource cargo was full at the start of the level (may have to reconsider this). To help with the managing mechanic I kept it so the player can not mine a planet when their hold is full. With this in mind the player is not told about it, thus they will probable think there is something wrong with the game. I need to give the player more feedback with this, e.g. text at the top reading "Cargo Full".

Fuel Low Warning:

A numbers of players requested a feature that when their fuel is e.g. 25% or lower, they are alerted some how in the game. This could be useful because the player may have needed an enemy encounter, and not have looked at their fuel bar, it could be a reminder. Like with the cargo full text I may add this feature in the next iteration.

Lowering the difficulty:

Another feature suggested was to either have the planets closer together, another trader in the level, have the enemy drop either fuel or health when dead. Another suggestion was for a speed boost feature, that does not cost the player any fuel but only works for a limited times when used.

Lost in the main Level:

Also some players became lost in the game since they would explore the level and could not find the trader again because it was not on the radar. I need to fix this issue. Another thing is player's can't make a return trip to the trader ship, especially after encountering an enemy because some of their fuel is used up from moving away from an enemy ship.

Ship movement when fuel is low:

Another suggestion was to just have the ship move extremely slowly when fuel has run out. This would also lower the difficulty because players can die too easily at the moment with both no fuel or health killing them ending the game.

Also the health box does not appear to disappear instantly thanks to a bug (I will fix this ASAP).

Enemy Damage Feedback:

Another item people commented on was, that they couldn't tell when the enemy was being damaged (well only a few people could see the enemy sparks and smoke). A suggestion for this was eaither a damage value above the enemy or a mini health bar (orange coloured, the same as the player's HUD, so keep with the house style helping the player).

Many people did like the flame animation from the ships exhaust and the explosion effect.

Bugs:

It was noticed when the first enemy is killed, the payer automatically replenished their health, so the player doesn't need the health box. After this the player can't be killed by the enemy. Many people noticed the bug. However everyone liked the 3d model of the rotating health box and how is slightly glowed.

Next Iteration:

A few players requested click sounds when they click on a menu button.

The bug where if the player dies during the mini tutorial during the game level (enemy tutorial) is still present, they will revert to the first tutorial level and when they get back to the game level, the tutorial will not run.

Main menu should have a more interesting back ground, than plain black, and possibly something animated going on in the background.

If I get the change I will alter the sounds files according to the suggestions above, but that depends on how much time I have left form other aspect of the game.

In the next iteration I will experiment with the "Warning Fuel Low" Text alert for the player. This will not take long to do and if player's do not like it I can remove the feature. I will do the same for when the player tries to mine a planet when their cargo is full. This will hopefully make the game easier to play since player's will not waste fuel traveling to a plant and thinking the game is broken.

Alteration to project time line

This blog is about my revised time line for my dissertation Project. At the moment I am working on my project, however because I have spent a lot of time on tutorial levels and the visual design (and group project and masters degree stuff), I have neglected the actual game play and the economy of the game itself. Therefore I would like to put more time into it to make the game an enjoyable experience for players.

I have updated it because I have having to fix part of the programming and design, and this is taking longer than expected, and this is preventing me from refining the game.

The time table below is the updated version.

Improving the enemy tutorial

Idea(s):

After my last play test and iteration I gained feedback. Players' liked how there was more variety in the game level now with the varying planets. I will keep this feature. However as I guessed, they needed to learn how to kill the enemy ships in the level. Also player's wanted to know when they were damaging the enemy ship and when they were receiving damage.

Implementation:

Mini Tutorial Level:

Initially I started creating a miniature tutorial level for the enemy ships. This took up half of my day. I planed a planet in the level for the player to mine, and an enemy ship for the player to investigate. After the player goes near the enemy, the enemy ship attacks the player, only damaging them slightly. I also reduced the difficulty of the planet mechanics in this level. This is so the player has time to learn the new mechanic. The enemy slightly damaged the player, reducing their health. Then a health bar appears in the HUD. The player is told about this.

The enemy's firing rate is reduced so the player has time to learn everything. Then the player is told how to fire the laser. When the enemy's health reaches zero, there is an explosion using a particle system and the player's score goes up.

Reconsidering the mini tutorial level:

After I built the tutorial level I played it through. There was a lot wrong with it again. Yes I showed, the player their ships health, but I did not link up the HUD to the health again, the bar just jumps in size. Also there was little indication as to how much damage the enemy had taken for the laser firing, and the laser worked more like a bullet. I.e, it would switch on for a brief time, then off, rather than for how long the player pressed the button for. As well as this, the tutorial was buggy and I needed to have some more level design. I worked out I needed more time than what was available and I wanted to improve the economy and mechanics of the game level rather then be bogged down by another tutorial level.

With this in mind I decided to leave this level alone and create a mini tutorial intro in the main game.

Re-creating the level:

Mini tutorial sequence:

Firstly, if the player starts playing from the first tutorial level, this triggers a static boolean. If this is triggered, the tutorial starts in the game level. After the intro screen the player can travel to any planet.

Showing Radar:

Where the player is positioned at the start of the level (in the middle of the Unity scene ), there is an "isTrigger" collider. When the player exits this collider and before they interact with any planets, the ships radar appears in the HUD in the centre and 0.5 of a second later, text is revealed saying "Radar". I added this because many players requested this feature because they said they became lost when exploring the level.

Enemy Ship:

Around some of the outer planets there is a patrolling enemy ship. If the player is near enough to the ship, the enemy ship will travel to the player. (I have made sure the player can't see anything else distracting during this event, apart from the planet in the background, as to not confuse the player) When it is travelling to the player, large text appears above the ship saying "Enemy Ship". This disappears after a second. A few seconds after this, the enemy ship fires it's laser towards the player. The player ship releases a small amount of sparks, I tried making the own sparks form the particle system, but this took too long and I couldn't achieve the result I wanted because it made the ship look like it was flying downwards. I used one the built in unity legacy particle emitter prefabs. When then enemy stops firing for a second, the sparks stop. The enemy keeps staring and stopping until it has been blown up by the player.

(Image above is the enemy ship text, the image is the laser fire instruction)

A few seconds after the play has been hit the first time, the health bar appears in the HUD, and text reads, "Health bar". The bar gradually reduces in size (x axis), when being hit to indicate what it's linked to.

The laser heat gauge bar appears and starts filling up slowly. When the player releases the middle click button, the bar shrinks quickly. Text appears about half a second after it is revealed saying what the bar is, the bar is also the same colour as the laser, this helps link the laser to the HUD. When the laser cools down from short bursts, is reduced in size quickly. When the bar is used a lot, e.g. to full, the laser over heats and the player can no longer use the laser until the HUD bar has shrink in size so it can't be seen. It's alpha channel also pulses to make it more noticeable by the player.

When the player is hit by the enemy ship, it also spawns sparks to show it's being hit. Another feature I added was a smoke particle emitter prefab (again from Unity's built in assets). I tried making my own, but again this took too long and the smoke was perfect for my needs. On both the player ship and the enemy ships, when their health values reach 50% or lower, smoke particles start spawning, so the player know things are getting bad. E.g. if the player's health is 50% of lower, the player ship emits smoke but not the enemy. If the enemy ship's health is 50% or lower, the enemy ship will spawn smoke and not the player.

When the player has destroyed the enemy ship, it explodes, and text at the top of the screen read "You have destroyed the enemy ship" and the player's score in the HUD increases. After this the player has completed the tutorial and can carry on with the game.

Player Reactions:

When the enemy ship appears players thought, the text was too large and part of it could not be read because it was off screen with how large it was.

When playing, many people requested the enemy ships drop wither health or fuel because the player is low on both after the battle.

Many people requested audio feed back with the player's actions, such as attacking, giving and receiving damage, better explosion sound and better game over sounds and get a back ground track.

Give the enemy a different colour laser weapon form the player. E.g. player has a red laser, enemy has green laser.

The player needs to be seen in the radar so they know where they relative to the game world.

Bugs found:

• When the player dies, they are sent back to the first tutorial level, regardless of where they are in the game. After they complete it again, the player is sent to and old unused level.

• Some times the player attaching the enemy does not work correctly.

• The enemy ship can attack the player from a great distance but the player can't do the same.

Next iteration:

Many play testers liked how the enemy attack system was more like a laser than a bullet and the amount of damage the player received is enough (not too much or too little).

Next iteration I will add some more sounds the players actions, like laser firing and damage sounds.

I will also add a health box in the next version, probably when the enemy dies it will spawn a health box which the player can go into and collect health.

Another thing I will make the enemy easier to kill. I will reduce it's health form 7 to 5.