The Event Manager Plugin manages global info in your virtual world, as a collection of text strings. Systems can read / write this info in this one place, decoupling them from others and providing easy access to information.

This technique is efficient to implement mission systems, dialog systems, gameplay, simulations and more, as they are systems which often require complex information from another, which is now easy to manage.

Example usage:

1. Have a dialog option unlock while X info is present and Y info is not, such as a topic to talk about only during daytime.
2. Have a door automatically open when X info is present ("player_found_key").
3. Set up complex event designs with ease, such as progressing a game level or mission.

• Read / Write global information in one place.
• Automatically run functions for a combination of information.
• Efficient for sharing info to mission systems, dialogs, simulations and more.
• Systems sharing information can be decoupled.

First follow the docs on how to install a plugin in general.

This plugin does not require any setup.

Info: is a short piece of text, describing what is going on in your virtual world. In a game these can look like "found_key_X", "started_mission_X", or "weather_sunny".

Info Event Subsystem: All info is stored here. Globally read from / write info to this system.

Event Trigger: An event trigger makes an event happen automatically (function call) for a combination of info. Example: A door opens for the combination: (has info "found_door_x_key", not info "door_x_lock_broken").

Info Event: This is an action (function call) which is automatically performed by an Event Trigger. This is the code which makes something happen in your world, like opening a door or spawning objects.

The example image shows how an Info Event Component registers a single info event for the actor it is attached to, an example door. The method "ActOnInfoOpenDoor" will be called when the info "FoundKey" is present and "OpenedDoor" is not.

The door actor contains a few components: two walls, the door, a key, a collision box for the key. Walking through the collision box adds the info "FoundKey" to the Info Event Subsystem.

The addition of info to the Info Event Subsystem causes the Info Event Component to check if any of its info events matches the current info. It does (Only "FoundKey" is present). The bound function "ActOnInfoOpenDoor" is called, which hides the key, removes the door, and adds the info "OpenedDoor" to the Info Event Subsystem.

Walking over the key now opens the door. The info system is extremely useful when dealing with large amounts of information from several systems.

Common uses for info: mission systems, simulations, AI, level events (doors unlocking, object spawning.), and dialog systems.

Info can be used without events and event triggers as well. Following is an example on how this is done in a dialog system, where a combination of 4 info strings from different systems unlock a dialog topic:

A dialog starts. Person B can ask person A to buy apples, only if the info condition is met:

• has info: "overall_relation_good" > Relation with person A is good.
• has info: "time_day" > It is day time.
• not info: "task_buy_apples_done" > The task hasn't already been done.
• not info: "shop_x_closed_permanently" > A world event would not prevent this from being possible.

Without Info you would require more complex code to integrate the dialog system with the mentioned example systems ("relations", "time", "tasks", "world events"), to get to all the information required.

With the Info system all the required information was retrievable from one place at once, the Info Event Subsystem. This reduced complexity and decoupled the example systems.

The Info Event Subsystem is a Game Instance Subsystem. It manages Info. Info strings can be globally read or written by any system. This makes information easy to access while decoupling those systems.

Examples of info strings are given in the previous topic "Info".

This subsystem broadcasts when info is added or removed.

The state "Has Full Info" tells if the current collection of info is considered complete or incomplete. While you are loading a collection of default info (from a save file or elsewhere), "Has Full Info" must be marked as false to make the system aware that we shouldn't broadcast changes until "Has Full Info" is set to true. This avoids responses to incomplete info. By default, the info is considered complete and any add / remove actions to info broadcast directly.

The method "Full Info Contains" is used to check if the full info contains a string of info. This gives you an error if "Has Full Info" is currently false, to notify you of probable misuse. This is the method you would use in the previously given example of a dialog system looking for a topic's info conditions.

The Info Event Component can be added to any actor. It listens for info from the Info Event Subsystem, and manages its own info events.

An info event is a function which is automatically called for a specific combination of info. (has info X, has info Y, not info Z.)

The task of this component is to connect info events to the actor this component is on. (if placed on a door, a combination of info opens the door.)

Blueprint users can configure this by calling the method "Add Info Event" on their Info Event Component.

C++ users can do the same in one line using "Bind Info Effect":

This detailed explanation of the event trigger behavior can help you make design choices on a larger scale, important to deal with questions like when to add / remove info, how to prevent retriggers, and how to deal with events when loading a saved state.

An event triggers when the info subsystem holds a combination of HasInfo and not NotInfo. The trigger can look like:

• has info: "mission_1_starts"
• not info: "spawned_mission_1_enemies"
• event: SpawnEnemies() + AddInfo(spawned_mission_1_enemies)

In this example info was added (spawned_mission_1_enemies) to prevent a future retrigger.

In general it is better to add info to function as "not info" on the trigger, than to remove info, to avoid a trigger condition. This depends a bit on the situation. A weather system reporting the current weather as info might remove "weather_sunny" and add "weather_rain". A game mission however, often acts a bit as a log of things which did happen and can not be undone. ("started_mission_1", "opened_door_1", "found_key_x", ...)

An immediate retrigger is guarded against, as long as the event was triggerable on the previous check (when info was added or removed globally). An event trigger meeting info conditions will trigger the event only once until the conditions are no longer met. then it can retrigger when info conditions are met again. This can reduce the amount of HasInfo / NotInfo required, has HasInfo(found_key) does not require NotInfo(opened_door) to prevent a retrigger.

However, your event trigger / retrigger guard design depends entirely on your implementation. If for example, you use a save game system to load some previously stored data, you must consider what you restore and how you restore it. For example, restoring previously spawned characters from a save system does not prevent an event trigger from spawning new (duplicate) ones if not instructed to.