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.

Prototype Questionnaire responses

I received about 15 questionnaires back from both peers and other friends and family. The following results categorise these results, as well as listing many of the aspects they had written down (for questions 2 and 7)

Question 1) Do you think the prototype was fun?

Positive response, most people thought that the prototype was fun, in fact some went so far as to say they found it addictive, and claimed to have played it for half an hour or more in some cases.

Yes: 13

No: 2

Question 2) What do you think made it fun?

Many people said that, the simplicity of the game, coupled with how difficult it was due to the random nature of the AI behaviour and an element of chance on the laser shots made the game “addictive”. Majority also said that they felt that the ship felt good to control, and that certain addition parts (detached camera and auto-pilot mode) made the game more interesting, especially as they tried to figure out ways of using them. They also said the destructible terrain was a fun aspect, and made the game feel more “dynamic”

Question 3) Do you think the game worked mechanically?

A perfect response, everyone said they felt that the game worked from a mechanical standpoint, with little to no issues with control mechanisms or gameplay.

Yes: 15

No: 0

Question 4) Did you find the control system easy to use?

Some who hadn’t played a game like this before took a while to get used to it, and that impacted their initial playing of the game, but the response afterwards was good. One respondent said that he felt the ships was “too responsive”.

Yes: 12

No: 3

Question 5) Did you feel the AI was too rigid?

A lot of people didn’t think the AI was too rigid, despite it having only a basic routine. However, some said that they did feel the AI was a bit rigid, but that it actually didn’t impact gameplay too much because of the manoeuvring advantage they have on the player. They felt that the AI’s relative stupidity allowed them to outsmart it, and that was an enjoyable aspect for some of them.

Yes: 5

No: 10

Question 6) Do you think the game was balanced?

Many people thought the game was “hard but fair”. Despite the random nature of the shots in earlier versions of the prototype, they didn’t feel that it unbalanced the game. Some, however, did feel that the random aspect made the game feel as if it was completely luck based, and that took away from their enjoyment partially.

Yes: 12

No: 3

Question 7) What aspects, if any, do you think could do with improving?

A lot of people mentioned how the AI could be difficult to find, and that some of the time was simply spent flying around the obstacles to find them, and then just making strafing runs to try and destroy them before they themselves were destroyed. They suggested having targeting reticules on the side of the screen, like in many other games in this genre. Someone else suggested an audio cue, where they would constantly make a noise (an engine noise for example) so you can pinpoint where they are relative to your position.

Another thing mentioned by one person was that the controls on the ship where too precise. The game takes the exact value of where the mouse is and interprets it as a set of transforms for the ship to perform, based on the distance from the centre of the screen as well as the angle from that central point. Because of this, the ship can move very quickly as it turns, potentially disorientating the player and causing them to “lose their bearings”.

Question 8) Do you think that it could work as a core mechanic in a game?

The response from this and the next question were very encouraging. All of the respondents said they felt that it could easily be used as a core mechanic, and that it should be used as a core mechanic, as they felt it would make the game more fun, and it was something which was expected of the genre.

Yes: 15

No: 0

Question 9) Do you think that it could function as a game in its own right?

The response from this was very encouraging as well. A lot of people commented that it wouldn’t work as is as a game, as there is nothing after defeating the enemies, but that if the idea were fleshed out, even if this was the centralised, core mechanic of the game, it could become a standalone title. That led me to believe that the prototype was a success.

Yes: 9

No: 6

Prototype Questionnaire

Question 1) Do you think that the prototype was fun?

a)      Yes

b)      No

Question 2) What aspects do you think made it fun?

Question 3) Do you think the game worked mechanically?

a)      Yes

b)      No

Question 4) Did you find the control system easy to use?

a)      Yes

b)      No

Question 5) Did you feel that the AI was too rigid?

a)      Yes

b)      No

Question 6) Do you think that the game was balanced?

a)      Yes

b)      No

Question 7) What aspects, if any, do you think could do with improving?

Question 8) Do you think that it could work as a core mechanic in a game?

a)      Yes

b)      No

Question 9) Do you think it could function as a game in its own right?

a)      Yes

b)      No

3 Different states of playing:

The above shows the three possible states that the player can play the game (not including main menu or other UI screens). The three states, which encompass the three main aspects of the game, are the Free-Flying aspect, or the exploration and combat part of the game; the Mining and Producing aspect, or the trade part of the game; and being docked with a space station, which encompasses the idle part of the game, and trade, along with Mining and Producing. It shows the flow between the 3, and really emphasizes on the exploration part, due to the fact that both other states require the central part.

3 Different kinds of AI 

