This post is mainly a mid-stage summary of the mechanic design work and related code implementation I have done so far.

When working on gameplay mechanics and coding, most of my energy usually goes into simply making things work first. Every time I solve a problem, it often feels like finishing a full day of fieldwork—from early morning until late at night—and still needing to write a report afterward. Because of that, many small details never made it into a proper blog post.

To make it clearer what parts I have actually implemented so far, I decided to collect and organize the pieces of work that were previously scattered across different stages of development.

“Press E” Interaction System

• Implemented the logic for showing / hiding the “Press E” prompt when the player enters or leaves a trigger area
• Tested the basic interaction flow with NPCs and interactable objects

Dialogue System (Ink + DialogueManager)

• Responsible for importing Ink JSON files into Unity and calling them through the DialogueManager
• Debugged the calling order of Continue() to ensure dialogue text appears correctly
• Used story.currentChoices to test multiple dialogue choices, and investigated why sometimes only a single option appeared

Early Design of Reputation / Choice Logic

• Drafted the basic reputation design in documentation (for example: which choices affect which characters, and how they might influence different endings). However, due to current scope considerations, these details cannot yet be finalized
• Explored whether reputation should be stored as numerical values or flags, and how it should be read and referenced during dialogue

Item Acquisition Flow (e.g.： Sierra’s Bracelet)

• Designed and partially experimented with different acquisition methods in the design document, such as:
  • obtaining items from NPCs
  • opening chests
  • finding tools before unlocking certain objects
  • or being guided by a “ghost”
• The main considerations here include:
  • exploration paths
  • player effort vs reward
  • whether the design should include backtracking

Wwise Integration Tests (Audio as Feedback)

• Implemented a simple AudioTrigger script in Unity to test whether Wwise Events can be triggered properly on in-game objects
• Recorded and processed simple UI sounds and looping footstep audio, and solved issues where loops did not connect smoothly
• Encountered issues such as Unity failing to detect SoundBanks and UI sounds being overridden by footstep sounds, and attempted to troubleshoot event settings and loading paths

Reputation Manager – Basic Framework

• Built a simple Reputation Manager system to record key choices made by the player during dialogue
• Currently the system can maintain and update reputation values on the Unity side, but integration with Ink is still incomplete.
  My script is currently unable to properly read custom data attached in Ink (tags / extra data), so further research into the Ink API and data transfer methods will be required.

Dialogue Portrait Brightness System (Collaborating with Kevin)

• Designed and attempted to implement a portrait brightness adjustment system during dialogue:
  • the speaking character is highlighted
  • non-speaking characters are dimmed
    This helps players quickly identify the current speaker in multi-character conversations.
• I built the initial concept and partial implementation, while Kevin is now continuing with optimization and further development of the system.

Some Typical Bug Cases

Example 1: Dialogue choices exist but are invisible in the UI

For a period of time, when the dialogue reached a choice point, the game would appear to freeze—no new text appeared and no options were visible.

The debugging process went roughly like this:

Inside DisplayChoices(), I used Debug.Log to print story.currentChoices.Count, and found that the number was correct for example, 3.

This meant that Ink had already successfully passed the three choices to Unity, so the issue was not on the Ink side.

Later I discovered that the UI layout of the choices was incorrect. The buttons were actually positioned outside the dialogue panel, so the player could not see or click them.

During this process I also learned the importance of switching between game view and scene view while testing UI problems.

In other words:

The logic layer was working, but the UI layer was completely invisible → which meant the player was effectively stuck forever.

After adjusting the UI layout (anchors, alignment, and container size), the choices displayed correctly.

This bug may look stupid, but it illustrates something important:

sometimes the mechanics and logic are working perfectly, but the problem lies in the presentation layer. If either layer breaks, the player simply experiences it as “the game is broken.”

Example 2: Subsequent dialogue choices fail to appear

Another issue occurred when the player selected the first dialogue choice successfully, the dialogue continued, but the next set of choices never appeared, causing the game to stall again.

Through debugging logs I confirmed that:

• Ink still had remaining dialogue content
• But Unity never entered the choice-display logic again

The bug was eventually fixed at the time, but to be honest, I can no longer remember the exact cause.

It was most likely related to call order or state not being properly reset.

What this bug revealed was:

• When I was focused on “just fixing the problem first”, I failed to document the debugging process in time
• Looking back now, I only know where the issue once occurred, but I lack a complete record of how it was solved

This is also why I later felt the need to write a summary like this, to compensate for my past habit of simply fixing an issue and then closing the laptop without documenting the process.