Nodes logic, it is viable?

What good an integrated game engine, when you can’t work with nodes?
I think node framework is going to be the #1 designer tilt option, when it comes to choose among the Game engines.
I work in unity3d , have worked a bit in unreal engine too. For me, scripting for game isn’t something uncommon, but for majority of developers / designers having a good node based framework is essential, since the put more work towards design then scripting.

1 Like

Nodes shouldn’t be abdomed, it can be real usefull for non-programmer and can also be useful for prototyping.
Lubos should work more on haxe and less on nodes and should depend on community to build more nodes.
About node documentation, I am working on it. I created pull request for LOGIC node documentation(need to be accepted by lubos), only Inverse, switch, To Bool, left in Logic Nodes doc. Then i will move to other nodes doc.
Here my pull request ->

Don’t get me wrong , i like nodes scripting, its what i use with Unreal 4.
But it is lot of time and effort trying to get nodes up to date to Haxen, and getting better nodes (see my explanations above).
It would diminish a lot Lubos work focusing only on one programming language instead.

It’s more about nodes needs a full redesign than documentation (variables reference names, vector outputs for example , rotation and transform) or some nodes not working.

Give him some break. Armory3d is very far away from being a proper game engine, it’s only on 0.5 version, not even on 1. Lot’s of stuff is needed. I feel frustrated working with it, and to be honest, Haxe is like learning another language (i don’t know anything about python, but c#,java are quite different).
But i would suggest Lubos to put more work on logic nodes, instead of Haxe, since majority will be using the logic nodes.


Yes. I agree with you. Documentation is a must. I tried reading some of the code of nodes, and to be very fair, it looks like spaghetti code.
Most nodes don’t work. Node colors are not consistent, nor they provide information about what type of input is their.

Perhaps you are right, perhaps nodes should get some priority.

I mean most Blender users are artists, most are not coders and will use nodes.


biggest problem for me is the spaghettiying with bigger setups. As time goes on there needs to be a way to have a value somewhere without a cable connecting it from 3 miles away.

1 Like

Nodes are an essential part of armory. They are the thing that lets artistts become interactive content creator. I have done all my work in nodes for over 20 video tutorials. Is it perfect ? Hell no. But I can make a lot work and am still getting more to work all the time. And as stated we are still in alpha or beta. With lots of work to do yet.
I have been looking into Lumberyard and Godot visual scripting and there are completely different from each other. It is so awesome that this was even part of this project from the beginning. With the caliber of the people on this forum we should be able to help built all kinds of nodes and add abilities to them like passing information. I was under the impression that we were here to learn and help improve the engine.
I suck at coding but have been able to figure most of it out and even sort of help in the development of a couple new nodes. Together we can do that.


It would be great to figure out how to do groups for the logic nodes like you can for the material nodes.

Lot of spaghetti would disappear with better nodes, variable name references for example that does not need to connect to the original variable node.

A reflexion about a model near the MVC one could improve this spaghettis problem too.

I still like how Sverchok avoids some node spagetti with the poorly named wifi in/out nodes. Its really just kind of hiding some of the noise but every little bit helps!

You can already do it with array and index …
I would prefer to have something like a named point like what is used in PCB design tools.

For your info a post was about meta nodes too … "Meta" Nodes

But really I think that if you have a spaghetti problem, it is more due to an architecture software design problem than to the nodes capabilities.

Nodes are incomplete.

Each node variable should have a name and could be referenced anywhere

This would decrease the connections to variables.

1 Like

Hey I created whole new thread regarding Improving nodes.
Maybe you can put your answer there can all can understand what i am talking about in third point.

if I may, you have already that with Set Property and Get Property ?

It’s not the same.Property is for object properties.
While variables you create in the graph doesn’t have a name.

@MagicLord If really necessary, you can set a property on an Empty that you call “my variables” and Set/Get Property that do the job ?
Otherwise with Array and Index you can simulate a Bus like on an eletronic card.

Considering the first remark of @Simonrazer seems point on “How to organize spaghetti ?”
If it can help you, I think that you have to ask yourself some usuals simple Software Architect questions like thereafter :slight_smile:

  1. Do I start redesiging/rewriting everything/refactoring ?

  2. Where to start ?

  3. How to start it ?

  4. What to change in first ?

With 1, for example, I think that you have to consider in first some simple points like :

  • the behavior of the whole application is it well understood ?
  • Is the spaghettis tangled in a large loop or in sub nodes paquets?
  • Do my traits have a high cohesion ?
  • Is it a question of performance or testability ?

This kind of approach for example could be inspring for a new Architecture design tool with Nodes in Armory.