Testing the Improved Prototype

Note: There should be two posts (including this one) this week since I did not have the time to post anything due to being busy with my dissertation and group project last week. Therefore this will make up for it. Also, I have been busy with both my first port folio assignment and setting up my next one (the web site). However during the Christmas holiday I should hopefully get my dissertation to where I want it to. However since it's christmas I may not blog as much due to the holiday. Either way I will let you know what is going on.

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

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

Iteration Five: Conversion and trader rates

Note: Any aspects of the game that are unchanged I have left out of these blog posts so these are shorter and quicker to read making them more information dense.

This week I have been working on different conversion rates and the production rates from each source of each planet.

The reason being this week (yet I had many play tests this week with about 2 iterations) from making the game too easy to win and exploit, every one struggled to win in any form. What I mean is, I rose the cost of energy from the trader too much, and because players could only earn one currency per mass, and each energy from the trader cost 5 currency, every one struggled to make more than one trip around the game world.

Everyone who has play tested my game has said they like the idea of it. However in the previous iteration I have made it far too difficult.

Energy Resource Transactions

Another aspect I changed was that it costs two energy to move and one to stay still during the turn. This was because I found one player only moving one space at a time and they racket up plenty of resources. There fore to remove this aspect and make people more around the world more I implemented the rule earlier in the paragraph. However... When testing this rule in the next iteration I had made a few errors. Firstly I changed an aspect of the game based upon one person, which is a pretty bad idea. Secondly, it was not much of an improvement from the previous iteration. The player was able to move around more and gain more resources, but not very much.

Due to this massive request I will revert the movement cost back to how they were and find a way to make the game more challenging yet make the difficulty curve less steep. In the next iteration movement will cost will be a lot lower, and the cost for being waiting in the same spot for a turn will be removed, but I will find another way to keep the player moving around the game map.

Trader

With the trader, every one though the cost of the energy resources was far too high and this made the game vastly too difficult. In face each game, lasted only a few minuets. To counter act this, I lowered the transaction for the trader. I lowered the conversion from 5 currency to three currency for one energy resource. The trader has another entity attached to it some where off the board, so all resources that it exchanges stay in the game. In the new iteration, many people still found this expensive but they preferred the lower price from this iteration to the last iteration iteration. I will fix this in the next paragraph which many people suggested.

Buyer node source

With this iteration I introduced another converter into the game. A number of players thought it was strange how they just gain currency from 'mass' resources and they also thought there was little reason to move around the game wold.

To fix this and give the game more context, they player once they have mined all the resources from a planet source, they can visit the nearest buyer node and can convert their tangible 'mass' resources into another tangible currency resource. This slightly improved the game, however the game was still too difficult. This was because again the conversion rates were not high enough. The player would convert all of their mass to tangible currency resources with a rate of one for one, due to the cost of the energy being

More energy resources or higher mass to currency conversion rates

Many players kept asking for more energy resources or higher mass to currency conversion rates so they could travel more before they become stranded. Due to this I increased the quantity if resources the player starts with. This alteration was met with praise, and I shall keep it in the game for now.

In the latest iteration (no. 5) I rose the quantity of currency the player gets in exchange for the mass resources, from one for one, to one for three. This way the player will be able to purchase at least one energy resource from the trader for every mass the collect.

However this was met by another challenge. Some players complained that they would not get enough mass to make another trip and many others thought the game needed to be less predictable.

Planet Mass production rates

I thought to make the game less predictable, I would introduce an element of randomness to the game. By this I mean the resource connections and the rate at which each planet source produces mass resources. I change the rules so that, every turn, each planet source in the game (four planets) were equal distance from each other, and they produce one mass a second, however every turn for each planet I rolled a die. When the die shows a positive number an extra resource is made. This worked to make the game less predictable, and many people liked it because there was a 50:50 change of a source making two resources a turn. I will keep this feature and play around with it for the next week to refine it more.

Another issue I fixed was how many mass a planet could hold until it resets, I lowered this to 7 because people thought this was too high. So far people like the change, but I may reduce it to keep people moving around the map more. And I need to add more spontaneity to the game with the resource production. Like more sources that are more valuable.

What Have I learnt this week?

In future, I will not change an aspect of the game unless many people request it (I have been doing this most of the time, unless some one found a major game breaking flaw), and I will alter as few aspects of the game as possibly in each iteration. This will make it easier to see which feature works and which needs tweaking or tearing every time.

Another thing I will do in future iterations is, I will either use dice to keep track of resource counts... Actually I will just use the machinations visual scripting tool for play testing because, there are more sources to take care of, and more multipliers it has become more difficult of resource counts. Also it will dramatically speed up game play and if a player does not like an aspect of the game I can easily change it. In face I need to start using the tool more often during play testing.

Another Note: This link below is the the blog post that contains the references I need from books or other sources.

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

Bibliography References

References:

Theory:

Adams, E. (2012). The Designer's Notebook: Machinations, A New Way to Design Game Mechanics. Available: http://www.gamasutra.com/view/feature/176033/the_designers_notebook_.php?page=1. Last accessed 19th October 2013.

Adams, E and Dormans, J (2012). Game Mechanics: Advanced Game Design. Berkeley: New Riders NRG. p60 - 62.

club sound. "Melt down 1.wav." Freesound.org. club sound, 28 Aug. 2010. Web. 31 May 2014. <http://freesound.org/people/club%20sound/sounds/103687/>.

Electronic Arts, (2011), Mass Effect 2, console game: PS3, Electronic Arts, USA: California

GALAWANA. "Galawana Studio." Galawana Studio. GALAWANA, 17 Jan. 2013. Web. 31 May 2014. <http://www.galawana.com/unity3d-camera-shake/>.

