Some questions

Hi @pspeed,

  1. I just came across a usecase where I would like the DefaultEntityData#registerComponentHandler() to be public. Maybe it should throw an Exception if there’s already a ComponentHandler for that kind of Component or something like that, but I’d like to make my systems attach different handlers themselves. In this special case I want to implement a better way of looking up positions and to do so I thought of a handler which organizes the data besides just holding it.

Which brings me to 2.:
How do you handle spatial organization within the es? My first approach is to use a special handler (see above) which orders the positions like you described here. So whenever a PositionComponent is inserted or changed, it get’s sorted into the according cell. Based upon this I would implement different filters, e.g. a BBoxFilter, which operate on the organized data. So in the getEntities() of the handler the handler just reads the BBox-values from the filter and won’t use filter#evaluate() anymore. This function would probably still have to be implemented, because it’s used whenever a update happens, but I think at least for many different lookups this would be a good approach. How do you this or do you do it at all?

A better way to do this is to embed the cell ID right in the position component. This is what I do for Mythruna and then querying cells is easy. Not only that, I can continue to use the stuff already provided by the ES like EntitySet. For example, I have entity sets with an or filter on Position that pulls in the ‘cells’ around the palyer (I call them tiles or zones)… when the player crosses a tile boundary then I reset the or filter and the EntitySet automatically updates itself. The rest of the code doesn’t even have to care.

At any rate, the systems should not be registering component handlers. If you really must have custom component handler then do it at setup time like with persistence… and then you can subclass DefaultEntityData and add your component handler just like the persistence layer does.

Exposing this publicly would lead to dangerous hackery, I think… and anyway, as noted the really persistent developer can easily make it public themselves by subclassing DefaultEntityData… though I highly recommend against it to anyone reading this far. :slight_smile:

@pspeed said: A better way to do this is to embed the cell ID right in the position component. This is what I do for Mythruna and then querying cells is easy. Not only that, I can continue to use the stuff already provided by the ES like EntitySet. For example, I have entity sets with an or filter on Position that pulls in the 'cells' around the palyer (I call them tiles or zones)... when the player crosses a tile boundary then I reset the or filter and the EntitySet automatically updates itself. The rest of the code doesn't even have to care. At any rate, the systems should not be registering component handlers. If you really must have custom component handler then do it at setup time like with persistence... and then you can subclass DefaultEntityData and add your component handler just like the persistence layer does.

Exposing this publicly would lead to dangerous hackery, I think… and anyway, as noted the really persistent developer can easily make it public themselves by subclassing DefaultEntityData… though I highly recommend against it to anyone reading this far. :slight_smile:


This is a dirty way I didn’t want to go, so I asked for a different solution =D
But I just read something about premature optimization and pain I had forgotten… So forget about the previous questions, I will ask them again if I ever get far enough to be concerned about speed matters. Please apologize for stealing you some of your precious Mythruna dev time.