Month: January 2022

12 Second Unity Physics Game Prototype (Collaboration w/ Shijie Song)

Aims

• To produce a game that would never exceed 12 seconds, win or lose
• To build a simple control scheme due to the short duration of the game
• For players to feel satisfied to continuously attempt to complete the game despite failure

Development Process

1. Explore and draw up concepts: “Race Against Time”, “12 Seconds to Poop”
2. Outline the different components necessary to build this game: a UI Start Menu; including instructions, a Timer, the Rotating Mechanism for the Maze
3. Use C# script to build components, e.g. for aesthetics – fading start up screen
4. Illustrate and import maze from Photoshop
5. Add necessary physics components to game objects, e.g. Gravity Component

Feedback

• The ball would get stuck in certain pathways of the maze
• Players had difficulty completing the game on their first go, constant trial and error between different maze routes made the game feel tedious
• Players appreciated the concept of the game, finding it both clever and funny

Reflection

A few bugs had arisen in the prototype, including the ball getting stuck or transported between walls. Revamping the rigid body components of the maze should amend these issues. Building a captivating game that only lasts for 12 seconds was difficult.

Avoid and Collect Game Prototype

Aims

• Create an endless running game that gets more difficult over time
• To give the player both health and scoring components, implementing an element of competitiveness
• To randomly generate different patterns of obstacles and collectibles, to avoid and collect respectively

Development Process

1. Contemplate the mechanics and different themes for this prototype, this includes finding Sprites for Game Objects
2. Code Player Control, Obstacles and Collectibles to meet minimum requirements of the brief
3. Create a Spawner game object via a C# script that generates obstacles to spawn in random patterns, and spawn progressively faster over time
4. Implement a light health and scoring system to make the game competitive for players
5. Polish game: by adding particle systems for aesthetic effect, and generate a script that destroys game objects once they leave the screen’s field of view, to prevent lag

Feedback

• Players felt that the game should start a lot more difficult than it does, whereas others felt it should get harder a lot faster than the code dictates it to
• Some players felt that it was difficult to see certain objects, as most of the game objects are the colour brown
• Players enjoyed competing to obtain the highest score

Reflection

The endless runner genre was a big inspiration for this game, implementing a progressively difficult obstacle system was a key aim that I felt was met. Although players felt the difficulty could be more challenging at times, the game would eventually get to the difficulty they desired. Implementing a difficulty system via a UI Menu Screen, offering “Easy, Medium, Hard” would address this, tailoring the game to the skill level of each player.

Ideally, original sprites would have been used to make the space feel similar and vibrant, however, as this was a prototype, all sprites were imported from the internet.

Twine Game Prototype

Aims

• To compose an immersive/descriptive script, that would influence players to imagine the world and characters, independently from player to player
• To develop some degree of player agency, providing players the opportunity to navigate freely, preventing linearity
• To build a game that reacts to a player’s actions, e.g. certain actions reveal new dialogues previously inaccessible to the player

Development Process

1. Build characters and script: includes personalities, relations and their purpose in the game
2. Think of the end game, accusing one from a roster of multiple suspects. This limits scope when developing scenes
3. String pathways together – includes alternating pathways after player’s are given a choice. Blocking out previously visited scenes where applicable
4. Build clues and evidence system – difficulty to generate an inventory using Twine’s built-in coding engine

Feedback

• Play testers wished for less linear dialogue paths during conversations
• Testers believed that including music and sounds to the game would benefit player immersion
• Most play testers enjoyed the game dialogue and were captivated by the storyline, discussing between themselves to ensure they accused the right suspect

Reflection

This prototype met my intentions for player immersion and agency. When spectating during playtests, players tend to pick different paths to one another. The script was humorous and easy to follow, during conversations players would immediately have their own opinions on each suspect and react to what they had to say.

For future updates, giving players multiple text prompts when replying to NPCs allows for greater control, and less like they are reading a book. Solving the inventory issues will add an extra element to the game, where players are able to recap their discoveries as the game can be quite lengthy. 

The game title “Crime Scene” acted as a suffice indicator to what players can expect. This game was always intended to be solely text-based so that player imagination illustrates the narrative, so personally, the inclusion of music or sounds is not necessary.