Gaming Minds Studios, Kalypso Media, (2012), Port royale 3: Pirates & Marchants [Windows]. Germany: Kalypso Media.

Kiymaz, Y. (2010). Solving the Pivot problem in Unity. Available: http://solvethesystem.wordpress.com/2010/01/15/solving-the-pivot-problem-in-unity/. Last accessed 7th Dec 2013.

LavaMind, 1994, Gazllionair, computer game: PC, San Francisco, LavaMind

Ninjutsu Games. "Asset Store." Asset Store. Version 1.3.0. Ninjutsu Games, 12 Dec. 2013. Web. 24 May 2014. <https://www.assetstore.unity3d.com/en/#!/content/8797>.

Stargate. Dir. Roland Emmerich. Perf. Kurt Russell, James Spader, Jaye Davidson. Live Entertainment, 1994. Film.

Stout, M. "So What Are We Doing Here?." Gamasutra. Mike Stout, n.d. Web. 14 May 2014. <http://www.gamasutra.com/view/feature/134949/learning_from_the_masters_level_.php?print=1>.

Trefry, G. "Chapter 7: Managing." Casual game design designing play for the gamer in all of us. Burlington, MA: Morgan Kaufmann ;, 2010. 139 - 154. Print.

Unknown, Unkown. "Wikia." Mass Effect Wiki. Wikia, n.d. Web. 22 Dec. 2013.  <http://masseffect.wikia.com/wiki/Combat>.


2D Art (sprites, UI and fonts and textures):

Brannum, Rebecca. Personal interview. 29 Apr. 2014.

Hastings-trew, J. "earth texture map." Planet Earth Texture Maps. james hastings-trew, n.d. Web. 26 May 2014. <http://planetpixelemporium.com/earth.html>.

Hastings-trew, J. "mars texture map." Planet Mars Texture Maps. james hastings-trew, n.d. Web. 26 May 2014. <http://planetpixelemporium.com/mars.html>.

Larabie, R. "Asset Store." Asset Store. Version 1.0. Ray Larabie, 12 Aug. 2012. Web. 27 Apr. 2014. <https://www.assetstore.unity3d.com/#/content/4235>.

Lorc. "Ray gun icon." 1238 free SVG and PNG icons for your games or apps. Lorc, n.d. Web. 29 May 2014. <http://game-icons.net/lorc/originals/ray-gun.html>.

msgdi, msgdi. "SciFi Muzzleflash + Laser Pack by msgdi." Unity Asset Store. msgdi, n.d. Web. 29 May 2014. <http://u3d.as/content/msgdi/sci-fi-muzzleflash-laser-pack/3Rr>.

"Asset Store." Asset Store. Tasharen Entertainment, 24 May 2014. Web. 26 May 2014. <https://www.assetstore.unity3d.com/en/#!/content/2413>.

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. Unknown, n.d. Web. 28 May 2014. <https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhF8AKTzEeAPVW9sl2WJEvDaZgt0Z7nIWoHGhOAH99Z_aiHJrz1uaYHQDIIOsXA8GUSoeVM7ET080LNrEurpxMJA29Rx5hnOlxJoPkz-4q_dSOlFfq5FStWhUnVKosiX6VzQsrx4NL-VUoO/s320/crack.jpg>.

Unknown. "Unknown."Unknown. Unknown, n.d. Web. 27 May 2014. <https://s3.amazonaws.com/colorslive/png/509299-PqhI_Cl78RheIJQS.png>.

Unknown. "Unknown."Unknown. http://wallpaperpanda.com/, n.d. Web. 26 May 2014. <http://wallpaperpanda.com/wallpapers/die/jA8/diejA8qik.jpg>.

3D Art:

crocobaura. "3D obj Satellite." 3D obj Satellite. crocobaura, n.d.  Unknown. Web. 26 May 2014. <http://www.turbosquid.com/FullPreview/Index.cfm/ID/337131>.

Duane's, Mind. "Asset Store." Asset Store. Unity, 5 Apr. 2013. Web. 22 Apr. 2014. <https://www.assetstore.unity3d.com/#/content/1807>.

ghdalstjr130@gmail.com. "Asset Store."Asset Store. GAPH, 7 Apr. 2014. Web. 12 Apr. 2014. <https://www.assetstore.unity3d.com/#/content/13998>.

niva3d.com. "3D 3ds spaceship space ship." 3D 3ds spaceship space ship. niva3d.com, n.d. Web. 1 Jan. 2014. <http://www.turbosquid.com/FullPreview/Index.cfm/ID/531813>.

Audio:

alienistcog, alienistcog. "dull-clangs.aif by alienistcog." Freesound.org. alienistcog, 22 July 2011. Web. 29 May 2014. <http://freesound.org/people/alienistcog/sounds/124711/>.

Bengtsson, J. "Third Cog Software - Cfxr." Third Cog Software - Cfxr. Joachim Bengtsson, n.d. Web. 27 Apr. 2014. <http://thirdcog.eu/apps/cfxr>.

Connum. "electric_sparks.mp3 by Connum." Freesound.org. N.p., 3 Oct. 2005. Web. 9 May 2014. <https://www.freesound.org/people/Connum/sounds/11709/>.

junggle. "btn050.wav by junggle." Freesound.org. junggle, 16 Jan. 2007. Web. 26 May 2014. <http://www.freesound.org/people/junggle/sounds/28860/>.

mckinneysound's. "Categories > Horror/Sci-Fi > Lasers/Weapons."freeSFX.co.uk. mckinneysound's, 27 Apr. 2014. Web. 27 Apr. 2014. <http://www.freesfx.co.uk/soundeffects/lasers_weapons/>.

