Last week I managed to test my game on a wide number of people and I received plenty of feed back. As always players like my game, however improvements were always suggested.
After several play tests players commented on a number of things (I noticed them as well).
Player Movement:
The first thing I had to adjust was the player movement. Player's often found the avatar skidded around the game map. Player's commented on how this did not feel right and this made the game too easy and they could just 'hoover' up all of the mass resources. Also they thought the game was a little too realistic (even though it is current set in space).
A number of players suggested, when they press the left and right keys, they ship turns and they only move when the forward key is pressed. This may it adds more to the managing mechanic and adds a slight level of difficulty for the player initially at the start of the game. It's not enough to penalise the player but it makes the controls feel nicer and is slightly more realistic than the player shifting though space.
Also this way the player can go around in circles if they need to in fewer button presses.
Mass Cargo Storage Capacity Limits:
I have been thinking about implementing this mechanic into the game for a while now to make my project more of a managing game. Before hand players were able to just move around the world freely and hoover up all of the mass resources together with in a single minute of game play. Players found this made the game too easy and because there were no limits on anything, so the player has to need to manage any variables.
Due to these comments from players I knew what I had been thinking since the last iteration was correct. There was no difficulty in the game since there was little management due to the lack on limitations on the player. Due to this, in the next iteration I decided I implement a cargo storage cap for the player entity.
Now there were two ways I could implement this new feature. One where if the player does not have enough storage space they are unable to collect the resources from a planet source entity.
The other option was if a player entered the trigger to collect the resources, they would only gain as many resources as their cargo could allow and the rest would be left there.
Using the Machinations visual scripting tool I tested both of these methods, the latter would require mode coding than the other and I wanted to test both out.
When testing out both mechanics using the Machinations tool, I personally preferred it and thought it added more to the managing mechanic because the player had to think more about their decisions whilst playing. After this I implemented it into my digital prototype.
Play testing the mechanic:
During play testing many players realised how they were un able to collect mass from planet sources unless they had enough cargo space left. Every one seemed to like the mechanic since no one complained about it since it was a managing game. However in future play tests if more people start complain about it I will change the mass resource transfer to the first option where the player gains what they collect. When I mentioned this to players one or two liked the idea, but again I will keep this the way it is for now.
Either way it works for now and from the play tests after introducing it players thought it felt more like a managing game since they had to manage how many resources they could collect. They also enjoyed the experience more since they couldn't just hoover up all of the mass resources in the game.
Adjusting the limit:
When I first implemented this mechanic I set the limit to 20 'Mass' resources since this was the same as the 'fuel' resources to keep things simple. I tested this my self a number of times both in the visual scripting tool and in the engine. I though this was not enough, to I raised the number to 25 then 30. I personally preferred the 30 mass storage limit, however I decided to test the digital prototype at University in the labs.
I initially tested the 20 mass cap, and many players though this was not enough, therefore I decided to raise the cap to 25 and players still though this was not enough. Therefore on the last few play tests with players I tried both 30 and 40 mass. They thought 40 was too much and made the game vastly too easy to win with not enough of a challenge. When I tested the game where the player could store 30 mass in their entity, the majority of players preferred this since it was enough of a challenge but not too easy to start with, so they could not just collect all the resources in one shot.
However in am aware in later developments of this game, this may need to be further adjusted depending on how the game develops, but at least I am getting the basics sorted out now.
Fuel capacity limits:
As soon as I realised I needed to introduce a mass storage limit I though I should include a maximum fuel capacity. However, I decided to introduce the mass capacity first to keep things simple and if things went wrong I could more easily.
I introduced a maximum fuel capacity limit into my game for the player character. This works by at the start of the game, the player starts with a full tank of fuel, however as the player moves around the game environment this fuel is drained, thus they have to carefully manage their fuel resources so they don't run out too quickly at the start and are stranded in space. When the player interacts with the space trader (the converter), if the player has enough mass, and storage space, the space trader will only convert as much mass into fuel as the player has room for it in their fuel tank.
When testing, players liked this feature because, they could only trade what they needed and they didn't waste any mass from what could not be used. This also added to the managing mechanic since it started to balance the game to an extent since the player has to manage how much fuel they have left in contrast of how much 'mass' they can gain and how many planets they can save.
This relates to a spinning plates mechanic since the player is having to juggle multiple resources all at once and as one item slows down and depletes the player gives it a nudge to keep the item going. As the game progresses the player will have more variables to juggle and keep going until so many variables have to by judged and nudged that the whole system collapses (Trefry, G. 2010, pp 139 - 154).
I have tested the max fuel capacity on several play tests, from 10, 20, and 30 fuel. The majority of players prefer having 20 fuel, draining at one fuel a second whilst traveling since this is enough to get around the game environment to make at least two trips, therefore not making the game too difficult. Players thought having the cap at 10 made the game too difficult having the cap at 30 made the game to easy and made it feel less like a managing game.
More player movement improvements:
Player dragWhilst adjusting the player movement properties, many players thought the ship did not stop fast enough in the game environment, this is tricky, because I had to balance how realistic the game was with making sure the player is not frustrated with imprecise controls. This was partly down to two reasons that I did not discover until several play tests later.
I increased the amount the player turned when they pressed the left and right keys, making the controls more responsive, I also increased the 'drag' and 'angular drag' properties on the player's rigid body settings in Unity. After increasing these values the players said this was an improvement but more had to be done, like the player turning still felt imprecise. The players preferred how the avatar movement stopping after a button press was more immediate, but they still felt the player drifted a bit after turning and moving.
Camera Following the player
This however was a fault on my part because I accidentally increased the turning buffer in the 'camera_follow' script that comes with Unity. This meant when the player turns, the camera follows the player moving slowly. Basically it was partly down to player perception with the game camera following the ship avatar. After I increased this drastically, but allowing a tiny buffer (at a value of 1.5(the higher the number, the faster the camera turns)). After adjusting this setting players felt they were more in control of the player avatar and the controls were more responsive and the game's flow felt a lot nicer.
Another part about movement
After I had fixed the settings above, a few players noticed something I had noticed during the last play test. Due to the code in the player movement, is a player just tapped the forward key, they would be able to move further using less fuel then if they had just held down the forward button. Several players suggested I fix this, and I got straight to it. Firstly I increased the drag property on the player's rigidbody (as mentioned in the previous paragraphs) in increments until player's were happy with it, it settled at 1.8, it was just enough to stop the player but just enough for a tiny bit of drifting.
After this there were two options:
If the player just taps the forward key and they are not already moving, introduce and ignition cost, so if they tap frequently, it will cost more than just press and holding the forward button (hopefully with out penalising the player) but if they do it infrequently it will not cost much fuel wise. Through this method I would have to experiment with varying ignition costs to make sure it wasn't too high or low.
The other option, involved more code work. If I used 'addRelativeForce', the cost for the fuel could stay the same (I slightly adjusted to fit this new mechanic), but the longer the player holds the button down the more their speed builds up to a point.
The last was just raising the drain cost for moving altogether, but I decided not to do this because it just penalises the player and there is a better way around this problem than just penalising the player.
I decided to try the second method and if people did not like it I would go for the first option. I implemented the second method through code (this took a while since I had not used this method before). After I implemented it adjusted the value so the minimum movement speed was not too slow and the top speed was not too high, this took a lot of experimentation but through play testing I settled on a speed to 200, this is because add relative force requires a higher value since it down to the relative press of the button and the size and mass of the rigid body which required more experimentation. I applied the same design practice to the player turning value (a value of 20).
During play testing sessions many players liked this new feature since it applied more strategy to the game and more control over the player avatar. It also made the controls feel more precise. This adds to the risk versus reward mechanic since the player can move only slightly at a lower cost but if they want to move faster and further, there is a higher cost and their fuel will deplete more.
Looking at it now, the new movement feature is superior and it removes exploits whilst adding strategy to the game since the payer will again have to manage their fuel with their movements around the environment. How I was doing the player movement was ok at the start of the project, but this new method should have been implemented into the game sooner and I heave learnt from this since this would have stopped players from exploiting the game.
Repositioning the players camera and resizing the game objects:
Whilst play testing I noticed how the camera followed the player slowly, this had happened during the last few iterations. I and many other players noticed how the objects on screen were quite tiny and the GUI text over the planet sources was small and quite difficult to read. Due to this I tried scaling up all of the planets in the game and slightly up scaling the player ship avatar. Along with this I had to reposition where the planets were in game and adjust their colliders accordingly so they didn't trigger themselves off. After I tested the game out a few times, I noticed something game breaking. The player movement had to be readjusted. I multiplied the player movement and turning speeds as much as I had upscaled the objects in the scene. After some tweaking and a number of play tests I had adjusted the values correctly and the players were happy with it. Again I wish I had spotted this sooner since many players (including myself) found it hard to see what was actually going on in the game. I also repositioned some of the planets to make the scene more interesting.
Another item I tested out was how far away the camera was from the player. Because a lot of people initially were confused when the camera was at a birds eye view. I moved the camera lower down and behind the player do they could actually see what was going on, also players felt more immersed in the game because they were closer to the action and they felt they were more in the game. (Image below)
This is how the camera originally was positioned.
This is the new positioning, it is closer to the player and one can actually see where the player is on screen (the white cube).
After this I tested it out on a number of different players, and they all felt this was a nice improvement. Also this uncluttered the screen since players could only see a few planets at a time and the values and bars on top of the planets were not confusing players since they were out of the way.
Turning whist stationary:
After making the changes above, I play tested the game on a few people, and lots of them said something that was mentioned collectively over a few past iterations. A few players found when the player ship avatar was not moving, they felt the ship did not turn fast enough. They thought this should be part of the games mechanics like a risk versus reward mechanic. If the player is moving they turn normally but they may not hit the planet they are trying to get to. Where as if they turn faster when stationary they are quicker and more accurate but they are not moving, so they risk loosing mass resources.
When I implemented this through code I created an if statement for when the player is not moving but pressing the turning button. This will use a new variable for stationary player turning, I set this to double the speed of normal turning as a starting point for the risk verses reward mechanic.
I have tested this speed out of a few players and they all liked the turning speed, however would like to test this out on more players to get a better idea.
Make the GUI more visual:
During the same play testing session a large number of players noticed how they found it was not that much like a managing game, because they were not concentrating on the GUI text in the corner. This was due to the GUI not being very user friendly and clean enough to understand. Due to this the players will have to think more and this takes time out from collecting mass resources if they have to look how text fields for space left and how mass resources they have, thus they did not concentrate on it.
Again this is something I should have addressed a while ago and I am currently fixing it with some simple art assets. Both bars have a background behind them to show the maximum capacity of both variables, and when the player upgrades one of these maximum values (when I implement the feature if I have the time), the size of the bar will stay the same, just the amount it takes up with in the space with change. This is brilliant from a design perspective since Mass Effect 2 uses this for health stats and the like because it requires the player to think less since they don't have to compare different values, like maximum health and current health in their combat system (Electronic Arts, (2011).
Unknown, Unkown. "Wikia." Mass Effect Wiki. Wikia, n.d. Web. 22 Dec. 2013. <http://masseffect.wikia.com/wiki/Combat>.
I have created two simple bars; one for the player's fuel and how much mass cargo they are storing. Because this is more graphical, the player will have to think less and just look at how full each bar is on screen.
Unfortunately I have not tested this on player's yet, however testing this myself, I have noticed a drastic improvement. It is a lot easier to work out how many resources you have and when to re-fuel one's ship due to the size of the coloured bars. Also so the player can tell the difference I have made the fuel and mass bars different colours (blue, and red) these were the colours of the counters from paper prototyping. Also the colours to the background bard are different from the foreground bars so the player can easily tell the difference. I have made them look like hazard tape since this is set in space and the player could be attacked by an external threat (I may include this later).
http://josepheasterdissertationblog.blogspot.co.uk/2013/11/bibliography-references.html
