I do not know if easy development finite state machine. it is an alternative code something similar visual programming.
Godot engine, blender, unity 3d and Unreal Engine already has it fsm … I’m sorry I’m not very code. But it is graphic and multimedia design.
Yes it’s a broader field but it boils down to a state driven system that use “transitions” to migrant from state to state.
This can boil down to the visual node based programming interface you mentioned but in its pure form it is represented by states that transition data. This can be represented in components or in the mentioned scenes that figur out the state change and perform them for you (like in Adobe XD Auto Animate).
Sorry for getting technical on you. I see what you request and the closest Hype has built in is a pipeline called custom behavior informing listening elements about events (in a non visual way this represents a node like linking but with limited parameter capabilities).
The state machine is a nice library but in fact most parts of this are also already in the existing runtime. You can save state in hypeDocument.customData and use custom behavior to signal state changes. You can then setup up symbol specific handlers listening to the signals to display the state change with relative timelines to have it seamlessly morph.
If you mind distributed code across functions you can even write it all in a scene init and use the simple extension Hype CommandPipeline to streamline the process to a single Hype function setting everything up.
I think the OP was identifying the node interface aspect of it as the actual FMS or wish, so this isn’t part of Hype but the underlying concepts pretty much.
Node based Interfaces and programming are nice. Much of that actually happens in the head of a programmer anyways and/or is forced onto the programmer by using structured programming interfaces. I like that visual node based system allow an easy access to programming for visual people and Hype has certainly that going for itself. Another upside are that nodes follow a strict input/output paradigm that forces to think in components and exposes users to think in reusable/repeating patterns.
With Hype 4 nearly all the ground works are layed down to create (basic) components. The event broadcasting offered by custom behavior even allows to expand the component interface (as “pipes”) into the GUI.
Far from nodes but something to think about. Then again Hype offers a “edit with…” feature since Hype 4. One could create apps that work as function factories. Even maybe plug in some software that reads JS and turns it into Scratch style blocks or an node base interface to regular JS.
I was just thinking… even though a node based panel is certainly off the table for the immediate future. A thing that could be beneficial to Hype would be a “cheat sheet” listing all symbols and scenes with their defined custom behavior and events (scene/symbolload, unload etc.) and actions … much like a sectioned (by scene and symbol) Trello board list.
At first it could be a read only board to get things going. Maybe down the line one could add actions in that “overview”. Certainly a good way to keep on top of a complex project.
I'm not entirely sure I understood but if you ask if hype has the same logic then the answer is no. Hype works with timelines and you have to think differently.
If you are wondering if hype can be used without code then the answer is yes, you have to use the timelines also to program the events and not just the animation.
Yes and no. For now I was thinking more along the lines of the existing triggers and their actions. These are currently all in panel tabs per item (sometimes even in a nested fashion) and only visible one at the time. Same reason I requested some screens I can’t make a exploration myself. Thank you for the visualization!
This is an alternative to the plain trello board displaying the commands inline in the board overview instead of only the triggers (with an additional click to reveal the actual commands).
This view is inspired by Scratch command brackets. If each command as a block is to different from the regular display in the known panels on could just put the known panel into a bracket (as a whole).
So to come back to flow based programming. As this „Trello board“ like concept is a bit different … one could even enable a flow connector mode on the Trello board to see how signals and commands flow. Scene commands and custom behavior sender/receiver can produce lines if one wants:
I’m following the discussion with interest but I didn’t understand much.
This reminds me the Quartz Composer programming and some 3D max plugins for special effects. The visual approach is intuitive but I don’t understand what it give more than the logic of timelines.Did I miss something?