mckinneysound. "Categories > Horror/Sci-Fi > Lasers/Weapons."freeSFX.co.uk. mckinneysound, n.d. Web. 9 May 2014. <http://www.freesfx.co.uk/soundeffects/lasers_weapons/?p=2>.

Pettersson, Tomas. "DrPetter's homepage - sfxr." DrPetter's homepage - sfxr. N.p., n.d. Web. 27 Feb. 2014. <http://www.drpetter.se/project_sfxr.html>.

peridactyloptrix. "Hover engine by peridactyloptrix."Freesound.org. peridactyloptrix, 9 Jan. 2014. Web. 31 May 2014. <http://freesound.org/people/peridactyloptrix/sounds/213384/>.

"Search for sound effects."freeSFX.co.uk. N.p., n.d. Web. 1 June 2014. <http://www.freesfx.co.uk/sfx/engine+power+down>.

Sweeper. "SoundBible.com."Electrical Sweep Sounds. Sweeper, 28 Apr. 2011. Web. 19 May 2014. <http://soundbible.com/1795-Electrical-Sweep.html>.

First and second Iterations

This may be a concise post.

This week after I refined my design document I set to work on my first iteration. At the start my game had a source, a drain and a few entities. This idea for the game was, the player (single player game) could move up to five spaces per turn and every turn each source produced one resource. Also the game world was constructed on a single grided sheet of A4 paper, 8 by 6 spaces. When the player moves, this takes up one energy and hey have up to five each turn. Also when the player i adjacent to a source, they can gain one resource per turn and they loose when they run out of fuel. The win condition is when the play gets as many resources as they can.

However, after a few play tests I needed to take it back to the drawing board because, I needed to include a trader, and a converter. This was the feed back from players. Also there was no threat in the game and because the game world was too small is was too easy to win the game. There was little challenge. I had simplified the game too much by stripping too much out.

Second Iteration

In this iteration, I doubled the size of the game world to spread things out since the all of the players asked for this, along with this I spread out where each node type was, making sure it they were not too near or far away from each other.

I added two new resources into the game. Energy and currency. The energy tokens are there so the player can easily visualize how far they can move across the game world. Also when the player gains resources, they also gain one currency token for every resource they gain. When the player visits a trader, they can trade one currency token for one energy. The loose condition when they run out of fuel.

Also the player can purchase a converter, that converts three mass to one energy or the other way round for three currency. Also, the player can collect all the resources in one go from a source. Also when a source has been cleaned out, it remains inactive for 5 turns.

Results:

One player found a few major exploits.

If he moved one space per turn gradually nearing a source planet, he would gain tonnes of resources from each planet very quickly with little effort. This drained away the sense of achievement. Because he could do this he could go to a trader and buy more energy resources and farm each source planet. This meant when a source was deactivated, it would do nothing to affect the difficulty of the game. This also made the converter irrelevant due to the exchange rates.

Suggestions:

One suggestion was to make the game multi-player. I may include this in a later iteration, but this is not my main priority. This would be to add some more strategy and accomplishment to the game.

Another suggestion was to add an artificial threat, like a space pirate that could attack the player so they loose some resources. I may include this in a later iteration but I have to fix the exploit at the moment.

Another suggestions was to penalize the player for moving one space at a time.

the last suggestions was to raise the trader exchange rates making the energy more expensive. As well as this, the converter should be set to a lower conversion rate then the trader. E.g. 3 resources one way for one of another, whilst the trader could be five currency for an energy resource.

What I will change in the next iteration?

In my next iteration I will make each source planet have a maximum number of resources they can hold, after this quantity, the resources are drained and reset to zero for that particular node source. This will add a negative feedback loop to the game. Also I will have to experiment with the trader and converter rates.

Dissertation Proposal Feed Back

This Monday when I received feedback on my dissertation, the comments towards it were positive, but that doesn't mean there is  not room for improvement.

The good points were that it was highly intelligent and well considered. Also the project seemed well scoped and reasonably challenging. As well as this the markers liked the idea of the core mechanics involved and were interested to seeing where this would go.

The negative points though were, I had not included regular play testing sessions into my mile stone time line. This was a fair comment since this will be crucial to the development of my game and I will make adjustments accordingly.

The other comment about my mile stone time line was about how it lacked the creation of art assets and GUI assets and implementing them into the game (digitally). This was silly of me and again I will make adjustments accordingly.

It was also pointed out I should build simple deconstructions of mechanics from managing game an internal economies from other games that I would like to include in my game. This is a good idea and I have already started doing this with the bank mechanic from 'The Settlers of Catan' (Franckh-Kosmos Verlags-GmbH & Co., 1995). This is a good idea since I can view all of the elements in the selected mechanics and how I can incorporate them into my game to further my understanding of them.

For the rest of the week I will be concentrating on refining my design document and refining the mechanics. By the end of the week I would like to have a basic paper prototype produced. However due to only received feedback on the proposal recently and getting group project work out of the way it seems more likely I will have a prototype produced some time next week.

I find this annoying since since I am behind on my project time line, however at least I am doing it now.

References

Klaus Teuber (1995). The Settelers of Catan. Germany: Franckh-Kosmos Verlags-GmbH & Co.

More possible job positions.

I have been looking for more possible job positions in the games industry as a games designer.

I have found 5 job adverts for possible positions at different companies (mostly indie companies) at varying levels, such as junior and senior (or lead).

The items in green are skills I already possess. The items in red are skills I need to learn or improve during my dissertation.

