In the early stage of the project, my role mainly focused on Mechanics Design, especially dialogue, reputation, objectives, and progression. At first, I wanted to understand how The Verdant Trail could connect NPC interaction, item collection, exploration, and story outcomes into a playable loop. Because of this, I made early attempts with the Ink dialogue system, portrait feedback, and a Reputation Manager prototype.

However, during the actual implementation process, I gradually realised that these systems were much larger than I first expected. Reputation is not just a value system. It needs narrative writing, Ink tags, inventory checks, story flags, UI feedback, and visible NPC reactions to support it. Otherwise, even if the system works in the background, it is still difficult for players to truly feel that their choices have created consequences.

After several playtest feedback meetings, the team’s priorities gradually shifted towards scope control, polishing the first level, fixing bugs, and creating clearer player-facing feedback. This also changed how I judged my own contribution. Instead of continuing to expand large systems that depended on many unfinished parts, I needed to focus more on feedback mechanics that could be implemented, tested, and directly experienced by players within the Vertical Slice.

This was also why I later shifted towards Wwise and interactive audio. I did not treat audio as simple decoration. Instead, I understood it as a feedback layer: it can help players understand their actions, spatial position, environmental atmosphere, and interaction results. Changes in footstep sounds, UI sound effects, spatial ambience, and river sounds can all make the game world feel clearer and more responsive.

Looking back, this was not a complete change in my role direction, but a production decision. My work shifted from large narrative systems towards smaller and more testable feedback mechanics. This helped me understand that Mechanics Design is not only about creating systems, but also about judging which systems can be completed, tested, and understood by players within the current scope.

Playtesting 1

Critique

As players played, the dialogue wasn’t happening at the correct time, so people didn’t understand the narrative at all. One said they had “no idea who I am” and doesn’t understand the objective. They suggested a name tag above the NPC’s.

There was no intuitive way to know how to open the inventory and the UI in the titlescreen was overlapping different elements, making it slightly jarring.

This is where I thought it would be neccessary to have an exposition for the pre-story for context. Players generally didn’t know what they were doing.

Positives

People found the map fun to explore, The mini games were regarded well and simplicity was well recieved too. People enjoyed both the ‘cute artstyle’ and the 3D envioronment.

Playtesting 2

Critique

Everyone generally agreed the Exposition was way too long and we skipped it half the time. Adam really didn’t like how long it took to start the game. It took 2-3 mins to to start playing. He just wanted to play the game. Anna 2 Also says the character dialouge has to be simplified and even suggested colouring the text to make it more undersatndable of who is speaking.

The narration was confusing. Anna didn’t understand if she was Tyler and Marcus until we told her. She was confused about the objective of the game and what to do. The narration wasn’t happening in chronological order. This confused a lot of people. Anna suggested an instructions / task page of what to do.

The game was still rough around the edges. You can still fall through the map. Anna wanted an indicator for whether this was an arrow game or a wasd game. Adam says the placeholder of the map was a bit confusing. Izzy was confused about the rock minigame. It wasnt clear that you’re supposed to drag the rocks out of the (invisible) parameter. Raff somehow managed to walk through the fence, bypassing the ending screen. The number of ites you have in the inventory was too small to see.

Kamilla would of liked a shift key to sprint.

Positives

People enjoyed the style of the game. Kamilla liked the low poly. She also enjoyed the game direction being a walking sim x visual novel.

The sfx was enjoyed, Anna liked the sound effects of completing the task. Kamilla liked the sounds when walking.

The inventory was solid. Anna easily naviagted through it, Raff also enjoyed the inventory.

Though Anna was confused about the plot, she enjoyed the story telling. Raff read through the story pretty dilligently as though they enjoyed it too.

Final Playtest

Positives

The dialogue is more consistent and people understood most of the story. Basic things like choices appearring when they need to is a huge win. Adam agreed that the game is fundamentally set in stone. He said the music felt like interstellar. When we pointed out that the music was made by Iris, Ollie thought it was something found online and made by a professional. Jordan pointed out that this was a viable vertical slice prototype.

Jess pointed out it was intuitive to gain reputation with the characters and satisfying to see their behavoir warm up to her. Lettie enjoyed the minigames to gain reputation and liked the art style and sound design. Jess and Ollie enjoyed the character dynamic between Marcus and Tyler. Jess also liked the subtle change in Tyler with bloody hands which was a neat featture for that situation to make more sense.

