04-06-2020, 08:29 AM
Entity Inheritance Structure
Forward Forward note
It seems like the post editor was being really weird, I have no clue why. Please excuse some blank bullet points, those are just bugs and there isn't meant to be anything there.
Forward note
This is list of plans proposed by me (Lazauya) on how to replace the current entity scheme. I have been informed that the current enity scheme is too rigid, and that "modules" should replace much of the logic. I tried picking out the modules that would apply to any entity, but not necessarily every entity. This means that for much of the entities, the module functions will be very sparse or non-existent. While I think the modules I outlined are already pretty exhaustive, I would like to see discussion on what should change/go/be added.
The issues that definitely still need discussion and clarification:
All of these plans differ on how/where the NBT data for the entity is stored. I chose to focus on that, as it seems this will either make Cuberite very efficient or end up in a huge disaster if done wrong. The current system is very memory efficient, but it is also apparently very inflexible. Reaching the current level of memory efficiency/speed probably won't be possible with completely flat class structures, but hopefully one of these plans will provide inspiration for the system that will come close to the current level while being flexible. Again, none of these plans are likely to be the final entity handling system, and discussion is required moving forward.
Plan 1
Overview
There is 1 class, cEntity.
The entity has pluggable functions dictating behavior, and contains fields for all potential NBT data attached to this entity.
Class structure
Pros:
Cons:
Overview
There is 1 parent class and 6 children.
The parent class has the same function fields as Plan 1.
The parent class houses NBT data that is common to all entities
Each child class houses the fields for the NBT data associated with any entity of the child type; e.g. cProjectile has fields specific to arrows, fields specific to
Class structure
Pros:
Cons:
Overview
There is 1 class, cEntity.
The entity has pluggable function fields dictating behavior, and contains a dictionary of dictionaries to store NBT data.
Class structure
Pros:
Cons:
Overview
There is 1 class, cEntity.
The entity has pluggable function fields dictating behavior, and contains a custom NBT tree structure to store NBT data. This would basically be structs within structs; each struct represents a possible tag, and each struct contains the possible fields for those tags.
Class structure
Pros:
Cons:
Forward Forward note
It seems like the post editor was being really weird, I have no clue why. Please excuse some blank bullet points, those are just bugs and there isn't meant to be anything there.
Forward note
This is list of plans proposed by me (Lazauya) on how to replace the current entity scheme. I have been informed that the current enity scheme is too rigid, and that "modules" should replace much of the logic. I tried picking out the modules that would apply to any entity, but not necessarily every entity. This means that for much of the entities, the module functions will be very sparse or non-existent. While I think the modules I outlined are already pretty exhaustive, I would like to see discussion on what should change/go/be added.
The issues that definitely still need discussion and clarification:
- Minecarts - where should the logic for minecarts staying on rails lie? i.e., which callback. Is a new callback required?
- current thoughts: split it up along, block intersection, placement, and pathfinding
- current thoughts: split it up along, block intersection, placement, and pathfinding
- Boats - where should the logic for boats staying on water/sinking lie? i.e., which callback. Is a new callback required?
- current thoughts: split it up along, block intersection, placement, and pathfinding
- current thoughts: split it up along, block intersection, placement, and pathfinding
- NBT data - how should NBT data be stored in memory?
- current thoughts: see plans
- current thoughts: see plans
All of these plans differ on how/where the NBT data for the entity is stored. I chose to focus on that, as it seems this will either make Cuberite very efficient or end up in a huge disaster if done wrong. The current system is very memory efficient, but it is also apparently very inflexible. Reaching the current level of memory efficiency/speed probably won't be possible with completely flat class structures, but hopefully one of these plans will provide inspiration for the system that will come close to the current level while being flexible. Again, none of these plans are likely to be the final entity handling system, and discussion is required moving forward.
Plan 1
Overview
There is 1 class, cEntity.
The entity has pluggable functions dictating behavior, and contains fields for all potential NBT data attached to this entity.
Class structure
- cEntity : cEntity
- damage = function | function called when damage is applied to this entity
- use = function | function called when the player tries using the entity; e.g. boats, villagers
- entityIntersection = function | function that dictates behavior when this entity intersects with another entity
- blockIntersection = function | function that dictates behavior when this entity intersects with a block
- burning = function | function dictates behavior of entity when it is caught on fire
- pathfinding = function | function that dictates if/how this entity seeks out new positions
- placement = function | function that dictates how this entities coordinates exist; e.g. minecarts on rails? paintings, leads, etc.
- gravity = function | function that dictates if/how gravity affects this entity
- statusEffect = function | function that dictates how status effects affect this entity
- Entity data = multi-field | NBT data of any kind of entity; Just include fields for all possible tags, even those that wouldn't be used
- damage = function | function called when damage is applied to this entity
Pros:
- Most extensible?
- Fastest?
Cons:
- Memory intensive
Overview
There is 1 parent class and 6 children.
The parent class has the same function fields as Plan 1.
The parent class houses NBT data that is common to all entities
Each child class houses the fields for the NBT data associated with any entity of the child type; e.g. cProjectile has fields specific to arrows, fields specific to
Class structure
- cEntity : cEntity
- damage = function | function called when damage is applied to this entity
- use = function | function called when the player tries using the entity; e.g. boats, villagers
- entityIntersection = function | function that dictates behavior when this entity intersects with another entity
- blockIntersection = function | function that dictates behavior when this entity intersects with a block
- burning = function | function dictates behavior of entity when it is caught on fire
- pathfinding = function | function that dictates if/how this entity seeks out new positions
- placement = function | function that dictates how this entities coordinates exist; e.g. minecarts on rails? paintings, leads, etc.
- gravity = function | function that dictates if/how gravity affects this entity
- statusEffect = function | function that dictates how status effects affect this entity
- Entity data = multi-field | NBT data shared by all entities; only include fields that are shared by all entities
- damage = function | function called when damage is applied to this entity
- cProjectile : cEntity
- Projectile specific data = multi-field | the specific NBT data of any projectile
- Projectile specific data = multi-field | the specific NBT data of any projectile
- cMob : cEntity
- Mob specific data = multi-field | the specific NBT data of any mob
- Mob specific data = multi-field | the specific NBT data of any mob
- cVehicle : cEntity
- Vehicle specific data = multi-field | the specific NBT data of any vehicle
- Vehicle specific data = multi-field | the specific NBT data of any vehicle
- cBlockTileEntity : cEntity (tnt, falling block)
- Dynamic tile specific data = multi-field | the specific NBT data of any dynamic tile
- Dynamic tile specific data = multi-field | the specific NBT data of any dynamic tile
- cItemEntity : cEntity (xp, item entities)
- Item specific data = multi-field | the specific NBT data of any item entity
- Item specific data = multi-field | the specific NBT data of any item entity
- cMiscEntity : cEntity (leash knot, end crystal, painting, etc.)
- Misc specific data = multi-field | the specific NBT data of any misc
- Misc specific data = multi-field | the specific NBT data of any misc
Pros:
- Less memory intensive than 2
- Fast
Cons:
- Memory intensive?
Overview
There is 1 class, cEntity.
The entity has pluggable function fields dictating behavior, and contains a dictionary of dictionaries to store NBT data.
Class structure
- cEntity : cEntity
- damage = function | function called when damage is applied to this entity
- use = function | function called when the player tries using the entity; e.g. boats, villagers
- entityIntersection = function | function that dictates behavior when this entity intersects with another entity
- blockIntersection = function | function that dictates behavior when this entity intersects with a block
- burning = function | function dictates behavior of entity when it is caught on fire
- pathfinding = function | function that dictates if/how this entity seeks out new positions
- placement = function | function that dictates how this entities coordinates exist; e.g. minecarts on rails? paintings, leads, etc.
- gravity = function | function that dictates if/how gravity affects this entity
- statusEffect = function | function that dictates how status effects affect this entity
- Entity data = dictionary | a hash map that stores NBT data
- damage = function | function called when damage is applied to this entity
Pros:
- Very memory efficient
- Easy to implement
Cons:
- Slow
Overview
There is 1 class, cEntity.
The entity has pluggable function fields dictating behavior, and contains a custom NBT tree structure to store NBT data. This would basically be structs within structs; each struct represents a possible tag, and each struct contains the possible fields for those tags.
Class structure
- cEntity : cEntity
- damage = function | function called when damage is applied to this entity
- use = function | function called when the player tries using the entity; e.g. boats, villagers
- entityIntersection = function | function that dictates behavior when this entity intersects with another entity
- blockIntersection = function | function that dictates behavior when this entity intersects with a block
- burning = function | function dictates behavior of entity when it is caught on fire
- pathfinding = function | function that dictates if/how this entity seeks out new positions
- placement = function | function that dictates how this entities coordinates exist; e.g. minecarts on rails? paintings, leads, etc.
- gravity = function | function that dictates if/how gravity affects this entity
- statusEffect = function | function that dictates how status effects affect this entity
- Entity data = dictionary | a hash map that stores NBT data
- damage = function | function called when damage is applied to this entity
Pros:
- Very memory efficient
- Faster than 3
Cons:
- Slower than 1/2
- Harder to implement