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.