People also navigated the UI more seamlessly. For example, nobody needed guidance to open the inventory.

Critiques

Lettie points out a game breaking bug of ‘moving all the way to the left once the game begins’. Falling thorugh the map still persists. Jess says the reputation bar is such a critical aspect of the game, too important to be hidden away in the inventory.

Some people were confused about the narrative choices which lead up to unnatural character interactions. This includes the option to share a blanket to the characters at the start when you haven’t found one to begin with. Same with the blood mushroom.

Adam pointed most of the UI in the start menu didnt work. And there wasn’t clear indication of overall progression.

Ollie was confused about the first pieces of dialogue, because it wasn’t clear that it was Tyler’s monologue. When walking up and down, the character hovered. Ollie would have preffered if the running cycle for moving left and right would be used for up and down. He said the SFX isn’t great, especially compared to the music. He also wanted an ‘x’ button for exiting the inventory as he found himself dragging his mouse the top right of it, only to realise it wasn’t there.

Distance Attenuation

First, the most basic thing: enable “spatial (3D) sound” in the game, and make the volume decrease as the distance increases.

Adjust the curve so that the attenuation feels closer to real life.

In practice, this can also be used to control how much a player hears certain sounds. For example, if a campfire sound is not very important, we can make it attenuate faster to prevent it from distracting the player.

In reality, sound attenuation is non-linear, so we need to manually adjust the curve, make the change more noticeable at close range and more gradual at long range.

This can control whether the player “notices a sound or not.”

For example:

Unimportant sounds (campfire) → faster attenuation → avoid distraction

Important sounds (enemy/footsteps) → slower attenuation → easier to hear

Basically, attenuation is a design tool, not just a physical effect 🤔

Distance Affecting Timbre (Filter)

When the distance between the player and the sound source changes, what we hear doesn’t just change in volume.

As distance increases, the sound not only becomes quieter but also “muddier,” because high frequencies are more easily absorbed by air, while low frequencies travel further. (Like when you’re next door to a livehouse: you might not hear the song clearly, but you can easily hear the bass “dum-dum.”)

In this case, we can use low-pass / high-pass filters to make the sound change dynamically with distance. For example, distant sounds are more muffled, while nearby sounds are clearer. So distance doesn’t just make a sound quieter, it also makes it blurrier.

Because with distance, what we hear doesn’t only change in volume. Different frequency ranges have different penetration abilities, so we can also appropriately add low-cut and high-cut.

Spread

If we don’t add spread, the sound will feel very “point-like” (sharp), and when moving left and right, the direction change will be very extreme.

But in reality, within a certain range, sound doesn’t come strictly from a single point—it has some diffusion. So we should increase spread appropriately to make it more natural and avoid the sound jumping crazily from left to right.

Of course, sometimes we can choose not to add it. For example, I think collectible sounds in Resident Evil 9 don’t need spread, since they’re hidden, you can locate them by sound direction. Similar puzzle designs can also use this as a clue.

ShareSet / Property Container

When a group of sounds (like footsteps or ambience) needs consistent rules, don’t tweak them one by one.

We can create a property container

Use a ShareSet

So that a whole category of sounds uses the same settings

This way, we can keep a consistent style, update everything at once, and avoid chaos. If we need individual adjustments, we can still tweak them separately.

Game audio is very different from film audio. It’s not just “playing sound,” but using distance / frequency / space / system management to control what the player hears, what they pay attention to, and what they ignore.

Listener

Wwise places the listener on the camera by default, but the camera is not always equal to the “player’s ears” (for example, in our current project The Verdant Trail).

For fixed camera or third-person views, using the camera directly may not be appropriate.

So we need to disable the listener on the camera rig, create an empty object, and attach the listener to it, so it follows the character (or the desired listening position).

This script is essentially creating an “ideal ear”:

The ear is on the player’s body (correct position), but the listening direction matches the camera (comfortable perception).

Because our hearing is related to orientation, the listener’s rotation affects spatial perception and weighting of sounds.

In 3D games, we usually let the “ears rotate with the camera,” so the world sounds natural to the player.

transform.rotation = mainCam.transform.rotation;

This line ensures that orientation and hearing direction are aligned.

But since our game uses a fixed camera, it’s actually… not that useful, because the camera direction is always fixed. However, in a first-person game, this would be very important.

I wrote this Salmon Run background track rather spontaneously when inspiration struck, so it’s really just a rough draft for now.

