In this playtest feedback meeting, we first looked through the feedback spreadsheet and started to re-evaluate the current scope of the project. Although the meeting initially started from Alex’s feedback about “placeholder text”, the discussion quickly moved towards a more important question: what we could still realistically complete at the current stage of production, and what had to be cut.

At that point, the team had already realised that it was no longer realistic to continue pushing every design idea from the GDD. The combat system, especially, had become very difficult to complete with the remaining time, technical capacity, and team resources. Instead of continuing to expand large features, it made more sense to first make sure that Chapter One could run stably, and that players could smoothly understand and experience the core content of the current Vertical Slice.

Because of this, the team started to evaluate the priority of the playtest feedback one by one. Issues such as map clipping, players falling out of the map, and players walking through fences were treated as critical bugs, because they directly broke the player experience and interrupted the game flow. Compared with new features or lower-priority polish tasks, these problems had to be fixed first. The team decided to address them by adding invisible walls, colliders, and boundary limits.

The meeting also discussed whether we should add a sprint function. Although sprint is a common movement feature in many games, the team eventually decided not to include it. The reason was that the current project was closer to slow-paced exploration and NPC interaction, rather than fast movement or action gameplay. Adding sprint would not only change the pacing of the map, but also create extra testing costs. It could even make the already small map feel even shorter. Because of this, sprint was treated as a new feature that did not really fit the core experience of the current Vertical Slice.

The mini-map feature was also rejected. The current map was not very large, and players could mostly understand the spatial layout through the visuals and environment. Adding a mini-map for such a small scene would create extra UI, programming, and art workload, but would only bring limited improvement to the showcase build. This discussion made me realise that playtest feedback does not mean everything should be implemented. The team still needs to judge which feedback is actually worth moving into production based on the project goal, development cost, and remaining time.

For art and UI details, the team also filtered priorities carefully. For example, the item count display was unclear because the UI icon overlapped with the number. This affected how players read information, so it needed to be fixed quickly. However, some more detailed icon polish or extra art refinements were temporarily moved to a lower priority. This did not mean that polish was unimportant. It was more because, at that stage, the project needed to solve stability, readability, and core playability first.

For the development plan, the team formed a compromise. Kevin and I would continue focusing on improving the first level, fixing bugs, adding necessary content, and strengthening the core experience. After finishing the current optimisation tasks, playboi cope could start building the second level forest and cabin scene. This allowed us to make sure that the first level, as the main showcase area of the Vertical Slice, would be properly polished, while still letting some asset production continue in parallel so team members were not just waiting for each other.

At the end of the meeting, we also discussed updates to the website and process documentation. The team decided to include the organised feedback spreadsheet and meeting outcomes as part of the website content, while continuing to update individual development logs. This reminded me that process documentation should not only record the final outcome. It should also record how the team made decisions based on test feedback, how we cut scope, and how we redistributed tasks.

This meeting helped me understand more clearly that Vertical Slice production is not about making everything from the GDD. It is about keeping the parts that best represent the core experience within a limited timeframe. For us, the stability of Chapter One, the clarity of player objectives, and basic interaction feedback were more important than adding combat, sprint, or a mini-map.

This also affected how I judged my own work afterwards. Instead of continuing to expand large mechanics systems that would be difficult to fully close in the short term, I needed to focus more on content that could directly improve the player experience and be tested more easily, such as UI feedback, interaction feedback, ambience, and spatial audio. This was not giving up on design. It was re-evaluating what was most worth implementing under the current production conditions.

This playtest feedback meeting focused more on the opening sequence, objectives, the dialogue system, and the reputation system. The more obvious issues from the test feedback included: the opening being too long, players not knowing their current objective, weak character readability during dialogue, and confusion around narrative order and quest trigger logic. These issues were all connected to the areas I focused on early as a Mechanics Designer: dialogue, reputation, and progression.

