5 ms·

"A thing should be a thing. It should not be a bunch of things pretending to be a single thing. With nodes you have to pretend that a collection of things is a

"A thing should be a thing. It should not be a bunch of things pretending to be a single thing. With nodes you have to pretend that a collection of things is a single thing." Just want to say this line was great, very Terry Pratchett. Feels like something Sam Vimes would think during a particularly complex investigation. I love it and hope you keep it moving forward. Haven't gotten a chance to mess around with it, but I have some ideas for my AI projects that might be able to really utilize it.

jorl17 2y ago
This quote looks like it could have been written by Alberto Caeiro, right before he would turn around and apologize for putting too much thingness into things, less they become less thingy in the eyes of us over-thingers.
tines 2y ago
In isolation, isn't the quote prima facie so bad and so wrong though? We think of collections of things as single things constantly. A human is a collection of body parts, body parts are collections of chemicals, chemicals are collections of molecules, molecules are collections of atoms... and yet at each level we think of those collections as being single things. Not being able to do that is just... absurd. The project looks awesome though.
- CrimsonCape 2y ago
  Agreed. Type systems are nearly always "temporal" yet are too simply designed to address that. "Temporal" to mean that at any given slice of time during a running application all objects have a signature that matches a type. Yet most programming languages only allow compile-time analysis and "runtime" is treated as monolithic "we can't know at this point anything about types"
- devin 2y ago
  I think maybe it is intended as a critique of systems where the individual parts don't compose or scale particularly well, where it feels sort of hollow to call it a "system" because of how uncoordinated and inefficient it is at the "single things" layer.
- jjslocum3 2y ago
  Yes! In programming speak, you're talking about levels of abstraction.
- stevage 2y ago
  I think the point is that a body is obviously and intuitively a thing, and doesn't need any pretending. Whereas take something like a marketing brand that has been spread too thin over a bunch of disparate products, everyone has to pretend really hard that it is one thing.
- throwaway290 2y ago
  The thing about nodes is a joke like around 80% of the text.
derefr 2y ago
This quote is likely intended for people who've tried other solutions and disliked them, but as someone who's never used a game engine of any kind, I'd appreciate someone giving me an ELI5 of how "nodes" relate to "pretending that collections of things are things." Is the problem here that using a nodal editor encourages/incentivizes you through its UX, to assign properties and relationships to e.g. a `Vector` of `Finger`s — but then you can't actually write code that makes the `Vector<Finger>` do anything, because it is just a "collection of things" in the end, not its own "type of thing" that can have its own behavior? And does "everything is an Entity, just write code" mean that there's no UX layer that encourages `Vector<Finger>` over just creating a Hand class that can hold your Fingers and give the hand itself its own state/behavior? Or, alternately, does that mean that rather than instantiating "nodes" that represent "instances of a thing that are themselves still types to be further instantiated, but that are pre-wired to have specific values for static members, and specific types or objects [implicitly actually factories] for relationship members" (which is... type currying, kind of?), you instead are expected to just subclass your Entity subclass to further refine it?
- kgeist 2y 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.
  - derefr 2y ago
    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?
danbolt 2y ago
I think the paragraph after is really interesting: “Also when creating things with nodes, you have to go back and forth between node GUI and code.” You can see Godot’s Node/GDScript setup as a bit of a response to this argument. Or, they try to make the “going back and forth” as seamless and integrated possible with things like the $ operator and autocomplete. That said, I do think at the end of day, the “thing is a thing” mindset ultimately prevails, as you have to ship a game.
- whoknowsidont 2y ago
  The problem is "a thing is a thing" only gets you those exact things with those exact thing-behaviors. Sharing behaviors or making things look or act like a little bit like this other thing becomes an absolute nightmare, if not out right impossible, with "a thing is a thing." There's a reason graph based systems or ECS is basically the corner stone of every modern engine. Because it works and is necessary.
