Suggestion: Sheet‑Owned Custom Variables With Designer‑Friendly UX

[CG-Tespy]

Overview

Introduce a system that lets each Event Sheet define and manage its own set of variables. These variables would be local to the sheet, editable through the Event Sheet editor, and usable across Actions and Conditions. This gives designers a structured, visual way to store and manipulate data without relying on global variables or external scripts.

What the Feature Includes

• Per‑Sheet Variable Sets
• Each Event Sheet can declare its own variables. Supported types could include int, float, string, bool, and Node references.
• Designer‑Friendly Editing UI
  • The Event Sheet editor would expose a foldout panel containing a scrollable list of variables. Users can add, rename, reorder, and delete variables directly from the UI.
• Custom Variable Types
  • Advanced users can define their own variable types with custom editor widgets.
  • FlowKit would auto‑detect these types and integrate them into the variable picker.
  • This is similar to how Fungus handles custom variables in Unity.
• Integration With Actions/Conditions
  • Variables become first‑class citizens in the visual scripting workflow, usable anywhere values are referenced.

Why This Is Valuable

• Improves data handling for designers
  • Users can manage state directly within the sheet that needs it, without jumping to GDScript or global registries.
• Enables smoother cutscene and story logic
  • Local variables make it easier to track temporary state, flags, counters, and references during narrative sequences.
• Supports FlowKit as a story‑centric eventing system
  • This aligns with workflows common in tools like Fungus, Yarn, and RPG Maker, making FlowKit more approachable for narrative designers.
• Reduces clutter in global systems
  • Sheet‑local variables prevent the global variable space from becoming a dumping ground for one‑off values.

Why This Should Wait

This feature touches several core systems: FlowKitEngine, FKMainEditor, serialization, and the Action/Condition value pipeline. Implementing it now would be risky because:

• The editor and engine are still being modularized.
• Adding variable definitions, UI, serialization, and runtime access before that work is complete would create tight coupling and technical debt.
• Refactoring after implementation would be significantly harder.

Once the editor and engine are more modular, this feature becomes far easier to implement cleanly and maintainably.

[Lexian-droid]

This sounds like a good idea 👍