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.

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.

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.