Fugue Devlog 4: Dialogue System Improvements

Not a lot of coding today, but a lot more work on the dialogue system. Sketching the manager render sequence out, figuring out the speaker tracking, dialog box placement, etc.

I've tried to think through all possible cases but surely some have been overlooked. I just hope that none are serious enough to require a complete restructuring. There are so many cases to consider, but a few that are trickier include:

• Should multiple on-screen decisions be allowed? If so, how do players select between decisions? Right now I'm thinking that only one decision be allowed, but don't know of a robust way of enforcing that constraint in the dialogue editor validator.
• Should time stop/player movement be locked while in dialogue? I like the idea of being able to move around, break off from conversations, etc. Makes it feel more lively. But it adds in complications of pausing and resuming dialogue. And fixing the player in place while in a conversation feels like a reasonably "real" constraint to have.
  • That being said, pausing and resuming is necessary for ambient conversations. For example, two people having a conversation, then pausing to address the player when they get close enough (e.g. "Can I help you?"), and resuming their conversation once the player leaves their vicinity. This is part of a broader question of whether or not the ambient dialogue system should be distinct from the "player" dialogue system. Ideally they are one and the same, and the player's involvement is a special case (e.g. time stops/player movement stops only if an active script includes the player as a speaker; dialogue always auto-advances/times out if the player isn't involved, etc).
• How should dialogue progression be handled? There are a lot of potentially conflicting cases here. In general there are three ways a statement can advance: the player hits the next dialogue input, the player selects a choice (if the statement is a decision), or the statement times out (if it has a timeout specified). This is straightforward if there's one statement on-screen. But if there are multiple, as with simultaneous dialogue, then what? If some statements have timeouts and some don't, does pressing the next dialogue input advance them all? Or do they wait for the timeouts to finish? There isn't really a clear answer here. I may just have to pick something and be ready to change it as the rest of the game develops.

This last point is kind of the case with the dialogue system more broadly. I won't really know how well any of this works until I implement it and start working through test cases.

I did get a very basic version of the speaker tracking implemented, was pretty straightforward to do in Godot. Basically I calculate the full bounding box ("AABB") of a spatial node and use that to determine its center x coordinate and maximum y coordinate. Then unproject that point to the camera/screen space. It will get more complicated with multiple speakers and potentially overlapping dialogue boxes, though I think I have a decent solution to that in the sketches above.

Blender scripting

I also learned a bit of Blender scripting (which uses Python). Most people I know who do a lot of 3d modeling use Rhino/Grasshopper, and I've seen a lot of really amazing work done with scripting in that tool. It looks like Blender is just as capable, which is cool.

I made a big button for quickly exporting the current file to my Godot model folder. Normally I have to go to the export dialogue, navigate to the appropriate folder, then save. Navigating through folders is slow...it's a small thing but smoothes out the workflow a lot.

I'm also really impressed by the environment Blender provides for scripting. It has a console for trying things out and logs every interaction you have with the UI so that you can easily figure out what functions do what. There are also several templates provided that make it easy to quick prototype an idea.