Since the scene takes place by a river, and Erik mentioned that “if there is music, it would be nice if it stayed calm throughout,” I thought a soft, flowing piano might work well. There are variations in dynamics and pacing, but those are quite difficult to express in Guitar Pro. I’m also not very comfortable using the piano roll in FL Studio, so once my MIDI keyboard arrives I plan to record it directly by playing it in.

Considering that the focus of the audio design should be ambient sound, if I eventually finish this piece and put it into the game, the volume will likely be relatively low with quite a lot of reverb. On one hand, this helps match the outdoor environment; on the other, I want the music to remain subtle, almost like something you can only faintly notice in the background.

I let a friend listen to it without giving any context, and they said:

“Although I don’t know much about piano, it feels like reaching the end of a long journey, sitting on a hillside or a patch of grass, looking into the distance, wanting to reflect on the ups and downs of the past. But in the end, what really stays in your heart are just the sunsets and sunrises you saw along the way. It feels very calm and gently flowing. The latter half feels like stars.”

So it seems I managed to convey the atmosphere and feeling fairly well.

Since this is meant to be the BGM for a river scene, I used many continuous and repeating motifs to evoke a sense of flowing water. Shortly before the ending there is a brief pre-outro build based on a sustained E5. Through repeated high notes and denser note patterns, it aims to create the feeling of starlike reflections shimmering on the river surface, while slightly increasing the presence of the BGM. Otherwise, with the way I tend to mix things, people might barely notice the music at all. I still hope players can notice it just a little, without it taking away their attention from the gameplay.

While composing, the tempo of the piano is intentionally quite fluid. On one hand, it makes the piece more lyrical and less rigid; on the other hand, it mimics the natural flow of a river. However, this also makes dynamic control and notation significantly more challenging.

Stylistically, the piece leans toward a neoclassical approach. The main reference is Ólafur Arnalds, and I was also inspired by Oskar Schuster, especially his piece Damascus. The section I mentioned earlier was partially influenced by how he handles similar passages. Personally, I would love to include the subtle mechanical clicking of piano keys, but given the limited time, that kind of detail is unnecessary for our game.

After Erik listened to the full track, he felt that some parts might be “too much.” I completely understand where his concern comes from, but since this is not the final version, I will probably keep the piece for now. Before I become more familiar with Wwise, I might write a few other simpler pieces (although this is not my main responsibility), and only later think about mastering and mixing. If I ultimately can’t achieve the atmosphere I described, I might consider removing the scene BGM entirely and leaving only the ambience and SFX.

Over the past two days I finished the newly released Resident Evil 9: Requiem. The section in the sanatorium basement where you repair the fuses was particularly interesting to me. The map design there is not exactly stunning, but it is quite clever. I have been thinking about whether we could adapt a similar approach into the game we are currently developing.

Since many important items are given to the player directly by NPCs, for example the compass, I do not feel like I have much room to intervene in that aspect. So I started thinking that perhaps I could instead design small puzzle elements around the items that the player gives to NPCs in exchange for important story-related items, or items that significantly increase NPC reputation.

Right now, I am thinking about Sierra’s bracelet. First, I need to confirm in which scene we want the bracelet to be obtained, and whether we allow the player to return to previous scenes.

I should confirm with Alex:

• In which scene does Sierra’s bracelet appear? I want the narrative logic to be as solid as possible.
• Do you think NPCs might have passed through certain locations before arriving at Basecamp, other than Basecamp itself? This will determine where Sierra’s bracelet should appear. Alternatively, we could also say that some wild animal dropped the bracelet there.

I may need to confirm with Yansong:

• If the bracelet is not in the initial scene, what will the later maps look like?

My current idea is that the bracelet could be located somewhere that the player cannot initially access. For example, if the bracelet falls onto a small island in the middle of a lake, the player would need to build a simple wooden bridge before reaching it. The player might need to search for wooden planks or find a hatchet to construct the bridge. The hatchet, in turn, might require the player to investigate an abandoned campsite.

If we go with the ‘obtain the hatchet’ route, we could also lock the hatchet inside a simple locked box. The player would need to acquire a basic lockpicking tool to open it. The lockpicks could be limited in number, while there are more locked boxes than lockpicks available. In that case, the player would need to decide which box to use the lockpick on.

I just discussed it with Alex, and the other party proposed that “we have ghost” in the cabin, which allows ghost to hold Sierra’s bracelet, and then in exchange, the player needs to submit something to ghost

