Entity relationships

[rafi0]

Hi
I thought that fleks is based off flecs(c++ implementation). But i guess its not?
Anyways i saw this article about entity relationships and thought that it is really cool and offers great possibilities:
https://ajmmertens.medium.com/building-games-in-ecs-with-entity-relationships-657275ba2c6c

long story short its about being able to do something like this:
1.

// Eats, Apples , Melons <--- those are components (or tags)
entity.add<Eats>(2, Apples)
entity.add<Eats>(4, Melons)
// then we can query like this
query<Eats>.foreach{...}

and the queries are the most powerful feature of this:
https://www.flecs.dev/flecs/md_docs_2Queries.html

Do you guys think its doable in fleks?
I spent some time already trying to create a proof of concept in fleks, but so far no success.
I'm looking forward to a discussion.

[Quillraven]

Hi,

there are a lot of ECS implementations out there but Fleks is definitely not based on flecs (which I heard for the first time now :D). Also, in C you have certain features which are more convenient than in JVM based languages like Java and Kotlin. One big difference is the possibility in C++ to like "inherit" static fields. This is important for unique component ids that can be "magically" created in the background while in Kotlin we need to inherit for a specific interface/class to make that happen.

Anyway, I quickly read through the article and imo most examples (maybe all of them) are already doable in Fleks but in a different way.

Just to give you two examples:

Inventory

This can be solved by having a single component that references to the different items (=entities). You can then add an Inventory component to an entity and add any number of items to it. Items are also entities and are therefore very flexible in a way that you can add e.g. a Damage component to an item to boost the damage or an Armor component to boost the armor. The item position is than the position in the list or whatever datastructure you want to use for the items.

class Inventory : Component<Inventory> {
    val items = mutableListOf<Entity>()

    override fun type() = Inventory

    companion object : ComponentType<Inventory>()
}

Likes

In Fleks we have families to know if an entity has a specific configuration of components. You could implement an enumeration for entity types like:

enum class EntityType { DOG, CAT, .... }

and a component like:

class Likes: Component<Likes> {
    val types = mutableListOf<EntityType >()

    override fun type() = Likes

    companion object : ComponentType<Likes>()
}

You can then create a family like world.family{ allOf(Likes) } to get all entities that a Likes component and e.g. inside an IteratingSystem you can iterate over those entities and you know what they like or not. Or simply get the Likes component and you know what they like or not.

Referencing entities in components is also save in Fleks because of the version that we have for each entity. If an entity gets recycled it will have the same ID but a different version and therefore, if you check entity in world in a critical system/component that references entities, you will know if an entity still exists or not.

---

So in short, I think a relationship functionality is not super important since everything can be solved in multiple ways and I am pretty confident that Fleks can solve all those problems.

However, I understand that the special storage and implementation of a relation system will be faster/more convenient in certain scenarios which would be cool.

Unfortunately, I won't have the time to look into that but I can give you some hints that might be important for you:

• In Fleks there is a UniqueId class that is responsible for creating unique ids for components/tags. Have a look at the component.kt file. From what I understood a relation also has a unique id so this might be useful to reuse
• In Fleks you can safely reference entities in components. There is also a constant Entity.NONE to support null-safe references in Kotlin.
• In Fleks the same component can be added multiple times to an entity if it has different component types. Here is an example of a Sprite component that can be added two times to an entity. Once as foreground sprite and once as background sprite:

  data class Sprite(
      val background: Boolean,
      var path: String = "",
  ) : Component<Sprite> {
      override fun type(): ComponentType<Sprite> {
          return when (background) {
              true -> SpriteBackground
              else -> SpriteForeground
          }
      }
  
      companion object {
          val SpriteForeground = componentTypeOf<Sprite>()
          val SpriteBackground = componentTypeOf<Sprite>()
      }
  }

[rafi0]

Thank you for a quick reply.

Likes

In Fleks we have families to know if an entity has a specific configuration of components. You could implement an enumeration for entity types like:

enum class EntityType { DOG, CAT, .... }

and a component like:

class Likes: Component<Likes> {
    val types = mutableListOf<EntityType >()

    override fun type() = Likes

    companion object : ComponentType<Likes>()
}

This not what i meant. I would like to be able to add both Likes-Cats and Likes-Dogs.

• In Fleks the same component can be added multiple times to an entity if it has different component types. Here is an example of a Sprite component that can be added two times to an entity. Once as foreground sprite and once as background sprite:

  data class Sprite(
      val background: Boolean,
      var path: String = "",
  ) : Component<Sprite> {
      override fun type(): ComponentType<Sprite> {
          return when (background) {
              true -> SpriteBackground
              else -> SpriteForeground
          }
      }
  
      companion object {
          val SpriteForeground = componentTypeOf<Sprite>()
          val SpriteBackground = componentTypeOf<Sprite>()
      }
  }

This is really interesting. I think this has the potential to fulfill my requirement. I will fiddle with and we will see...
Thanks :)

[rafi0]

Hey, i tried many things and you were right, the best approach here would be to stick with the good 'ol mutableList :) Thanks

[Quillraven]

Thanks for replying back! I think the relation stuff is still a nice to have feature but I will not have the time atm to add it and as mentioned above imo all the relationship examples of the article can be already solved in different ways in Fleks.

I will keep it in mind though and it might be a feature for a future release!