All of these jobs are available in the UK (a few of which are in Suffolk). From the table above I have a lot of work to do since I have a lot of skills to improve and gain. A number of these jobs require a jack of all trades where as some are more design focused. For example 'Shiver Entertainment' requires artistic skills to a degree. Since art is not one of the strong points I will have to improve this to a passable standard but not as a main focus, more of a polishing off type of thing.

Some of these jobs require coding skills (that I already have, but may require improving). I can already code in Unity3D but I might need to improve these code skills to do things more efficiently, or learn a new method. Again this will only be needed when I implement my designs into Unity when they are polished off and is not my main focus since design is what I am concentrating on.

A number of jobs required paper prototyping skills. I have done this with many projects in the past so I know how to do it. However I will need to improve this skill since this will be key to the design of my artifact and many design jobs require this, since it saves programming time on a faulty mechanic.

Another jobs requested, excellent communication skills. As much as I am articulate, my communications skills when explaining concepts are not as clear as they could be. As a designer communications with different departments is crucial in development. Thus I will have to improve this. One way I could do this is through breaking down each idea into simple elements in the design document, and replicate this verbally when I need to. This is crucial in the industry because if a team member get's the wrong idea or some thing is not clear this cold complicate the design and development process in the game's creation.

Possible career positions which my DIssertations could lead to.

Job's found on Gamasautra:

Games Design:

All Levels:

Shiver Entertainment have an advertisement on Gamasutra for a game designer. The requirements for this position are, minimum of one professional title, to be motivated and passionate about a broad range of genres and platforms. This advertismen also details they will hire artists and game play programmers. This new start up company will produce freemium games for Windows, Android and iOS. This company is focused on immersive gaming experiences for the plat forms listed above. The idea is for the designers to bring AAA experiences to mobile and tablet devices. The CEO is John Schappert, the former COO if EA and Synga and former head of Microsoft.
http://jobs.gamasutra.com/job/game-designers-all-levels-miami-florida-25277

Since I will be creating my game in Unity, my project could be transferred to a mobile platform and the controls would have to be simple enough for players to use on a tablet device. The job type for this is 'Game Design' and the studio is located in Miami, Florida.

The experience level for this application is N/A and the educational requirement for it is a basic high school certificate.

Senior:

Interactive Selection
Location: Midlands, UK

Involves: Working on AAA title, taking on responsability for for large sections of game design, leading junior team members. Reporting to lead designer, one will ensuring quality of design in allocated area. Must be working with and developing design staff and will act as a champion of quality across game team. Must be flexible, approachable and motivated.

Requirements: At least 5 years industry experience. Experience working as a senior designer on at least one published title current generation console (PS3). Consistent high quality of work, excellent communication skills, can write in a stylish and persuasive manner, excellent working knowledge and passion for racing games.

http://www.gamesindustry.biz/jobs/interactive-selection/midlands/england/uk-and-europe/senior-games-designer-games-innovator-id62140


Programming:

Junior:

Hay Specialist Recruitment
Experience: Mobile games.
Education Bachelor's Degree

This role is mainly about coding the front-end client for games, yet you need to be involved with every stage of game development from beginning to the end.

Essential: Computer Science Degree with games technology module.

Desired: Enthusiasm (plus one or more of the following), experience with Unity, Unity3D, C#, SQL, JAVA, FLASH.

http://jobview.monster.co.uk/Junior-Games-Developer-Job-London-London-UK-126117353.aspx?from=indeed

Senior:

Linden Lab

Software Engineer, Unity

Education: Bachelor's Degree  Location: San Francisco

The job involves working on new and exiting game projects. One's has to deal with versatility and change
and as an engineer one will end up learning new skills. The task involves working on live code bases.

What's involved:

Building new systems and improve existing ones. Collcaborate with other engineers on live products in using agile development. Extending and optimizing large scale game systems, such as physics and game play mechanic. Aid mentor and help juniors, and work closely with other department such as artists and designers.

Required skills:

5+ years of software engineering.
High proficiency in C# or C++
Sharp focus on prioritization on user-experience and know where and when trade offs need to be made.
Collaborative and fast to adapt in a multi-tasking, fast paced distributed thinking environment.
Strong 3D maths skills

Bonus Skills:

Previous Experience with Unity
Previous game industry experience
Experience with physics systems development

Lead:

Rumble Entertainment Inc.
Experience: Mid-Senior

Direct a team of programmers for an online AAA game with a large scale deployment. The department also works with other disciplines of games design.

Desired Skills: Fluent in C#, C++ or Java, experience with other languages is a plus. BSc in Computer Science or equivalent experience.
Effective in directing and delivering production soft-ware for high quality games.
10+ years development experience with one shipped game product as a technical lead.
Direct experience with client/server typologies used in online games.

Bonus: iOS or Android experience, Unity 3D game engine experience, Experience with online game services.

Balancing an in-game economy

In this Gamasutra article, Soren Johnson discusses how to balance in-game economies using forms of inflation.

However in some games if the economy is not pruned and tested thoroughly, things can become chaotic very quickly and backfire. E.g. when Ultilma Online started, it was famous for how quickly the economy spiralled out of control. Zachary Simpson analysed UO in 1999, showing a number of the more notable errors experienced at launched.

• Players used vendors as infinite safety deposit boxes by setting the prices of their own resources vastly above the market value.
• Resource hoarding forced teams to leave the closed-loop economy as the game world started to run out of goods.
• Cartels (including one from a rival game company) monopolised the market on magical Reagents, stopping average players form casting spells.
• The item crafting system encourage vast over-production via rewarding players for each item produced.
• Due to over production, this led to hyper-inflation as NPC-shopkeepers printed more currency on demand to purchase the worthless items.

Fortunately since then, MMO (and offline games) have come far since them. EVE: Online hired an economist graduate for balance out the economy by analysing the flow of game resources and the fluctuation of in game prices.