- notnaut 2y ago
  I’ve been trying to learn godot for years and I’m not doing so hot. This chatter feels very relevant to my struggles but I’m not the best with software design, so what do I know? I was in a tizzy the other day and spammed my thoughts out about it, I hope it’s relevant here. trying to wrap my head around using scenes vs. nodes in something simple like a 2d platformer. Platforms: My thinking: I'm gonna be using a ton of platforms, so it'd make sense to abstract the nodes that make up a platform to a scene, so I can easily instance in a bunch. Maybe I'm already jumping the gun here? Maybe having a ton of an object (set of nodes) doesn't instantly mean it'd be better off as a scene? Still, scenes seem instinctually like a good idea because it lets me easily instance in copies, but it becomes obvious fast that you lose flexibility. So I make a scene, add a staticbody, sprite, and collision shape. I adjust the collision shape to match the image. Ideally at this point, I could just easily resize the parent static body object to make the platform whatever size I want. This would in theory properly resize the sprite and collision shape. But I am aware it's not a good/supported idea to scale a collision shape indirectly, but to instead directly change its extents or size. So you have to do stuff based on the fact that this thing is not actually just a thing, but several things. This seems like a bad idea, but maybe one way I could use scenes for platforms is to add them to my level scene and make each one have editable children. Problem with this is I'd need to make every shape resource unique, and I have to do it every time I add a platform. This same problem will occur if I try duplicating sets of nodes (not scenes) that represent platforms, too. Need to make each shape unique. That said, this is easier than using scenes + editable children. Ultimately the ‘right’ way forward seems to be tilemaps, but I wanted to understand this from a principles perspective. The simple, intuitive thing (to me) does not seem possible. When I ask questions about this kind of stuff, 9/10 times the suggestion is to do it in a paradigmatic way that one might only learn after spending a lot of time with an engine or asking the specific question, rather than what I would think is a way that makes dumb sense.
