More Refining

Note: Currently one of my group team members work ethic has disintegrated. I mean some of his tasks have not been completed from the Easter Sprint (we made sure we did not over scope the sprint). The tasks he did not complete have now become blockers. Considering that he frequently leaves his tasks until the last minute, my other team mate and I will have to take on his uncompleted tasks as to not compromise the project. Therefore, thanks to said team mate, I will have to take on his uncompleted tasks and this will have a knock on effect for my dissertation (well I hope I will not have to take out too much time from it).

Wow! I can feel the heat.

Idea:

At the moment I am just refining everything to make sure it's as polished off as can be. From the last iteration it was suggested by many play testers that I should increase the size of each planet by about three or four times it's current size. As well as this I should vary the sizes of each planet, and give each planet a different texture or colour tint.

Implementation:

Planet Sizes increased:

After receiving feedback I decided to increase the size of each planet. Firstly I doubled the size of each planet and tested it, and it appeared the planets were still not large enough. After this I doubled their current size again, I got a few play testers to look at it and they thought the planets were the correct size after that.

I should have done this a few months ago, several players had been asking for this. After a while I did correct the scaling, but the planets were still tiny (about 4 times the size of the player ship). I wish I had increased the size of the planets to a greater extent earlier, because I could have started on the level design a lot earlier.

Varying planet sizes and colour tinting the material texture:

After implementing this change, it was suggested by a number of players to vary the size of each planet and to give some of them a different texture or change the colour tint of the material applied to them, so they were not all identical.

Old Planet

New Planets

After hearing this I copied the planet material texture three times, and I gave each one a different colour tint and applied it to each planet. One being, purple, green and blue.

When testing this on a few players, they seemed to like this alteration and said it should help to give the scene some variety and if the player is lost, they will know which area they are in.

Along with this I have had to make some technical adjustments to the scripts in order to fit in with the current scaling, such as trigger colliders, particle effects and glowing light effects and how each planet shrinks when being mined. When the planet has finished replenishing, it regrows to it's original size.

Designing the Level:

Old Game level:

When I had first produced my digital prototype (back in late December) I had some basic level design, but it was bad. The entire level was symmetrical and all of the planets appeared to be the same size colour and have the same texture. This confused many players. This is why I when I finished my tutorial level to completely start over with a new scene in Unity and start from scratch.

Old game level (above). Many players found they became lost quite easily because everything was similar and symmetrical.

Current game level:

On Tuesday I decided to do some level designs for the main game level. Initially I re-read the Gamasautra article on this topic by Mike Stout (Stout, M. 14 May 2014). After I read it I went into the design of the level, with this I quickly discovered something. Because my game is set in space and there are no corridors or tunnels, I do not have to worry about the flow of the level.

With this each planet currently contains the same amount of Mass resources, but planets further away have enemy ships to shoot. I would like to vary the quantity of resources on each planet, and the further out ones have more resources, but I will perfect this in the next iteration.

Player Reaction:

Today I had a few play testers try my game. Many of them liked how the planets were larger and how each enemy was patrolling around each planet and how each planet was a different colour and size. This helped to distinguish between the varying body's.

A few players asked for a radar in the HUD, because they could not see the planets outside of the camera's view. Provided I have the time I will implement this feature.

With the player attack system for destroying enemies, many players liked the laser shooting, however they did not know if the laser was actually hitting the enemy and if so, they did not know if the enemy was taking damage. Also they did not know if the player was hitting them, they wanted more visual and audio feedback.

Another thing, the player did not know how to attack the enemy initially. I need to implement a mini tutorial for this so it's explained to the player. For this I will either construct a quick level demonstrating the mechanic or quickly introduce it into the current level.

Last thing, many players could not make a return trip to the trader, players asked for either, a speed boost for no extra cost, enemy either drops health or fuel, or reorganising the level or adding another trader.

The Game Grid:

Since I introduced the grid at the bottom of the scene many players have commented on how much easier it is to move around the level and see where they are relative to other game objects  and how much they are moving in the scene. I am glad I have introduced this into my project.

Whilst I remember, I did not create the grid texture, Rebecca Brannum did (Brannum, R. 29 Apr. 2014.). She created it and gave the file to me in person, so credit goes to her for this. Also because the grid has an alpha channel and was made with a glowing effect (it does not actually glow, it just looks as if it is glowing). Therefore, when I first introduced it into the game, the transparency did not work and many people connected on how out of place and non-3D it appeared. However after experimenting.

