We could have a syntax (for .py and .hx) that allows us to implement inheritances between logic nodes, with a node editor and a symbology/node naming that highlights those inheritance links between nodes ?
The advantage would be an easier maintainability and reusability of code.
2 Likes
Yeah, I’ve thought a little bit about trying to somehow implement interfaces in nodes because they are so useful in programming. I’m prototyping out a game and sooner or later I’m probably going to get to the point where I need that. Once I get there I’ll probably be attempting to make something roughly along those lines at least.
1 Like
Another interesting possibility too could be to encapsulate an entire node tree as a new logic node, again for less code/spagetti and easier maintainability.
(The “in” could be so corresponding to a kind of special On Event in the node tree and the others inputs as specialized local properties in the node tree; idem for outputs with a Send Event and specialized set property )
Those nodes could have a special name, like a “package” with in a "self.inputs.new(‘NodeSocketString’ " name to design/define/call it.
Thus we could call them inside a node tree, while their inner workings remain hidden, as we do with actual logic nodes.
Thus some main benefits of using logic nodes “package” seems for me :
- implementation details of the node package can be hidden, as when using actual logic nodes,
- as “logic nodes package” contents are placed in a separate node tree, thus we allow preventing naming collisions (not sure always the case today between actual node trees ( as for example when using with animation the notifyOnUpdate(…); ),
- as with others logic nodes, it can be separately verified / tested/ compiled (it’s a great advantage to have the various parts of our Armory applications, as with logic nodes, that are compiled with no knowledge of the other compilation units with which they will be combined like in node trees). Making logic node package increases this security/reliability of our applications.
Thus to define those possible logic node package, some of the more common of them could be:
- a group of related logic nodes, as it is done in a node tree, along with their shared data/events, with those data/events not visible outside the logic node package,
- one or more data/node types for manipulating (as with specialized event and property).
Also it could be interesting to create a new kind of Node tree, only used to create a new logic node package, thus with some goodies to help/verify rulls for creating a new “logic node package”.
Then making logic nodes package with inside others logic nodes packages could lead to shape genericity and inheritance and could be visualized inside this new kind of Node tree editor.
1 Like
That topic has come up a few times. Material nodes, already have node groups and we might be able leverage the same thing in Logic Nodes, even if we wanted to extend the concept a bit. It is definitely something that we will want to pursue.
Function nodes, help a little bit with the separation of concerns, but it isn’t solution for every situation.
sure @zicklag and we are not far from that … we have some avenues to explore that can already be used/reused to approximate inheritance and logic node package … and maybe that as a first step it could be done at home by simply specifying/defining some design rules, in order to simulate/approximate it already today using:
- inheritence between logic nodes, with the already existing “extends” keyword for class in haxe and with some design constraints to follow.
- a preliminary logic node package could be already kickly defined reusing the code of the Call Node Group and with some new design rules and logic nodes to be defined. (for example a new node that is the sum of the Call Node Group + Send Event Node can be the starting point …)
2 Likes