top of page

 - PlayThing - 

Tools:

81nwobjayd181.webp
Miro_logo.png
Octicons-mark-github.svg.png

Duration:
8 months

Team Size:
6

PlayThingProject_edited.png

Horror

Single Player

Puzzle

Unity

Project Description:

A single-player horror game based on using sound cues to guide the player on a journey to escape an abandoned toy factory. The game consists of three sections, each increasing in difficulty with different threats alongside assisting the player with item collectibles.

My Role:
I was designated as the primary programmer of the project though the group collaborated in many aspects with game design being discussed amongst us all. I considered design decisions with the implementation process in mind and created mechanics that aligned both with our game pillars as well as an intuitive experience 

 Design Process 

My priority during this design process was to ensure our mechanics were both relevant to the design of the project and practical when implementing them into Unity. Taking in factors such as the scope, game pillars, and my own programming ability, I would inform the group about what we could achieve and how design decisions would go about being scripted. This allowed me to gain experience in evaluating my own and others' design choices while also fulfilling the transition from concept to in-engine mechanics.

Plaything Lever.png

​Lever from section 1 being reused for final objective in section 3.

Plaything Wires.png
PlaythingMechanicsTaught.jpg

Elements Taught on Each Level

Being involved with the design and programming process, a big aspect I prioritized was keeping the mechanics intuitive as this project is a short experience and players would not have long to learn complex systems. When creating these mechanics, I made sure to use repetition and signifiers which allowed for a very straightforward understanding of how they worked. This not only kept consistency for the players understanding but also played a large role in saving development time as we were able to reuse existing sciprts/mechanics.

 Implementing Key Systems 

Below are a few of the mechanics/systems that I played a part in designing conceptually and my implementation of them. Highlighting both what each one is (hover over image) and why they were added or designed a certain way.

PLaythingWalls.PNG

What: Two variations of walls that close in when the player is between them. One that fully closes to kill the player (red) and another that only partially closes (yellow). 

​

Closable Walls

Why: This obstacle was added to the game to challenge the player with urgency and sudden changes in a tense setting. The visual signifiers of caution tape and light along with the sound cue of the walls moving give the player an understanding of how these obstacles operate. The mechanic is also present in the final section, allowing the player to switch it to their advantage when evading the enemy AI as it closes off the path behind them. Additionally, this mechanic fits the contextual setting of a toy factory and the game's 'maze' structure. 

image.png

Final Objective

What: There are two wires(red & blue) spread throughout the final section of the game with one end attached to the final door's lights and the other attached to a corresponding lever in the maze. Once both levers are activated, the final door is open to escape through.

Why: This objective is meant to be the final challenge the player must complete, using what they've learned. The wires are meant to encourage the player's exploration of the section. The color of the wires, along with their corresponding lever handle and light, are used to clarify the completion of the task by keeping a consistent signifier that they recognize. Additionally, the lever mechanic is featured earlier in the game so the player will already be familiar with how it works.

Playthingbattery.PNG

What: This system gives the player a flashlight that dims over time, along with batteries that can be picked up to boost the flashlight's radius, distance, and intensity back up. 

Battery / Flashlight System

Why: This system was first made as it was too dark for player navigation, though it took away from the player's need to use sound cues. To balance this, the flashlight loses its strength over time to limits its benefits while still assisting the player. Additionally, the battery collectibles encourage the player to explore the level and strategize when to take advantage of the temporary benefits.

PlaythingElevator.PNG

What: An elevator takes the player to the basement (final section). This triggers a sequence where the final section is temporarily visible just before the basement lights all shut-off.

Elevator Sequence

Why: The main focus of this sequence was to act as a transition point that:

  • Gives the player a moment of space

  • Supports the context of the setting

  • Sets up the final section in a tense and chilling way, letting the player momentarily spot the enemy threat and be left in the darkness.

PlaythingLevel.PNG

What: Levers are interacted with to get to the next section in the game and used as the activation for the final objective.  

Lever Interaction

Why: This mechanic was chosen to be the foundation of the game's interaction, allowing for a straightforward and relevant action for the player to become familiar with. Though a simple action, this gives the player another level of intentional action to progress through the game and a goal to reach during the final objective.

PlaythingCheckpoint.PNG

What: This system is made up of checkpoints that activate a light when triggered. If the player dies, they are respawned at the most recent checkpoint triggered.

Checkpoint System

Why: This system was important to allow the player to fail without giving a major consequence, allowing them to keep a consistent sense of progression. Additionally, the light activating when triggered contrasts with the dark environment, giving the player a safe moment of pause before continuing.

 Playtesting & Telemetry 

Telemetry Hooks
In preparation for playtest sessions, telemetry hooks were added to the project to track things that would be relevant to our survey questions. Things such as the player's position, when they sprinted vs walked, a button to press when they felt scared, which batteries were collected, and so on. With this information tracked and collected into Excel tables, it was very useful to see playtest results that were quantified. Having numbers associated with our findings, we could determine if our design choices were successful or not and if any changes we made between playtests were successful enough to be claimed as such.

FeltScaredChart.png
FeltScared.png

Heatmap tracking location of player when sprinting. Highlighting intended urgency caused within closable walls

Players informed to press button when scared (telemetry hook). Shows intended increase of fear between level 1 and 2

Playtest Methodology

image (13).png

Consent​

Form

Survey

Before

Playtest

Survey 

After

Survey Questions
A lot of time was spent refining the questions that were asked to playtesters and the methodology used. Appreciation testing was used as I was able to observe playtesters to see their reactions and experience with the game, where they succeeded and where they struggled, and any major issues that could be spotted during the playtest. By staying silent and asking certain questions only before and after the playtest, I could get unbiased results and see how the game would be played as if it were a real player at home.
 

 

 

 

 

​

 

For the questions, the way they were worded and the time at which they were asked were important to gain relevant information. Questions asked before the playtest regarded the player's demographic/experience while questions asked after the playtests were focused on the tester's thoughts on what they experienced. By structuring it this way, we could understand the results of the playtest based on who the testers were in relation to their experience. Additionally, questions were worded in a way that invited clarification and explanation:

  • Avoiding yes or no questions

  • Using a 1-7 rating scale (clear neutral point)

  • Keeping questions unbiased  

  • Related to telemetry hooks
    ​

Before Playtest

BeforePlaytestQuestions.PNG

After Playtest

AfterPlaytest Question.PNG

Results

image (18).png
image.png

With these steps, I can know how familiar the playtesters are with this genre and type of experience, how everyone responded to each relevant mechanic, and finally analyze those responses to determine the outcome of the playtest. In this example, I now understand that the majority of testers found the battery pick-ups useful as (17/25) playtesters answered between 5 and 7 for that question.

 Personal Takeaways 

  • How to design mechanics with this awareness of the process it takes to create within other disciplines such as programming, level design, and system design.

​

​

  • How important it is to intentionally implement every mechanic with a purpose rather than focusing on quantity

​

​

  • Gained experience in working with others for a longer amount of time and how to go about collaborating in a focused and safe manner.

bottom of page