Nested Game Objects in Unity vs HTML5 Djinn


  • Jammer

    @geoff2

    In ‘A Wizard’s Lizard 2 Game Development #5’ which can be found on Youtube here:
    https://www.youtube.com/watch?v=UTFE6t_rnGU

    At around 18:25 you spoke briefly about wanting to use “a nested game object”, or objects with children, and how in your HTML5 engine (Djinn) you did not support this functionality. You referenced how you have not seen the benefit of this until working with Unity, but you pointed out that it was “powerful”. I was wondering if you could elaborate on this a bit. Basically my understanding of an object with nested game objects in HTML5 would work something like this:
    function ENTITY() {
    this.position = {
    x: 0,
    y: 0
    }
    }

    Or maybe some components that would be joined to an entity, and structured in some way similar to this:

    function COMPONANT() {
    return {
    position: function() {
    this.x = 0;
    this.y = 0;
    return this;
    }
    }
    }

    And this would then have some joining function, and be constructed with dot notation which I understand to be more stylistic than functional. For example:
    function FUZE( ent ) {
    return {
    position: function() {
    ent.position = COMPONANT().position();
    return this;
    }
    }
    }
    var player = new ENTITY();
    FUZE( player ).position();

    and then you are left with an entity with the position component.

    Anyway, I know this is just a jumble of nonsense, but currently my heads pretty deep into trying to understand ECS as well as trying to implement it without getting too wrapped up in every little nuance, but here I am.

    I want to I guess more directly ask, if you were to sit down and design an HTML5 ECS / engine / framework, would you build your components with nested children, and if so any example would be very much appreciated.

    Thanks!

    p.s. Sorry this is so jumbled but I’ve reread it a couple times and don’t really know if I can articulate my question better. Also, please let me know if this is bad forum etiquette. I’ve read many forums, but for some reason I always have trouble discerning what is appropriate and what is not. Thanks!


  • LDG

    The idea of nested entities is more conceptual than technical. I want to make that distinction because your code examples here appear to be about constructing entities, e.g. “fusing” a component onto an entity, which isn’t what I mean by nested entities. Also, for clarity, when I use the term “game object” it’s synonymous with “entity”. Unity refers to its entities as game objects, which is why I swap back and forth when talking about these concepts.

    The primary idea of nested entities is that child entities are affected by their parent’s transform, e.g. position, scale, and rotation. Nested children entities are still full entities in their own right, with their own set of components. In Unity, the transform component handles the parent/child relationship.

    Here’s how this might look if you were expressing your entities as simple JavaScript object literals:

    // Parent entity
    var entity = {
      transform: {
        position: {
          x: 10, // Offset by 10,10 from the origin point
          y: 10
        },
        scale: {
          x: 2, // Scaled up by 2x on the x and y axis
          y: 2
        },
        rotation: Math.PI / 4, // Rotated by 45 degrees
        children: [
          // Child entity
          {
            transform: {
              position: {
                x: 5,
                y: 5
              },
              scale: {
                x: 1,
                y: 1
              },
              rotation: 0
            }
          }
        ]
      }
    };
    

    When the above entities are rendered, the child entity’s transforms are relative to its parent. So, in absolute world space, the child entity would be rendered at 15, 15 (the parent’s 10, 10 + its own 5, 5), at 2x scale (again, the parent’s scale is 2 multiplied by the child’s 1), and rotated by 45 degrees (because the parent is rotated by that much).

    This is beneficial because you can now simply transform the parent entity and the child entity automatically reflects those transformations. For example, if we changed the parent’s position to 50, 50, the child would then be rendered at 55, 55.

    Hope that helps!

    FYI: You can format your code blocks on the forum by putting three backticks on the lines above and below your code.


  • Jammer

    Yes this helps immensely. Thank you very much for such a detailed explanation! I look forward to a time where I can help others as you guys have helped me, and I look forward to sharing something worth sharing one day with you all in this wonderful community.

    After googling backticks:

    function Vox( invaluableAdvice ) {
        return THANKS;
    }
    

    Cheesy I know, but I hope the sentiment translates appropriately!


  • Tiger Hat

    I dunno if it helps or confuses the matter, but I think that nested entities really is more of a function of the transform component in relation to a scenegraph. In Unity it just so happens that the transform component is not optional, so it makes it seem like the entities themselves are related this way. It’s definitely cool to use the parent / child transforms like that, most 3D modeling software and many game engines do it this way (scenegraph / nodetree). Sometimes though certain things you want to do, like float a name text over a mesh’s head is easier to as a sibling that just follows the transform (at least the math is easier :) ). I wonder in Unity if there are any other benefits to various systems from the parent / child relationship.

    In my version of entity component system, it’s better to work with entities in a flat array, however for rendering, you can still push all of the entities that have a transform component into a scenegraph. Also, not every entity needs a transform IMO.


  • Jammer

    @Warspawn
    Oh man- so although google has provided me with a definition of a scenegraph, I feel that I may need more. I will look into this deeper. With all the jargon associated with development it amazes me I understand anything at all these days. Thanks for your reply!


  • Tiger Hat

    well basically, it’s just a tree which is a type of graph. A tree doesn’t allow for the child nodes to connect back up to the parent nodes as a generic graph would, so actually I’m not sure why it isn’t called a scenetree :)

    So, in Unity (and many other rendering applications) the entities (or as they call them GameObjects) are stored in a tree. There is one root node for the scene, and then all other GameObjects are children of that. GameObjects themselves can also have children and that is why it is sometimes referred to as “nested” because they are inside the parent object. When Unity goes to render the scene, it walks the tree (or a portion of the tree based on a spatial query) and renders each child. As was said, the children are rendered relative to the parent’s transform, which makes it very handy if say you have a player image at {x: 10, y: 10} relative to the root scene at 0, 0; then you attach a gun image as a child to the player and you want it to be located on the hand of the player image at 16, 20 (say it’s a 32x32 sprite). That gun will then need to adjust it’s coords by 10 to stay lined up with the player who is offset from the scene. It goes on for each child, a muzzle object might be a child of the gun, located at the coords of the gun image where the bullets should come from. That way everything stays lined up, and you just have to move the player around.

    Incidentally, a scenegraph is a tree ordered by how things should be rendered to the scene. There are other trees, such as a quadtree or octree that are ordered by spatial coords (x, y, z). Parent nodes from the scenegraph (references to) would be added in relation to their size and position to a quadtree so that when your player is at 10, 10 you can easily query to find all of the scenegraph nodes that are “near” and pass that into the renderer (or other processor like physics for collisions) so that the list of items that it needs to traverse is much smaller.


  • Jammer

    @Warspawn
    Wow, thank you! Okay, this does clarify some things. I feel that this concept has a lot of versatility- Geoff referred to AWL’s collision systems using quad trees in past lostcasts, and I have often wondered how all of these various methods are actually implemented. The deeper I dive into game design the more I realize just how deep this ocean is.

    Thank you for laying all this out.


  • LDG

    I’ve typically used quadtrees for collision detection, but I’ve been thinking about using them to determine which entities to render as well. Instead of checking each entity’s coordinates/size against the camera, you could just make a quadtree lookup using the “collision box” of the camera/viewport.


Log in to reply