To be honest, I feel that this kind of mechanism has been cut a lot… It was getting harder and harder for me to find what I could do

Based on the above, we will tentatively let the ghost keep Sierra’s bracelet. So my goal now is to figure out what the ghost wants and how the player can get it.

Regarding the Timer:

A hard time limit might be too restrictive for a narrative-driven game. Since the GDD also mentions that exploration is an important element, we probably should not make this too strict. The passage of time could instead be driven by events rather than by a rigid countdown

To be honest, we didn’t do much “long-term” planning, because our playtest cycle was actually a bit stressful for me. Given the workload, my technical designer and I probably need to start coding. I’m not familiar with Unity, and many problems will still occur when I actually get my hands on them, even though I know how to solve them. So I can’t guarantee that I will be able to perform tasks according to a certain time table at the moment. Therefore, my specific plan is to only do the first playtest. After that, there are only vague “what should I do” and “what to do next”.

According to Erik’s definition of the game pillars, most of this game’s distinctive features rely heavily on long-term progression. Because of that, it is difficult for us to fully demonstrate these elements within a minimum viable playtest, especially those that require extended development over time.

However, we can still identify and implement several essential mechanics to showcase the core gameplay experience, such as the dialogue system.

Before the first playtest, we expect to complete character movement, the construction of at least one map, part of the narrative content, and a basic dialogue system. If our development progresses more efficiently than expected, I will also attempt to implement branching dialogue.

Based on my understanding of the GDD, dialogue choices and branching paths will influence the player’s reputation among other NPCs. The reputation system will, in turn, directly affect subsequent narrative developments and ultimately shape the game’s ending.

Since my work has strong dependencies on Alex’s work (who is responsible for narrative design), I am currently limited in developing further branching content beyond the implementation of core gameplay mechanics.

Over the past two weeks, I have broken down the essential systems the game currently requires and established a learning priority based on their importance and impact on development progress. I have now completed the character movement code and am currently studying and testing the implementation of the dialogue system.

In addition to programming, I have also been learning more about synthesizer fundamentals in preparation for future sound design and music production. However, this is not our primary focus at this stage.

Kevin is currently working on designing the game’s website, while Yansong is studying the target 3D modeling style for our project.

Since none of us are particularly skilled at pixel art, and our lead artist Yansong is more experienced in 3D, we have decided to experiment with an art style similar to Octopath Traveler: 2D characters, movement inspired by 2.5D perspective games, and fully 3D-modeled environments.

At the same time, we are considering redrawing certain CGs and character illustrations based on the updated GDD, aiming to refine the original drafts. However, this is not a current priority, so we will likely use the existing character artwork for the first playtest.

I’ve been thinking about what game sound design should actually look like if I were to work on it.

Up to now, my personal work has been mainly focused on Foley and sound design for film and video. But game audio feels fundamentally different from film audio. If you simply drag sound files into the engine, the result often feels like the audio was added in post—detached from gameplay, not interacting with mechanics, not participating in the narrative, not affecting game feel. It just tells you “there is a sound here,” much like early beta versions of Minecraft.

In film sound design, the progression of sound is relatively linear: everything follows a timeline.

I think I’m currently stuck on the question of what kind of sound design can be considered truly integrated into the game experience.

That said, considering the use of a bitcrusher, perhaps what Erik wants isn’t a fully realistic soundscape. However, if the art direction ultimately moves away from a pixel-art style (since Yansong is considering 3D models with a 2.5D fixed camera, and it’s hard to predict the final visual outcome), a bitcrusher could end up feeling very out of place. This is something I’ll need to discuss with the TA.

I’ve also been thinking that if this is a third-person game with a fixed top-down camera, adding a large amount of close-range character detail sounds (such as cloth movement or small bodily motions) would pull the listener’s focus back toward the character’s body. This would reduce environmental depth and make the space sound “flat”and overly intimate, potentially causing confusion in spatial perception.

For this reason, I personally think that in this scenario, environmental audio should take priority over character-generated sounds.

Although this issue isn’t critical at the moment, I’ve briefly thought about some potential problems that might arise in sound design. This is more of a quick brainstorm than a finalized conclusion.

After implementation, try turning off the visuals and listening to the audio alone.

If the player can clearly tell what the character is doing, what environment they are in, and what the emotional tone is, then the sound design is successfully integrated, and that artificial, “stuck-on” feeling naturally disappears.