Can markets balance the game?

Many games designers have used economic game structures as a tool for balancing out their games. E.g. Rise of Nations, every time the player purchases a unit such as a Knight, the price of the future unit of the same item raises. This simulates pressure of demand based on the price. This design encourages the player to diversify their forces in game, this was to maximise their in game purchasing power.

Through allowing the variables of different paths and options to float around during a game, designers present players with a constantly evolving landscape, this extends the re playability through guaranteeing no dominant strategy.

Although if this method is taken too far, auto-balancing by tweaking the economy can potentially destroy a game. Valve back in 2006 conducted an experiment with it's game Counter Strike: Source, by implementing a dynamic weapon pricing algorithm. The idea the developers has was "the prices of weapons and equipment will be updated each week based on the global market demand for each item. As more people purchase a certain weapon, the price for that weapon will raise and other weapons will become less expensive."

However, due to the overwhelming popularity of certain weapons this trumped the ability of the algorithms tp balance the game. E.g. very effective weapons sky rocketed, whilst the less useful weapons flat lined, this led to some extreme cases. If this persists, by the price climbing higher and higher, this can become prohibitive for many players and they may not only just change their strategy. If they are not having fun they can just change to a different game unlike a real world economy.

Due to this, playing with a games economy is a slippery slope. If the cost of a player's favourite weapon has been raised it may feel like a penalty and should only be done if the imbalance is actually destroying the game play.

Putting the Economy Inside the Game

In some cases a better use of economic dynamics is as a transparent mechanic inside a game itself. Plenty of board games provide examples of certain free markets. The game Puerto Rico increases subsidies to improve the appeal of unpopular technologies and roles. In the case of the first one, every turn no one decides to be a Craftsman, a single gold piece is added as a "reward" for choosing the role. When the gold increases gradually, a few players will can resist such a bounty, that nicely solves the problem of making sure roles are chosen.

In Puerto Rico, the game has clearly better or worse options, they merely change from turn to turn. In this instance auto-balancing actually works, and keeps the game fun because players are rewarded for choosing less common strategies, instead of penalising players for sticking with their favourite strategies. Also the effects of the market are transparent before the game, so it doesn't feel like the game is against the players'.

the game power grid is a great example of a free market since it's based around actual resources. In this game, all resources are purchased from one central market to supply their power plants. The resources are placed along a linear track of escalating prices. Each turn, X new items are added to the market, and the players purchase Y pieces. As the supply fluctuates, does the price of each item.

By making the demand mechanic transparent to the players, the market becomes its own war zone. By purchasing as many resources as possible, a single player could drive the price out of range for most players in the next round, causing some players to not be able to power their plants that turn. Therefore, with a completely free open market, the price of items can be used as a weapon, just like a bullet with a gun.

Benefits of Having Free Trade

A number of strategy games, which include Age of Empires, have included free markets which players are able to purchase or sell products, influencing nationwide prices with their actions. These markets serve as "greed tests" in which players are frequently tempted to sell when they require cash or to purchase when they are short of a specific resource, however they realise in the back of their minds each time they use the market, they could be giving an advantage to another player.

However , the market dynamics of these games generally repeat themselves, since the prices usually bottoming out once the players' production overwhelms their needs. This effect stems from the fact the game maps emphasise economic fairness, each player is guaranteed a decent quantity of resources near their start location. Spreading resources randomly around the map may lead to a far more dynamic market mechanic, however this is at the cost of overall pay balance for a game with a core military mechanic.

However in some games like M.U.L.E. the player has to specialise in a certain resource, and gain economic dominance through this. due to this the players' rarely can produce all the resources they need on their own and have to purchase resources from other outlets and players.

The players are arranged at the bottom of the screen, and the sellers at the top. As buyers go up, so does their asking price. As their position moves down, so does their asking price, where the two are level, a transaction is made.All information is public for greater transparency. The mechanics are, the player either has to adjust their prices or cave in to the other players. Some times a player will have to spend money to produce resources to power their buildings or food and drink to feed the labour, the player may want to save every last penny. This this case, prices generally fall only if the a player is scared another player may sweep in and gain the benefits.

What Might be in my game?

Since my game revolves around an economy I may include in inflation mechanic since I find this aspect interesting and it could help my games economy. However, I require more research on the topic, and it depends if I have the time to do it in my project. If I do have the time to include this in my dissertation it will probably be involved when upgrading aspects of the game. For example health capacity, how powerful a certain ability is.

Emergence and Progression (how I can use these with managing mechanics)

History of Emergence and Progression

Games of emergence are those of fairly simplistic rules but much variation. The term if used because the puzzles and the order of events are not planned beforehand but occur during game play. Emergence is produced due to the many possible combinations of rules in card games, board games and so fourth. Juul says "Emergence is the primordial game structure" (p. 324) many early games were those of emergence.

Games of emergence come in many different, states, forms and configurations during game play. The possible arrangements of the game pieces in drafts constitute different game states, since the arrangement of a single draft by even one position can make all the difference. The possible combinations of draft pieces on game board is large, however the rules for the game can sit on a page of A4 paper and the game is still played to this day.

Games of progression however, offer many pre designed puzzles and challenger which the designer ordered, generally through level design. Progression usually relies on a intricately controlled series of events. The designer controls the challenges the player comes across through designing the levels in such as fashion the player has to encounter the events in the specific sequence. In a game of progression the quantity of game states is quite small, the designer has complete control over what is included in the game. When a player is put on a set track like an on rails game, the player travels from one in game challenge to the next one.

Emergence

