Another playtest feedback meeting focused more specifically on the opening sequence, objectives, the dialogue system, and the reputation system. The most obvious issues from the playtest were that the opening was too long, players were not sure what their current objective was, character speech was not clear enough, and the narrative order and quest trigger logic were confusing. These problems were all closely related to the areas I focused on early as a Mechanics Designer: dialogue, reputation, and progression.

First, the team discussed the pacing of the opening sequence. Since the voice-over was slower than the player’s reading speed, the team decided to remove the voice-over and background sound effects from the opening comic, and only keep more concise subtitles or static text. To avoid players completely missing key information after skipping the opening, the team also discussed adding a story summary system. Whether the player manually skipped the opening or not, a short summary should be shown after the dialogue, so the player can quickly understand the core background.

This decision made me realise that narrative content in games is not only about being complete or well-written. It also needs to fit the player’s reading speed, the testing rhythm, and the way players interact with the game. For a Vertical Slice, the opening needs to communicate the background quickly, instead of making the player wait too long before they can actually play.

The second focus was the objective system. During testing, some players were not sure what they were supposed to do next, so the team decided that quest prompts should be triggered automatically after dialogue, and specific objectives should be displayed in the backpack or UI, such as picking berries. After an objective is completed, the UI should show the change through a tick mark, greyed-out state, or by automatically moving focus to the new objective. This shows that the objective system and dialogue system are not separate: dialogue gives the player the goal, while the UI helps the player track that goal.

The meeting also discussed character readability. Players sometimes could not tell who was currently speaking, so the team decided to add character name cards into 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 more temporary logic to simulate speaker highlighting, the playtest feedback proved that this direction itself was valuable. Later, the TD implemented a more stable version through speaker / player tags, allowing the Dialogue Manager to identify the current speaker from Ink tags and highlight the correct portrait.

The most important topic was the reputation system. The meeting clearly pointed out that although the framework of reputation had already been built, there were still technical issues in connecting it with Unity, and it also depended heavily on the delivery of narrative writing. For example, value changes such as giving berries for +5 reputation or giving the map for +15 reputation needed to be bound to specific dialogue, quests, and item interactions. If there were no matching dialogue branches or NPC reactions, even if the reputation value changed, it would be difficult for the player to understand its meaning.

This made me further realise that the Reputation Manager is not a system that can be completed in isolation. It needs to work together with the Dialogue Manager, Ink choices, inventory, story flags, the objective system, and narrative content. The meeting also mentioned that players could sometimes trigger later dialogue before completing the required task, so later versions needed to restrict dialogue trigger conditions through specific items or story flags. This shows that dialogue, inventory, and reputation all need clear system interfaces.

From a reflection perspective, I initially thought of the Reputation Manager too much like a backend manager: it records Sierra and Marcus’s values, and allows them to be increased, decreased, and read. However, in actual production, the real difficulty was turning those values into consequences that players could perceive. Players need to see changes in NPC attitude, dialogue options, quest states, or ending conditions. Otherwise, reputation is only a hidden background variable.

This meeting also explains why reputation was not fully implemented into the Vertical Slice in the end. 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 from this 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 first that the reputation mechanic can actually be perceived by the player, before expanding it to more NPCs, more quests, and more ending branches.