I used the same technique as to detail game states as to detail the possible states that the player can be with relation to AI, and the effect that this will have on his ability to play the game in certain areas/certain ways. It shows the benefits of being allies with people, which promotes following missions and doing things that help drive the players enjoyment and help them to achieve their prime goal, which is to increase their number of credits so they can buy better ships and other goods.

Included in that is two cybernetic feedback loops, which act to keep the game from spiraling away or towards the players favour. Under allies, the clause “May increase enemies in certain factions/groups” serves the purpose of not having the player become allies with every single faction, and thus take away one of the more enjoyable elements of the game; combat. A check will be made to see how many allies the character has made. As that number increases, so does the likelihood that one of the factions or groups will denounce you because you are allies with one of their enemies; police denouncing you because you work with pirates for instance. Not only does this make sense from a story perspective, it helps eliminate a player getting into a situation where they can’t lose because they have everyone as their allies.

Conversely,  if the player finds themselves in the unlucky situation where every faction hates them, the failsafe that allows them at least one group to ally with is that when you increase in number of enemies, the likelihood of one of their enemies allying with you is increased. “The enemy of my enemy is my friend” is the logic, and it means that the player can still get the benefits of having an ally, even if they have managed to successfully antagonize the rest of the galaxy.

Project plan and limitations within that

Seen above is a screenshot of my project plan. The lack of detail is down to a few things. First of all, the very short time frame. This is due to my having worked as part of a group prior to this, but unfortunately the group fell apart, and we were left without enough work to show for it. Due to this, I was forced to start again, with a limited time frame (but an extension luckily)

The other reason is that a lot of the more time consuming parts of the creation process, like modelling and rigging, will be handled using free assets. Due to the time constraints, I do not have time to model and make every asset in the game. It is therefore much easier to just spend a day finding the models I would want to use, and importing them. This allows more time for the more important aspects, such as coding the mechanics and bug-testing. 

Again, due to the time constraints, I have had to condense the game idea and strip some of the mechanics that I was meaning to use. I have there put that I wish to be able to implement a Combat, Exploration and Trade mechanic. However, as you will see in the screenshot below, that I had to remove the trade element from the final product due to the limited time. Luckily, Exploration and Combat are the two main aspects that majority of respondents from my questionnaire said they wanted, so they were the two main aspects I focused on. Taking the time out from using the trading mechanic effectively added an extra couple days too each of the other mechanics, so I could make them more refined and better tweaked.

Top-Down and Bottom-Up Games design

The above image shows the top-down process and the bottom-up process. The process, on its own, handles the two main approaches to games idea generation, and the design process. One side takes a concept, for instance a game where the player is the only human in existence, and has to deal with life in a deserted earth. The opposite side, bottom-up, is where you have a mechanic (or in this case you start off with verbs that you can apply mechanics too) and you create a game around these mechanics. In the previous idea, I could have started with a survival mechanic, and come up with the core idea’s that would feed into that survival game.

It is important to remember that a couple of external factors will skew which specific approach you take, and using only bottom-up or top-down to design a game will not provide you with a solid enough base to make a compelling game. Some of the factors that affect which to take are things such as what the target platform would be, what time frame we have to create the game in, and for the most part the limiting factors around how the game will be made and run. On a system where you have no resource limitations, top down allows for some very vivid and deep games that have a complex list of interlinking mechanics. However, due to the fact that there are these mechanics, the game itself would struggle to run on a lower end machine (or on phones and tablets). On the other hand, if you are making a game for a lower end machine, then it is a much better idea to take a game mechanic that you know would fit the target platform, and potentially could be programmed to work efficiently, and then flesh that out with other game aspects and a “package” that the mechanic can be delivered to the player in.

Applying this to my game idea

There were a couple of things that made it a difficult choice to choose one over the other. The target platform is supposedly going to be android and iOS devices, with PC support as well. That means that bottom-up would be the better process to take. However, due to the fact that the concept is already solidly chosen (space exploration game), I have the first step towards top-down.

Mechanically speaking, it is a better choice to do bottom up, because although we have an IP that we are working too and an idea, we need to focus on how that will fit into the target medium, which could potentially affect the way the game plays. In the verb stage of the pyramid, I chose several game “states” that the player could be in, which can be seen in the next post. These states contained a number of actions which the player would be able to make when they are in that state, as well as defining a base state and how the different states interacted. This meant that I could clearly outline the ideas I had and wanted to implement, and could list them as a system of mechanics. It also better allowed me to look at how these mechanics linked together, and formed a cohesive interlinking system.

For the mechanics, I implemented Ben Cousins theory of Hierarchies, which lists interactions and mechanics based on their parents. For instance, if a player is holding a gun, then they have the ability to shoot it. If shooting it means it runs out of ammo, then the player can reload it. Categorizing the mechanics this way meant that I could also then have a list of the mechanics that I want to implement, ready to work on when it comes to the creation of the game.