First, the team discussed the opening flow. The playtest feedback suggested that the opening was too long, and we also realised that the comic and dialogue content at that point was quite lengthy and not integrated closely enough with the following gameplay. Since the voice-over playback speed was slower than the player’s reading speed, the team decided to remove the opening voice-over and only keep the comic, subtitles, or a more concise version of the static text.

To avoid players completely missing key information after skipping the opening, the team also discussed adding a story summary. Whether the player chose to skip the opening or not, they could still see a short summary before entering the main gameplay, so they could quickly understand the core background. This decision made me realise that narrative content in games is not only about being “fully written”. It also needs to fit the player’s pace and the testing context. For a Vertical Slice, players need to enter the playable section quickly while still understanding the basic setup.

The second focus was the objective system. During the test, some players were not sure what they were supposed to do next, so the team decided that objective prompts should be triggered automatically after dialogue, and specific goals should be shown in the backpack or UI, such as picking berries or finding the map. After an objective is completed, the UI needs to show the state change through a tick mark, a greyed-out state, or by automatically moving focus to the next objective.

This discussion made me realise that the objective system is not just a UI feature. Technically, we can prepare the task system framework in advance, but the actual objective content still needs to be connected to the narrative structure. For example, objectives like picking berries or finding the map need to be introduced through dialogue or story context. Otherwise, even if players see the task in the UI, they may not understand why they are doing it. Because of this, the objective system actually connects narrative, dialogue, inventory, and UI feedback.

The meeting also covered character readability. Players sometimes could not tell who was currently speaking, so the team decided to add character name cards to the dialogue system and strengthen the visual feedback of “whoever is speaking gets highlighted”. This was related to my earlier attempt at portrait feedback. Although my early version used a temporary logic that roughly guessed whether the player was responding based on whether choices were visible, the playtest feedback proved that this direction itself was valuable. Later, the TD implemented a more stable version through player / speaker tags, allowing the Dialogue Manager to identify the current speaker from Ink tags and highlight the correct portrait.

Another important issue was confusing narrative logic. The meeting mentioned that players could sometimes trigger later dialogue before completing the required previous task, which made the story order unclear. The team discussed two possible solutions: one was to trigger different dialogue based on whether the player had a specific quest item, such as the map; the other was to add prerequisite locks for certain quests or dialogue.

This discussion helped me understand more clearly that the dialogue system cannot simply play text in a fixed order. It needs to read the player’s current state, such as whether they have a certain item, whether they have completed a task, or whether a story flag has already been triggered. Otherwise, the dialogue content can become disconnected from the player’s actual progress. This also explains why the later Dialogue Manager needed to push states such as inventory, story flags, and reputation into Ink.

The most important topic was the reputation system. Around 33:41 in the meeting, we discussed the difficulty of implementing reputation. At the time, I mentioned that although I had already built the basic framework for reputation, the system was highly tied to the story and needed affection changes to be clearly embedded into the dialogue scripts. For example, handing in berries could increase reputation by a certain amount, while handing in the map could increase reputation by a larger amount. In other words, the value system itself was only the foundation. It had to be placed into specific dialogue, item delivery, and quest nodes before it could become a mechanic the player could actually experience.

This made me realise that the difficulty of the Reputation Manager was not just whether the system could add or subtract values. The more important questions were: when the player triggers this change, why it happens, how the NPC reacts afterwards, and whether the player can see the consequence. Without matching narrative content and dialogue branches, reputation can only remain a background variable instead of becoming a complete gameplay loop.

This meeting also explains why reputation was not fully implemented into the final Vertical Slice. The issue was not just code implementation, but the combined result of narrative content, system interfaces, and production scope. As a Mechanics Designer, I learned that cross-system mechanics need clearly defined interfaces from the early stage: what variables Ink needs, which tags will change reputation, which items will affect dialogue, and what feedback the player will see after completing a task.

If I were to rebuild this system, I would first design a minimum playable loop: one NPC, one Ink dialogue, one quest item, one reputation change, and one immediately visible NPC reaction. This would prove that the reputation mechanic can actually be perceived by the player before expanding it to more NPCs, more quests, and more ending branches.