Currently the graph that models a conversation is implemented with petgraph and stored into a component Talk.
This also keeps track of the start_node and current_node (these are NodeIndex).
There are also some helper components (CurrentText, CurrentActor, CurrentNodeKind...) that can be queried, but they are kinda useless since you just need to query for Talk and you can access all the info you need.
It would be interesting to try to model the graph as a bunch of entities:
Each node as an entity with several components (text, nodekind, next...)
the "Next" component contains the Entity of the next node.
We can group these components in a Bundle to quickly create nodes.
We could have a root Entity that represents the entire dialogue graph (with some marker component). Then each children entity has the bundle of components to make it a "TalkNode". They each have the "Next" component so we know where it points to.
It becomes it easy to despawn the entire dialogue graph cause we just need to despawn_recursively() the root entity.
Perhaps we could use aery to add relationships between entities.
Instead of using "Next" component to have a pointer to the next dialogue, we can put the 2 TalkNode entities in a relationship? We should investigate this.
The relationship can also be useful to tie together a TalkNode with the Actors.
We ca have all the actors of a dialogue graph as their own entities (with the appropiate components) connected to each TalkNode in a relationship.
Currently the graph that models a conversation is implemented with petgraph and stored into a component
Talk. This also keeps track of thestart_nodeandcurrent_node(these are NodeIndex).There are also some helper components (CurrentText, CurrentActor, CurrentNodeKind...) that can be queried, but they are kinda useless since you just need to query for
Talkand you can access all the info you need.It would be interesting to try to model the graph as a bunch of entities:
Bundleto quickly create nodes.We could have a root Entity that represents the entire dialogue graph (with some marker component). Then each children entity has the bundle of components to make it a "TalkNode". They each have the "Next" component so we know where it points to.
despawn_recursively()the root entity.Perhaps we could use aery to add relationships between entities. Instead of using "Next" component to have a pointer to the next dialogue, we can put the 2 TalkNode entities in a relationship? We should investigate this.
The relationship can also be useful to tie together a TalkNode with the Actors. We ca have all the actors of a dialogue graph as their own entities (with the appropiate components) connected to each TalkNode in a relationship.