Project Process Overview
This section is my final process reflection for the Semester 2 group project. The previous pages already show my technical development, testing evidence, and weekly development records, so this section does not repeat detailed testing tables or weekly diary entries. Instead, it reflects on my overall growth, contribution, and understanding of the Technical Designer role.
In this project, my main responsibility was technical design. This included interaction systems, item pickup, inventory UI, puzzle logic, camera-based observation, door progression, and player guidance. My goal was not only to complete individual features, but to connect these systems into a playable vertical slice.
Through this process, I gradually understood that the value of a Technical Designer is not simply to make features work. The role is to translate design ideas into gameplay systems that players can understand, use, and experience.
My Development Journey as a Technical Designer
At the beginning of the project, I mainly focused on whether features could function inside Unreal Engine 5. For example, I focused on whether items could be picked up, whether the UI could appear, whether a door could open, and whether the puzzle could trigger the correct result. At first, these seemed like purely technical problems.
However, as the project developed, I realized that many issues were not only technical issues, but also player experience issues.
A feature can technically work, but if the player does not know it exists, or does not understand how it connects to the next objective, then the feature is still incomplete from a design perspective.
Because of this, I started to think more from the player’s point of view.
| Early Thinking | Later Thinking |
| Does this feature work? | Can the player understand this feature? |
| Does the Blueprint trigger correctly? | Does the player know what they triggered? |
| Can the door open? | Does the player understand why the door opens? |
| Does the UI appear? | Does the UI help the player understand progress? |
| Does the UI appear? | Does the puzzle clearly connect to the game objective? |
This shift helped me understand the role of a Technical Designer more clearly. It is not only about logic implementation, but about building a bridge between technical systems and player experience.
Key Design Decisions I Made
Prioritising the Core Flow Instead of Adding More Features
There were many ideas that could have been expanded during the project, but I decided to prioritise the core gameplay flow:
Explore → Collect Items → Unlock New Area → Solve Puzzle
This helped me control the project scope. Instead of adding more complex features, it was more important to make sure the player could complete one clear, coherent, and playable experience.
Using UI to Support Player Understanding
While developing the inventory and interaction prompts, I realized that UI is not just decoration. It is an important tool for helping the player understand the game state.
If the player picks up an item but receives no clear feedback, they may not know whether the item is useful.
If the player approaches an interactable object without a prompt, they may miss important content.
If the player cannot see their current state, they may think the game is broken or unclear.
Because of this, I focused on making the UI clear, direct, and supportive of the gameplay flow rather than visually overcomplicated.
Connecting the Camera Mechanic to the Horror Atmosphere
The camera mechanic was not only added as another gameplay feature. It was designed to support the feeling of investigation and uncertainty. Through the camera, the player could see hidden information that was not visible normally, creating tension through contrast.
This decision helped me understand that technical mechanics can also shape atmosphere. A feature should be usable. It should also connect to the theme and experience of the game.
Connecting Separate Systems into One Experience
In the project, individual systems were easier to understand on their own. The more difficult part was connecting them together. Item pickup, puzzles, door locks, camera mechanics, and UI feedback all needed to work as part of the same experience.
This helped me understand that a vertical slice is not just a collection of features. It is a complete player experience. Each system should guide the player toward the next step rather than existing in isolation.
What Changed During Development
At the start of the project, my working method was more feature focused. I would first think about how to implement a function and then think about where it belonged in the experience.
Later, my thinking changed. I started asking:
What does this feature do for the player flow?
Does it support the intended game experience?
Can the player understand it without extra explanation?
This change influenced how I developed features later in the project. I no longer focused only on whether a Blueprint worked. I started to focus more on whether the features were clear, stable, and connected to other systems.
Through this project, I learned several important lessons
| What I Learned | My Understanding |
| Features need to support experience | Technical functionality is only the foundation. Player understanding is the key. |
| Scope control is important | Fewer complete features are better than many unfinished or disconnected features. |
| UI is part of player guidance | UI is not only visual design. It directly affects whether the player understands the game’s state |
| Systems need to connect | A successful individual feature does not automatically create a successful experience. |
| Documentation is part of the design process | Documentation is part of the design process |
| Technical Designers need two perspectives | They need to understand both technical implementation and player experience. |
If I worked on a similar project again, I would improve the following areas
1. Organizing Blueprint Structure Earlier
Some Blueprints became more complex as I experimented and added functions. During the final organization stage, I realized that clearer naming and structure from the beginning would have made debugging more efficient.
2. Checking Features from the Player’s Perspective Earlier
Some features were completed technically before I fully considered whether the player could understand them. In the future, I would check the player-facing clarity earlier, as soon as the feature becomes functional.
3. Documenting the Process Earlier
When preparing my portfolio, I realized that some early development evidence had not been saved clearly. In future projects, I would save screenshots, videos, and short notes immediately after completing important features.
4. Separating Essential Features from Optional Features More Clearly
In a team project, time and energy are limited. Next time, I would define earlier which features are essential for the vertical slice and which features are optional. This would reduce pressure later and help protect the quality of the core experience.
This project gave me a more practical understanding of the role of Technical Designer. At the beginning, I mainly focused on feature implementation. By the end of the project, I focused more on how each feature affected the player’s experience.
The biggest lesson I learned is that a mechanic needs to be functional, clear, stable, and connected to the overall flow. Item pickup, UI prompts, puzzle logic, door progression, and camera mechanics are not isolated systems. Together, they determine whether the player can understand and complete the gameplay experience.