Variable Categorization

gumbomasta 4 years ago updated 4 years ago 6

In objects that hold a lot of variables, Categorization has been a helpful tool for sorting them and looking them up at a glance.  It has no bearing on the logic of the game - simply serving as an aesthetic sorting tool in the editor.  Is this something you'd consider implementing?  

Bolt Version:
Unity Version:
Scripting Backend:
.NET Version (API Compatibility Level):
Satisfaction mark by gumbomasta 4 years ago

I have not used Bolt long enough to have that many object or scene variables, but I can see it eventually getting out of hand on some objects that are intended to have a lot of communication with others. I was also thinking there should be some sort of coloring, grouping, or searching something down the road. Would make it much more readable, when different macros have their variables intermingled. Ones intended for public use. Good suggestion.

I just wanted to bump this - any idea if this would be worth considering in a future release?

Under Review

Hm, I'm having a hard time seeing the context in which you have so many variables that categorizing them would help. Can you give me an example case? Also, how would you see the UI for this? 

this is a playmaker FSM in my current project that handles character dialog:


These are all variables that I've created and assigned.  

For a complex FSM like this, the ability to sort a wide variety of variables into categories that are relevant to the task at hand is extremely useful for at-a-glance adjustments and debugging.  Notice how I crated several categories: Controls, Routing, Text Properties, Setup.  Again, their categorization has no direct impact on the logic itself - it's purely used as a visual sorting tool. 

Thank you for considering this.


Actually I'm going to decline this, but only because you've given me a much better idea!

Basically what you were trying to do here is expose variables as configurable parameters.

A much better place for this would be the graph input node. However, the ports in the graph input cannot be shown in the inspector of the parent flow machine... But they could! Then it would look a lot like your screenshot above.

More information in the idea thread here:


If it achieves the functionality you say, and offers visual clarity in the inspecter, I think it's a worthwhile approach.   I look forward to its implementation.