Dev Diary 5

My cat has been really REALLY annoying today. Its hard enough trying to get these systems to work, extra hard when every 10 minutes i get a whining meow asking for treats or to play. I love her, but holy crap man, i need some space sometimes and i need EXTRA space when im thinking hard. And even now, writing this, im just waiting for some needy ass cat to walk in and break my train of thought. The problem with anger/impatience, be it at yourself, at people or at pets, is that they are temporary. You do yourself a disservice by wasting time being irritated and irate when, at the end of the day, these pets and people are really just saying, "hey, i wanna be around you." So really, i gotta not be so grumpy, its just thinking these things through isn't easy, and it isn't fun sometimes.

There, thats off my chest.

I dont want to work on the direct control logic (where you possess a unit and drive them around, firing off abilities), and i dont want to work on yesterdays project of migrating the level editor over from editor world to runtime world. So i worked on the dialogue editor/story editor.

This will be good for users because it can look at the story scripts, which are pure XML, and give users a GUI to edit those scripts. Further, by using drop downs and stuff, it removes a lot of chance for typos from data entry.

The "PuppetShowManager" script reads whatever module (dialogue script) and parses trigger words as "actions". These "actions" let the system understand that it should have character xyz enter stage right, for example, and use dialogue balloon abc to say whatever its supposed to say. We have a choice node, for decision trees, as well as costs (food, gold, flags) for those choices. So lets say a goblin comes out on stage, and gives you the flag "metGoblin" and then a later module needs "metGoblin" present to unlock the choice "TalkedToHank" or something. Further, these flags can effect dungeon generation, where a if during generation you have "metGobliln", it may bias to spawning "GoblinBoss" room.

The goal is to let users extend this as much as they want. Loading in and assigning new actors, generate new stories, and build new dungeon rooms. I have a little bit of technical debt later on when i make it so that the users can implement their own tiles, mobs, items, walls, and furniture. Thats going to be hard to do, but also fun to do. It will be the first project i've made that is user extendable.

Mods.

Thats cool... Also that would open up the steam workshop for the project. Neat.

Here is chatGPT to give you a more professional breakdown on what we did today.

High-level goal (today)

Build a runtime dialogue editor scene with:

• A timeline of dialogue actions

• A single, context-sensitive inspector window

• Clean SRP separation

• Runtime-spawned UI that actually responds correctly

What we implemented & fixed

1. Runtime Dialogue Editor Architecture

You locked in a solid mental model:

• Timeline = list of actions (read-only summary + selection)

• Inspector = one window, context-sensitive

• Router = decides which inspector panel to show

• Inspectors = own binding + editing logic per action type

This avoided the “one window per action” UI explosion.

2. DialogueTimelineUI

• Runtime-spawned rows from [c]DialogueAction[/c] list

• Each row shows:

  • Node index

  • Node label

  • Action type

  • Short description/summary

• Rows have multiple buttons → all wired to the same selection event

• Timeline opens/closes with:

  • CanvasGroup fade

  • Scale pop animation

  • No [c]SetActive[/c] abuse

3. DialogueTimelineRowUI

• Unified click handling:

  • Any button on the row triggers selection

• Emits:

  event Action OnClicked;

• Clean separation: row knows index, not editor state

4. DialogueActionInspectorRouter (core of the day)

This was the big fight, and you won it.

What it now does correctly:

• Holds CanvasGroup panels, not GameObjects

• Routes based on [c]DialogueAction.type[/c]

• Animates panel transitions (fade + scale)

• Manages raycasts & interactability

• Owns open / close orchestration

• Does not decide toggle behavior

Critical fix:

• Inspectors now return [c]bool[/c] from [c]Bind()[/c]

• Router respects that return value

bool shouldOpen = inspector.Bind(action); if (!shouldOpen) { HideAll(); return; }

This finally fixed:

• ❌ close → instantly reopen bug

• ❌ animation race conditions

• ❌ router overriding inspector intent

5. Inspector toggle logic moved to inspectors

This was the actual root cause.

Each inspector:

• Tracks its currently bound action

• If the same action is clicked again:

  • Returns [c]false[/c]

  • Performs its own cleanup

• Router simply reacts

This is the correct ownership boundary.

6. EnterActionInspector

Fully implemented and working:

• Uses TMP_Dropdown (not free text)

• Pulls options from [c]CharacterRegistry[/c]

• Binds back to [c]DialogueAction.characterId[/c]

• Shows character portrait image

• Handles:

  • Rebind

  • Toggle close

  • Safe rebinding without event spam

7. CharacterRegistry

• Persistent singleton ([c]DefaultExecutionOrder(-100)[/c])

• Editor-authored list of:

  • [c]characterId[/c]

  • [c]sprite[/c]

• Runtime lookup:

  • [c]GetCharacterIds()[/c]

  • [c]GetSprite(id)[/c]

• Designed to later expand to user content

8. Animation & UX polish

Across timeline + inspector:

• CanvasGroup everywhere

• Fade + scale pop

• Correct [c]blocksRaycasts / interactable[/c] handling

• No invisible-but-clickable bugs

• No SetActive flicker

Net result

By the end of today you have:

• ✅ A functioning runtime dialogue editor foundation

• ✅ Clean SRP boundaries

• ✅ A working action timeline

• ✅ A context-sensitive inspector that does not fight itself

• ✅ A pattern you can extend to every other action type