Jump to content
  • Advertisement

Aku Studio

Member
  • Content Count

    0
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Aku Studio

  • Rank
    Newbie

Personal Information

Social

  • Twitter
    @Aku_Studio

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi Haegarr,
    I carefully read an old post regarding relationship inside ECS especially parenting.
    I tried to stick to your explanation:

    ¤ Parent
        + PlacementComponent
            * Position
            * Orientation
    ¤ Child
        + PlacementComponent
            * Position
            * Orientation
        + ParentingComponent
            * IEntity (parent)
            * local_placement (Position x Orientation)
    
    => PlacingSystem
        | Entity.Placement.Position = f(Entity.ParentingComponent.Parent.PlacementComponent.Position, 	
    					Entity.ParentingComponent.local_placement.Position)
        | Entity.Placement.Orientation = f(Entity.ParentingComponent.Parent.PlacementComponent.Orientation, 
    					Entity.ParentingComponent.local_placement.Orientation)
    

     It is a good fit for a single parent|child relationship but I am wondering how to deal with parent|child|grand-child one. Position have to be updated in the right order ie from root to leaves.
    Do we need a plain old scene graph or can we handle this sticking to ECS philosophy?
    Best regards,
    Romain

    1. haegarr

      haegarr

      Hi.

      Yes, you need to consider a processing order. But a scene graph is a multi purpose structure. As such it is not suitable to solve a single particular problem. What you essentially mean is a dependency graph.

      However, in case of ECS the sub-systems are responsible to store the component data in a reasonable fashion. In the given case there may occur dependencies on each other, so the sub-system has to partially sort the stored data. This will fail on a mutual direct or indirect dependency (which should be disallowed), but will work in all allowed cases. Then the data can simply be processed in order.

      See You on GDnet

    2. Aku Studio

      Aku Studio

      Hi Haegarr,

      Thanks for your input. I misspelled it but I was in fact talking about some kind of dependency graph and not scene graph.

      If I follow you: putting data inside component, attach them to entity and leverage this dynamic bag to identify which entities a system should work on does not imply that entities must be managed as a flat list inside systems: we need to think the smartest data structure regarding context.

      If we stick to SRP, system's single responsibility is to dynamically gather entities. It should - must have to - then leverage an underlying engine (subsystem/kernel/service) to effectively process those entities. If we introduce an abstraction here we can then have the flexibility to switch between different engine which store and work on entities in their own efficient way.

      It makes sense for me this way. I will continue to dive into.
      Not only for its inherent qualities ECS forces you to approach situation differently.
      It deserves a better exhibition as it is clearly IMHO a major software paradigm.

      See you.

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!