When people use the term emergence, originated from the term in complexity theory. It refers to how a system behaves which can't be derived from its constituent parts. Whilst, Juul is cautious not to confuse emergent behaviour in games  that display behaviours the designer did not fore see before hand (2002). Like in any complex system, the big picture is greater than all of it's part together. Some games such as chess have relatively simple rules yet generate an great deal of depth. Games like these are constructed from relatively simplistic parts, yet the number of approaches and strategies they allow are huge. No two sessions feel alike. Emergent games do not come fro the complexity of the parts it's made from but from the complexity of the many iterations with all of it's parts.

Simple Parts in Complex Systems

The contents of complexity studies all manner of complex systems in life.The agent or elements in these complex systems may be sophisticated in itself, these are particularly simulated with simple models. E.g. the flow of pedestrians in different environments, great results have been obtained by simulating pedestrians with merely a small number of rules and achievements (Ball, 2004, pp. 131-147). It is possible to generate emergent games with a small number of complex parts, mechanics of games systems which work with simplistic components yet still create emergent game play are more interesting.

Progressive

With progressive games, many of them contain stories to drive them in a particular direction, this is frequently told over the course of several game levels. Each level usually has clearly defined missions which structure the tasks in and set the player's goals for them in order to finish the level. The designer must plan out the game and the levels in such as fashion the game produces a consistent experience. Frequently the designers use a variety of mechanics to manipulate how the player is able to move through a game. When designing a game with an interesting story, understanding the progression mechanic is vital.

When designing game levels, progression in an important aspect. There key elements when a designer has to control when parts players will encounter first, these include, what they need to complete to proceed, what resources they start off with. The designer decided that abilities the player has control of and manipulating the lay out of the level, including where items are placed in the game, for example power ups. Through this, players are not thrown into the game, they are gradually brought into it. E.g. as player's go through the game exploring it and gaining experience and skills, they will gradually have an experience that is story like by gaining relevant information from event in the level.

The rules of a game are relate to the number of possible states, but it's not completely true more rules will lead to more possible states. Along with this, when a game produces a large quantity or possible states whilst using only a few rules, the game will become more accessible to players.

Game States and Game Play

When designers talk about the path the player(s) take through the possible states of a game, probability space, people sometimes describe the path a a trajectory. The different possible game play trajectories and states through a game are emergent properties of a game rule system. Game which allow lot's of different, intriguing trajectories arguably have a greater quantity of game play than games which generate fewer trajectories  or not as interesting ones. Although, to determine the kind and quality of the game play is not easy, if not impossible, by merely observing the rules. By comparing the rules of two different yet simple games, you can see these difficulties. E.g. Naughts and Crosses and Connect Four.

Naughts and Crosses

1. The game is played on a 3 by 3 grid.
2. Players take turns occupying a space.
3. A space may only be taken once.
4. The first player to occupy three spaces in a row (orthogonally or diagonally) wins.

Connect Four
1. The game is played on a 6 by 6 grid.
2. Both players take turns to take up a square.
3. A space may only be taken once.
4. Only the bottom most available space in a given column is about to be occupied.
5. The first player to take up four spaces in a row wins.

While there may only be a few differences between the rules for two similar games, the difference in the game play can be massive. It can be far greater than the amount of mental effort required in order to understand the rules.

In the commercially available version of Connect Four, the most complex rule, (no. 4) is enforced via gravity: player's tokens will just automatically fall to the lowest available space in the upright playing area. This saves players from manually enforcing this rule and permits them to focus on the rule's effects instead. Even though the small differences in the complexity of the rules, tic-tack-toe is appropriate only to small children, therefore Connect Four is about to be played by adults. The latter allows for different strategies on a great scale, and takes longer to master the game. When two experienced players compete, it will certainly be an exiting match. Rather than being a certain draw as the case is with Naughts and crosses.

Comparing Emergence and Progression

In Juul's original article, he expresses a preference for game which use emergence: "On a theoretical level, emergence is the more interesting structure" (2002, p.328). This regards emergence as an approach which permits designers to produce games in which the freedom of the player is leveled with the control of the designer. In a game of emergence, the designers don't specify every single event in detail before the game is published. Though the rules might make certain events quite likely. However, in practice, a game with an emergent structure often still follows fairly consistent patterns. This is discussed by Juul, the gun fights which almost  always erupt in a game of Counter-Strike (p.327).

In his other book Half-Real, he is nuanced in his discussion of emergence and progression (2005). The majority of modern computer games are hybrids. They include some features of both. GTA: San Andreas has a vast open world yet also has a mission structure which influences new elements and unlocks this world piece by piece. In the game Dues Ex, the player is shows the main path yet there are different strategies to each mission and can use different paths when they encounter different challenges along the way.

Emergence and progression are simply different, neither is better. Pure emergence games and pure progression games represent two different extremes. many casual games, are pure emergence. Pure progression games are very rare. The majority of games include elements of both mechanics, like a level in a game my exhibit emergent behavior with in a game based around a progression mechanic.

What parts will I use in my game?

Due to the nature of management games, and my research I will use progression in my game since the player will be progressing to the next level trying the reach the set goal in the level. However a little emergence may be used since pure progression games are rare. A few of the in game entities will have only a few different game states since these will be be performing one task however this could change.

What parts I might use in my game

I may use emergence on a small scale in my game since a few of the entities will not have many states, there fore adding some variety to the games state. However due to the nature of the game and the mechanics this will be on a limited scale.

References

Ball, Philip. 2004. Critical Mass: How One Thing Leads To Another. New York, NY: Farrar, Straus and Giroux.

Jull, J. 2002. "The Open and the Closed: Games of Emergence and Games of Progression.". Finland: Tampere. pp. 323-329.

