Design process; Cybernetic feedback loops
Over the
course of the design process, I applied the cybernetic feedback loops technique
many times to overcome issues to do with the game lacking a feeling of depth,
or the game becoming boring.
So, the
first one that I thought about implementing was a loop which checked the
players surroundings through a collision mesh, and see’s if there is anything
there. If that mesh isn’t triggered for 2 minutes, then it will spawn a group
of enemies, a random number, behind the player, which will immediately start
attempting to kill him. The idea of this was that it stopped the game becoming
stale, and essentially if at any point the player is lost for something to do,
it will create a task for the player. Unfortunately, this scenario is quite repetitive,
and arguably runs into the same problem as having nothing; find nothing for 2
minutes, get attacked by enemies, kill enemies, rinse and repeat. But it offers
some alternative, and ideally there would be a table of “random encounters”
that could happen to illicit a response in the player.
Unfortunately,
due to time constraints and a lack of experience with Unity, I wasn’t able to
implement this feedback loop, but the idea there is one which could be
implemented at a later date, and completely compliments the idea of
exploration. It is a core loop which I would implement if given the time.
Another
feedback loop I implemented to help the players keep alive, was a feedback loop
to do with the players shields. The shields, as in many games, can regenerate.
Being the first line of defence against enemy lasers, they go down first. The
feedback loop checks to see if the player has lost any shield in the combat,
waits for 10 seconds, and then begins the process of regenerating the shield.
Regeneration depends on how much shield is missing. This example of a positive
feedback loop (as it helps to keep the player alive, stopping the game from spiralling
away from the players control) is counteracted by an opposing loop. If the
player takes damage while his shields are regenerating, and that damage is
above a threshold, he stops regenerating and has to wait another 10 seconds.
This makes it so that the player doesn’t essentially become an un-killable machine,
who simply has to fly around to continue keeping his health up. This feedback
loop is a counter example, an example of a negative feedback loop. It prevents
the player from abusing the regeneration of his shields during combat, and
means that they have to make conscious decisions, like having to run away from
the enemy ships until their shields had regenerated.
Due to a
time limitation, I had to implement a shortcut in the game for weapon
interactions against objects. Instead of coding a blocked health system which
would instantiate for every object in the entire game, I had the script that
deals with the laser prefab randomly select a number between 0 and 20, and then
check to see if that number was below 2. If the number was below 2, then the
object would be destroyed. It was a simple and easy alternative to hard coding
health. However, due to this randomness, there is potential for an object to
never be destroyed, because of this random chance. I implemented a feedback
loop to make sure that you could always destroy something in 10 shots or less.
If the number didn’t come up as lower than 2, it would increase the number that
you need to get under from 2 to 3. If it didn’t roll lower than 3, it would
increase to 4, and so on and so forth. In theory, after 20 iterations of this,
you will always be able to destroy it because the code will ask, “is this
number lower than 20?” and it always will be. This feedback loop is sadly only
in the game due to time constraints though, as it is was much easier to code
this than a convention health system.
These
last feedback loops are ones which I didn’t use, as I didn’t implement the systems
they were going to reference. This loop is concerned with players who are
trading large amounts of goods. Like in the real world, supply and demand is a
common thing in the Elite universe, and the feedback loop has to do with this.
To accurately represent supply and demand, the price of goods increases as you
buy more and more of them. Now, this isn’t from a single vendor, this would be
an increase on the base price that neutral shops give you. It is realistically
most important when you buy from one retailer and sell to another. This feedback
loop is the core of how the trading system works. Conversely, as you sell lots
of goods, the price per goes down, because the amount in circulation is high.
This feedback loop encompasses the whole trade system, and has other feedback
loops embedded in it. For instance, if a player has a lot of rare goods, but
tries to sell them all to a single trader, he might be rejected, due to the
trader not needing or wanting the amount of goods he’s trying to sell him. On
the other hand, a trader with lots of goods will be more happy to sell you the
ones he’s got a higher price than normal, for the same reason as you.
In
essence, the feedback loop goes:
1)
Check
total amount against player amount
2)
Price
per item increases by some amount as player amount approaches total amount.
3)
Price
per item decreases by some amount as player amount goes away from the total
amount.
4)
If
the traders own inherent amount is reached, the player will be unable to sell
any more of those goods to that trader.
5)
If
the traders inherent amount is reached, he will sell the goods at a higher
price to the player.
6)
Rinse
repeat for every purchase interaction.
The
above flow shows how the game calculates the influence the player is having on
the trade market. The feedback loop therefore makes it interesting and more
realistic for the player, who is obviously trading as they enjoy that element
of the game.
Finally,
there would have been a loop for the mining mechanic. The loop would have the
chance of finding an asteroid with rare ore increase or decrease based on how
many the player has found previously, and also how much rare ore he has at that
moment. When a player mines an asteroid, there would be a chance to find one of
several different ores, of varying values. Finding an ore of a lower value
increases the chance to find an ore of a higher value by a small increment. As
the ore gets rarer, it increases the probability of finding ore of both higher and lower value, higher slightly less
than lower, with the scale depending upon the rarity of the ore you mined. If
you mine the second rarest, it only increases the higher probability by a
fraction, whereas it increases the lower probability by a much larger number.
This means that as you mine ore, you will always be increasing the chances of
rarer ores, until you reach the rarest ore, which resets the scale. This
feedback loop serves to keep the player interested and give them a sense of
fulfilment as well as a sense of excitement when they find that rarer ore, but
also keeps the player from finding the rarer ore all the time. Due to both
probabilities increasing, you will still be more likely to find a lesser ore,
but as you find more and more lesser ore, you will become more and more likely
to find the better ore, perpetuating that loop.
Due to the plethora of feedback loops I was able to come up with, and the effects I saw on how it made the game better and more balanced, as well as seeing how it could have made the game more balanced had the mechanics I hadn't implemented been put in, I think that it is a solid technique for making sure that there is interest for the player, as well as stopping the game from spiraling into unfair difficulty, or game breaking easiness. I believe that it is the best technique I have used, tying only with Pattern Language Techniques, and I would certainly use it again, as it has helped shape not only my games design, but my games runtime.
Due to the plethora of feedback loops I was able to come up with, and the effects I saw on how it made the game better and more balanced, as well as seeing how it could have made the game more balanced had the mechanics I hadn't implemented been put in, I think that it is a solid technique for making sure that there is interest for the player, as well as stopping the game from spiraling into unfair difficulty, or game breaking easiness. I believe that it is the best technique I have used, tying only with Pattern Language Techniques, and I would certainly use it again, as it has helped shape not only my games design, but my games runtime.
