04-09-2020, 06:35 AM
I'm going to be using "component", "module", and "subsystem" interchangeably from now on.
The question of where the data should be stored in the class is still very important.
Should any data be stored inside the entity class, or are we just going to store everything in chunks and let modules access the chunks? I don't believe it's wise to have individual modules responsible for their own NBT data. It seems like a lot of the modules would need to access the same data, like position/rotation. Perhaps we can just group modules that need direct access to that information, and call those modules when we need to modify that NBT data, like the module for burning calling the module for damage. As I'm writing this, it seems like a promising solution but more research is required. The downside to this would be that it may be slower than if we let the modules access the data directly, but I don't see a particularly big performance hit. Besides, we already abstract away access right now as far as I can tell, this would just be adding an extra layer or two of function calls at most.
On a different note, here's an alternate idea for storing the NBT data. We have a root struct, say cNBT (or sNBT if you use those naming conventions). We then can create a cEntityNBT, which all further entity NBT classes should inherit from. We also should extend the cNBT class with the necessary data for each type of entity; we have cProjectileNBT, cMobNBT, cBreedableMobNBT, etc. Within each type, we further subdivide it into cArrowNBT, cVillagerNBT, etc, for the entity-specific NBT data. cArrowNBT can inherit from cEntity and cProjectileNBT, while cVillagerNBT can inherit from cEntityNBT, cMobNBT, cBreedableMobNBT. The obvious downside to this seems to be that this may not be as generic as was initially hoped. The plus side is that this is still a super generic way to do things, and it promises to be very very fast; each access to the data would only need to be a single dereference. And of course, you could abstract it away to make it thread-safe.
Feedback is welcomed.
The question of where the data should be stored in the class is still very important.
Should any data be stored inside the entity class, or are we just going to store everything in chunks and let modules access the chunks? I don't believe it's wise to have individual modules responsible for their own NBT data. It seems like a lot of the modules would need to access the same data, like position/rotation. Perhaps we can just group modules that need direct access to that information, and call those modules when we need to modify that NBT data, like the module for burning calling the module for damage. As I'm writing this, it seems like a promising solution but more research is required. The downside to this would be that it may be slower than if we let the modules access the data directly, but I don't see a particularly big performance hit. Besides, we already abstract away access right now as far as I can tell, this would just be adding an extra layer or two of function calls at most.
On a different note, here's an alternate idea for storing the NBT data. We have a root struct, say cNBT (or sNBT if you use those naming conventions). We then can create a cEntityNBT, which all further entity NBT classes should inherit from. We also should extend the cNBT class with the necessary data for each type of entity; we have cProjectileNBT, cMobNBT, cBreedableMobNBT, etc. Within each type, we further subdivide it into cArrowNBT, cVillagerNBT, etc, for the entity-specific NBT data. cArrowNBT can inherit from cEntity and cProjectileNBT, while cVillagerNBT can inherit from cEntityNBT, cMobNBT, cBreedableMobNBT. The obvious downside to this seems to be that this may not be as generic as was initially hoped. The plus side is that this is still a super generic way to do things, and it promises to be very very fast; each access to the data would only need to be a single dereference. And of course, you could abstract it away to make it thread-safe.
Feedback is welcomed.