Digitising my prototype

As of my las play test I came to the conclusion I need to create a digital prototype ASAP. I already created a simple prototype for what I thought my dissertation was going to be in Unity, however I may as well have started from scratch since I wrote new scripts for everything.

However due to a few technical complications I have partially created the prototype, due to other assignments building up (I'm feeling the pressure). I have the basic mechanics working, such as the sources, drains and converters, and when the player interested with the game world things worked fine. My trouble was with representing the data visually.

I was initially going to use way pints and path finding to move the player, but this was trouble some and several players found this tiresome. Therefore, recoded the player avatar to move via the arrow keys. The next problem (I am still working on this but getting very close to finishing it) was displaying the quantity os 'mass' resources on each source planet. Initially I used the GUIText function, and I have had to relearn how to use this feature as (it isn't the most visually appealing option, but it will do the job for now).

I came into another snag with the method, it would only show the quantity in the player view port, after some time scouting the web, I discovered a royalty free script, that placed the text over the object itself.
Although again, this came with another snag, it updated the quantity on each source, but when the player took the mass from the newer sources (that hold 14 mass, but are further away for a risk versus reward mechanic), I had to use a separate collider on an object since the script on the GUIText would move around and when I did this the mass would not transfer due to the script not being on the correct child. Also when I has the source script on the collider and when it was inactive it would still run for some reason so the player would receive the non-updated quantity of mass resources.

So after struggling for hours gradually working out what was going on (I haven't used this method for a while and I'm a little rusty but I'm getting there)  the inactive script was still running in unison with the other active script for some reason, maybe the variables entered on the inactive scripts were still being using used by the active components that they were attached to (it was being freaky). Either way I decided to represent the data more easily to the player (the text displayed was a little challenging to read due to the font and size) and speed up the creation process since I had spent a lot of time working out why the other method was not working. I am currently working on representing the quantity of resources via a bar above each planet source using a plain. This in turn should make it easier for the player to see how full of resources a source planet is and how quickly it is draining visually since the bars will be shrinking at different rates thus the player will use less thinking power and concentrate more on other aspects of the game itself.

At the moment I am still working on this part of the game since I have done this part of a game like this before. I have not used game objects (like plains) to represent data visually before in this manner (I have done it via GUIText using .png) and I have not needed to manipulate Vector3 localScale variables though code before. I am having to adjust the 'x' axis scale at the moment and having to convert the quantity as a percentage so the bar doesn't tape up half of the screen due to the quantity the entity is storing. Whilst doing this it is a challenge but with my books on javascript I am getting there.

After this I will have to modify the buyer converter. I have included this in the game, but it is basic. when the player enters the collider for the entity, their resources are automatically converted into fuel, but with all of these entities, the player will have to be with in the collider for a short period t add some difficulty. The reason for this being, the player may shoot past a planet too quickly and have to go back. This also stops the player whizzing around the game world every where.

With the control scheme if players do not like it I will attempt to make it so the player click an area and the ship follows suit. Also with the planets, the further out the planet sources are, the more 'mass' resources they contain, but they will drain at a faster rate (between 1 - 3 to add variety) this will make the player choose which oath to take. Either play it safe with the closer planets or spend more fuel for a higher reward.

Also with the conversion rates it was suggested by many players, to keep it simple. It used to be, one mass for three currency, and three currency for one fuel. Since the player can only purchase mass, it was suggested I remove the unnecessary conversion until I fix the current mechanics and remove the currency until the player has more to purchase with it.

(I will probably reintroduce currency into the game when everything has been refined, I'm keeping things simple).

Also many players' suggested a conversion rate of one mass for one fuel at the buyer (converter). When paper prototyping this, players preferred it since it was easier to keep track of it, but they still wanted a digital version since it took ages for me to keep track of everything.

In a later version of the game, I would like to experiment with energy resources becoming more scarce ad more expensive and inflation. I would also like the buyer node to let the player choose via a GUI screen, how many fuel resources they would like to buy. However this will be in a later version.

Link to my updated bibliography:

http://josepheasterdissertationblog.blogspot.co.uk/2013/11/bibliography-references.html