Revisiting Flappy Bird – The Pain Point
Remember our Flappy Bird example from mid-2025?
The long chain of variable initializations was needed for two main reasons:
- No way to declare variables before using them
- More critically - no way to define custom data structures that could group related values together and be instantiated with a single node.
In retrospective it seems obvious: we just need proper structured data containers. But building the scaffolding to support this properly in a visual, node-based system is a bit more involved.
Searching for a Solution
I spent a long time trying to bring OOP concepts into Divooka. A huge amount of effort went into DiOS (Divooka Open Standards), with the hope that a complete standard would naturally solve these kinds of problems. But standardization work is slow and deep - just like making Divooka itself feature-complete.
Then, while working on something completely unrelated and taking a short break from this topic, it suddenly clicked.
The key insight: start simple and approach it from a functional/declarative angle first, before jumping into inheritance, encapsulation, polymorphism, and all those good stuff.
I'm really excited - we finally have meaningful progress.
The Divooka Way
To claim our goal as "everything is a node" is a bit too strong, but I strongly prefer keeping almost everything on the graph.
This aligns with how we already handle structured primitives - direct value setting of compound inputs. That way, there's still hope that users can drop down to raw node programming when they need full control (and thus keep everything programmable).
Traditional property panels (like Unreal Blueprints' object definition GUIs) are out - they break the pure graph paradigm.
Instead, the solution is declarative, similar to how TerraGen works: the mere presence and connection of certain nodes defines meaning.
This feels awesome for several reasons:
- We can make full use of the 2D graph layout - place things exactly where we want them visually
- It stays completely coherent with Divooka's graphical paradigm
- No need for separate "class editor" UIs
What's Been Implemented So Far
Current working pieces:
- Graphs can now act as modules
- Support for module-level data members and behavior members
- A main module tied to the document, with existing graphs serving as associated behaviors
Module-scoped instance node – in Events context
Module-scoped instance node – in Dataflow context
Top-level module behavior graphs
This immediately unlocks:
- Clean access to (top-level) module instances
- Shared event and dataflow instance data
- A unified programming and document model for subgraphs (still a work-in-progress)
- In procedural contexts (Glaze! especially): we now have proper data containers - no more awkward giant variable lists or forced tuples! (Compare to the old Flappy Bird screenshot)
- Much simpler and more natural state storage/access in Glaze! and procedural graphs
This is a big deal - for a system that's gearing up for real production use, it feels like crossing a major milestone in usefulness and core abstractions.
Current Limitations & Remaining Work
Still plenty to fix/polish:
- A bunch of bugs and edge cases
- Proper serialization support
- Smooth context switching between graphs
- Subgraph consolidation / better nesting UX
Looking Ahead
This is a solid foundation, but there's still a long road:
- Full modularization support
- Modules inside modules (nesting)
- Module inheritance / composition patterns / polymorphism
- Base DOM exposed as the "main module" for metaprogramming API
- Detailed documentation: how it all fits together, recommended usage patterns, expected behaviors, pitfalls
- Module-level scoped instances (deeper/finer control)
Overall - I am very happy with the direction. It feels like Divooka is finally getting the abstraction power it deserves while staying true to its visual, graph-first philosophy.
I am hyped for what we will achieve.
Top comments (0)