Here is discussion on Nodal Logic in blender.
Python Linked Nodes
Wouldn't it be better to have each logic node just be in place of some python code? That way developers can easily create new nodes, and people not as good at python can use more advanced logic. -Anthoni
Regression / Completness
Need to go thru all current logic bricks and ensure there's a node for what they do. --Roger
Need a gaming network set of nodes to send/receive IP messages. Initialize/test connection speed, Get should include address it got from and packet value. Should also then have a packet decoder/encoder that puts a set of property values into a packet and sends it out.
Going through and implementing each node with Python would expand the BGE API, which would benefit the BGE Community.
Graph Ownership / Targeting
- Each instance of a graph, and all the nodes contained within, are owned by a single object.
- Other objects passed to nodes as parameters as required. If not provided, the owner object is used as the target by default.
- Setting the target of a nested node graph sets the target for all nodes contained within it.
Calling Other Scripts
It can be useful for encapsulation to be able to invoke a script on another object. For example, you might have an object in the scene that renders text. Scripts attached to other objects use this central text renderer. To draw a string you could set a property on the text renderer, but then the text might not be rendered until the next frame. It would be better to be able to invoke the text renderer's script directly, or be able to send it a message with a zero-frame delay. -- Z0r
Playing The Devil's Advocate
I think a node system where connections can start going in any direction could get more confusing than the current layout. Right now, the "selected" "active" "linked" buttons are actually really good content filters. Don't think that using nodes similar to those being used for compositing will make things look cleaner. Being able to mix coded bits and block bits is a nice state to be in if you're making a prototype. It makes things go faster and keeps the user thinking instead of defaulting in to stupid mode. Read this blog post: http://www.flight404.com/blog/?p=41 I think this guy has a good sense of just how distracting nodes for programming can be. Most of your time you spend just moving the nodes around trying to make their arrangement look pretty. At least right now, while doing that is impossible, it keeps me from trying to even bother, which in turn makes me more productive. That's my two cents. -- Bmud
Certainly, nodal programming can be slower than writing code - especially when you're dealing with low-level things like arithmetic. But nodes can be really powerful when they encapsulate some complex logic. Then you can look at problems from a very high level. So writing code will still be important, but nodes will make the code easier to re-use by a wider audience. Notice that the proposal includes the idea of defining new nodes with Python. Also, I find the current system unmanageable: if you open a file after a couple of months of not editing it, it is very difficult to see how the logic works. It's a complete mess. Compositor-style nodes can and should be arranged to be pretty - it will make your life easier later on. -- Z0r
Response to recent edits, 7th of November 2009
Great update! Just some suggestions:
- -1: Timer Value: [...] If start > finish, it connotates a countdown timer. Good idea, but I think this will actually make it harder to use. If Start > Finish it should just activate its Finished output. This way the scripter doesn't need to check their inputs so thoroughly. We should have a separate Countdown Timer node, or allow the timer to be configured by setting a property on it.
- Where a node operates on an object, it's name has to be selected on the face of the node [...] Can we also specify the object by a connection to another node? This would allow e.g. iteration over a list of objects.
- Property Set: [...] This can be a user-defined property, or a standard property like rotation. Doesn't this go against the recent changes to the Python API, which clearly separates built-in properties from user-defined ones? Compare object.property vs object['property'].
One of my most-desired features is a debugger. Please, let's design this system so that scripts can be debugged. This is how I see it working:
- A breakpoint can be set on any node.
- When execution reaches a node with a breakpoint, the game is paused. Control is returned to the main Blender UI. The current node is highlighted, and the values of outputs can be inspected.
- Execution may also break if a node throws an exception, e.g. if one of the inputs in invalid.
- The user can step through execution of the script, node by node.
- When all nodes have been processed for this frame, the frame is rendered. Execution breaks again at the first node on the next frame.
- Regular game play resumes when the user instructs the debugger to continue (via a button or keypress).
Even if this isn't a feature of the first release, it would be great if the nodes were designed to accommodate it. Python debugging would be great too :) Z0r
Is it possible to construct behavior trees using this model. It seems to be a very powerfull approach to game AI and would make the task of describing game character behaviors much more comprehendable. See http://aigamedev.com/open/articles/behavior-trees-part1/ for a quick introduction. Used in e.g. Halo. (Sorry if this is not the correct place to put suggestions like this)