Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Integrating Dialogue Data

A topic by bojjenclon created Jul 27, 2023 Views: 185 Replies: 3
Viewing posts 1 to 2

Hello, I’m trying to integrate dialogue nodes into my engine and I’m wondering what the intended workflow is for this. A dialogue node once exported has the graph property which defines ports and links, are these meant to be how the flow is integrated or is this purely for the GUI? Mostly just wanted to pick your brain and understand your intentions so I can write my code better. :)

Developer

Hello there! The implementation is really up to you! I would parse the graph.nodes array, locate the “start” node (or any other useful node) and start crawling from there.

Some useful props:

  • In the extras property you have the type, and the scriptID associated with that node.
  • Inside each node you have a ports array which you can use to get all in and “out” ports (1 for script nodes) so you can build your flow with that.
  • Once you reach a choice node, you can query its “out” ports to show the different options to the player, the link array associated with that port will give you the id of each connection the port has, so you can navigate to the next node.

Basically what you have there is the whole graph serialized. The dialogue player is a (super simple) example on how to implement.

Hope it helps!

Hey thanks for the info! I’ve got basically everything working, I just have one follow up question: how to find a given actor’s info in the Director from a Dialogue? In the export, the actor seems to just be the name supplied between the colons. However, it’s theoretically possible for there to be multiple actors with the same name, so just doing a naive name match on actors in the Director data seems wrong. How is this mapping meant to occur without the ID supplied to the Dialogue for the line’s corresponding actor?

Developer

Well the ::ActorName:: tag Is supposed to be unique, meaning, the app would autodetect and group the same string into the same actor. It is, in practice, an ID. I think the “real name” should be inside the properties, but again, is up to your implementation. Hope it makes sense!