When I first started experimenting with ECS, I was trying to integrate it in a very piecemeal fashion. I then decided that wouldn't work and rebuilt Azymus (multiple times) around an ECS core. However, that seemed to introduce a large number of logistical problems, so I started over from scratch.
I find myself repeating this pattern a lot:
with all entities at x, y
if it has a position
and if it has a renderable
and if it has a field of view
then do something
which ends up being the sort of thing an ECS handles very well.
So what doesn't an ECS handle very well?
It seemed to me that the ECS didn't work well with the tile map. Which is fine, because tiles are a separate structure entirely in the current iteration. I no longer need to maintain a shadow map or any other smelly shenanigans to get good performance.
Specs isn't trivially amenable to proximity searching, meaning that there's some setup work to be done to generate a quad-tree. Which, 1) I'm not sure is even necessary, and 2) I'm doing already, so who cares? And I'm sure this is more an issue with my mediocrity than with Specs.
The real problem, though, and the main concern of this issue, is that commands and actions and so forth require arbitrary data.
Whereas I think a system is typically supposed to get, say, position storage, renderable storage, and light source storage and be equipped to pass that stuff around, it's entirely possible that the command in question will need access to the field of view or body or who knows what.
So: how do I solve that? My naïve attempts were to 1) pass the world around, which is obviously extremely smelly, and 2) pass literally every component storage in to the relevant system, which I didn't finish implementing before #16.
TBH, I'm still not sure if commands and actions and so forth as I have them implemented would play well with the ECS architecture. But I'm pretty sure I need to refactor them completely anyway.
So, honestly, IDK WTF I'm doing. But this issue is here to gather my thoughts.
Am I reversing course on #16?
Not quite.
When I first started experimenting with ECS, I was trying to integrate it in a very piecemeal fashion. I then decided that wouldn't work and rebuilt Azymus (multiple times) around an ECS core. However, that seemed to introduce a large number of logistical problems, so I started over from scratch.
I find myself repeating this pattern a lot:
which ends up being the sort of thing an ECS handles very well.
So what doesn't an ECS handle very well?
It seemed to me that the ECS didn't work well with the tile map. Which is fine, because tiles are a separate structure entirely in the current iteration. I no longer need to maintain a shadow map or any other smelly shenanigans to get good performance.
Specs isn't trivially amenable to proximity searching, meaning that there's some setup work to be done to generate a quad-tree. Which, 1) I'm not sure is even necessary, and 2) I'm doing already, so who cares? And I'm sure this is more an issue with my mediocrity than with Specs.
The real problem, though, and the main concern of this issue, is that commands and actions and so forth require arbitrary data.
Whereas I think a system is typically supposed to get, say, position storage, renderable storage, and light source storage and be equipped to pass that stuff around, it's entirely possible that the command in question will need access to the field of view or body or who knows what.
So: how do I solve that? My naïve attempts were to 1) pass the world around, which is obviously extremely smelly, and 2) pass literally every component storage in to the relevant system, which I didn't finish implementing before #16.
TBH, I'm still not sure if commands and actions and so forth as I have them implemented would play well with the ECS architecture. But I'm pretty sure I need to refactor them completely anyway.
So, honestly, IDK WTF I'm doing. But this issue is here to gather my thoughts.