MothCocoon / FlowGraph

Design-agnostic node system for scripting game’s flow in Unreal Engine
https://discord.gg/Xmtr6GhbmW
MIT License
1.17k stars 228 forks source link

allows to setup a mapping between gameplay tags and sequence tags. #183

Closed soraphis closed 7 months ago

soraphis commented 8 months ago

It uses the Actors that register via the FlowComponent's IdentityTags. Within the node the designer can define the mapping

The Example Sequence: image

The FlowNode: image

Possible Future Improvements:

MothDoctor commented 7 months ago

I'm sorry, but I'm unsure if adding Actor Bindings to the core node wouldn't be too much. This node wasn't intended to fulfill all needs of projects operating on Level Sequences. It's supposed to be a node showing basic functionality.

Actor Binding could get quite complex in specific projects. In the current version of the proposed changes, we only add bindings (although it would be sufficient in many projects!). There's no support for SaveGames which would be essential for gameplay-driven Level Sequences. And supporting this might require more and more changes and pull requests.

This being said, I would have nothing against adding this logic in the class inheriting after "Play Level Sequence" in the example Flow Quest plugin. What do you think? :) https://github.com/MothCocoon/FlowSolo/tree/5.3/Plugins/FlowQuest/Source/FlowQuest/Public/Flow/Nodes

soraphis commented 7 months ago

Hi, I made the changes in our project, because we needed them. I felt like, it could be beneficial for others too, so this PR was born. Also another aspect: getting feedback from people more knowledgeable in the plugin and unreal than I am :D

so in this regard thanks already! You're absolutely right about the missing SaveGame support and I will address that as soon as I find time for it.

Regarding inheriting the Node to add functionality, I'm not generally opposing the idea, but wondering: Let's say my game designer is setting up our next level, if I inherit from the node, there will be two nodes in the palette, doing like 90% the same thing just that one of them supports more features. should he pick the wrong node it's also a bit annoying to replace the old one.

I feel like there is no real gain from separating them.

I'm also now thinking: is there a way to "hide" registered nodes? like, could I create a child PlayLevelSequence that has more functionality and hide the original PlayLevelSequence somehow?

MothDoctor commented 7 months ago

Regarding inheriting the Node to add functionality, I'm not generally opposing the idea, but wondering: Let's say my game designer is setting up our next level, if I inherit from the node, there will be two nodes in the palette, doing like 90% the same thing just that one of them supports more features. should he pick the wrong node it's also a bit annoying to replace the old one.

I'm also now thinking: is there a way to "hide" registered nodes? like, could I create a child PlayLevelSequence that has more functionality and hide the original PlayLevelSequence somehow?

Yes, you can hide built-in nodes from the Palette in your project. Just add it to the NodesHiddenFromPalette list in the Flow Graph Settings. This way you don't need to modify the plugin's code. It might a way to easier for you to simply use your class.

And now I'm thinking that even adding proper SaveGame support might need additional changes in a specific project, so... I guess it's best to close this PR. I would be more open to accepting a custom node to the FlowSolo project than keep extending this "base node".