Splitter (Iterator) Node about arrow HOT 11 CLOSED

I intend to implement this node with priority and include a safety warning in its sub-inspector.

Also watched the GDC talk. Good watch for sure.
I found the approach they took to tell the story, very interesting.

Thanks for both suggestions.

from arrow.

We now have Sequencer node in v2.0.0.

I think you may find our new Character Tag System interesting as well.
It may be used to manage events (somehow like what they did in Firewatch) together with Tag-Edit and Tag-pass nodes.

from arrow.

Note I was able to implement this pretty easily by duplicating the randomizer node and changing the name of everything to splitter (Find & Replace)

from arrow.

The thing is, each type in the Arrow's node system, needs to know what is the next node to play.
There can be different strategies to select that next node. The basic one is to have one path forward (similar to content and variable modifier nodes.) Another approach is to let player choose which node they want to go to (e.g. dialog and interaction) or define a condition to choose for them.
In other words, to run multiple events, we have to chain them somehow or have a way to choose between them.
Now when we intend to split to different nodes and have no preference, the best strategy to select the next node can be randomizing.
So I think randomizer is exactly the inverted hub.
Suggestions for any other strategy that is not implemented is very welcome.
If you're suggesting to rename the node to splitter; I don't think it really reflects the underlying process.

from arrow.

I mean a node that has two or more exits, which are played sequentially.

I was using this to link logic trees together so that the same dialog could have different options.

When I drop something in the house, it can check a few separate condition trees and play the correct dialog. Currently randomiser does not work like this since it only plays one output.

from arrow.

Here's an example of my tree:

It was used in this game:
https://tavurth.itch.io/small-santa-stories

from arrow.

OK! have questions though.
What if more than two of the conditions return true or dispatch to multiple different path with either true or false ?
Then won't we have multiple next nodes, while we can only print/show one of them to the player ?

from arrow.

For me I will play each of those dialog trees until the end, step by step.

A use for this would be when the player enters an area. Imagine they have several party members, those party members might say something if they have not talked to the player recently.

We can use a splitter node to link to each of those dialog sets, and perhaps include a delay node which can be setup with a random timer.

In that way, the players companions will talk to them randomly as they progress through the level.

from arrow.

In other words, the strategy is:

• let's forget the rule that: there is always only one next node
• provide developers with an option to iterate over multiple nodes which allows cases such as:

  "a little old lady arrives home, and I would like to be able to trigger multiple events from this entry point."

• and let developers face/mange the (unsafe) consequences; Where multiple possible events (iterated/parallel nodes) naturally result in multiple possible future events (next nodes) or multiple end-of-line signals or a mix of both.

?

This is normal when we develop game(-play or runtime) logic and catch exceptions;
Yet it is considered unsafe strategy in terms of narrative design, because a particular (sub-) plot may not [rationally] end and then (or at the same time,) evolve forward too. It either finishes or continues/branches.

The safe strategy is to use conditional chains (probably a lot of them in a macro) where all cases are meticulously handled and result in individual/singular future per condition/(sub-)branch (instead of multiple outcomes of non-chained sequentially outputted nodes.)

I say unsafe (not wrong) because it can be a handy feature if used correctly, where [all] outcomes are carefully handled.
It's can be a convenience at-least for avoiding lots of conditional chains. I agree.

from arrow.

Yep that feature breakdown sounds correct. In my screenshot above I didn't take much care about the possible race conditions of subplots, but I was building for a game jam in only 9 days.

I would say that with a few UI issues aside Arrow was very helpful for my project, more powerful than simply iterating on a codebase which could quickly become tangled and messy. More power for the developer will always win, and perhaps a note in the splitter node help docs about being careful would be better than not having such a feature.

If I might point out I feel like the game engine part of this app could be nicely separated.

For me I would have submitted a PR with this feature, but having to implement the whole feature-set of a story-mode splitter which i'll never use kept me from doing so.

from arrow.

I'm thinking more in the terms of Firewatch story.

They had a great GDC interview recently where they built their own version of something like Arrow, I think you might find it interesting to watch:

https://www.youtube.com/watch?v=RVFyRV43Ei8

from arrow.