Jull, J. 2005. Heal-Real: Video Games between Real Rules and Fictional Worlds. Cambridge, MA: MIT Press.

More research in managing mechanic Machinations

More on managing mechanics and a little about economy's. But mostly managing mechanics.

I have been reading a 'Gamasautra' article about Machinations, which is about the flow and management of resources in a complex games system.It is interesting because there is a free flash tool for developers to test out their systems. It simplifies complex games systems and the user can break down their systems to individual parts to see how their in game flow of resources works. The reason this was invented was because it is difficult to paper prototype complex systems and if you do it via code, this can take a while and if it doesn't work, the code and time is wasted. This is also good for testing out feed back loops in game economies and certain structural features in games.

It can also be good for testing the resource flow of multi-player games for a single play because the designer can get into the mind set of a single player and look at their in game options. It is also a good way to look at the structural qualities of game mechanics with out any complex coding.

The main purpose if Machinations is for designers to model activity, communication between parts of a games internal economy and interaction. The article says any games economic system is dominated by the flow of it's resources.

The tool allows designers to model a game's internal economy by using Machination diagrams that use several types of nodes which, push, pull, gather and distribute game resources. It also has resource connections to determine how these resources move between two elements, and the state connections determine how the current distribution of resources in game modifies all the other elements of the diagram.

How does it work?

