Comment by kgeist
11 days ago
In a node-based engine, everything is just a graph of mostly ready-to-use nodes, all you do is create nodes, parent them, delete them; behavior can be attached to specific nodes. There may be no clear boundary where an entity "begins" and where it "ends", because everything is just a bunch of nodes. I'm not sure why the author is against it, in a proper engine you can quickly prototype mechanics/behaviors by just reusing existing nodes/components, and it's very flexible (say, I want to apply some logic to all child nodes recursively -- no problem; or I want to dynamically remove a certain part of a character -- I just unparent the node), and often such engines allow to test things without stopping/recompiling the project. On the other hand, OP's engine apparently requires you to do everything by hand (subclass Entity in code) and recompile everything each time. Basically, a node-based engine is about composition, and OP apparently prefers inheritance.
I still can't really picture this. (And I've googled the concept to no avail. Is there a high-level overview anywhere? Even one specific to a certain game engine would be nice.)
I was initially picturing a DAW VST node graph, where nodes are all effectively top-level-peer specifications to build top-level-peer actors; and the connections between nodes represent dataflow relationships that should be established between the actors.
But is this behavior actually more like:
• a browser DOM, where the nodes (DOM elements) themselves have types — with live behavior that depends on their types and statically-configured attribute values — but where this behavior only comes into play when a node is parented into a live "document" (where you can build nodes or entire subtrees outside of the document, hold onto them + manipulate them, and then attach/detach them to instantaneously activate/inactivate them); where all nodes are containers for child nodes whether they like it or not; but where node types are free to decide what their children "mean" — i.e. whether the children participate in the document as they expect (like nodes under an HTML <div> tag), or whether they are passivated, acting only as private information for the parent node to consume/reference (like nodes under an HTML <picture> tag, or under a Shadow DOM shadow-root)?
• the node graph acting as something like an AST in a Lisp, where a tree-walker component "executes" the graph by recognizing nodes as macro functions, and calling those functions, passing in their parsed-but-not-evaluated "raw" child-subtree ASTs, expecting to get typed entities back in return?
• or something else, that I don't even have a mental model for?
There may be no clear boundary where an entity "begins" and where it "ends"
Is this useful to not know where the boundaries are? Sounds like it can become a night mare.