I used a transparent/Diffuse shader material and dramatically decreased the alpha cutoff. After implementing this change, many players commented on the improvement and said how much they liked it.

For next iteration:

For the next iteration I will plan some level design, and increase the size of each planet and vary the different sizes to add to the realism a bit. After this I will fix any bugs caused by this adjustment, such as colliders, lights and so fourth.

After this I will go forward with the level design. Many players have pointed out how they became lost because the planet orientation was symmetrical and each planet is identical. I will try this by initially making each planet bigger by the power of two, each time, then I will try with tinting different textures.

I would also like to try and add some non interactive object into the game, since many players have connected on the game being a bit empty. I may introduce some asteroids into the game, but I will get the first two items sorted out first.

Implementing Enemy art assets into the game

Right, this should be a brief blog post.

I have implemented the enemy into the game, but the enemy needs more refining. Initially I only had a grey box for place holder art.

After spending some time on the Unity Asset Store I found a free model with a reasonable poly count. The ship it self has a light coloured texture and a darker texture. I went with the lighter texture because many players commented it would be harder to see since my game is quite dark any way.

I down loaded the free model form the Unity Asset Store (Duane's, M. Web. 22 Apr. 2014. www.assetstore.unity3d.com/#/content/1807). The poly count for this model is 1256 polygons and comes with a 1K, TIFF, specular and normal maps in .jpg format. This has so far not hindered the performance of the game.

After implementing the ship into the game, it received many comments from different players during play testing sessions. I also added a particle system to the back of the ship to add to the immersion and to add a little to the realism. With the colouring of the exhaust flames I decided to colour them differently to the player ship. I did this to help the player differentiate between the different ships depending on what viewing angle the player is at. E.g. If the player is behind the ship, they will see the different colour flames. Also because the ship is larger than the player ship, the colour of the flame should be more intense in order to burn more fuel, e.g. closer to a white hot flame, than red hot.

The image below is the ship in the scene view.

The image below if from the player's in game view, where every thing is in action. The enemy ship is patrolling the glowing planet to the left.

Again when I tested this, the ship and the particle system both received positive reviews, also many people liked it because it has a light texture that contrasts with the dark background of the game. Therefore it's easier for players to sport whilst in the game. With this in mind I will keep this asset in the game.

For next iteration:

For the next iteration I will plan some level design, and increase the size of each planet and vary the different sizes to add to the realism a bit. After this I will fix any bugs caused by this adjustment, such as colliders, lights and so fourth.

After this I will go forward with the level design. Many players have pointed out how they became lost because the planet orientation was symmetrical and each planet is identical. I will try thins by initially makes each planet bigger by the power of two, each time, then I will try with tinting different textures.

I would also like to try and add some non interactive object into the game, since many players have connected on the game being a bit empty. I may introduce some asteroids into the game, but I will get the first two items sorted out first.

Re-programming the player ship

This will be quite a short blog post, due to the nature of it. I have had several problems in the part with my player code scripts and I have finally worked out what went wrong with it and have fixed it.

I was meant to start doing work on the planet sizes and the level design, but this has taken priority today since I have noticed it and want to fix it before it becomes a major problem. I after posting this blog I will continue with the rest of the game.

The problem:

When I would make an object look at the player, e.g. the mining particle system that fires towards the player, it would either not fire or it would fire in a completely different direction to the player. Other items would so this as well on occasion.

The explanation:

The player ship is composed of several different game objects, each one with a different purpose. There is an empty "gameObject" that holds everything, the player mesh, a green particle system, and several particle systems and point lights on the exhausts to add the immersion to make it a little more believable.

Originally I added the movement script to the mesh and the rigid body to it as well. When the game was running, only the mesh would move inside of the empty parent game object. With this in mind, it explained why some of the transforms were strange and because the parent was in the position it started at the beginning of the scene and the look at for some particle systems would either not work, or fire towards the stationary parent game object.

This is a major design floor I have managed to spot before it's too late. When I last redesigned and re-created the player Prefab, it made sense to have a game object to hold everything because for example, if I needed to change the position because some of the other game object that were children of the mesh would operate correctly. Thus I made everything equal in the hierarchy. However I did not think to mode the move the player scrip to the parent game object.

How I have fixed the error:

Basically I have removed the script from the player ship mesh, and any mouse turning scripts from the mesh and have added them to the parent game object and added the current values in the inspector and the same for the audio sources. In the coming weeks this will make my life a lot easier. I wish I had discovered this sooner. When I did this today I had to reassign some variables in the inspector for the trader ship the activate certain sounds, but apart for that, everything is fine. This should hopefully avoid any future problems involving "Transforms".

Improving the enemy Path Finding rout

Note: Recently I have been quite bust with my application to my masters degree. The University has kept asking for my transcripts and they did not get them apparently. Their e-mail system may not allow attachments or something. However after a long process, they finally have them, also I have been offered a place on the course, however I have contacted the course leader because I need to defer my place until next year. Crafting the e-mail took a while and now I am awaiting a reply. This is why my works has been more varies than I wish for it to be and this blog is delayed.

Changes from last iteration:

Enemy patrol around each planet:

With this level I decided to have only four planets (that may change) and a re-fuelling ship in the middle. Around each planet is one enemy ship, following it's own set of nodes, I have implemented path finding code. Each enemy has path finding code attached to it and each planet has 6 nodes around it like a ring. This means the enemy ship is traveling in rings around each planet. So when the enemy ship finished it's patrol and runs out of nodes in selected array, I have made it reset the array so it goes around again. However I tried to instantiate another enemy when the player destroys the old one. However, the bulletin array system will not allow me to add objects though code to the array, therefore only one ship goes around each planet. I also did this because I don't want to over complicate the game too quickly. Therefore if player's for more difficulty or more enemies, I will increase the number or their health values.

the image below shows the patrol path the enemy object takes. The circle is the planet, the six black dots are the array of nodes, and the red ship follows each node in order. When it completed the circuit, it resets, and starts following the start node again and the others back in order. The arrows show the direction the ship moves in and visits each node. By the way, the individual nodes do NOT move, but the enemy patrol ship (red drawing) does move.

In game spacial grid:

Another thing, players were unsure weather they could move in 2D or 3D. With this in mind I implemented a translucent grid at the bottom to give the player a better idea of where they were in the game world and how far they are away from other objects in the game.

Just to make things clear, the player can more in any direction they want, the movement is not grid based, it's purely so they player can roughly gauge how far they are away from each game object.

Replacing the bullet with the laser:

I decide to replace the bullet with the laser. This is because in most space games and sci-fi films, lasers are used and it fits the theme more. Another addition because I can activate and de-active the laser on comment I do not need to worry about destroying the laser if it misses the enemy. When I implemented the bullet, it seemed out of place but also if it missed the enemy, it would keep moving for ever and need to destroy itself. With this in mind there are few objects on screen, therefore fewer items for the player to keep track of.

Enemy interaction:

When testing the game myself I initially changed the code so the enemy is following the path nodes by default. The enemy has a large 'isTrigger' collider and when the player enters it's the enemy follows the player. This is to improve the threat and obstacle of the game. When I originally implemented the enemy AI (or technically VI) I tried doing this through ray casting. This worked and it was fine, but I discovered when the enemy is near the player, it eventually starts pushing the player backwards.

I thought this may frustrate the player because then they can only shoot the enemy and this could force the player into the sight of another enemy. With this in mind I modified the script, so when the ship is very close to the player, it stops moving towards them, when when it's out of the range, it starts moving again.

When I implemented this, the ray casting did not fully work. When the enemy was close to the player it kept moving. I worked out I had programmed the ray cast in correctly. However because I had already spent a low of time on this method using different variations of ray casting I decided to try a different approach.

Collider Method:

I created two isTrigger" colliders, and when the player enters the outer collider, the enemy ship follows the player and moves towards them. When the player moved into the inner collider, the ship stops moving. When the player exits the inner collider though, the ship starts moving towards the player again. I thought from a design point of view, this would help give the player some slight breathing space and the enemy will not keep pushing the player backwards.

Whilst testing player's like this feature since it adds enough of a threat to be entertaining but also enough breathing space to shoot the ships.

Player controls:

Since I changed the player controls a few months ago from WASD (keyboard) to mouse clicks and movement, this has improve many players experience with the game. I have had to tweak the parameters of the controls, but it non the less works more smoothly with the game. A number of players wanted this feature and I wish I had included it sooner. It just makes the controls much easier to work with and the ship easier to control. Also if wanted to port this to the Android App store (a few months after handing in the dissertation), the SDK (soft-ware development kit) would automatically convert the commands in the scripts to phone and tablet controls (like taps and swipes), so there's plenty of scope.

Another, thing is it makes it easier for the player, and if I progressed the economy, by added a shop, where the player could purchase upgrades, I could just use mouse click for everything. With one control system, it would make the player's experience a lot nicer and smoother in general.

Player Reactions:

Player test one:

• After many play tests I discovered a number of things wrong with my level. One player did not like the control scheme for the mouse (they wanted the scroll wheel as the moving button, and the left click for firing).
• The second but that was noticed was how the player could easily click out side of the screen and wonder why the game was not responding. I.e. the player would click out side of the screen accidentally making the game loose focus. Then the player would wonder why it wasn't responding. I need to fix this so, I need to tell the player to click on the ship at the begging of each level. This is annoying because the player will not know why the game is not responding other wise.
• The sounds were horrible (apart from the ship thruster sounds) and they did not stop when the player had completed the action it was associated with. I thought I had fixed this bug, but I am glad this hole was pointed out.
• On the good side, the player liked the patrolling AI around each planet but they thought they needed a little more refinement though.
• Another point, the laser needs reprogramming, it works more like a bullet than laser. When the player clicks down, the damage is only caused on the TriggerEnter, rather than trigger stay, so the damage is implemented only once.
• Enemy death explosion takes too long.

Player test two:

• The audio was buggy, when an action is occurring the audio for it plays, but when the action for mining planets and the fuelling is finished the audio does not stop. Also it's not fast enough and the audio file sounds horrible.
• The laser does not work like a laser (like the comment above). The laser goes though objects. It should stop when it hits an object.
• The explosion lasts for too long, it should only last for a few seconds.
• Inconsistency between levels. The player is a lot bigger in the actual game level and faster compared to the tutorial level.

Next iteration:

• In the next version of the game I will fix the laser fire system, so when the payer is holding down the fire button, the damage will happen on "OnTriggerStay".

• I would also like to implement the art for the enemy ships, so the player has something more interesting to look at in the game world and help immerse the player into the game. Because if the player just sees a grey box, the will not look threatening unlike a large pointy, intimidating ship coming towards the player.

• One of the next things I would like to do it increate the size of each planet, because many players have asked why the planets are the same size as the ship. With this in mind I would also like to re-design the level itself but it's pointless considering I should readjust the size of the planets first.

Slight (Asethetic) Improvements to the User Interface

Note: This will be a brief Blog. Partially because this is more of a superficial improvement that I wish to test out. Also I have been quite busy recently because I have had news from my Masters Degree application. I have been offered a place on the course, but due to complications I want to defer it. I have contacted the University and course leader about this and process has taken up a surprising amount of time. However I'm sure they have a good reason since they are dealing with hundreds of applicants and many other things they may be experiencing.

Idea:

The last time I texted out my game a portion of people enquired about the font of the UI and the main menu. Player's wondered when I would finally implement the final font, and I thought I should do that soon before I forget.

This is not at the top of my To-do list but it may immerse players into the game world and set the scene
for the game itself. Again I would like to experiment with adding an extra layer of immersion by simply a different science fiction font into the mix. It might help because the font looks like a computer and the menu and intro screens vaguely resemble holography or pains of glass.

Implementation:

Many players liked the font and thought it suited the theme well since it looked like a sci-fi/ futuristic font for a space company/ federation. I personally think I will keep the font for now, and if I have the time to find another one and find a more suiting one I will replace the current font. The font I am using is from a font pack called "Square Pack", and the font itself is called "quadrangle.ttf"(Larabie, R. Web. 12 Aug. 2012. <www.assetstore.unity3d.com/#/content/4235>.). The main body of text in the image below displays what the font looks like (it's below the main logo).

It does not quite match up with the logo above, however I plan on amending this quite soon (the font in the logo), but it's not at the top of my to-do list.

Items for the next iteration:

Add actually enemy ship 3D art assets.
Find missing sound for game interactions and backing sounds for the scene to immerse the player.
Re-design the level (meaning, properly design the level intelligently).
Add a mini tutorial into the game level, to quickly introduce enemies and how to fire the laser.
When the enemy is taking damage, add a sound effect and visual effect, do the player knows if they are actually damaging the enemy ship. Also do this for the player if time is permitting.

Implementing more sounds into the game

Ideas:

After a number of play tests, I implemented some new sounds into the game. I replaced the old planet mining sound, because many players said it sounded horrible. When I changed the sound to a new one a while ago (I should have already put the reference in the bibliography) player's thought it was an improvement. However some of the new sounds like when the player is refuelling, many players' requested for the audio files to be changed.

Implementation:

Menu button click sound:

With the menu button click sounds, I found a nice sound for this, I wanted something light sounding because the menu looks a little like a pain of glass or hologram but I wanted something that had a little weight and felt responsive. With this in mind I have found one online, which I will test with players to see if they like it or not.

Ship moving sound:

I have implemented a thruster sound for this. I originally found two good sounds however I went to the first sounds because player's liked how the first one was more subtle and not in one's face. After properly implementing it into the game, player's liked it but a few asked for it to be only slightly louder because they found it difficult to hear.

Ship Fire laser sound:

I have not found a sound for this just yet, however it's one of my top priorities currently. Many player's have stated they would like a sound effect for this action, however I have not managed to find one that's suitable as of yet. I hay have to purchase one online via the Unity Asset store.

Planet mining drill sound:

Since I last implemented the mining sound, I decided to find another audio file. Many player's connected on the sound to be horrible and manipulating the sound did not improve anything. The audio file I found was made by mckinneysound's uploaded to freeSFX.co.uk (mckinneysound's. Web. 27 Apr. 2014. www.freesfx.co.uk/sound). Many player seemed to be ok with this sound. With the general reaction to this, because player's though the sound was ok but not completely horrible I will keep the sound effect in place unless I am able to find a suitable replacement in time.

Ship receive damage sound:

I have not found a sound for this but again it's on the top of my priorities list. I would like something that sounds like a heavy object has hit a heavy metal object, or if a car has a metal dent or if something was hit by a bullet.

Player ship dead sound:

For this I have used a soft-ware tool called "cfxr", it is a reworked Max OS X version of SFXR by Bengtsson, J (Bengtsson, J. http://thirdcog.eu/apps/cfxr). I used this tool because I found many of the explosion sounds online did not fit the theme and most of them sounded tinny. Now I know one can't scream in space due to the lack of air but I thought it would help with the game feel and be responsive for the player. The cfxr tool is an application that will randomly generate a sound from a range of topics, such as e.g. explosions, random, PickUp, Shoot, PowerUp, Hit, Jump and bump. When the user clicks these buttons it will randomly generate a sound from one of these fields.

Although this tool is designed for creating simple 8-bit sounds, quickly, I have found it quite useful in the past. The CFXR application is a Mac Port of Dr. Petters SFXR program. It was ported by Joachim Bengtsson.

Enemy ship dead sound:

With the enemy ship dead sound, because  liked the explosion sound I created using the CFXR application I decided to use it again, when the enemy ship explodes (Bengtsson, J. http://thirdcog.eu/apps/cfxr). After I implemented this and had it play tested, many users seemed to like it. With this in mind, I will keep the sounds effect since it goes well with the explosion particle effect unless I manage to find a superior audio file.

Many players did not notice how I used the same explosion sound on the enemy death as the player death. Player's seemed to like it because the ship would blow up when shot at, and it adds to the immersion of the game with the visuals and is found to be satisfying.

Result and next iteration:

During the next iteration, when I have fixed various errors from my previous iteration, and refined variouse part of new design features (i.g. make it more visual when the enemy is taking damage (and the player), I will find some more sounds to add, such as taking damage, laser fire, and refuelling sounds. As well as this I would like to add a sound for when the player's score raises, to make the score system when the player had killed an enemy ship, more responsive and satisfying, so the player get audio as well as visual feedback. If the game is more responsive both visually and audio wise, the player can think less and concentrate more on avoiding and destroying ships and other aspects, and managing their resource gained in the game.

Implementing the game's goal and player's reactions

Note: Apologies I have not posted for a while I have been busy catching up on group work due to one of my group team members not completing on of his tasks on time that one of my group tasks relied on (he did have a good reason though).

Another note: A earlier in the year I applied for a Masters Degree in Hong Kong with BAFTA scholarship funding. Recently I received an offer for a place on the course. With in mind, and my group project stuff going down the pan I have had a mountain of things to manage lately. This is one of the reasons my blog posts have not been as frequent as I have wanted them to be, and why my game has not been updated on Kongregate.com as frequently as I want it to be.

Ideas:

At the moment my game contains a grind mechanic that has been well developed. Now I need to implement a goal for the player. My idea for this is, to make the player see how high a score they can get ad try to beat it. Like Tetris, it is essentially who looses the best.

The main idea being, the player mines a planet for "Mass", and the player goes to the trader and exchanges it for money or fuel, (I will decide which one after some play tests). I will add an enemy ship for the player to shoot, include a shooting mechanic and add a new resource into the economy called "ships" or "score". This will be so the player can keep track of their score. Also I could progress this by when an enemy ship has been blown up it could leave some cargo for the player to collect. For example they enemy could hold a valuable resource, like fuel or currency in it's cargo hold or more "Mass" resources for trading. With this the enemy ships could attack the player, thus the player needs to repair the ship, and upgrade cargo holding and so fourth.

I could also add achievements into the game (but that's not for a while yet, if at all depending on time constraints).

Implementation:

With the enemies I implemented one into the game. One enemies would randomly appear and travel to the middle of the game world and then attach the player if they were in range using a path finding. So the enemy would follow an array of nodes then follow the player. When the enemy finds the player it starts firing a bullet towards the player. When the bullet contacts the player, the player's health depletes. When the player's health reaches zero. They hit the game over screen. The player has a maximum health value of 10 (integer).

The player can fire a bullet back at the enemy ship by click the scroll wheel on the mouse (or middle click). When the bullet is instantiated, it fires in the direction the direction the player is facing. When the bullet hits the enemy collider, it decreases the enemies' health value by 1 (the enemy has a total of 3 health). When the enemies health reaches zero, the enemy dies and response where it started and the player's score increases by an integer of 1. This goes to the player's GUI (there is 3D text near the HUD).

However with the enemy AI I was not quite sure how to implement it into the level. That's why it had a strange entry into the level.

Player reactions:

Players liked the AI and the new mechanic, but many commented on how the enemy ship should patrol around each planet rather than in the middle of the star system.

Players also suggested implementing a laser rather than having shooting a bullet due to the theme of the game.

The enemy should follow the player when they are with in a certain range of the player and stop moving when too close to them.

Amendments for next iteration:

For the enemies I will experiment with them patrolling a planet. I.e. One enemy ship, flies around a single planet in a loop. This should add some challenge to the game since the player has to avoid each enemy whilst trying to mine a planet.

I will also implement the laser system since a many players asked for this feature. It also fits the theme more and it's more responsive and faster since my target audience it teenage males and those in their early twenties. With this in mine the laser is a lot faster and more rewarding.

Also with following the player, I will try implementing this feature using ray casting since this feature is more efficient for finding out weather the player is in range of the enemy. Also if the enemy is too close to the player, they will hit the player and eventually push them infinitely
.

Slightly polishing off the first tutorial level

What I plan on doing:

With the first tutorial level, I decided to implement a new feature (just on an aesthetics point, not mechanically). As mentioned in the previous blog post, many players suggested I decrease the size of a planet when it's being mined because it adds some slight realism (not that I intend of my game being hyper realistic).

Implementation:

When I implemented this into the game, I had to find out how to readjust the size of an object on a local basis thought code. I found out I had to use transform.localScale -= Vector3() to do this since this is part of unity's transform vector properties. I used a boolean to activate the shrinking planet feature, so when the player is mining a planet, it set's the miningSize boolean property to true, and the localScale decreases by value "x" and when the planet has been drained of it's resources, the function stops.

Running into a few walls:

When I tested out this feature, it initially worked well, however I noticed, that a trigger for part of the tutorial would some times not run and I wondered why this was occurring. I spent some time looking through my code wonder what was going on, incase I had miss typed something. After a short break I discovered, the OnTriggerStay function for the planet was nut running, and I looked at the scene as I was playing the game. Because I had the model of the planet as the parent (the pretty visual part) and the trigger that does all of the interaction and transactions between the planet and the player was attached to an isTrigger object was the child of the planet, the trigger was shrinking relative to the parent, thus causing the bug.

To fix this I created an empty game object and called it "planetHolder" and made the collider and the planet model children of that game object side, and making them both equal in the hierarchy. This fixed everything in the tutorial. Just after this, when I created the new game level (new actual in game level) I recreated each planet in the scene in this way to avoid future headache like this.

Play Testing:

During play testing, the first level and the new "Level 1", many players liked how the planet's glow changed colour and the size of the planet changes when it's being mined. Player's said it helped them understand what was going on in the game because each transactions was happening visually. Also they said the planet shrinking when being mined was a nice touch since it fitted in with the theme and so when they tried to mine another planet they could easily se which planet to mine by it's aura and size very quickly.

For the next iteration of the game I will try implementing a goal into the game. Because I have improved the design bringing out the current mechanic, I think I can now go progress with the game's creation itself. I will try going slightly down the shooter rout, meaning the player will mine mass, to upgrade their ship, so they can shoot more ships to improve their score. When I last tested this on a few people, some said they wanted more of a goal and they would like to upgrade the ship they control. I will give this a try and see how people will react to it but I will not drill down so I can get a general idea of what direction should take the game in.