First Blog Post#
It’s hard at first and this is our very first blog post for TinkerFlow, our publicly funded project (Especially this is the first blog post I’ve ever written so far…). We’ve advanced the project far enough that it’s now visible on Codeberg. Our main milestones are set, and we’ve already begun work on the very first one.
So what is VR Builder?#
VR Builder is an authoring system made by MindPort GmbH that enables programmers and non-programmers to create interactive VR/XR experiences inside Unity. For this, VR Builder provided an abstracted process editor that visualizes the logical steps of a process. Thinking about a bike-assembly process. Each mechanic step is represented as a node in the process editor, each node has functions that are called when the step is activated and has conditions that lead to the next step. Based on this every process-based task can be created with VR Builder.
Why TinkerFlow then?#
There is more context needed: We both believe in open source and are eagerly following developments in the Fediverse. For us, open source means that people can inspect it, adapt it, build themself, and the most important thing, they can integrate it into their projects and pipelines. The company that developed Unity is no longer the same company it was 10 years ago. The usage of Unity feels cumbersome, everything takes a long time to load, the interface is complex for beginners, and the costs are getting higher.
To explain our view of the current situation is the following: Unity is indeed a great and powerful Engine. We don’t want to argue otherwise. We’ve worked with the engine for years and published several (research) projects with it. Don’t get us wrong (please!), and we apologise for the negative bashing here! With specialised knowledge and a lot of programming experience, you can develop scaleable and awesome applications. If it’s a game ore a VR/XR application for a specific training. It offers a scaling environment and a lot of possibilities and customisations.
BUT, the audience of Unity (single users, indie developers, smaller groups, or even companies) has shifted more toward huge studios and mobile gaming area only (Or this is my interpretation of the current trends e.g. Godot was the most used game engine for GMTK Game Jam 2026 submissions.) It has increasingly deterred many circles, which means that it is challenging to use such an environment in schools to encourage children and young people to engage in (3D) art creation, programming, and self-expression. Or use it inside companies for their own or customers projects. If you’re a huge enterprise and want to use Unity you have to pay for every employee inside your company, if they want to use Unity or not, also agencies that cooperate with these companies need the Enterprise license (see also the new runtime fee .)
To give one good example of how Unity current feels like. If you open a plain Unity project, you have to wait (on my local machine) roughly 5 Minutes and then 30 seconds for every reload of changes. Godot opens in around 10 seconds and is fast as normal dotnet builds and runs. Unity just feels clunky, which is the worst for beginners.
We know that not everyone can learn programming and would much rather express themselves creatively, and that’s exactly what TinkerFlow is for. We see Godot as a potential opportunity to restore these areas of application, also through collaboration with other library developers and with a creative and diverse community. We have a clear view of how, what, and with what we will develop TinkerFlow, and what the outcome should be: a platform that is used, that is developed also after the funding, usable by everyone who wants to create apps (with Godot). For example, a teacher should be able to create a simple assembly exercise, change its steps, and test it without modifying the underlying runtime.
Licensing#
We’ve been thinking about licensing. It’s an important part of a (software) project. We plan to go with a dual licensing model, private and research, smaller projects can go with the open-source license, while anything beyond that requires purchasing a commercial license from us. If open-source is not enough for the project.
We’ll see how the community responds, what feedback we get, and how well it works.
Acknowledgments#
A huge thank-you to the NLNet team for selecting our project and providing funding. We’d also like to thank all partners involved, especially those who’ve provided legal guidance, explanations, and recommendations. We’re very grateful for that support.
Thank you MindPort for creating VR Builder and providing the tool as open source. The idea of TinkerFlow would not exist without it.
Technology Stack & Platforms#
- Version control Git on Codeberg
- Development environment Godot, Rider, PlantUML, Excalidraw
- Tested platforms are Linux (PopOS) and Winderp, with a focus on cross-platform compatibility
- CI/CD we use Woodpecker (We haven’t finalized that part yet…)
Next Steps#
In principle, what the most important tasks are: modularising VR Builder as much as possible and extracting the process-runner-engine, specifically by extracting Core Runtime and VR Builder Runtime to achieve engine independence usage. We’re starting by refactoring Core Runtime to extract components from it, moving them back into the VR Builder package, and establishing a structure where:
@startuml
tinkerflow-theme
skinparam componentStyle rectangle
package "TinkerFlow-Debug" {
component "Godot sample project\nTinkerFlow-Debug" as DEBUG
}
package "Submodules (git)" {
component "TinkerFlow-Core\n(addons/TinkerFlow)" as CORE
component "Process Engine - VR Builder Core\n(addons/ProcessEngine)" as ENGINE
}
package "Unity side" {
component "VR Builder (Unity)" as VRBUILDER
component "ProcessEngine via OpenUPM\nco.mindport.processengine" as UPM
}
DEBUG --> CORE : git submodule
DEBUG --> ENGINE : git submodule
CORE --> ENGINE : required
VRBUILDER --> UPM : consumes same engine code
UPM --> ENGINE : same repository, Unity build config
@endumlOn the Godot side TinkerFlow with Core Runtime On the Unity side VR Builder with VR Builder Runtime and Core Runtime
Step by step, we’re removing compile errors from the TinkerFlow side while simultaneously checking compatibility with the Unity version. Both must remain compilable once this goal is reached, TinkerFlow continues to function on the Godot side, and VR Builder keeps working the same on Unity.
Our further approach will be to create project examples that combine TinkerFlow with Git submodules and the Core Runtime repository, hosted together on Codeberg. When we make changes, they happen on Codeberg first. After it, we’ll then create pull requests for runtime changes on GitHub.
For our example setups, we’ll also create tests to catch compile errors and especially runtime errors early. The architecture is kept simple, working with Git submodules, which will later also allow templates and additional assets to be created in the same way. This approach lets us respond quickly to changes while maintaining compatibility with both Unity packages and VR Builder. We stay in contact with the MindPort team and VR Builder’s core developer (thanks again for your work) to get feedback and address potential architectural changes early, making sure our modifications align with VR Builder’s architecture and Core Runtime design.
More updates will follow. We’re rolling up our sleeves and getting to work, stay tuned!
This project was funded through the NGI0 Commons Fund, a fund established by NLnet with financial support from the European Commission’s Next Generation Internet programme, under the aegis of DG Communications Networks, Content, and Technology.