Moving forward, the Core aspect of the game was the bit that was easiest. Simply put, because of the nature of a game like this, and the fact that I was working from an existing IP, a lot of the story based aspects and content are already available. I had to make decisions on things like how many ships there would be, what the art style might be, and the different game paths the player could take. But the core centralized idea of the game was going to be based off that of Elite, so I wouldn’t be deviating too far from those ideas.

Next, I looked at the context the game would have within the concept. This sort of links in directly with the concept, because as I have previously mentioned, I already have a core concept that I was working off due to the fact I’m using an existing IP.  The context would be that of a large, sprawling galaxy where the player can earn their keep however they want. The concept would be that the player has a starting ship, and an amount of credits, and they have to increase that number of credits however they want. If other, “side quests” pop up and distract them from that, there would always be the aim of gaining credits and better things as their main goal.

And as already mentioned numerous time, there is the concept, which is the concept of starting out with a ship and a little bit of money, and essentially being told to "Explore and gain more money!".

Data collected from the questionnaire

The amount of questionnaires collected was 41, with a fair selection of both female and male respondents, as well as older respondents.

Question 1) What is your sex?

Majority of respondents were male, some female.

Male: 27

Female: 11

I’d rather not say: 3

Question 2) What is your age?

Largest amount were 36-45 (parents of friends)

16-25: 13

26-35: 4

36-45: 21

46-55: 3

56-65: 0

Question 3) Have you ever played a space simulator game?

Larger number hadn’t played a space simulator.

Yes: 18

No: 23

Question 4) Do you know what one is?

Many respondents had heard of one.

Yes: 15

No, but I’d like to know: 7

No, and I wouldn’t like to know: 1

Question 5) If you answered yes to question 3, did you enjoy it?

Many had enjoyed it.

Yes: 14

No: 4

Question 6) If you answered yes to the previous question, which aspects did you enjoy (Circle those that apply)

Exploration and Combat were very important, as well as Trade and Ship customisation.

Trade: 10

Exploration: 13

Combat: 16

Politics: 3

Production/Mining: 5

Ship customisation: 10

Micromanagement: 2

Question 7) Would you be interested in a sequel to the critically acclaimed game Elite?

Many people who had never played a Space Simulator game had never heard of it, or didn’t know what it was.

Yes: 21

No: 2

I don’t know what that is: 18

Question 8) What platform would you like to see it on the most?

Was nearly a tie between PC/Mac and the Tablet/phone devices.

PC/Mac: 22

Tablets/phone devices: 18

Consoles: 1

Questionnaire into the amount of interest in a Space Simulator game

Question 1) What is your sex?

a)      Male

b)      Female

c)      I’d rather not say

Question 2) What is your age?

a)      16-25

b)      26-35

c)      36-45

d)      46-55

e)      56-65

Question 3) Have you ever played a space simulator game?

a)      Yes (Jump to question 6)

b)      No (Jump to question 4)

Question 4) Do you know what one is?

a)      Yes

b)      No, but I’d like to know

c)      No, and I wouldn’t like to know

Question 5) If you answered yes to the previous question, did you enjoy it?

a)      Yes

b)      No

Question 6) If you answered yes to the previous question, which aspects did you enjoy? (Circle those that apply)

a)      Trade

b)      Exploration

c)      Combat

d)      Politics

e)      Production/mining

f)       Ship customisation

g)      Micromanagement

Question 7) Would you be interested in a sequel to the critically acclaimed game Elite?

a)      Yes

b)      No

c)      I don’t know what that is

Question 8) What platform would you like to see it on most?

a)      PC/Mac

b)      Tablets/phone devices

c)      Consoles

Thank you for taking the time to complete this questionnaire! It will help me greatly!

Research into the Space Trade Simulator genre, and Elite.

Elite (1984)

The IP I will be using for my game is Elite. It is regarded as one of the greatest games of all time, and is the father of the modern Space Trade Simulator genre; despite not being the first game of its type (Star Traveller came before it). The game itself is considered the greatest example of its game type, and is the game that almost every other space exploration game is measured against.

The original game, Elite, had the player start off in a Cobra MK III, with 100 credits and one main goal; Make money. They could do this in a number of ways, be it trade, pirating, bounty hunting or mining. The overall idea was to allow the player to essentially make their own way, with only one simple goal to keep them occupied. Because of the way that the game worked, the player could jump between the different methods of monetary gain, simply because of the fact that ship type is the only main difference (and weaponry)

The original game also had a couple of other key aspects, and despite these originally only being there due to technological constraints by the systems they were running on, has actually helped to enhance the gaming experience. The main aspect is that systems had only one star, which was orbited by a single planet, and that in turn was orbited by a single space station. Similarly, its wireframe nature became one of the defining things about the game. And one of the better parts of the game play and the universe was the fact that there was such a rich and deep galaxy that the player could explore; there would be alliances between planets, a stock market that could be affected or even cornered, police ships that monitor your every move and make sure you are kept in line (or try to), and dynamic instances of pirates, traders and other free-flowing things.

