We’re happy that we finished the separation of VR Builder Core. The new structure is more modular and fixes the engine dependency completely. But there are still bugs on the Unity side that need to be fixed now (yey!). A good thing is that there are VR Builder tests to make sure that the changes we made can be validated by the unity engine tests. If every test passes, the refactored system (should) has the same behavior, but the tests are not covering all code lines, so the behavior is not 100% the same. Every bug that we find will be added to the tests of VR Builder.
Refactoring and library structure#
The last blog post explained how we refactored the architecture of VR Builder and the introduction of the new service locators.
It’s not complete yet (and it will be a mess if it is done), because the whole structure is complex. With this architecture diagram it’s easier for me to understand the architecture, and it’s a nice spagetti picture! So the current result is a separated Godot package called TinkerFlow Core. Which is used by TinkerFlow Debug, a Godot sample Project to test the whole package and editor-based implementations. This Godot-Project should also contain a demo scene with 3D Elements and sample processes that can be edited or played.
Successfully compilation on Unity#
The picture below shows the great success so far. We created an empty Unity project, added the refactored process engine and the refactored VR Builder core. The project compiles and throws no errors while compiling. But we are far from a running system, where everything works on editor-time or runtime. The mentioned service pattern and refactored architecture need to be applied to the existing VR Builder structure. We have to face problems like newtonsoft-json serialization, editor-based events, new scriptable objects and editor-based settings that need to be fixed again.
Initial tests with the pre-build VR Builder unity tests show 407 passes and 123 errors (with 83 endless loops). This is related to the changes of how the process and gameobject handling were changed because of the now engine-independent process runner.
Successfully compilation on Godot#
On the Godot side is the initial compilation is also successful. The first tests with the process running at runtime work, and the editor-based rendering of the process as well.
(See upcoming blog posts for more details).
TinkerFlow controls the process engine, and the interaction with it is slightly different, so we need to think more of how we want to interact and provide tools to the end user or developers. We want to be more experimental than the VR Builder inside Unity. Keep updated and take a look at our upcoming posts to that!
Additional documentation#
This Website (the landing page and this blog) is our documentation and the main entry point for all developers or contributors. We may add some more content related to business use cases or for agencies and educational purposes. The source of our website can also be visited under codeberg.
Additional structured content snippets of TinkerFlow can be found on our wiki page at codeberg. The API specification can be found here under API.
Tutorials are planned under Guides, where tutorials, guides, and helpful information can be found to get started with TinkerFlow. E.g. getting started with TinkerFlow, how to create a process, how to set up VR at Godot, how to export a TinkerFlow project.
Overall important links as a collection
Project Group: https://codeberg.org/TinkerFlow
Forked Core Runtime: https://codeberg.org/TinkerFlow/VR-Builder-Core-Runtime
TinkerFlow Core (actual package): https://codeberg.org/TinkerFlow/TinkerFlow-Core
Godot test project: https://codeberg.org/TinkerFlow/TinkerFlow-Debug
Project management and milestones: https://codeberg.org/TinkerFlow/-/projects
Documentation and website source: https://codeberg.org/TinkerFlow/pages/src/branch/main
If you want to get more information, please visit our project group at codeberg as well!