The diagrams are composed or pools and resource connections. A pool is a location which is where resources are gathered. In the applet they are represented by open circles and the ones with more complicated functions have a tweaked visual appearance (but that's for later). The resources stored with in them are represented by smaller circles stacked up on them. When the amount of resources is to high to show visually, they are represented by an integer number with in the circle.

Pools are used to model entities in an economy (but they can't use factional values, only integers). For example if you had a resource called 'Petrol' and an entity called 'Player's petrol tank', one would use a pool to model the petrol tank.

The most basic form of connection is a 'resource connection', it drives resources form a single to node (or entity) to another in the feedback loop game structure. In the diagram they are represented as solid arrows connecting the nodes in the diagram. These connection can transfer resources at all sorts of rates. There is a label adjacent to the resource connection indicating the quantity of resources that can be moved along the connection in a single time step. If the label is blank, it means it transfers one resource.

The random flow rates of resources between nodes can be specified and tweaked using the label box. Random rates are represented in different forms. For example, the rates can be represented using different die rolls and a die symbol will show near the connection. Due to this the applet diagram will randomly generate a number from the type of die (or dice) specified and possibly add a modifier to the combination. In other words the Mechinations Tool is able to generate random number combinations like pen and paper role-playing games. In PRG's a six sided die is represented as a D6 and two of those dice is represented as 2D6, thus the result would produce a number between 2 and 12.

But there is another way. These random number can be represented as percentages. A resource connection labeled 25 percent indicated there is a 25% change one resource can flow along the connection at each time step. One can use percentages higher than 100%. E.g. 350% means a transfer rate of at least three plus a 50% chance if one more.

Activation modes

In each iteration nodes can fire. When a node fires, it transfers resources along the connections which are connected to it. A node can fire depending on it's activation mode. A node has four activation nodes.

A node can fire automatically, so every iteration it fires. All automatic nodes fire together.

A node can be interactive, meaning it fires when the player clicks on it representing a player action. In the Machination tool these fire when a player clicks them. These nodes have a double out line.

A node can also be a starting action, this is represents with a little 's'. These fire before the first iteration, just after the user clicks the 'run' button.

A node can also be passive, meaning it only fires in response to a trigger generated by another element. Resources are able to be pushed to other nodes, but they don't push or pull unless triggered, these don't have a special mark.

Pulling and Pushing Resources

When a pool fires, it will attempt to pull any resources through any inputs connected to it in some way. The quantity it draws is determined by the rate set by the push nod. When in this node, when the pool fires, it pushed resources through it's out put connections, at the rate of it's out put resource connection. A pool push mode is indicated with a p, a pool which has only out puts is always considered to be in push mode, in that case the P marker is omitted.

If a pool is attempting to pull more resources than exits at the end of it's inputs, it will deal with it in one of two possible ways.

Automatically a node draws many resources as it possibly can, up to the flow rates determined by it's inputs. If not enough resources are accessible, it can still pull those which are.

Alternatively, a node (or pool) is able to be set to draw all of no resources. In this mode, when too few resources are accessible, nothing is drawn.


In a managing game this would be useful when dealing with an internal economy and distributing resources.

What will I include in my game from this?

For my recourse managing game I will include, resource pools since these are entities for resources to be held in.

Interactive nodes will defiantly be present since they represent a player action, when interacting with other entities to transfer resources. This action could be used as a trader for example in an economy.

Automatic nodes will be in my management game. I could use this to represent a 'source' where resources are created in the game for the economy.

Passive nodes. This could be used as a possible source or drain. However this would be more suited to being a converter or trader if used in an economy. In my option though it is more suited to being a converter. It could loosely be used as a source, but one that is infrequently used though.

Resource connections

I will defiantly use these in my game since resources need to flow to and form different entities in order to operate correctly. I could also utilize the rate at which the resources flow in these connections between entities. This would be useful when transferring resources from sources to another entity at specific rates, which could later be modified.

Pushing and pulling Resources

A node that pushes resources from one entity to another would be useful with a 'source' in a managing game since sources create resources from thin air and do not require any input. These would just push resources to the next node required or store them in the entity until needed.

If there was a player avatar this would be both a push and pull node since the player would gather all resources they could get from sources, yet they would push resources towards drains. E.g. bullets towards and enemy until the enemy dies in which the enemy is the drain.

A drain in a game economy would require a pull function since it will be physically removing resources from the game itself. It would be set to pull all resources because if not enough of a resource is available it will destroy any sent to it down a resource connection.

A converter and trader would need both a pull and push node since a resource product would flow through one connection and out the other end. A trader would be represented by a node that only draws resources when enough are available, if not nothing is drawn. This is because a trader needs a specific number of resources to trade for another set of resources.

This would also be good for a bank entity or inventory to store resources for a later time in a game. This is because all they have to do is store resources regardless of the quantity flowing from each connection.

What Might be included from this?

A converter on the other hand would pull any resources from it's inputs in order to convert the resources. This would be useful since it will pull as many resources as it can, up to the rates of it's inputs (upon t activation of certain conditions). However if not enough resources are available, it will pull as many as it can. This could work with a converter because it could convert as many resources as it can get it's hands on, depending of the requirements of the process.

Starting action nodes. I'm not sure weather this will be needed in the economy. It could be used to trigger of an event in a level in the game.

References

Adams, E. (2012). The Designer's Notebook: Machinations, A New Way to Design Game Mechanics. Available: http://www.gamasutra.com/view/feature/176033/the_designers_notebook_.php?page=1. Last accessed 19th October 2013.

Refining the mechanics to a degree

One of my ideas was to look into procedural generation. I mentioned this to Chris and I read a book on it that he decremented, and I read the areas he decremented I start on and other parts I was interested in. He suggested looking into textures, then noise, then another area (I think bump maps(but my memory is horrible)).

Therefore over the weekend I read the chapters on texturing, noise, bump mapping, fractals and terrain. Even though these areas were interesting, the mathematical formulas were a bit above my level and I worked out they would annoy me in the long run.

After this I worked out I would rather make a resource management game in Unity. I have previously worked with resource management game in a past project. I enjoyed creating the game and researching the managing resource mechanic, however I do not feel I fully explored the area and would like to make a robust game out of it.

For the time being I will keep the helicopter game idea with the managing mechanic but I will develop the skin for it later (but shortly).

What mechanics and things my game will contain

Resource managing mechanic:

Resource managing is when a player is forced to keep track of multiple elements while frantically clicking around a computer screen attempting to keep everything stable and on track. When creating a board game there variables must be limited since people can't keep track of too many variables. However with computers, the designer can hide tonnes of these and show only what the player needs to see, which adds more polish and complexity. This can mean keeping track of more game pieces, but managing more items such as capacity variables and and how far away some pieces are to each other (Trefy, G. (2010), p139).

Resources:

A resources is any concept which can be measured numerically (either as an integer or decimal). Nearly anything in a game can function as a resource, (this includes disposable items under the players control). Anything a player can gather, produce, collect or destroy is most likely a resource of some kind (Adams, E and Dormans, J. (2012), p60).

Tangible 

A tangible resource is a resource which holds physical qualities and can be stored in a particular place in world space and occupies world space. These often have to be more else where in the game world. An example of this is a players inventory like a ruck sack or if a player has mined gold and need to store it some where like a bank (Adams, E and Dormans, J. (2012), p60).

Intangible:

Any resources in the game world that do not occupy world space or posses physical properties are intangible and they do not need to be held is a specific location. This can include, player health, or time for a timer (Adams, E and Dormans, J. (2012), p60).

Entities:

An entity can store specific quantities of a resource. For example in my game, the player avatar, water tower or house, are entities since they store resources at a specific quantity (Adams, E and Dormans, J. (2012), p.61).

Simple entities:

A simple entity stores only one value of a resource. For example, a glass can only hold fluid in it. In my game for the time being, the houses on fire will be simple entities since they will only be able to hold the variable for the fires value (unless things become more complex) (Adams, E and Dormans, J. (2012), p.61).

Compound entities:

These are a collection of a number of related simple entities, meaning compound entities can hold more than a single value. For example, the main avatar in my managing game will have a maximum speed value, damage value and maximum water value. All of these entities tied together compose a compound entity, and the simple entities are relabeled as attributes (Adams, E and Dormans, J. (2012), p.61).

Sources:

This mechanic creates completely new resources out of thin air. They may produce a resource when a certain condition is met, at a certain time. A source will generate a resource of some kind and store it in an entity some where in the game world. Sources can produce resources and a continuous production rate, or can be triggered by events in game. They can also be activated and deactivated (Adams, E and Dormans, J. (2012), pp.61-62).

Drains:

These are the polar opposite of sources. These physically take resources out of the game, reducing the amount stored in an entity permanently removing them from the game (Adams, E and Dormans, J. (2012), p.62). For example in my game, when I put out a fire, the fire is a drain since it reduces the amount of water in the game world.

What my game will possibly contain

Converters:

A converter physically turns one kind of resource into another in the game world. For example if a player has some iron ore and they convert it into a iron block when it is smelted. The act of smelting is a converter mechanic and converts resources at a specific rate, in some game the player can upgrade the efficiency of the process (Adams, E and Dormans, J. (2012), p.62).

Traders:

A trader, moved resources from one place in game to another completely different place in the opposite direction, according to a given exchange rule. Unlike converters, traders do not crate of destroy resources, just move them from one entity to another (Adams, E and Dormans, J. (2012), p.62).

References

Adams, E and Dormans, J (2012). Game Mechanics: Advanced Game Design. Berkeley: New Riders NRG. p60.

Adams, E and Dormans, J (2012). Game Mechanics: Advanced Game Design. Berkeley: New Riders NRG. p61.

Adams, E and Dormans, J (2012). Game Mechanics: Advanced Game Design. Berkeley: New Riders NRG. p62.

Trefy, G (2010). Casual Games Design: Designing Play for the Gamer in All of Us. Burlington: Morgan Kaufmen. p139.