Possible Architectures: Action Resolution

Possible Action Resolution Systems

Below are several of the architectures we've discussed and think may have some merit for our situation. Note that we can also use a mix of several together, to complement different systems.

Priority Queue

Description:

Actions have a fixed priority, and their order is based on them activating in a particular order.

Pros: Simple to implement and explain.

Cons:

• Ambiguity (how to break ties, i.e. if two actions have the same priority?)
• No "preventative response mechanism" (an action can't trigger another action to go before it, only after). Or is there?
• Need to define priority by hand, and "fit in" priority for other actions.

Event-Driven

Description:

Events trigger actions to occur. Timeline is: Pre-action Event, Action, Post-acition Event. The Pre-action Event can trigger other Actions that modify the initial Action.

Pros: Flexible, individual actions simple to right.

Cons: Ad-hoc, hard to extend (PoC used this, adding new actions was difficult), hard to plan.

Graph Resolution

Description:

Actions are represented as a graph, with order resolution decided by the engine (not the actions).

Pros: Ordering and execution are separated.

Cons: Very difficult to predict side-effects, probably hard to extend.

Stack Resolution

Description:

Actions resolve on a stack, with triggered abilities getting added to the stack (similarly to Magic: The Gathering). This is similar to the Event system, except it's a logical stack instead of an execution stack.

Pros: Can work with Actions as objects rather than procedures.

Cons: Additional formalism?

<type>

Description:

Pros:

Cons: