Final Changes:
Bugs:
First tutorial Level cut from the game:
A few days before the dead line I encountered a bug during one of my last play tests. During the first tutorial level when the player goes near the purple trader ship, the tutorial plays up to a point but the trader ship does not refuel the player's ship. As part of the tutorial sequence, because the player is not refuelled the player can't move at all. Also as apart of the tutorial, when the player is interacting with the trader ship it's position is frozen until the transition is completed. This is so the player doesn't wonder off and look track of where they are (this does not happen in the actual game). I have tested the main game and this does not happen, because luckily the trader ship in the tutorial uses a different script but does the same stuff.
I tried debugging this for many hours, by checking all of the values were correct for the if statement, made sure no game objects in the scene or in any other scenes were interfering with it. The Mass values and the player fuel values all matched up the requirements for the trader to refuel the player by using Debug.Log and other debugging methods. I even asked my programming lecturer if he could see what was going wrong wrong and he said the if statement was not being met, with the correct values. After double checking the fuel and Mass values met the requirements for the trader it still wasn't working. After this, it was suggested I cut this tutorial level from the game since it would take up a lot of time to fix which I do not have and I'm not being marked on it. Instead I have written an instructions sheet for how to play the game. The enemy tutorial still works though, so the tutorial button at the start links to the game level but activates the enemy tutorial.
If I had more time on this project, I would have located and fixed the bug. Post Dead line I will attempt to find and fix the error because I will have plenty of time to do so. I find this quite annoying because the game will be seen in it's full entirety.
When player's laser over heats:
During my last iteration several players were engrossed in combat and they still wondered why their laser would stop working. To fix this I added a smoke particle from the built in Unity assets (the FluffySmoke Prefab). I have used this prefab before to demonstrate how much damage the player and enemy have taken as well as other features. However I used this for the laser cool down function as well but created a separate prefab and modified it. The smoke particles have a larger start size, and I created a different particle texture that I tinted red to match with the laser. I created a new material for the laser smoke because other wise the smoke using the same texture would have been red as well.
When the player presses the fire button when the laser is cooling down, a short puff of red smoke will rise. This should help the player work out the laser is cooling down since it's the same colour as the laser, and the gauge bar. As well as this above the gauge bar, text reds "Laser cool Down".
Tutorial button On the Start Screen Buttons:
The Tutorial button goes straight to the game, but activates the mini enemy tutorial at the start. This is down the the bug I mentioned earlier in the post.
Player Health Regeneration responsiveness:
In order to help show the player their health resources are being replenished, as well a the GUI health bar growing, and pulsing, the orange light on the player (the same one that activates when they receive damage) will light up until the amount of health from the health box as been added to the players current health bar (for the record I mean current health resources value not maximum health value). As soon as the health has been added to the player, the orange light switch off.
Enemy re-spawn Laser Damage Value:
When the player has killed the enemy, the enemy will re-sawn and start patrolling around a planet. However, that enemy's laser damage value (the damage the laser delivers to the player) will slightly increase (by 0.25 each time). I kept this change, and settled for this value increase, because it adds some progression to the game, by very gradually increasing the difficulty of surviving against enemy ships. I made sure it was this value because anything higher in my opinion, ramped up the difficulty too quickly. Also I made sure this value only applied to individual enemy ships. Fox example, if the player shoots an enemy patrolling around a planet, the enemy around another planet will not be affected by the change until that particular enemy has been killed. Again I did this in order to not ramp up the difficulty of the game to quickly.
Unfortunately I have not had time to test this on other people, however I personally think this will draw the player in and keep them amused for a while. With this in mind I tested but put myself in the player's shoes (which was difficult) and I think the difficulty progression was suitable but I'll have to see what the final play testers think.
Mass Storage Increase Feature:
In this final iteration I decided to add a new feature that was requested by a few players. When some players requested that they wanted a Mass Storage Space increase at some point in the game. I after some experimentation, I created a function that when the player has minded four planets, their Mass Storage Space increases by 5. I decided on these variables because it's not too high making it too difficult for the player, but it's not too low so it removes difficulty all together. I decide on four planets, because again, I found five and six planets took too long to travel around, and two or three were simply too easy, there was no challenge. But again I will let the final play testers decided.
End Result and Personal Appraisal:
On the mechanics side of things, my project has become less of a resource managing game, but the economy is still there, it's more prominent than the managing mechanic. Because I decided to add enemy ships that patrol planets and attack the player as my obstacle for the player gain Mass resources and increasing their score, my game is less of a managing game than it originally was. It is still there but it is faint and the player does not end up being over whelmed with resources until everything collapses. it's more how long can the player last until they run out of resources and "how high a score can they get?". It is more of a shooter game with resource management than a resource management game.
The game is not a polished off as much as I planned on it being, and it is not a complex or deep as I wanted it to be, but it has kept play testers interested for a little while and through out development every said they liked the idea. The game is not a interesting as I originally hoped, but it has kept play testers engaged, and I have learnt a lot making a game like this. It was certainly a challenge. Current'y the game has a number of mechanics and it turned into a large project which needs more polish. It would be good as a prototype because it demonstrates the mechanics I need to show and it serves it's purpose, but as a game end product it needs more polish every where. I would like to continue this project after the dead line, but using the knowledge I have gained over the past year and avoiding all the mistakes I had during the project for a more polished product.
The resource managing mechanic would have been more prominent if I had made the resources decaying over time the obstacle. Where as with how the game in it's current state, the resource managing mechanic does work with the internal economy but with the game going down the shooter rout it is not as prominent as I expected and not as entertaining as I had originally hoped. I have learnt if I want to make a internal economy and resource management game, I should not include shooter mechanics and enemy ships as obstacles. Maybe one could do it, just I have not found a way to do it.
Things that went well:
Early, Regular and frequent, play testing:
During the entire project I have always made sure I have had play testing sessions through each iteration of my project. This is because a player may find a game breaking bug, or find a way to do something with one of the mechanics that I have completely over looked that could improve the game significantly. Also I can get a player's opinion of a particular mechanic, or find if a source is not producing resources fast enough or if a drain needs slowing down. This went well because I regularly received player feedback and took the most requested items into consideration when iterating.
No over scoping:
Normally with my project I have a habit of over scoping them and under estimating how much time each task will take to complete or learn. I avoided it this year by estimating how much time I thought something would take to do based on past experiences (or for a new skill, how long to learn) and then doubling that estimated time. This has proven useful because I have not created more work for my self than I can handle and realistically complete in the given academic year. This way I have made sure I have completed my tasks on time according to my mile stone time line, and if something goes not as planned, I have buffer time. This also means that I do not have a million different mechanics that will quickly fall apart, I have time to develop the simple mechanics and see what works with it, for a more refined and polished experience.
How to create an in game tutorial:
Before this project, I have always made an Instructions screen for the player in digital projects. This is O.K. for simple games. However for a complex project like mine, it required more work in order to show the mechanics to the player.
Originally I crated several instructions screen, that would explain each element of the game to the player. However, after several play tests and one of my lecturers went though it, I discovered the "How to play" scene was badly written because I had written everything from the designers point of view and not the players.
After this I created a tutorial level, showing the player the different mechanics of the game. However, after a number of play tests I realised the level needed a complete re-write because I explained everything in the wrong order, I did not explain other aspects of the game enough and in some parts I explained too much to the player too quickly. For example, I would show the player three items at once and explain what they were very quickly, where as I should have show the player one things at the time and allowed them to digest the information at a reasonable pace.
After gaining feedback, asking for help form the lecturers and several re-writes, the tutorial level was perfect (or as near to that as I can currently get).
How to create a pseudo simulation game:
I have never made a digital resource managing game with an internal economy. I have also never made a space themed game before. This has been a learning experience for me because I have combines two areas of design I find interesting and experiment with how compatible they are with each other. It has been a challenging year, but I have leant I had more time I could have polished the game off more and done more with the economy. However, form my experience this year, I think the theme suited the mechanics of the game and it was an interesting experience because I learnt how to balance a game's economy, design a level and keep the game interesting. I have also found out it is difficult to make a simulation game entertaining because simulations have a serious tone, so I now know when to cut back on the realism and make the game more entertaining by holding back on scientific accuracy.
What didn't go so well (Mistakes from this project I have learnt from):
During the dissertation project I have learnt a lot from my mistakes and general experimenting on the project. I'm sure I have more to learn and will continue to make more mistakes, but as long as I learn from them and make new ones rather than keep repeating the old ones I will progress as a designer. The whole game has not turned out exactly as I have planned, but at least it works.
Paper Prototyping and spending too much time on the theory:
During the first semester I spent most of the time (at least 80%) on the project working on the theory and the paper prototyping. This was good to a point. What I mean by this is, I was intending my my project to be a digital game built in the Unity3D engine. I spent most of the semester working with the paper prototype and with this I started drilling down into the specifics a little too early (I didn't do it as much as I normally do, which is better than I used to be but it still happened). However, when things were breaking more and more, I noticed this a lot sooner than I normally would have, thus I saved my self some time and kept in mind the big picture when designing the mechanic for the game.
With the nature of my game, I spent too much time on paper prototyping the wrong parts. I should have just tested of the economy with prototyping (and the Machinations tool). Various elements of my game, such as the movement and actions were on gridded paper and I had to make the paper prototype turn based. This caused a lot of headaches for my game and when I built my first digital prototype in Unity, I scrapped the gridded movement and turn based feature in my game since it was being a hinderance because there was a dominant strategy with the level design and the events in the game were quite predictable. Also if it was a non-digital board game, the economy would be incredibly unbalanced. And the managing resources mechanic would either be too difficult or too easy and generally horrible to play. If it was a non-digital game it would be better as a card game in the style of "Gazillionare" (Gazillionare, 1994).
Any how to summarise what I have just said, I spent too much time on the paper prototype and I prototyped all of the game, nit just the economy and resource managing aspects. This slowed down development of the game by far. However, at least I am well versed in the theory of internal economies and resource managing mechanics.
Digital Prototype:
Straight after I received feedback on my proposal and went through my design document at the start of the year I should have created a digital prototype of the game in Unity as well as creating a paper prototype of the internal economy. This would have saved me a lot of time and my game would have been more polished, have a deeper experience for the player and more enjoyable to play overall.
Focus On Design and Usability:
Shortly after I created my first digital prototype, the design and usability were a left left to be desired. E.g. everything was static, player's did not know what they were doing or what their goal when they started playing, the controls were complex (the keyboard controls were uncomfortable). I fixed my changing it to mouse movement and the "space bar" as the fire button. Another example when the player was gaining resources, it wasn't clear if they were gaining anything.
However I took several week to improve upon this and and make everything more visual for the player. From this I have learnt that as a designer I need to grab the players attention and make game actions as visual as possible so the player has to think less. This was the player will spend more time playing the game than wondering how to play it in the first place. Things like, if an enemy will attack and you want to warn the player, represent the charge in a visual way, e.g. particle system for a laser charging up. Another way to explain this is when my digital prototype started out, a resource connection between the player receiving resources from a source, was instant but the player didn't know what was going on. After this I made the trisection slower (but at a snappy speed) but also very visual, using particle systems going towards the player from a planet and the resource GUI bar increasing in size. I know the example is long winded but hopefully I have carried my point across.
Spending too much time on the wrong areas:
After the Christmas break I started creating a tutorial level for the player. However, my tendency to drill down, took over and I defiantly have spent too much time on the tutorial levels. With this time (as I have maintained through out this blog post) could have been spent on improving the level design and the economy of the game, by doing things such as adding new resources, or when the player shoots an enemy, their maximum fuel or mass capacity increases. I could have refined my game to a superior standard than it currently is but again this is something I have learnt from. In my next project, every week I work on it I will take time out to make sure I am not spending too much time on the wrong parts of the project and putting too much work into part of it, because that effort could going into a more worth while part of the project. E.g. I spent too much time on the theory in the first semester, and this
semester I spent too much time on the player tutorials that I could have spent on the economy.
What I could have done:
This project had so much potential. If I had more time and especially if I had immediately created a digital prototype instead of just the theory during the first semester, I could have further polished and refined the game and possibly add more features. I could have so much more with the economy, I could have added a wider variety of different resources for the player to collect that have different values.
Trading resources:
Considering my game is very nearly mouse only, if I had developed the economy further, the player could trade multiple resources using the mouse, or even to this with a planet. When the player is purchasing or selling resources or buying upgrades this could be done all using the mouse . I could have done this by creating a new scene in Unity3D and using nGUI for the interface to make it easier to use.
Enemies:
I could have added more enemies into the game as the player managed to shoot more ships (especially if the player upgraded their ship, if the option was there). For example, I could have added a variety of new ships into the mix, with either differing textures or 3D modes for the player to easily distinguish between them all. These ships could have had different abilities and, perks or attack styles. If I did ad this they could have dropped different items for the player to pick up, or drop the game item, but in a different quantity or dose. E.g. they could drop fuel or a health pack that could heal the player more.
If I had the time and I still chose to keep the enemies the same, I could have gradually increased the difficulty. E.g, when the player shoots down an enemy ship near a certain planet, the next ship that spawns near that planet could be slightly more powerful by being able to move faster, faster firing rate, more powerful laser blasts to damage the player more, have more health so they player has to either upgrade their ship for a more powerful laser cannon or shoot more frequently, or I could possess a different weapon that could follow the player. Another idea for a weapon could be something like a mine that explodes when the player is near it, and it could be cloaked.
Up-grade the player ship:
If I had the time I could have furthered the economy by introducing a new tangible resource called experience points or credits that the player could gain for mining planets or shooting down enemy ships. With this the player could upgrade their Mass resource cargo hold, so they could hold more planet Mass and visit more planets before having to go back to the trader.
With this the player could purchase special items to help them in game. E.g. they could have purchased a new ship that had more capabilities than the default one. They could purchase a health upgrade for their ship, improve the ships fuel efficiency, how much fuel the ship can hold, how much Mass cargo it can hold, improve laser damage power and accuracy, and firing rate, purchase a new laser to replace the old one or just purchase another laser for double barrelled action.
Given more time I could have included a shield or armour the player could purchase for their ship so it would not have taken as much enemy damage. Again though, I did not have enough time during the dissertation to do this. After the project has been handed I may come back to this project and introduce some the the features mentioned in this section.
I did cross my mind that the ship could slow down slightly if it was over loaded with cargo. I decided not to include this feature because I remember in an early iteration I tried this out and it was not liked by players.
Decaying resources:
If I had gone down the rout of using decaying resources as my obstacle (and possibly the enemy ship) I could have furthered the in game economy trading system. For example, one planet could have one resource, and another planet may need said resource, and exchange it for in game points or some kind of reward. With this a planet's resources could decay over time whilst the player is trying to get to said planet, and when other planet that needs those resources, will pay X amount of currency depending on the quantity the player has. Or whilst the player is transported said resources from A to B, the resources could decay, so either way the obstacle could be time, meaning the player can't wait around.
This would have been quite interesting to experiment with and would have made the resource managing mechanic more prominent. I could have had a variety of resources to trade and exchange.
Experience points and Ship upgrades:
The player could have gained experience points for shooting down enemy's or mining planets. These could have been spent on upgrading the player's ship, if upgrades were available. This was the player could hold more fuel, cargo, health, purchase weapons, buy a shield for the ship, increase ship movement speed, fuel efficiency and a tonne of other things. The player could use these to shoot down more enemy ships or anything. The player could have purchased another ship, weapons, weapon upgrades, improves their radar, bought mines, a portable turret, or enemy battles, a satellite to find new planets (if I used the fog of war mechanic). I could have added a warp drive ability, so the player could jump from one area in the level to another very quickly, but at the experience of using up more fuel.
Achievements:
If I had the time I could have included achievements, such as, 'Kill 50 ships' or mine 30 planets, or even "Mined 20 planets in 60 seconds". The player could have earned an achievement for gaining a certain high score or a new high score. I had not messed up how much time I spent on each part of the game, and I implemented this, I could have added a list of achievements for the play so they could improve their score and keep playing.
Unlock able:
Given more time I could have added unlock able items, like new weapons, ships, resources, planets, features, or abilities like warp drives or possibly new levels and game modes (actually, not game modes, but possibly a new level). This way it would keep the player interested, and I could experiment with the resource managing and shooting mechanics more. However if I had time too do this I would need at least another year and a team of at least 5 people, other wise it would be over scoped.
Orbiting planets:
More time it would have been interesting if the planet's in the system orbited around a star or something. The player could visit different solar systems for trading and find new resources to mine and obtain as well a new enemy's to encounter. If the planets were orbiting, they could have different modes, e.g. if a planet had completed an orbit it might give the player extra points or resources or if the player caught it before it had completed an orbit, they could gain extra points before the resources fully decaying. Even, the planets resources could be different during each orbit and trader or other ship NPCs could have been following the orbit and give the player a good deal.
Radar Planet Range:
If I had more time I would add a feature where when the player looks at a planet, they can see a ring around it. This could have multiple purposes, it could be bigger depending on how many Mass resources it contains, and it could show the player how near they need to be to the planet in order to mine it rather than the player keeps traveling towards it until the mining starts happening. I regret not having the time to implement this feature, it would have been useful to the player. If I had not spent so much time on the tutorials, I could have possibly implemented this feature.
Space Debris Damage Player and Possibly Contain Loot when Player shoots it:
Given the time I would like to have let the asteroids slightly damage the player just to add another layer to the internal economy. I am referring to both the moving and static space rocks. I would like to have done this because it would give the player another obstacle to avoid and make the game more interesting because as well as avoiding the enemy, they wold have to avoid both the static and moving asteroids other wise the player would receive more damage. However whilst refining the economy I did not have the time to implement this feature because it caused an error and I did not have the time to fix it, and I couldn't see what was causing it and because it wasn't a huge part of the game I decided cut it. Given more time I would have liked to implement this into the game. it would have added an extra layer of immersion to the game. The same for the Satellite 3D model.
Also I would have liked the asteroids to have been destroy able when the player's laser hit it. I could have done a lot with this like it's spawns more health, fuel, introduced another resource or an in game loot item, like shield or weapon, or it could have broken into spammer asteroids. Again, I would do this given more time.
Enemy Laser Speed:
Currently the speed of he enemy laser blast travels at is faster than the player's laser blast. Unfortunately this makes it a little bit more difficult for the player to avoid the enemy's laser shots, and it is a bit difficult for the player to see the enemy's laser. As a result this makes it more difficult for the player to avoid the incoming fire. Given more time I would like to make the enemy's laser blasts slower so it makes it easier for the player at the start of the game to avoid the enemy's fire. However I did give the player plenty of health and made the enemy easy to kill as part of balancing the game's economy. I still would liked to have slowed down the enemy's laser blast as a bit of polish for the game.
Key items I have learnt for my next project:
Devise how much time I spend on which parts of the project. As I have said earlier, during the first semester I spent too much time on the theory side of the game. I originally planned on the game being digital and built in the Unity3D engine and did this eventually. I decided to paper prototype every part of the game instead, where as I should have just paper prototyped the economy of the game. With this, parts of the paper prototype were not carried over into the digital version, such as orthogonal movement of the player ship, like a fixed grid. With this in mind, I accidentally slipped back into my old habit of drilling down into the mechanics too early rather than rapid prototyping so I can quickly see what mechanics work and which do not. However I noticed this a number of weeks before the Christmas break, so I had some time left to fix things before it was too late.
To add to this point, after the Christmas period I concentrated on creating tutorial level for the player because my instructions screens were badly written. As part of my drilling down habit I spent more time on the tutorial level than I should have, and put it towards refining the economy of the game because I was not being marked on the tutorial. Through out the iterative process when I play tested the game, I was refining the internal economy. As described before, I became too bogged down with the tutorial levels like in my group project. Again though, I did refine the economy according the play tester suggestions, like if a drain rate was too high (e.g. fuel) I personally think I spent a lot of time on the economy itself but I could have spent even more time on it for a slick playing experience and to add a variety of resources for the player to mange and to make the game a more interesting for the player.
With this in mind, when I go through my next project I will decide weather it will be a digital or non-digital game (most likely digital). I will then carefully devise which elements need to be paper prototyped and which need to be created digitally on a weekly basis. After this I will take time out each week to examine weather I have started drilling down too much or too early at the start of the project. If I do this, my next project will go a lot smoother and develop faster because with the digital prototype I can promptly change what elements I need to and make sure things like the player's actions and the heads up display or GUI are linked up correctly so the player can work out what is going on in game easily.
I will also take time out each week to make sure I am not spending too much time on the wrong areas of the game. E.g. spending too much time on the tutorials than on the internal economy and game play, because the over time spent of the tutorial should have been out towards furthering and refining the economy to make the game more interesting.
Another thing, I am glad I tested out ideas for this during my Summer break, so I had an idea of what I wanted to do for this project.
I have made a lot of mistakes this year, most of them I noticed before it was too late to fix and others (like bug) I notice them too late. The main thing is it has been an amazing learning experience, and I have learnt from all of the mistakes I have made this year and from the past three years in total. I'm sure in the future I will continue to make more mistakes because no one is perfect, even AAA studios make terrible games some times. However as long as I keep learning, try new ideas and mechanics, and don't repeat the old mistakes by learning from them, I will be a better games designer than I was before,
I feel my design skill have improved this year as well as my programming skills, and I have improved as a designer this year as a result of this dissertation project and what the problems I have encountered.
Monday 2 June 2014
Saturday 31 May 2014
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.
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.
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. 27 May 2014. <https://s3.amazonaws.com/colorslive/png/509299-PqhI_Cl78RheIJQS.png>.
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. 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.
Monday 26 May 2014
Re-doing the enemy tutorial, polishing and improving responsiveness
Idea:
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.
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>).
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.
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):
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.
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.
Friday 23 May 2014
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.
Sunday 18 May 2014
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.
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.
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.
Tuesday 13 May 2014
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:
Martin:
Dominic:
Good Points
He loves the bass like thruster sound
Bradley:
Good Points
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.
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.
Subscribe to:
Posts (Atom)