jameshart 2y ago
It sounds like the sort of thing Sam Vimes would say before being begrudgingly forced to admit, after being forced by Sybil to undergo some painful personal growth, that maybe, sometimes, a thing might need to be more than just a thing. And that Vetinari’s entity component system might seem complicated but it works, damnit and it makes the city function.
- tsumnia 2y ago
  And once Nobby says he likes Tramway, everyone realizes Vetinari was right all along XD (I'm just glad someone got the reference)
  - lelanthran 2y ago
    > And once Nobby says he likes Tramway, everyone realizes Vetinari was right all along XD Well, except for Detritus
    - tsumnia 2y ago
      Well OBVIOUSLY except for Detritus! Things is too many things to count.
      - atombender 2y ago
        Unless we are talking about liquid-cooled Detritus.
taneq 2y ago
Unfortunately everything is a collection of things pretending to be a single thing, even single things. The best we can do is pretend, or avoid finding out.

jorl17 2y ago

This quote looks like it could have been written by Alberto Caeiro, right before he would turn around and apologize for putting too much thingness into things, less they become less thingy in the eyes of us over-thingers.

tines 2y ago

In isolation, isn't the quote prima facie so bad and so wrong though? We think of collections of things as single things constantly. A human is a collection of body parts, body parts are collections of chemicals, chemicals are collections of molecules, molecules are collections of atoms... and yet at each level we think of those collections as being single things. Not being able to do that is just... absurd. The project looks awesome though.

CrimsonCape 2y ago
Agreed. Type systems are nearly always "temporal" yet are too simply designed to address that. "Temporal" to mean that at any given slice of time during a running application all objects have a signature that matches a type. Yet most programming languages only allow compile-time analysis and "runtime" is treated as monolithic "we can't know at this point anything about types"
devin 2y ago
I think maybe it is intended as a critique of systems where the individual parts don't compose or scale particularly well, where it feels sort of hollow to call it a "system" because of how uncoordinated and inefficient it is at the "single things" layer.
jjslocum3 2y ago
Yes! In programming speak, you're talking about levels of abstraction.
stevage 2y ago
I think the point is that a body is obviously and intuitively a thing, and doesn't need any pretending. Whereas take something like a marketing brand that has been spread too thin over a bunch of disparate products, everyone has to pretend really hard that it is one thing.
throwaway290 2y ago
The thing about nodes is a joke like around 80% of the text.

derefr 2y ago

This quote is likely intended for people who've tried other solutions and disliked them, but as someone who's never used a game engine of any kind, I'd appreciate someone giving me an ELI5 of how "nodes" relate to "pretending that collections of things are things." Is the problem here that using a nodal editor encourages/incentivizes you through its UX, to assign properties and relationships to e.g. a `Vector` of `Finger`s — but then you can't actually write code that makes the `Vector<Finger>` do anything, because it is just a "collection of things" in the end, not its own "type of thing" that can have its own behavior? And does "everything is an Entity, just write code" mean that there's no UX layer that encourages `Vector<Finger>` over just creating a Hand class that can hold your Fingers and give the hand itself its own state/behavior? Or, alternately, does that mean that rather than instantiating "nodes" that represent "instances of a thing that are themselves still types to be further instantiated, but that are pre-wired to have specific values for static members, and specific types or objects [implicitly actually factories] for relationship members" (which is... type currying, kind of?), you instead are expected to just subclass your Entity subclass to further refine it?

kgeist 2y 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.
- derefr 2y ago
  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?

danbolt 2y ago

I think the paragraph after is really interesting: “Also when creating things with nodes, you have to go back and forth between node GUI and code.” You can see Godot’s Node/GDScript setup as a bit of a response to this argument. Or, they try to make the “going back and forth” as seamless and integrated possible with things like the $ operator and autocomplete. That said, I do think at the end of day, the “thing is a thing” mindset ultimately prevails, as you have to ship a game.

whoknowsidont 2y ago
The problem is "a thing is a thing" only gets you those exact things with those exact thing-behaviors. Sharing behaviors or making things look or act like a little bit like this other thing becomes an absolute nightmare, if not out right impossible, with "a thing is a thing." There's a reason graph based systems or ECS is basically the corner stone of every modern engine. Because it works and is necessary.
notnaut 2y ago
I’ve been trying to learn godot for years and I’m not doing so hot. This chatter feels very relevant to my struggles but I’m not the best with software design, so what do I know? I was in a tizzy the other day and spammed my thoughts out about it, I hope it’s relevant here. trying to wrap my head around using scenes vs. nodes in something simple like a 2d platformer. Platforms: My thinking: I'm gonna be using a ton of platforms, so it'd make sense to abstract the nodes that make up a platform to a scene, so I can easily instance in a bunch. Maybe I'm already jumping the gun here? Maybe having a ton of an object (set of nodes) doesn't instantly mean it'd be better off as a scene? Still, scenes seem instinctually like a good idea because it lets me easily instance in copies, but it becomes obvious fast that you lose flexibility. So I make a scene, add a staticbody, sprite, and collision shape. I adjust the collision shape to match the image. Ideally at this point, I could just easily resize the parent static body object to make the platform whatever size I want. This would in theory properly resize the sprite and collision shape. But I am aware it's not a good/supported idea to scale a collision shape indirectly, but to instead directly change its extents or size. So you have to do stuff based on the fact that this thing is not actually just a thing, but several things. This seems like a bad idea, but maybe one way I could use scenes for platforms is to add them to my level scene and make each one have editable children. Problem with this is I'd need to make every shape resource unique, and I have to do it every time I add a platform. This same problem will occur if I try duplicating sets of nodes (not scenes) that represent platforms, too. Need to make each shape unique. That said, this is easier than using scenes + editable children. Ultimately the ‘right’ way forward seems to be tilemaps, but I wanted to understand this from a principles perspective. The simple, intuitive thing (to me) does not seem possible. When I ask questions about this kind of stuff, 9/10 times the suggestion is to do it in a paradigmatic way that one might only learn after spending a lot of time with an engine or asking the specific question, rather than what I would think is a way that makes dumb sense.

jameshart 2y ago

It sounds like the sort of thing Sam Vimes would say before being begrudgingly forced to admit, after being forced by Sybil to undergo some painful personal growth, that maybe, sometimes, a thing might need to be more than just a thing. And that Vetinari’s entity component system might seem complicated but it works, damnit and it makes the city function.

tsumnia 2y ago
And once Nobby says he likes Tramway, everyone realizes Vetinari was right all along XD (I'm just glad someone got the reference)
- lelanthran 2y ago
  > And once Nobby says he likes Tramway, everyone realizes Vetinari was right all along XD Well, except for Detritus
  - tsumnia 2y ago
    Well OBVIOUSLY except for Detritus! Things is too many things to count.
    - atombender 2y ago
      Unless we are talking about liquid-cooled Detritus.

taneq 2y ago

Unfortunately everything is a collection of things pretending to be a single thing, even single things. The best we can do is pretend, or avoid finding out.