Editor Complete, Runtime Next

We are happy that we finished our second milestone. The basic UI connection based on the concepts of milestone one is implemented and lets users interact with the ProcessEditor and the StepInspector inside Godot.

TinkerFlow supports at this point the basic authoring functionality of the process creation. The serialization path from VRBuilder to TinkerFlow is stable enough for a simple import.

We are not done here! There are a lot of construction points for UX, e.g. copy a step node into the clipboard and past it back into the graph editor, color highlighting of steps, step-sample inserts and so on. This means we still add more upcoming features into the graph system, and we definitely fix a lot of bugs there as well!

Next is runtime and VR

#

The next phase moves to the runtime of Godot, so getting processes executed inside a Godot scene at runtime. This includes the first integration of VR-based interactions as well.

The good thing is that the runtime requirements are way simpler. A process file is loaded from a JSON, gets translated from JSON to the Process. All process-based entities must run (correctly) alongside the Godot scene. But for that we need a user representation at the scene, a synchronization between the process GUIDs and scene-based objects with these GUIDs (over our Component System), and so on.

The player character itself needs to exist inside the scene with a user-controllable object, and the handling of interactions with the process, so the scene reacts when a transition fires and behaviors are executed.

This is our first process tested at runtime, which runs so far:

@startuml
tinkerflow-theme

start
:Enter chapter-1, enter start step;
:Change to step 1;
:Activate step 1;
:MoveObject to position object Pos1;
:No condition, change to Step 2;
:MoveObject to position object Pos2;
:No condition, change to end-chapter;
:Enter chapter-2, enter start step;
:Change to step 3;
:Activate step 3;
:MoveObject to position object Pos3;
:No condition, change to end-chapter;
:No chapter left, exit process;
stop

@enduml

So, by creating objects and linking them inside TinkerFlow’s ProcessEditor to a condition/behavior, no additional coding is required to perform the functions:

This is the fundamental idea of TinkerFlow, to create a visual editor that allows users to design and control processes without writing code, and at this point we add more features to this system.

Beyond Coding

#

Developing TinkerFlow by coding is only half the story now, some topics we want to cover in the future.

Early adopter talks have started, two partners are already registered for a meeting, and we wait to see what their feature requests will be. The first mentioned feature request is the GDScript based implantation of ‘TinkerFlow Runtime’. What we will evaluate at the fourth milestone just because to be more compatible with all users of Godot (not just the dotnet part of it).

We are in contact with a graphic designer from the NLNET Foundation, who helps us by redesign the logo and creates some more graphics, again with some ideas of the current web design.

We plan practical guides around concrete use cases that show how to build them in TinkerFlow.

The API reference should generate from code comments and appear live on the website over Woodpecker CI.

The example project should be testable for anyone to try TinkerFlow out.

If you know someone working with process-based trainings or similar scenarios, or just to try TinkerFlow write us on Mastodon, LinkedIn, or any channel on out website.

Thanks for reading!