Creating Game Systems

Systems of the Slash Framework derive from the GameSystem base class:

[GameSystem]
public class HealthSystem : GameSystem
{
	public override void Init(IAttributeTable configuration)
	{
		base.Init(configuration);
  
		this.Game.EventManager.RegisterListener
			(RPGGameEvent.EntityAttacked, this.OnEntityAttacked);
	}
  
	private void OnEntityAttacked(GameEvent e)
	{
		var entityAttackedData = (EntityAttackedData)e.EventData;
  
		// Get damage done by attacker.
		var attackComponent = this.Game.EntityManager.GetComponent<AttackComponent>
			(entityAttackedData.AttackerId);
  
		// Get armor provided by defender.
		var armorComponent = this.Game.EntityManager.GetComponent<ArmorComponent>
			(entityAttackedData.DefenderId);
  
		// Compute final damage.
		var damage = attackComponent.Damage - armorComponent.Armor;
  
		// Reduce health.
		var healthComponent = this.Game.EntityManager.GetComponent<HealthComponent>
			(entityAttackedData.DefenderId);
		healthComponent.Health -= damage;
  
		// Notify listeners.
		var damageTakenData = new DamageTakenData
			{
				EntityId = entityAttackedData.DefenderId,
				Damage = damage
			};
		this.Game.EventManager.QueueEvent(RPGGameEvent.DamageTaken, damageTakenData);
	}
}

The GameSystem attribute tells the Slash Framework to automatically add, initialize and update the system. Systems can use the Init method to register as listeners for specific game events. In the above code snipped, the HealthSystem is interested in EntityAttackedEvents. If such an event occurs, the system computes the actual damage caused by the attacker, reduces the target entity’s health, and notifies further listeners of the damage the entity has taken.

If health system was responsible for having entities die, it could check the new health value after, and remove the entity if necessary. You could also introduce a DeathSystem that listens to DamageTaken events and removes dead entities. It takes some experience and practice to get an idea of how to design these systems and events – from our experience, it is generally a good idea to split up systems as much as possible.