Node map visualization - Githubissues

addie-lombardo commented 6 years ago

Wanted to give this a go as I've worked with/on the original Yarn editor and a couple other in-engine visual dialogue systems.

Will be pushing code to the following branch on my fork. feature/node-map

radiatoryang commented 6 years ago

thanks for moving on this!

here's a bunch of thoughts I had on designing it:

there's a use case where you'd want the treeView, the nodemap, and the edit pane, all visible at once, right?... maybe it should be a vertically-resizable wide pane on top of the edit pane?
- it's going to be fun to try to tightly couple all these panes -- selecting a node in nodemap should also select the node in the treeView, etc... nodemap should use same data structures as treeView / viewState
- when in Yarn playtest preview mode, it'd be cool to have that Mecanim / UE4 blueprint style visualization of node progress / which node we're currently in.
  - just realized there's currently no debugging features for analyzing Yarn Spinner instances during Unity play mode... maybe that'll be more like a v0.7 feature
when node parenting get implemented (I guess via Merino-only node tag? see issue #3 ) it'd be cool if moving a parent node moved all its children
one thing I really like in Unreal 4 blueprint is the comment boxes, which are crucial for organizing anything more than a handful of nodes
- maybe this is what node parenting would do: act as a node grouping thing, visualizes boxes that encapsulate the positions of all children nodes... that way, this structure is reflected in both node map and the treeView
a fun feature that'd be cool for a v0.6.5 after base nodemap stuff is implemented: automatic arrangement / relax / untangle, with springs and repulsion, like http://arborjs.org/ -- and nodes with more body could also have more mass in this physical system, so you'd be able to intuitively "feel" the biggest parts of your Yarn file (and also let users disable it if it kills editor performance)

addie-lombardo commented 6 years ago

Thanks for the additional design ideas/considerations!

For a v1 of the feature, I'm planning to make the nodemap a separate Unity editor windows so it can be shown/hidden by the user as needed but reduce the complexity of including it all in one window. I'd also love to add comment boxes at some point, it's one of my favorite things in blueprint!

addie-lombardo commented 6 years ago

A small update on this issue, knocked out the most basic functionality for visualizing yarn files in a nodemap this weekend. Will work on more UX/polish side stuff in my free time in the coming week!

addie-lombardo commented 6 years ago

I've been looking into implementing comment boxes to Merino as part of the nodemap window as suggested but have reached a(nother) design decision. We for obvious reasons want to keep output files from Merino as close to the "official" yarn format and that which Yarn Spinner supports to reduce potential issues and unnecessary parsing.

While we could add a new serialized field to yarn files to define where comment boxes are drawn, you mentioned above the following.

maybe this is what node parenting would do: act as a node grouping thing, visualizes boxes that encapsulate the positions of all children nodes... that way, this structure is reflected in both node map and the treeView

I started taking said approach but ran into the fact that there are many ways this can be displayed on the screen to the user (shown below) and decided to check for others opinions of what should actually be encompassed within a comment box and if/how possible nested comment boxes would exist.

Potentially this would be something which would be best to hold off on until https://github.com/radiatoryang/merino/issues/11 is implemented and just have all nodes within a folder be encompassed with a comment box instead of having it relying exclusively on the parenting of nodes.

radiatoryang commented 6 years ago

personally I think 4 makes the most sense to me?

addie-lombardo commented 6 years ago

Yeah me too, we'll go with that for now then!

radiatoryang commented 6 years ago

I just did a big PR that changed how file loading works (#17), apologies if that affects your node map stuff

I think reading/writing TreeElements in the TreeModel should still mostly be the same, it's just MerinoTreeElement.leafType enum that decides whether it's a Yarn node or a File or a Folder (folder is currently unused though)...

it's unclear to me how you should visualize multiple files in the node map, I guess treat them just like any other parent? (this seems like a UX problem unique to Yarn's use of multiple files, vs Twine or Blueprint)

it'd be cool to have an early basic version of this for v0.6, let me know if you need anything~

addie-lombardo commented 6 years ago

Hey, thanks for letting me know. We should talk over dms sometime about future direction for Merino regarding features/refactoring so we can keep more in sync with each other.

The core of the nodemap is implemented, I'm now more working on quality of life features to make it's addition to Merino feel more useful and powerful along with overall codebase refactoring to allow the two windows to work independently from each other.

I'll pull #17 tonight and start working on fitting what I have into the current master before submitting a PR now that v0.5 is out.

Edit: I don't know what I expected responding to this via email.

radiatoryang commented 5 years ago

polished this up as best as I could, and now merged into master (#33)... thanks so much for all your work @charblar

radiatoryang / merino

Node map visualization #9