Description

After considering the different options for flyweights, it is clear that the current approach does not live up to standard due to them being practically a singleton globally accessible state that can be assigned to a set of entities. If two sets of entities have different data, we would need to create a new flyweight to encapsulate this data.

One approach to fix this was to create a map where we would have a getter and setter for the data on the flyweight, and then we could map an entityid > flyweight data. The issue here is in cases where there is no easy concern about who "owns" the flyweight data. If for example, we had a pack of mobs, with a leader and six other mobs, then the leader is typically the one that controls all the data, but there is no easy way to ensure this. To sort this we need to start creating abstractions for the flyweight data that can become very specific depending on the issue we wish to solve (see https://skypjack.github.io/2020-02-02-ecs-baf-part-7/).

The best way to resolve these issues is to just remove the flyweight entirely, and then users at their own discretion can create abstractions over components to solve the issues they wish to solve, as creating a one solution fits all approach would be very costly, and likely never cover all the possible use cases anyway.

Proposed Changes

• Remove Flyweights

Linked

Resolves #109