Best practices for developing advanced blocks + potential new utility

[Cervator]

Terasology/FunnyBlocks#8 got me thinking a bit about how somebody would naturally approach designing new advanced blocks, and made me realize we don't really have any good guidance for it.

Specifically that PR encounters a few issues we've hit before (like for several GCI tasks) and while I get the feeling they are problematic I am not sure how badly so am curious what others would think.

Possible code smells

• Permanent entities for blocks that only really need them when interacted with: in this case each BreakingBlock is persisted so it can be tested. Maybe we could use some new interaction events? See section below
  • As an example of a good case for permanent entities there is the chest, which needs to remember its inventory.
• Usage of an UpdateSubscriberSystem that could possibly be avoided: the BreakingSystem checks in the loop for any BreakingBlock that may need to "tick" - could this be handled via event or scheduler instead?
  • As an example of a good case for update() usage: something that needs to make a change every tick for sure, like a particle system emitter. What might be a good cut-off duration to suggest moving from using update() to the scheduler instead?
• Usage of entityManager.getEntitiesWith() to process: in this case blocks actually being in the progress of breaking might be rare, as would be stepping on one. Could new events help trigger processing more selectively?
  • As an example of a good case for getEntitiesWith: One-time searches like figuring out an actual count to use in some form of logic, or getting a bunch of entities to transform in some fashion

Some of these cases probably need some researching with a profiler in hand to actually test the performance when large quantity effects are in play. Maybe a decent area to write some benchmarking tests for?

New utility

A lot of functionality revolving around blocks will tend to want information for when a player or creature bumps into or steps on specific blocks. Could it make sense to add some outright WalkedOnEvent, BumpedIntoEvent, WalkUnderEvent etc that are triggered by a single event handler for CharacterMoveInputEvent rather than have a bunch of modules all implementing their own handler just to see when it matters?

At present the specific block under the player's crosshairs will have a temporary event spun up to then test an interaction with (or maybe I'm thinking of when a player starts hitting a block - a temporary entity is spun up to contain the health info). Similar functionality for blocks stepped on, stepped under, or brushed up against could be very useful, and avoid permanent entities for "advanced" blocks that don't need to constantly store unique data (all following the same defaults like a block type but with an entity involved)

@portokaliu added new utility a little while back from the physics system, like when you throw an item against a wall, resulting in a new event to catch. I wonder how many more simple things like that we could add to make new content easier and more performant?

Related

• Tutorial: Transitioning to "The Terasology Way" of thinking, for MC modders #2444 - catching bad habits for how similar logic might work in MC
• Tutorial module: Events, interactions, and inventory #2158 - tutorial covering events and interactions
• Tutorial on basic entity system usage #2153 - tutorial on the ES in general
• gestalt-entity-system introduces a way to index entities - but I am not sure about the details or if it would change any related math here