Braben and Bell, the creators of the game cite numerous science fiction sources as their inspiration, like Star Wars, the Hitchhikers Guide to the Galaxy, and the original BattleStar Galactica. Despite its numerous similarities to the tabletop Traveller, it was said by Braben that the original game wasn’t based on it.

Important things to remember if I am to create a sequel to this iconic game is the freeform aspect; limiting the player is something which needs to be avoided. Similarly, having a rich galaxy for the player to explore is one of the very key aspects of Elite, making sure that there is a diverse story lying beneath the surface.

The game is one that consumers would be wanting, for a couple of reasons. Recently, on Kickstarter, one of the original creators of the game, David Braben has put up the project of “Elite; Dangerous” this sequel, which is set to be made by him and his new team at Frontier development, reached its funding goal of £1,250,000, and surpassed it even by £250,000. The fact that there was so much interest and that it was funded shows that there is still a dedicated crowd among the fans of Space Sims.

Galaxy on Fire 2 (2012)

I also researched Galaxy on Fire 2, because it is a Space Sim which was created for tablet and phone use. Available on Android and iOS devices, it is a lighter version of the classic Space Trade Simulator genre, in that it is optimized more for portable devices. Being a successful release on the Android app store (4/5 of 4000 votes) it is a good example of the genre on phones and tablets.

The game uses an onscreen GUI, which controls the direction and angle that the ship flies at. This is different from other games of this type, most of which opt for a mouse follow system and controls to modify pitch/yaw. GoF2 opted for this system because it allowed a great deal of control over the ship, in a relatively small space (corners of the screen). This is, as I said, different from other Space Sim games, but being the only real Space Sim on android, it shows how good that specific approach is.

The game is more story driven than Elite, with various missions ushering the player in a certain direction. This is most likely due to the limitations technologically of phone platforms, meaning that larger, more in depth worlds and open ended exploration where too intensive for the system.

So to take from this game, I need to remember to make the control system intuitive or interesting, hopefully not in a way that is awkward to use or hinders game play. Similarly, I will want to take into account the limitations of the platform that the game is being developed for, because it uses a different processing architecture and doesn’t allow for as much to go on. This means that most likely I won’t be able to have a sprawling, open world for the player to explore, and that at best if I want to do that it will all have to be instance based (where it loads it star system by star system). Trade is in this game, but it isn’t the main focus; it is there because it is a key part of the genre, but the game is developed more for a combat/dogfight style of game play. I feel that a more trade centred game, more like Elite, would be something that the market would enjoy. I am not, however, suggesting taking out all of the combat elements. I simply mean to focus more on the trade element.

Target Audience

For this kind of game, audiences will tend to be older, more “nerdy” males. This is partly down to the huge number of Space Sim games that were released in the 70’s and 80’s, but also because there has been a decline in the number of Space Sim games since the 90’s, due to their open-endedness, complex controls and immense detail. Younger generations therefore will be less likely to be interested in a game like this, simply because they didn’t grow up with it to the same extent. I therefore suggest that the Target demographic is Males aged between 25 and 50. I also have questionnaire data to support this. I created the questionnaire, which I sent around to many of my friends, but also asked their parents to answer it, and many of my working colleges were asked as well, contained only a few simple questions. It asked; do you like space simulator games, your age, sex, what platform they would be most likely to play on (Android, iOS or PC, and if they would prefer it on phone or tablet) as well as what specific aspects you enjoyed about space sims, from a list (or, if their answer was no, they didn’t like space sims, what things they didn’t like about them). I collected about 40 different questionnaires, which a range of ages, from 18 upwards. Although a lot of the responses where that they did enjoy space simulator games, the amount of 35-45 year old men who answered yes to that question was quite high. This is important in seeing what platform they would be most likely to play it on as well. Next we need to see what the most common phone owned by people in that age range is, so that the platform can be properly targeted. One study showed that for Males aged between 18-54, it was more often cited that they owned android phones as opposed to iPhones. This suggests that an Android system would be better to develop for, when considering the target audience purely.

The target audience gave me a number of aspects that they particularly enjoyed about this particular genre, those being the combat, as it is exciting and fast paced, the trade as it fills a niche that other games don’t fill, as well as the exploration aspect, that a lot of games of this genre do quite well. Using these as the core 3 aspects I will work on when attempting to implement into my game should hopefully mean I please the largest amount of my target audience, and the data suggests that if I were to make the game for a phone system (which a lot of respondents said they would enjoy) that the Android system would be better received due to the skew in ownership.