The event loop

The life-cycle of events in Indigo is very strict so that we can support referential transparency.

Key features of events:

The events list received by the frame is never empty, it always contains one Frametick event, and it is always last.

Indigo processes events as follows:

  1. The current frame emits events via Outcomes. These events are not available to the current frame.
  2. Most events are sent to a queue, but some system specific events will be processed and actioned immediately, specifically:
  1. Audio events
  1. Network events
  1. Storage events
  1. Asset load events
  2. When the next frame starts, all the messages that went to the queue are retrieved in order, and the FrameTick is appended.
  3. The events are then used to construct the InputState which is included as part of the FrameContext.
  4. The events are then consumed as follows (note that each stage could create new events to be processed on the next frame):
  1. The events are sent to the model update function in order.
  1. The events are sent to the view model update function in order.
  1. The events are sent to the subsystem update functions in order.
  1. The events are passed to scene elements to process entity events.
  2. All events are then discarded.


All events must be tagged with the GlobalEvent trait in order for Indigo to process them.

You can create your own events by simply extending GlobalEvent.


Full Screen


The CanvasGainedFocus and CanvasLostFocus are very similar to their Application* counterparts. The main difference is that the game canvas can lose focus independently of the application if the game is being run from inside a web application (such as a Tyrian App or game site). In this scenario the Canvas* events will fire whenever the canvas loses or gains focus from the user clicking around the external parts of the site, and will also fire when the application loses or gains focus.


Handling InputEvents can be a bit tricky in some situations, so Indigo includes Mouse and Keyboard classes that can be accessed from the frame context, providing a rich interface to gather more complex information from those input devices.


What did the mouse do and at what location?

A Mouse event consists of the following properties:

For events (such as Click) where a button is pressed, an additional button property is provided.

Up to five mouse buttons are supported, including the most common left, middle and right buttons.

The following events are available:



There is only one audio event used to play one off sound effects, since background music is described on the SceneUpdateFragment.

Network events

It's important to be aware that a network is considered online if there is access to the local network only. As such, an online network is not a guarantee that the internet or indeed a single resource on the internet is available.

Web socket events

HTTP events


Used to load and save data from local storage.

Should any of the above fail one of the following StorageEventError types will be raised as a separate event.


These are the low level events used to load additional assets at runtime. If you want a slightly more sophisticated loading experience, please look at the asset bundle loader sub system.

Note that the LoadAsset event is a convenience event, and in fact loads a bundle containing one element, which is why there is no corresponding "AssetLoadError" event, just the bundle version.

The load events also have a makeAvailable flag, which if set to false, loads the asset to the browsers cache but doesn't add it to the engine, this means you can add it to the engine quickly later. The available flag on the response indicates whether the asset has been made available or not.