Listeners

A game as crazy about organizing events (creating, organizing, modifying, and destroying) needs a solid system for interested parties to pay attention to certain types of activities so that they can react accordinly. An object should be able to subscribe to a certain type of event, listen with a filter, and broadcast events so that it can fit in well with the system.

Listeners are currently implemented as being interfaces. An object which implement this interface can be registered as subscribers to a particular kind of message. The singleton message manager (currently lumped into the main game world object) is informed of messages by the performers and will then relay the message to all of the subscribers.

Here are some of the existing listeners:

Solidity Listeners

The solidity listeners (examples include the MiningTask or MovementTask) are informed if anything in the game becomes solid or ceases to be solid. Things that involve movement or the accessibility of a certain area of the map should know if a particular area of the map is now impassible. Movement will be cancelled if a path can no longer be found to connect two points after something becomes solid between them. The mining task will stop assigning tiles to be dug if they are surrounded by impassible tiles.

Entity Creation Listeners

Whenever an entity is created, all Entity Creation listeners are informed. The reason for the creation can be provided as well. The only concrete example of this I could use right now would be the MiningTask. Sometimes, when you dig up a tile of dirt a rock will fall out of it. The rock is a new entity which was created! The creation of this entity and the reason ("New rock at [14,4] due to mining!") is received by the MiningTask which adds "clean up that rock" to it's list of tasks.

This would be a case where a filter might be appropriate. This could be done by the broadcaster, or just by the MiningTask to simplify things. The miningtask can just do a quick "if event.reason == mining".. who knows.