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.
