This is very much a product of the UI not "communicating" well with the reader/user -- (@Unity -- see this topic). Somebody once said -- "A game is just a database with a fancy interface." I would agree. DOTS would concur as well, if it could. Thinking along these lines -- Variants should really be more easily translated into specific instances, in order for the "prefab" workflow to be more easily communicated. For example, I had no idea that a "Variant" wasn't the gameobject instance itself -- (i.e. the instance I was supposed to be using in the world), so I created tons of variants with only VERY slight changes to their values (sprite/model, jumpheight, canjump, etc.) and had tons of these slight variations laying around (i.e. one variant with only the sprite/model and jumpheight, another variant with only the jumpheight, another variant with just sprite/model and canjump, and another variant with only the sprite/model). THIS IS TERRIBLE and really sucks when a simple template prefab (a special "variant" of a prefab with user-marked fields that can and will change) would be a LOT better to have -- especially for DOTS. You could have multiple versions of this template prefab, but you would rarely have MANY -- which is the valuable thing here, in terms of authoring AND performance. This is the one thing that drives me mad about NestedPrefabs. Please don't repeat this mistake in VisualScripts. DOTS would handle sweeping changes of the look/feel types of behavior for me in my behavior VisualScript instance if it had a VisualScriptVariantTemplate. Need a new behavior that _only_ changes color, model, shader, etc.? -- Make a VisualScript "Variant" instance from a template and call it (with whatever values in whatever fields you want to change) whenever you like. Simply run it with the hard-coded authoring changes made in the Editor's hierarchy or another VisualScript. Just treat them as instances until they are converted into "templates" or into ready-to-use "drop-in" prefabs/scripts/nodes/states. Until then, make it easy to change/author them without worrying about "Applying Changes" to specific whatevers (fields/componets/etc.) Variant Instances The TemplateScript could be a Variant that reference fields from a "ready-to-use" PrefabScript, but instead of directly changing these fields (i.e. model component / sprite component / size / color / etc.), it simply marks certain fields as changeable, leaving the others "immutable" -- this lets you reference (and chunk) only one instance of the locked data, while processing MUCH smaller chunks of data (that actually changes) in particularly complex gameobject-based entities. These would be known as "Variant Instances" -- These would simply let less processing take place because data has been pre-filtered via the user's input (rather than using searching tags for chunks, as we currently do for Entities). This would let more efficient script systems be built on top of (entity-level) systems -- which I don't think @Unity is doing right now. Please correct me if I'm wrong on this though, @ans_unity -- I would really love some clarification. Anyway, these "Variant Instances" would allow one to very easily author a complex StateMachine system (like the one described here) using a purely template-based (gameobject/nestedprefab/variant-styled) workflow. You'd just use TemplateNodes that have a particular type of property/system associated with them that can be used as an argument provided to it when executing one of these nodes after calling it in another VisualScript (and providing it arguments to specify the field value).