1. The forums will be archived and moved to a read only mode in about 2 weeks (mid march).

RFC Feature Graph

Discussion in 'Contributing & RFCs' started by SOFe, Nov 2, 2018.

  1. SOFe

    SOFe Administrator Staff Member PMMP Team Poggit Admin

    Messages:
    1,968
    GitHub:
    sof3
    This RFC is most likely purely theoretical and almost impossible/impractical/extremely time-consuming to implement in PocketMine, but it sounds pretty cool.

    PocketMine right now implements block physics, entity-block interactions, item-block interactions, item-entity interactions, etc. in different classes, scattered across the source code, with little API for modification. This RFC proposes the organization of these "features" using a graph structure. The principle is like this:

    When the server starts, the server initializes an empty directed unweighted graph called "FeatureGraph".

    When registering block types, entity types and item types, each type is inserted into FeatureGraph as a node.

    Then, the interaction between different nodes are inserted into FeatureGraph as edges called "FeatureEdges". Each FeatureEdge represents one interaction between two types, so there could be self-edges (an edge that points from the same node to the same node) and multi-edges (multiple edges between two nodes).
    (Drawback: If a feature applies to many nodes, the feature has to be set many times. E.g. for the feature that determines the block-breaking time of generic items and generic blocks, it has to go through hundreds of thousands of pairs, which might eat about one or two megabytes of RAM alone)

    When a block updates, its interactions are checked from the feature graph. For example, If a lava block flows near an air block, a FeatureEdge indicates it to flow into the adjacent air block in the next tick. If a lava block flows near a water block, another FeatureEdge checks if it has to be changed into a cobblestone.

    There are several advantages of this FeatureGraph structure:
    • Plugins can easily disable a certain feature by searching it by key when the plugin is enabled.
    • Plugins can easily search features implemented from other plugins.
    • Handling updates in plugins is more efficient, because the server will search for feature edges in the graph (probably through a hashtable, so good time complexity). Plugins no longer have to listen to events for every single block change or every single entity move.
    • Plugins can easily remove all features. This is useful for "dumb" servers, i.e. servers that are not intended to implement gameplay features by itself. An example is the possibility to implement remote-hosted levels, which is a kind of semi-proxy.
    • Code is more organized. If I ask you "where is the code for lava and water interaction", you won't be sure whether to check in Water.php or Lava.php, or just Liquid.php. If I ask you "where is the code for armor protection", you have to check Armor.php, DiamondHelmet.php, Entity.php, Player.php, or even Armor.php, and eventually find out it is in Living.php (meanwhile sword damage is in Sword.php). FeatureGraph puts each feature in its own class instead of sticking to the class of one of its interactions (either the item or the entity). Code gets much cleaner (although might have many classes).
    However, this refactor is a very huge and tedious change that cannot be automated yet humans find it too tedious. Therefore, I am opening this thread only to discuss whether this is possible and good (even though nobody is gonna have the time to do this).
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.