Escape Room Puzzle Prototype (Collaboration w/ Abhimanyu Chattopadhyay)

Aims

• For players to use multiple physical spaces during the game
• For players to easily locate and solve tasks with little or no guidance
• To create a captivating story, via an insight into a fictitious character, retracing their steps over the course of the Escape Room

Development Process

1. Discuss different narrative approaches to determine the plot for this Escape Room, agreeing on the Heist genre
2. Exploring various types of tasks, e.g. shading, tracing, jigsaw 
3. Create the main game item, a journal, using coffee to make it look authentic, in order to produce a compelling story element for the game
4. Plan the flow of tasks, and how they are incorporated into the journal

Feedback

• Players appreciate the journal’s appearance, describing it as authentic, as it helps set the scene for the Escape Room’s narrative and makes for a more interactive experience
• Play testers had difficulty locating where and how many tasks could be found in the contents of the journal, often having to be directed where to look
• Once some players had realised how to identify the tasks, they would look for more despite there being no similar tasks
• Some players were confused once they had to move location once all journal tasks had been completed, this was usually due to not having read through the journal thoroughly

Reflection

This prototype included a gripping narrative along with a set of challenging cryptic tasks, meeting the development objectives. However, players had difficulty finding the tasks. Implementing indicators such as shading in some words on the same page as the journal shading task helped minimise this. An indication to the number of tasks that could be found in the journal would also help with any confusion for players.

Due to the nature of certain tasks, such as cutting out certain objects in the journal, playtesting this prototype was made tedious as extra journal copies had to be made for each trial.

Race Game without Dice Prototype (Collaboration w/ Jia Liang Cai)

Aims

• To give players the freedom to choose how much they want to move their piece by, along with consequences to prevent players exaggerating 
• Implement an element of strategy for when players compete against one another
• To balance the number of moves made my players and the length of the race, ensuring the game is not drawn-out nor short-lived

Development Process

1. Contemplate and explore different ideas to replace dice found in typical board games
2. Upon considering different themes, we agreed to base the prototype on Formula 1
3. Determine game mechanics: shortest and fastest routes, how players choose to move their player piece
4. Outline a consequential tyre health system, finetuning this with playtesting
5. Design board and player pieces: finding 3D models online in order to 3D print a set of blue and red pieces

Feedback

• Players preferred having a single track between corners rather than two separate paths, keeping corners separate, introducing a slip stream feature; inspired by Flamme Rouge
• Players advised that instead of each player taking turns to move, a count of three allows both players to reveal their desired move at the same time, making movement competitive and random
• Players preferred using physical pieces to represent movement rather than using fingers when counting down from three
• Various tweaks to the health system advised by play testers allowed for smoother game flow
• When play testing, one lap around the track felt too short, so an increase to two laps per game seems beneficial for enjoyment

Reflection

Player feedback has greatly benefited this prototype, for example, the introduction of slip stream causes players to think before they move, considering where their opponent is on the board, emphasising the desired element of strategy from my own personal objectives. Clear instructions, in text form, would allow easier understanding of game rules and mechanics for players, rather than verbally explaining to play testers.

No Components Game Prototype

Aims

• To create a game that was both fun and not complicated for players to understand
• To implement a player vs player aspect to my concepts; similar to existing No Components Games
• To achieve a competitive nature between players, to ensure investment from play testers

Development Process

1. Research into existing No Components Games, e.g. Rock Paper Scissors, Viral Pointing game, Eye Spy, Charades, Hide and Seek, Arm Wrestling. Drawing inspiration to produce an original concept
2. Playtest original rules with an opponent, taking feedback on board to design a new set of rules
3. Playtest new rules with an opponent to experience game flow and duration

Feedback

• Players felt the original rules made the game too short, play testers advised giving players the opportunity to regain a lost limb
• Players were confused by how to mirror their opponent using a limb they have lost
• Confusion as to who was attacking or defending each round

Reflection

This game was enjoyable for players, both players and spectators were invested and would cheer when a limb was guessed correctly. Regarding how to mirror an opponent when you have lost your own limb, implementing a pointing feature resolved this, as using eyes was not accurate enough. Also advising the attacker to count down from three prevented any confusion between rounds. 

Ideas to make this game for three players or more had been discussed, with a clear vision for future development and interesting concepts.