Entity Rewrite Possibilities

[Lazauya]

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:

• 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
     
    
• 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
     
    
• NBT data - how should NBT data be stored in memory?
   
  • 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
    

Pros:

• Most extensible?
  
• Fastest?
  

Cons:

• Memory intensive
  

Plan 2
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
    
• cProjectile : cEntity
  • 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
    
• cVehicle : cEntity
  • 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
    
• cItemEntity : cEntity (xp, item entities)
  • 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
    

Pros:

• Less memory intensive than 2
  
• Fast
  

Cons:

• Memory intensive?
  

Plan 3

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
    

Pros:

• Very memory efficient
  
• Easy to implement
  

Cons:

• Slow
  

Plan 4

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
    

Pros:

• Very memory efficient
  
• Faster than 3
  

Cons:

• Slower than 1/2
  
• Harder to implement