WEEK 1
In the first week, we clarified the overall project goal: the instructor explained that the core of this semester’s project is not to create a complete commercial game, but rather to create a vertical slice that represents the core experience of the project, based on GDD. This means that all our subsequent work should revolve around “the part that best reflects the gameplay, atmosphere, and design direction,” rather than endlessly expanding the content.
After that, I learned that team and role allocation were established. The teacher divided discipline-based roles this time, which is to make us more flexible in the project process, and it is also more convenient for everyone to organize the project experience into the content of the portfolio that is in line with their own direction.
My core identity in the team is Mechanics Designer, that is, the person in charge of game mechanism design. After communication and coordination with the team members. My main responsibility is to transform the gameplay ideas put forward by the team into a functional system that can run in Unreal Engine 5. Therefore, my weekly reflection will focus on recording technical implementation, system logic, player feedback, and the communication process between me and my teammates.
But this is a challenge for me. I have some technical experience, but I also need to use other time to do a lot of study and research.
WEEK 2
This week’s group projects have moved from the initial organization phase to the content comprehension phase. The course reiterated this semester’s goals: each team needs to create a vertical slice based on GDD and include it as part of their individual portfolios, while each member is required to continuously document their contributions in a blog. In addition, we developed a team contract to deepen our understanding of each other.
During this week, we have made more detailed divisions and adjustments to our role responsibilities. The course specifically mentioned that this kind of team division is based on a broader discipline, rather than being completely fixed to a single role. This means that I not only need to focus on mechanical design itself, but also actively participate in discussions of tasks and game strategies. I also studied relevant game cases and summarized my findings, sharing them with team members in a timely manner.
I started thinking about what the player’s primary actions would be in this game, how environmental interactions would drive the experience, and what mechanics would be best suited as the core content of a vertical slice. Compared to the first week, which mainly focused on team formation and role confirmation, this week felt more like formally entering the project design itself. This made me realize that as a Technical Designer, my responsibility going forward is not only to come up with ideas, but more importantly, to help the team transform abstract concepts into concrete player behaviors, system feedback, and executable gameplay structures.
WEEK 3
This week’s course content differed from the previous two weeks. The focus shifted away from teamwork and GDD readings, and instead, it featured a guest talk about game production. This lecture helped me understand team projects from a more practical development process perspective and made me rethink my role as a Mechanics Designer within a team.
One sentence from the lecture really stuck with me: “Production is about getting the best out of what you’ve got in the context you’re in.” I understand this to mean that game development isn’t just about using management tools or following a certain process, but about making the existing content as efficient and clear as possible within limited time, resources, and team constraints. This is especially important for student projects because we can’t expand the content indefinitely; we must be more selective and prioritize what’s most worthwhile.
Furthermore, the lecture emphasized that games are about iteration and stressed the importance of playing tests as much as possible. This made me realize that mechanical design shouldn’t aim for complexity and completeness from the outset, but rather focus on building a working, testable base version first, and then continuously modifying it based on feedback. Especially for vertical slices, it’s more important to concentrate on clarifying a few key interactions and confirming whether players truly understand and experience the design, rather than trying many mechanics simultaneously. So, after communicating with my team members, I began creating and testing my first game mechanic: players unlock the camera view by picking up items, allowing them to see hidden objects
WEEK 4
This week’s focus was on the role of testing in the game design process, including smoke testing, user testing, bug report recording methods, and how to iterate the design based on test results. The presentation emphasized that as designers, testing is a fundamental part of the iteration process; it not only helps us discover hidden problems but also helps us verify the validity of the design and understand what players truly care about.
This week’s content gave me a more concrete understanding of my responsibilities as a Technical Designer. In the past, I would naturally focus on “how to design a mechanic,” but this course made me realize that a mechanic isn’t finished once it’s built; it must be tested to see if it truly works. The course materials mentioned several purposes of testing, including identifying key technical issues, determining the ease of understanding of the design, identifying what players truly care about, and helping the team confirm the design direction. These are all closely related to mechanical design because even if a gameplay element is functionally working, it doesn’t necessarily mean that players will understand it or want to continue interacting with it.
In addition, I’ve completed the first game mechanic: players unlock a camera view by picking up items, allowing them to see hidden objects. I shared this with my team members, and after discussion, they decided to abandon this mechanic and instead allow players to walk on specific walls.
At the same time, I also created a git hub group, which can effectively improve our production efficiency.
WEEK 5
This week’s course focused on puzzle design and playtesting preparation, and required… Compared to last week, which focused more on understanding the basic concepts of testing, this week made me start thinking more concretely: as a Mechanics Designer, how should I design an interactive mechanism that is understandable, adaptable, and testable?
The presentation slides mentioned that the focus of puzzle design isn’t just “whether there’s an answer,” but rather what the player actually does in the game—the interactivity itself. This made me realize that there’s a very direct relationship between mechanical design and puzzle design. A puzzle not only needs a clear question, objective, and tools available to the player, but also needs these elements to form repeatable and varied gameplay patterns. For me, this means that when designing interactions, I can’t just focus on whether the mechanism can be triggered, but also consider how the player understands the rules, how they learn them in the first interaction, and how they can continue to advance the experience through variations.
The course also mentioned that good puzzles usually need to strike a balance between novelty and challenge: too easy will disappoint, and too difficult will frustrate players, making playtesting essential.
This made me realize more clearly that mechanism design shouldn’t just be based on the designer’s own logic but must be validated through feedback from real players. For example, whether players understand the objective, know how to operate, whether they get stuck at a certain point for too long, and whether they truly derive a sense of accomplishment from it. These are all things that can only be truly observed through testing.
I have also completed the interaction mechanism between players and items in the levels. Players can pick up or drop items, and these items can be displayed and switched in real time in the inventory.
During Thursday’s game test, the three team members had significant disagreements. I think we should find an opportunity to sit down and discuss it face-to-face. Meanwhile, I gathered feedback from most of the game testers: Weaknesses: The use of game items is not yet apparent (of course, it hasn’t been developed yet), and the difficulty of level progression is too high. Strengths: Player interaction and movement controls are very smooth, providing a great experience. I will discuss these issues with my team members next week.
WEEK 6
This week’s course focuses on a retrospective, which involves reviewing and reflecting on the team’s recent work practices. The presentation slides emphasize that the core of a retrospective is not criticizing any individual’s performance, but rather reflecting on how the team collaborated, which processes facilitated project progress, which slowed it down, and how to improve in the future. Its goal is to help the team continuously improve, rather than simply summarizing results.
With the teacher’s help, we had a face-to-face communication session where everyone shared their thoughts and summarized our findings. Our group’s biggest obstacles were language barriers and a lack of clarity regarding role assignments. Through this communication, the three members successfully reached a consensus and decided to try again with the current roles. If the next test results are unsatisfactory, Kamilla and Erik will design the level, while Jermy will take on other tasks. I am very grateful for the teacher’s help, which successfully guided us to solve the problem. This experience also made me realize once again how crucial communication is in a project.
In the coming days, I will continue to complete the parts that need to be completed on the schedule. The task is very challenging, as the overlapping use of six mechanisms and systems is extremely difficult. After discussing with my team members, I will do my best to complete it, which will require a lot of time and effort.
WEEK 7
In the 7th week, I gave formative feedback on my personal blog and the research part. After reviewing my research content, Marie suggested that I watch the YouTube channel of GDC Festival of Gaming and search for speeches related to mechanic’s design. This feedback made me realize that my research cannot only rely on specific game cases but also needs to add more professional design lectures and industry resources.
This suggestion is very helpful for my character, because my main contribution in Daydream 2 is technical design and gameplay interaction. I’m not just making a blueprint but thinking about how a mechanism can be understood by players, how to be tested, and how to connect with the player’s experience. Watching design-related content can help me understand more critically: how a small function becomes a clear, playable and testable system.
After this feedback, I plan to use GDC-related resources to strengthen my research on interaction design, player guidance and mechanism clarity. This is also related to the problems found in subsequent tests, such as players do not fully understand why they should collect items, or do not know how to use the wall-climbing mechanism
WEEK 8
Included more complete systems: pickup, drop, inventory UI, climbing, final 4×4 puzzle, collectible objects, and level progression. The feedback showed that players liked the atmosphere, sound, level route, climbing idea, and final puzzle surprise.
However, the test also showed several issues. Climbing still needed more polish. Some players did not clearly understand why they were collecting objects. Some also did not understand what the camera-like collectible objects were for, partly because final art models were not finished and I used default UE models as temporary placeholders. This week made it clear that visual identity, UI explanation, and gameplay logic all affect player understanding.
WEEK 9
In Week 9, I focused on responding to the feedback from the second playtest. The main issue I addressed was that players did not clearly understand why they needed to collect objects. To solve this, I 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 was an important change because it connected item pickup directly to the level objective. The player could now understand that the collectible objects were not random props, but part of the door-unlocking progression. This week helped me understand that UI guidance can be used as a technical design tool, not only as visual decoration.
WEEK 10
In Week 10, the project moved toward the public building and final playable version. I checked whether the whole flow could work from start to end spawn guidance, movement, locked-door prompt, item collection, climbing, returning to the door, unlocking, and entering the final puzzle space.
During the third playtest, Ross suggested adding a climbing animation so players could clearly recognize when they had entered climbing mode. I also added a text sign near the climbable area to explain how to use the climbing mechanic. This showed me that special movement systems need more than code. They need animation, visual feedback, or instructions so players can understand the state change.
WEEK 11
In the 11th week, I mainly reviewed my contributions and organized the evidence for the website. Because the blueprint has been put into the gameplay system part, I began to check whether each system has enough supporting materials: game screenshots, blueprint screenshots, test evidence and reflection text.
I also sorted out the boundaries of my responsibilities again. I need to make it clear that the physical level route, the final art assets and the overall mechanism direction are not my personal responsibility. After group discussion in the second week, my responsibility is to realize the technology and turn the team’s ideas into a playable system. This explanation is very important, because a clear document can avoid misunderstandings of team roles.
WEEK 12
In the 12th week, I mainly organized the content of the website for the final submission. I checked the structure of the Semester 2 part, including the project overview, my role, the research process, the gameplay system, the trial test, the weekly reflection, the team contribution, the final reflection and the AI usage statement.
The focus of this stage is to make the project clear and readable to the evaluator. I will not only show what I have done, but also show how I research, realize, test, iterate and reflect. At the same time, if generative AI is used, AI Declaration is also required, because the course materials clearly require a declaration when using AI.
Last week made me understand that document collation is also a part of design practice. If the process is not clearly recorded, the work is easily misunderstood. By organizing roles, evidence and reflection, I can show more clearly how my technical design contribution supports the final vertical slice.