TVT

Author: JZ15N24

  • Playtest Feedback Meeting: Scope Control and Core Experience

    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.

  • Playtest Feedback Meeting: Dialogue, Objectives and Reputation Dependencies

    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.

  • Development Overview: From Mechanics Systems to Player Feedback – Iris

    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.

  • Spatial Audio Perception & Implementation in Game Design

    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.

  • Salmon Run – BGM

    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.

  • About Key Item Acquisition Quest

    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

  • First Playtest Scope

    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.

  • Non-linear Sound Design

    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.

    Overly loud or overly bright sound effects

    Pushing every sound effect to maximum volume, with excessive high frequencies, can make the mix feel harsh and disconnected. It’s important to leave proper headroom for each sound effect and apply appropriate high-frequency attenuation.

    Using only primary sound effects without supporting layers

    For example, when a character lands after a jump, using only the “impact” sound without a subtle “falling air” or motion sound can make the action feel thin and overly “skin-tight” to the animation.

    Lack of differentiation between environments

    Using the same reverb or ambient noise for forests, deserts, and indoor spaces removes environmental identity from the sound. Without scene-specific acoustic characteristics, sound effects tend to feel pasted onto the visuals rather than integrated.

    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.

  • Debug Log – Dialogue Display

    In the second half of last week, I fixed the issue where the range detection triggers “Press E”, as well as the start and end of the dialogue. Now I’ve started working on branching and choice-related content.

    Before I started, it was basically like this: you could press Space to end the dialogue, but no choices were displayed.

    After I built part of the UI and bound it to the DialogueManager, the following error appeared. Nothing related to choices was printed in the Console at all. I guess this means DisplayChoices() was never executed, or story.currentChoices.Count == 0.

    But “Hi there this is a test dialogue” was displayed normally, so I suspected the issue might be that there are actually no choices in the .ink file, or that there’s something wrong with my export format and it’s not being read properly…

    So I modified the code.

    I modified the Continue part inside DialogueManager so that when it detects there are upcoming choices, it loads the choices directly instead of ending the dialogue.

    Sorry that this part of the log is really messy, I only came back to write it some time after making the changes, and I kind of forgot what my thought process was at the time. Anyway, in the end I didn’t manage to solve anything. I even checked my Ink JSON file and confirmed it wasn’t an Ink issue.

    Then I suddenly remembered: debug logs are actually a really great thing. So I added a debug log here.

    After that, the following error appeared:

    Alright!!! This doesn’t look like it’s because of my Ink file. It looks more like my code is treating Ink’s choices as normal text and continuing them forward. Although the choices also didn’t appear as text, judging from the error message there seems to be that tendency.

    Maybe the UI didn’t have time to display the choices before my ContinueStory() pushed it to the next step. After all, it does show Choices Count=3, which means it reached the choice step. It froze because the UI didn’t display, so I couldn’t continue selecting.