Epistory: Automating Action & Reaction

A tale of candy distribution.


Most games can be reduced to a series of actions and reactions. Today I would like to share with you a way to facilitate iteration and expansion of these interactions. It will sound obvious to a lot of people but I would have loved to see this kind of example 6 months ago. When I was not yet used to component based mechanics.

It all started with a simple request a few months ago, we had just designed & implemented the scoring system and we needed items in the game world to be able to give points when activated. Easy, I wrote a small script which would be attached to objects that had to add points when activated. Controlled by our item’s base class, it would be called automatically.

The buildup

As time went on, that simple “points giver” script was updated to include various behaviors like prefab spawning, door unlocking and so on. It worked well but it was not very flexible. So I changed the structure to include a parent class to have a common entry point and place each behavior in a child class.

2015 09 02 17 25 18

It’s not standard notation but you can see the rewards and the items have a base class, and only these base classes interact with each other. The same kind of effect could be achieved with interfaces but I prefer to have a default implementation.

The true power of this structure lies in the modularity. Every trigger or actionable item in the game works with any reward and you can place any number of reward in a game object. The most basic action/reaction you can do is simply “collider – trigger – reward”. The player walks in the scene and something happens (tutorial message, cinematic, …).The possibilities are exponential and a new reward behavior is very easy to add.

Polish & additional features

Over time, features were added. Like the possibility to set a delay between the action and the reward. Camera travelling firing rewards at event points… What started as a joke -“reward” as in skinner boxes- is becoming a running gag: we’ll call this one “reward_kill_player”.

I recently did the same kind of structure for visual effects. A few key points (creation, destruction, hit, …) are exposed via a base class. You just have to derive from it and you get all the hooks that an artist would need to handle animations or particle effects.


The system is currently powerful enough to allow our designer to create our whole in-game introduction & tutorial with only the reward system. Looking back my only regret is that this system was not put in place earlier to have more of the game relying on it. Also, calling it “reward” when it’s in fact a “reaction” was a bit shortsighted.

I can share some sample code if some of you are interested. I leave you with one of the more complex interaction that we can produce.

main schema

P.S.: As a very tangible reward after a long wait between news here’s a few free gifs. Both features were added this week:

- One of the first iteration. Nothing special…

flower power 2


- One of the last iteration. Circular pattern, grows from the middle and not all of them at once.

flower power 3


- Black mist that will block your path (first iteration, polish will come later)

ink fog

  • Matt N

    The complex interaction image is interesting but without context it is just complex. Would love more insight into how the action and reaction base scripts are structured and how they are applied to objects. I am assuming the scripts have collider checking and look for specific object collisions to activate which makes proper tagging of object critical. I can see something like level completion being a script and with collision detection for any “Completion” tagged object causing that script to run and completing the level. Has advantages I am sure.

  • Thibaut Hanson

    Hello Matt,

    Sorry for the image, I tried to keep the structure intact but maybe more context around the snippets wouldn’t have hurt.

    Given our level/game structure the only interacting agent is the player, which greatly simplifies this kind of script. I tend to avoid object tagging because it introduces human error in the equation and instead rely on hierarchy and game object composition. Even though hierarchy is also error prone, it’s also a lot more visible.

    The action/reaction are not based on the level at all. It is only within the interacted object’s range (e.g. puzzle solving triggering a door opening).

    The “action” script ranges from a simple collider to a full on complex object (position based puzzle, “type to destroy” etc).

    Here’s sample code for a basic action/reaction. Both script are in the same Game Object. I took some liberties with formatting and declaration to show the structure.

    The reward base class

    public abstract class REWARD
    public void Activate()

    One reward

    public class REWARD_TELEPORT : REWARD
        public Vector3
    public override void Activate()

    Actionable objects base

    public abstract class INTERACTABLE_OBJECT : MonoBehaviour
    // called by derived object when rewards should be given
    protected void Complete(){/*activate all rewards*/} 
    // All the rewards it can find on the same game object. Filled during awake.
    protected REWARD[] RewardArray; 

    Actionable object trigger

    private void OnTriggerEnter()

    This allows us to completely separate actions and reactions but also combine them as we see fit.