First Playtest
In the first playtest, the prototype included the following features:
Player movement
Item pickup and drop
Jumping
Item pickup
Item drop
Climbing mechanic
In the first playtest, the basic movement, jumping, pickup, and drop systems were functional. However, the test revealed two main issues.
The first issue was that the climbing mechanic still needed refinement. Sometimes the player could not enter the climbing state correctly when approaching a wall. This suggested that the wall detection and climbing trigger conditions needed further improvement. The climbing mechanic also felt slightly complex for players, as they were not always sure when they could climb or whether they had entered the climbing state.
The first issue was that the climbing mechanic still needed refinement. Sometimes the player could not enter the climbing state correctly when approaching a wall. This suggested that the wall detection and climbing trigger conditions needed further improvement. The climbing mechanic also felt slightly complex for players, as they were not always sure when they could climb or whether they had entered the climbing state.
This test helped me understand that a feature working technically does not automatically mean the player understands it. In later development, I needed to continue refining the climbing trigger logic and connect item pickup more clearly with door unlocking and level progression, so that collecting items felt like a necessary part of the playable flow rather than an isolated action.
Second Playtest
Features Added
By the second playtest, the prototype included more core systems, such as:
Player movement and jumping
Item pickup and drop
Inventory UI
Climbing mechanic
Final 4×4 puzzle
Collectible objects
Level progression flow
Before analyzing the second playtest feedback, it is important to clarify my responsibility in this part of the project. The “cameras” mentioned in the feedback referred to three collectible objects placed in the level. The final models for these objects were intended to be produced by the art-focused team members, but they were not completed at that testing stage. As a temporary solution, I used default Unreal Engine models as placeholders so the interaction, pickup, and collection systems could still be tested.
Therefore, when players said they were not sure what the cameras were for, part of the issue came from the unclear visual identity of the placeholder objects, not only from the technical implementation. My responsibility was to make sure these objects could be detected, collected, counted, and connected to the door-unlocking flow. The final modelling and visual identity of these objects were not my responsibility.
Similarly, I was not solely responsible for the overall game mechanic design or level objective design. My role was to translate the team’s ideas into functional gameplay systems and give technical suggestions during implementation. Therefore, the feedback about players not understanding why they were collecting objects showed that overall objective communication needed improvement. I later responded to this by adding a UI prompt near the locked door.
In the second playtest, players responded positively to the atmosphere, sound, level route, climbing idea, and final puzzle. Several players mentioned the ambient sound, level design, wall-climbing mechanics, and puzzle surprise as enjoyable parts of the experience. This suggested that the project was beginning to feel like a connected playable sequence rather than a collection of separate mechanics.
However, the feedback also revealed several issues that needed improvement.
The first issue was that the climbing mechanic still needed refinement. Several players mentioned that the climbing mechanic needed more polish or felt finicky. This showed that although the climbing system was functional, the player experience was not always stable or clear.
The second issue was that the item collection objective needed clearer communication. Some players were not sure why they were collecting objects throughout the level, and some were not sure why they needed to complete the puzzle at the end. This showed that the connection between item collection, door unlocking, and the final puzzle needed clearer guidance.
The third issue was that the visual identity of the collectible objects was not clear enough. Some players were unsure what the camera-like objects were for. Since the final models had not been completed at that stage, the placeholder models allowed the system to be tested functionally, but they could not fully communicate the purpose or identity of the objects.
The fourth issue was that the transition into the final puzzle could be smoother. Players enjoyed the final puzzle as a surprise and a change of pace, but some feedback suggested that the puzzle needed a smoother transition. This showed that the final puzzle worked as a different type of interaction, but the move from traversal into puzzle-solving needed clearer pacing.
After the second playtest, I identified several improvement directions. First, the climbing system needed clearer trigger conditions and stronger state feedback, so players could understand when they could climb and when they had entered the climbing state.
Second, the item collection objective needed clearer communication. In response to feedback that players were unsure why they were collecting objects, I later added a UI prompt near the locked door explaining that the player needed to collect three objects in the level before the door could be unlocked. This directly connected item pickup with the door-unlocking objective.
Finally, the visual identity of the collectible objects needed to be improved through final art assets. While the models were unfinished, I used placeholder models to keep the system testable. However, the feedback showed that the final object models and visual identity were also important for helping players understand the mechanic.
Third Playtest
By the third playtest, I had responded to the earlier issue where players were unsure why they were collecting objects. I added a UI prompt near the locked door. When the player approaches the locked door, the UI explains that they need to collect three objects in the level before the door can be unlocked.
The purpose of this adjustment was to connect item collection more directly with the door-unlocking objective. The player no longer only sees collectible objects; they can also understand how those objects relate to level progression.
In addition, because players might not clearly understand how to use the climbing mechanic, I added a text sign near the climbable area. This sign explains how the player should trigger and use climbing, giving them immediate guidance at the point where the mechanic becomes necessary instead of expecting them to guess the controls.
In the third playtest, Ross gave important feedback on the climbing mechanic. He suggested adding a climbing animation when the player enters the climbing state. This would help players understand that they have entered climbing mode and would also make the experience feel more immersive.
This feedback showed that the climbing issue was not only technical. Even if the system allows the player to enter the climbing state, the player may still feel uncertain if there is no animation, pose change, or clear visual feedback. Although I added a text sign to explain how climbing works, Ross’s feedback made it clear that text guidance alone is not enough. The player also needs animation and visual feedback to feel the state change.
Based on the third playtest feedback, if the project continued, I would priorities adding clearer state feedback to the climbing system, such as:
Keeping the text sign near the climbable area to explain the controls
Adding an animation or pose change when entering the climbing state
Adding character MOVEMENT feedback during climbing
Adding feedback when leaving the climbing state
Adding a simple UI or sound cue if needed
This feedback helped me further understand that special traversal mechanics need more than technical functionality. They also need text guidance, animation, and visual feedback so the player can understand state changes. For technical design, gameplay logic and player communication are equally important.
Development Testing & Problem Solving
This was important because a feature can work technically but still fail as a player experience. For example, the item collection system worked, but players still needed clearer guidance about why they were collecting objects and how this connected to door unlocking. Therefore, my testing focused on both functionality and communication.
In addition to formal playtesting, I also carried out regular development testing throughout the production process. These tests mainly happened during Blueprint creation, feature integration, and version updates. The purpose was to check the stability of each system and how well it connected with other gameplay systems.
These development tests were different from formal playtests. Formal playtests focused more on player feedback and player understanding, while development testing focused on functionality, logic, state updates, and conflicts between connected systems.
In this section, I recorded the actual problems I encountered during development and explained how I tested, adjusted, and reflected on them. This process shows my critical thinking: when a feature broke or behaved incorrectly, I needed to identify the source of the issue, such as input, collision, UI, state logic, item data, level versions, or team workflow.