Initial Team Structure
At the beginning of the project, our team was organized around discipline-based roles. The initial role allocation placed me, as MD / Mechanics Designer. Erik was assigned as TA / Technical Artist, Kamilla as EA / Environment Artist, and Jeremy as WD / World Designer.
This initial structure gave the team a starting point for responsibilities, but it was not completely fixed. The module guidance explained that roles were discipline-based rather than strict job titles, allowing teams to adjust tasks depending on practical project needs.
Actual Team Responsibilities
Although the initial role chart showed our discipline directions, the actual responsibilities became more specific during development.
| Team Member | Initial Role | Actual Main Responsibility |
| Harry / Wang Yuheng | Harry / Wang Yuheng | Gameplay systems, Blueprint implementation, interaction logic, item systems, climbing, door unlocking, puzzle system, UI feedback, GitHub support, packaging support |
The assessment task was not to copy another student’s GDD exactly. The project was about taking a GDD as a starting point and translating it into a playable vertical slice, while making creative and practical decisions during production. The module introduction described this as moving the GDD into production and translating it into outcomes that reflect our roles.
Role Adjustment: From Mechanics Designer to Technical Designer
Early production role allocation slide from the team’s initial vertical slice pitch presentation, outlining each member’s primary responsibilities during pre-production. My role as Technical Designer focused on creating the gameplay loop and implementing gameplay systems in Unreal Engine.
Although my initial assigned role was Mechanics Designer, my practical role changed during development. After team discussion and project needs assessment, it became clear that the team needed stronger Unreal Engine 5 implementation support. Because I was more familiar with Blueprint logic, gameplay systems, and technical problem-solving, I gradually took on the role of Technical Designer / Gameplay Interaction Designer.
This role adjustment was not a role mismatch. It was a response to the real needs of the project. A vertical slice needs working systems, not only design ideas. Therefore, I became responsible for building the functional systems that allowed the team’s ideas to become playable.
I still contributed to mechanic discussions, but most of my actual work focused on implementation: movement, jumping, interaction, pickup and drop, inventory UI, item feedback, locked-door progression, climbing, puzzle interaction, technical troubleshooting, and final build support.
Game Mechanics Responsibility
Although my initial assigned role was MD / Mechanics Designer, the game mechanics were not designed by me alone. The overall mechanic direction came from the original GDD and team discussion. Team members proposed gameplay elements such as item collection, door unlocking, climbing routes, and the final puzzle.
My main contribution was to break these mechanic ideas down into specific, playable, and testable system rules, then implement them inside Unreal Engine 5. For example, when the team proposed that the player should collect objects to unlock a door, I needed to define how many objects were required, how pickup was triggered, how item state was stored, how the door checked the condition, how UI communicated the objective, and how this mechanic connected to the next part of the flow.
Therefore, I am not claiming that I independently owned the entire game mechanic design. Instead, as the initial Mechanics Designer and later practical Technical Designer / Gameplay Interaction Designer, my responsibility was to translate mechanic ideas into functional systems, refine their rules, give playability suggestions, and implement them in the playable build.
Responsibility Breakdown
| Area | Responsibility |
| Overall mechanic direction | Original GDD + team discussion |
| Mechanic idea selection | Team discussion, with my input as MD |
| Rule breakdown | Mainly my responsibility |
| Technical implementation | My responsibility |
| Playability suggestions | My responsibility from a technical design perspective |
| Connection to level route | Other team member’s level design + my gameplay systems |
| Visual presentation | Other team members depending on asset, menu, sound, or visual task |
Key point
The mechanic direction was the result of team discussion. My main responsibility was to break down, evaluate, and implement those mechanic requirements as playable UE5 systems.
A major part of my team contribution was translating broad ideas into specific gameplay systems. Often, the team would describe what they wanted the player to experience, but the actual rules, logic, conditions, feedback, and Blueprint structure needed to be worked out through technical design.
| Team Idea / Requirement | My Technical Translation |
| The player needs basic traversal | Implemented movement and jumping |
| The player needs to collect objects | Built interactable items, pickup prompts, pickup logic, and item data transfer |
| The player needs item management | Built drop logic, inventory slots, and UI updates |
| Collected objects should unlock a door | Built object count checking, door unlock logic, and locked-door UI prompt |
| The player should move on walls | Tested wall-walking ideas, then implemented a practical climbing system |
| The team wanted a final puzzle | Designed the puzzle rules and implemented the full puzzle interaction system |
| Players might not understand objectives | Added UI guidance, locked-door prompt, and climbing instruction sign |
| The building needed to be submitted | Helped with packaging, compiling, GitHub workflow, and technical troubleshooting |
When the team proposed that the player should be able to move on walls, the early idea included walking on the ceiling and creating an upside-down effect. I attempted to test this direction, but the result was not stable or readable enough. From a technical and playability perspective, I suggested simplifying the idea into a more controlled climbing system on specific wall areas.
I also made an early core gameplay flow diagram to show how movement, item collection, door unlocking, climbing, and puzzle-solving could connect into one playable route. This helped the team think about the project as a sequence of player actions rather than only as a physical level space.
The final puzzle came from team discussion. The team wanted a puzzle mechanic at the end of the playable route, but the specific rules and technical structure were not already defined.
For this part, I designed and implemented the puzzle rules, UI interaction, input mode switching, mouse cursor control, and the logic for entering and exiting the puzzle interface. This meant the puzzle became more than a visual element. It became an actual playable interaction connected to the rest of the level flow.
This was one of the clearest examples of my practical role. The team gave a broad requirement, and I translated it into a working system that players could use.
One of the main challenges during development was that not all team members had technical implementation experience. This meant that some ideas were described in simple terms, such as “add a door”, “let the player walk on walls”, or “add a puzzle”. However, each of these ideas requires many hidden technical decisions.
For example, adding a door requires unlock conditions, item state checking, UI feedback, locked and unlocked states, animation or movement logic, and testing. Adding a puzzle requires rules, input mode switching, UI interaction, completion checking, and a transition back to gameplay.
There were also moments where I had to explain technical limitations. For example, the team discussed adding water effects after the puzzle was completed. From my perspective, adding too many overlapping systems could increase the risk of bugs and make the building less stable. Another example was the idea of locking the camera into a top-down view when the player entered the puzzle room. I evaluated this and realized it could conflict with the puzzle interaction and camera/input logic.
There were also disagreements within the team about design direction and priorities. I do not see this as one individual’s fault, but as a workflow issue. When feature ownership, mechanic rules, and decision-making responsibilities are not clearly defined early enough, the technical implementation stage becomes more difficult and unstable.
This taught me that future team projects need clearer separation between mechanic ownership and technical implementation. Before a mechanic enters full production, the team should define its purpose, owner, rules, player feedback, scope, and testing criteria.
Besides implementing gameplay systems, I also supported the team with technical workflow issues. I helped team members understand how to use GitHub and explained that multiple people should avoid changing the same object or Blueprint at the same time, because this could create merge conflicts or broken project files.
I also helped with Unreal Engine Blueprint-related problems when other team members were stuck. This included explaining character Blueprint logic, correcting issues in the start and end menu Blueprints, checking remaining UI issues, and supporting the final packaging and build process when the team had difficulty completing it.
These tasks were not always visible as final gameplay features, but they were important for keeping the project working. My contribution was not only making systems for the player, but also helping the team manage technical problems during development.
During the final stage of production, we had a clear workflow issue around environment asset integration and level versions. Because the assets were delivered later than expected the time available for technical integration and testing was significantly reduced.
At the same time, the environment assets were not added directly to the existing working level. Instead, a new level was created based on the existing route. This happened because there were different opinions within the team about the quality of the previous level modelling, and the environment art and level design sides did not fully agree on the final integration approach.
However, this new level was not fully communicated to the whole team before it was created. Because it appeared very late in production, it introduced additional technical issues. After comparing the two-level versions, I found several technical issues in the new environment level, including the loss of pickup and door-unlocking functionality, missing item highlight feedback, and one replaced prop not displaying correctly during gameplay.
These issues arose the day before the test started. At that point, there was not enough time for me to fully check, fix, and re-adapt all existing gameplay systems to the new level structure. I reported these issues to the team as soon as I found them and explained that, because the final playtest was very close, there was not enough time to fully investigate and re-adapt all systems to the new level version.
