Engine design problem: speaker and actor occupation #71

New issue

Open

opened 2026-10-18 00:22:36 +00:00 by Roboticy3 · 2 comments

Roboticy3 commented

2026-10-18 00:22:36 +00:00

(Migrated from github.com)

The distinction between speakers and actors is confusing from an API standpoint. Can it be hidden/removed?
There are conflicting intents with the designs of how dialogue behaves when actors with certain speakers are/aren't present.
2.1. The engine doesn't have a clean way of condensing a player with private nodes into an NPC. What happens to the hidden nodes? Do they become auto?
2.2. The engine doesn't have a way to add actors that don't effect flow. e.g. actors that can be present without affecting singleplayer rule. This should be possible since I want to add "bots" that are capable of making decisions, but also headless. However, this poses an issue against the central design of the engine in how it handles "back and forth" interactions between multiple agents. There's no guarantee the bot would reply immediately. Is singleplayer rule, waiting for bots a special suspended state for the player?

1. The distinction between speakers and actors is confusing from an API standpoint. Can it be hidden/removed? 2. There are conflicting intents with the designs of how dialogue behaves when actors with certain speakers are/aren't present. 2.1. The engine doesn't have a clean way of condensing a player with private nodes into an NPC. What happens to the hidden nodes? Do they become auto? 2.2. The engine doesn't have a way to add actors that don't effect flow. e.g. actors that can be present without affecting singleplayer rule. This should be possible since I want to add "bots" that are capable of making decisions, but also headless. However, this poses an issue against the central design of the engine in how it handles "back and forth" interactions between multiple agents. There's no guarantee the bot would reply immediately. Is singleplayer rule, waiting for bots a special suspended state for the player?

Roboticy3 commented

2026-10-19 01:52:43 +00:00

(Migrated from github.com)

The solution is probably to add back the ownable flag, then follow the consequences of that through the design document, rigorously defining cases as they arise along the way.

Roboticy3 commented

2026-10-20 02:10:00 +00:00

(Migrated from github.com)