Prototyping

Control the sun

I made a prototype for this game using Lego. The prototype demonstrates the sun, in the background, moving across the sky. The more rotations the sun does the bigger the buildings (blocks on green platform) get, and more buildings get added, to represent the civilisation growing. The seasons are also represented on the bottom left; as the prototype progresses it goes through spring, summer and ends in autumn. Finally, the temperature guage is on the right and increases as the sun spends more time in the sky.

The prototype helped me to visualise the game better and see it in action. It also helped me explain it to other people. However, this prototype, along with discussing it with others, also made me realise that the game wasn't very engaging and had little risk, so I decided not to pursue this game.

time travelling trading board game

I utilised paper, Lego and other board game pieces to make a playable prototype for this game. I had three times (big circles with pieces in) that could be travelled to, for the cost of one piece, and each time had two butterfly effect slots (smaller circles above times) that, when both are filled with a counter, break the timeline and end the game. Players had to place a counter in one of these slots whenever they bought or sold three or more pieces at once. Having only two of these slots always gave player one an advantage, as they could buy three pieces in the starting time and then future players could only buy up to two, otherwise they would break the timeline.

The black and white pieces would be randomly distributed across the times at the start of the game. The prices, however, were always constant: in the left time black pieces were worth zero and white pieces were worth ten; in the middle time both were worth five; in the right time black pieces were worth ten and white pieces were worth zero. The price was the same for buying and selling pieces.

Each player, represented by the Lego blocks to keep track of the time they were in, could take two actions each turn. These actions were buy/sell in the time they were in and change time; they could be taken in any order but players could only do each action once per turn. For example, a player could not buy in one time, jump to another and sell in the same turn.

The result was a playable board game that, during playtesting, most felt was fun to play and allowed plenty of choices during a turn. One person explained that it would be interesting to have the timeline split into another timeline, instead of simply ending the game, and this could be achieved by unfolding a piece of the board to reveal a new timeline. Others stated that having three smaller circles, rather than two, before breaking the timeline would allow for more freedom during play as they often felt restricted when there was a counter there and they would end the game if they bought too many pieces. However, they all agreed that the prototype showed that the game had potential.

When observing play, I noticed that the game always favoured the first player; player two only ever stood a chance whenever player one made a mistake. I also picked up on the fact that, whilst choice was present, there was usually a clear decision each turn that was always better than other decisions. This may improve as more resources, especially time specific ones, are added, as the prototype only had two. Eventually, every playtest resulted in a sorting game of placing all the black pieces on the right and all the white pieces on the left. This felt repetitive and monotonous by the end; although, it may be possible to fix this with a variable stock market for each time, rather than pieces always having a fixed rate.

I eventually chose not to go through with this game idea as it was not as popular as my other ideas, and we were limited to three. However, I intend to take it further as a personal project after university.

The above image shows how players kept track of their money during the game. The person with the highest number when the game ended won. Each player started with 100 so that they could buy pieces freely during the prototype.

spring balance game

I created this prototype in Pygame, as I have a background in it and felt most comfortable using the software to quickly develop 2D games. The prototype, which was playable, has the player play as a falling square that has to go through holes between platforms to get to the bottom. I chose not to create the circle, which the player would be pulled into the centre of to win, and had the player fall straight down through the flat platforms because I felt that it still tested the core mechanics of the game. The unique twist of the game, that being that when the player touched a platform they would stay there until the circle spun the other way to launch the player up, was still present; in the prototype, the player square was thrust upwards whenever the bar at the top emptied all the way. The bar at the top constantly reset, to represent the constant spinning back and forth of the circle in the actual game.

The prototype felt fun to play, especially having to navigate the platforms quickly during freefall, and required a lot of forward thinking. Needing a lot of forward thinking was something I did not anticipate and, in the full game, I may need to implement a ten second intro where the player has a chance to examine the map to form a path in their mind, before anything starts moving. I found that when the player was stuck to a platform, it felt very restricting being unable to move; this could be fixed by allowing the player to move on a platform, but at a much slower rate than if they were in the air. Finally, I enjoyed the mechanic of being thrust upwards at predictable points.

When playtesting the game, I received similar feedback. Most felt that they were very restricted whenever they hit a platform and described it as frustrating; however, some said that they used the time to plan ahead. During freefall some players felt it was too slow, whilst others felt stressed as well as saying that they did not have much control over the game, and one player suggested adjustable speeds. There are multiple ways that a changing fall speed could be implemented: the first is through a selection of difficulty options that have faster speeds for higher difficulties; the second is that the player could be accelerating downwards, so as they freefall for longer then their speed slowly increases, and this would challenge players who are good at the game whilst not affecting players who are not; the final solution is to give the player a rechargeable boost that dashes them downwards a little whenever it is activated, allowing the player to have more control over their movement as well as giving them another simple but effective input. However, this game was most successful during my early playtesting, as everyone enjoyed the core mechanic, and so I plan to take it forward as one of my main three games.

propulsion game

My final prototype in this phase was for the propulsion game where the player controls a rocket and goes up and down into space collecting fuel, and avoiding asteroids or space debris. The prototype only shows the main mechanic of the player pressing a button to go up, by using up fuel, and automatically falling when they are not going up. This creates a balancing game where the player must constantly be pressing the screen to go up and letting go to go down, so that they can collect fuel coming towards them. In the prototype, the player's fuel is represented by the bar at the top and the white squares going across horizontally are fuel pickups.

The prototype only demonstrates this main mechanic and does not show other mechanics, such as the increasing high score or upgrade system that I intend for the game. However, if I choose to go with this as my final game then I will be regularly creating prototypes to test each of these.

From this prototype I found that the player's movement is erratic with a constant velocity being added whenever the player chooses to interact or not; for example if they press then the square always goes up 5 pixels every second, and if they do not then it always goes down 5 pixels every second. To fix this I could instead add an upwards acceleration, whenever the player presses, so that the velocity upwards slowly increases to 5 pixels per second, and I could do the same for the downwards movement. This would make playing less frantic, but also it is more scientifically accurate. I could also implement a feature where the downwards acceleration reduces as the player gets higher, due to the pull of the Earth's gravity getting weaker.

In the prototype I also found that the fuel pickups move too fast and that predicting where they would come from was difficult. On a wider screen this would be easier, as the player could see objects coming from far away, however, I intend to make this game for mobile devices. Therefore, I will need to implement signals that appear on the side of the screen and can inform the player that an object is X metres away.