Another Idea by me that would love to see implemented in the engine.
simple use case.
Imagine in the actual system to have a warrior slice and 2 cascaded slices minion and hero.
warrior has an attack of 1 where minion has 0.2 and hero has 3.
If I change for whatever reason the warrior attack to 2 minion and hero attacks are now still the same but what if I want minion and hero to react to this change letting me to evaluate a new value from the base one by some kind of formula?Actual implementation didn’t make it possible.
A system that let me relate this data would make for a faster way to tune things like easy buff and nerf for balancing purposes and also open the way to may truly powerfull workflows in art and gameplay fields.
In sidefx Houdini for instance whenever you can input a value you may replace it with a script where you can access global variables or even refer to whatever object trough a relative or absolute path system that maps the entire scene.
This is a quite complex system and having too much wide scoped references dangling around could not be a great idea, but adding some simplification and constraints it may be mapped to the lumberyard editor to achieve an unprecedented powerful worflow.
My Proposal for the system is to use python as just present in editor, and to limit the value scripting enviroment to:
a variable representing the last inherited manual value(before that the value switched to evaluated one in that case you simple inherit the script you can override)(imagine it being called $ or whatever) so I can convert minion attack to script and then input “return $ * 0.2” the engine will evaluate the script and try to cast to the required valuetype.
When the parent slice get updated the system also evaluate the script again.
Scripted values need to show evaluated value + a button to access the script source.
References to more focused external data by ad hoc Data Interfaces and Sources.
A central manager component that runs in the editor may manage all the registered data sources and arbitrate bindings and check for dangling references. This component will call the update on script that references dirty values.A runtime version of this manager component may exist using ebus to query data at runtime.Data Source can register to one or both of them to have both or just editor or runtime relevancy.
Data Sources are read only and generally will be generated from assets.Value Scripts will access to this data in very simple way so you can script things like “return chardata.warrior.attack * chardata.minion.attackmul” where chardata is a namespace contained in a Data Source implementing the Data Interface registered to the editor datasource manager .Then I may change the asset relative to this data source and everything dirty get evaluated and ready to be tested.
Programmers can create data sources classes that register to the datasourcemanager of choice and implements data interface so the script can leverage every kind of custom sources.
Editor may ship with basic data source classes for designers for instance one based on a json file.
Just imagine people implementing the interface using a custom asset generated by the asset processor from whatever source file and the editor can inspect this data and Script can access it.
People may implement excel importing to make a system leverage the data generated by complex excel formulas and just have entities use it.
Another Source may use a node based editor implemented in the editor that generates a large amount of procedural data and implementing this interface this data could be exploited from any entity.