You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 9, 2024. It is now read-only.
Copy file name to clipboardExpand all lines: README.md
+22-14Lines changed: 22 additions & 14 deletions
Original file line number
Diff line number
Diff line change
@@ -6,36 +6,44 @@ AER World is a prototype game state container designed to model games like [Hear
6
6
7
7
AER (Action Event Reaction) is a design pattern used in AER World that describes a way to clearly track and manage nested state changes caused by actions. The best way to demonstrate this is with an example.
8
8
9
-
The following is an example of AER World simulating the game state as `Golem 1` attempts to move away from `Player 0`.
9
+
The following is an example of AER World simulating the game state as `Golem 2` attempts to move away from `Player 1`.
1. When `Golem 1` moves away from `Player 0` as its enemy, `Player 0`'s "Opportunity Attack" reaction triggers. This interrupts the move action, and spawns a new action to deal 3 damage to the Golem.
38
-
2. When `Golem 1` takes 3 damage, its own "Reinforce" reaction triggers. This interrupts the damage action, and spawns a new action to gain 3 armor for the Golem.
45
+
1. When `Golem 2` moves away from `Player 1` as its enemy, `Player 1`'s "Opportunity Attack" reaction triggers. This interrupts the move action, and spawns a new action to deal 3 damage to the Golem.
46
+
2. When `Golem 2` takes 3 damage, its own "Reinforce" reaction triggers. This interrupts the damage action, and spawns a new action to gain 3 armor for the Golem.
39
47
3. Since there are no more reactions to any of the actions on the stack, the actions are popped. The golem is left with 1 HP and 3 Armor as a result of moving away from the player.
40
48
41
49
The AER pattern does not permit direct mutation of systems. Instead, every possible state change must come from an **action**. An action must be performed by a source entity onto a target entity (the target can also be the source).
@@ -46,7 +54,7 @@ An action may mutate state multiple times, across multiple systems. For instance
46
54
47
55
After each system state mutation, an action may choose to emit an event based on the result having met some criteria.
48
56
49
-
**Events** should only be created and used if there is a reaction that depends on it. For example, it does not make sense to create a `Death` event if there are no reactions in the world that care about death. However, it does make sense to add an event for `Move` because Opportunity Attacks may occur if an entity moves away from an enemy.
57
+
**Events** should only be created and used if there is a reaction that depends on it. For example, it does not make sense to create an `AfterDestroy` event if there are no reactions in the world that trigger after an entity is destroyed. However, it does make sense to add an event for `AfterMove` because Opportunity Attacks may occur if an entity moves away from an enemy.
50
58
51
59
**Reactions** are pre-defined event handlers, which conditionally perform more actions. They happen after an event is fired, which can happen at any point while an existing action is occuring. When a reaction occurs, it pauses the existing action and executes immediately. For example, the `Reinforce` reaction gains the reactor 3 armor whenever they are damaged.
0 commit comments