In the early stage of the project, as a Mechanics Designer, I mainly focused on the Dialogue Manager and Reputation Manager. My goal was to turn the GDD ideas around NPC relationships, player choices, item interaction, and story branches into systems that could actually run in the game. The Dialogue Manager and Reputation Manager were originally meant to form a mechanics loop together: the player makes choices in dialogue, those choices affect Sierra or Marcus’s reputation, and that reputation then changes later dialogue, NPC attitudes, quest states, area unlocks, or endings.
However, during the actual production process, I gradually realised that the scope of this kind of system was much larger than I first expected. The Reputation Manager itself was not difficult if it was only recording values. The real difficulty was making those values enter a gameplay loop that the player could actually feel. It needed to connect with Ink dialogue, story flags, inventory, quest states, UI feedback, and a large amount of dialogue content. Without enough follow-up content and visible feedback, reputation would only become a background variable, rather than a mechanic the player could understand.
At the same time, as a Vertical Slice, we needed to prioritise content that players could directly experience and that could be quickly tested. The dialogue and reputation systems were important, but they also required a more complete narrative structure before they could fully work. At that point, our production time, technical interfaces, and team resources were all quite limited. Because of this, I started to reconsider where my contribution should focus. Instead of continuing to push a large system that would be difficult to fully close in the short term, I decided to move towards feedback systems that were easier to implement and could better support the core experience.
This was also why I later shifted towards Wwise and interactive audio. The core experience of The Verdant Trail is closely connected to exploration, environmental understanding, and atmosphere. Players need to understand where they are, what state the current environment is in, and what certain areas or actions mean through the scene, sound, and feedback. In this context, sound is not just decoration. It is part of how the player understands the world.
For example, footsteps can help the player feel that they are walking on different surfaces. Ambience can strengthen the spatial feeling of a scene. River sounds can become part of navigation and area awareness. UI and interaction sound effects can help players confirm that their actions have actually happened. Compared with a background reputation value, these sound feedback systems can be heard and felt by the player more directly, and they can also be tested more clearly during playtests.
Because of this, I later moved part of my Mechanics Designer thinking into Wwise implementation. This shift was not completely moving away from mechanics. Instead, it was a shift from large narrative systems towards lighter and more achievable feedback mechanics. Wwise allowed me to connect player behaviour, scene states, and audio feedback together. For example, through Switches, Events, AkAmbient, spatialised sound, and ambience logic, the sound could change based on the player’s position or actions.
This process also made me rethink the scope of mechanics design. A mechanic does not always have to be an obvious value system or quest system. Sometimes, mechanics can also exist in the feedback layer. When the player presses a button and hears a confirmation sound, walks onto a wooden bridge and hears different footsteps, or gets closer to a river and hears the water sound change, these are all system responses to player behaviour. They may not be as complex as reputation, but they are much easier to turn into a complete and testable experience loop within a Vertical Slice.
Looking back, this shift was a realistic production decision. The reputation system represented my attempt to design a long-term narrative mechanic, while the Wwise implementation allowed me to provide more stable and presentable support for the project within a limited timeframe. It helped me realise that, in a team project, choosing what to do and what not to do are equally important. The value of a design idea does not only depend on whether it is interesting as a concept, but also on whether it can be implemented, tested, and perceived by players within the current scope.
Leave a Reply