Interaction

1 - Pulsors

Overview

Setup

Refer to the Interaction Set Up Guide in Get Started section.

Features

• Pulses
• Reactors

1.1 - Pulses

Image showing the Pulse component, as seen in the Entity Inspector.

Pulse Overview

Functionality

Pulsors are the thematic components that represent a single Pulse Interaction.

Each component carries the relevant information necessary to exchange data with the Reactors that are able to detect said Pulse.

Get “PulseType” event for each type.

By unifying these exchanges, we open up a workflow to add any number of new Pulsors and related Reactors.

Pulsors can be stacked on a Trigger Collider. What can be reacted to will all do it in tandem. Pulsors effectively define living properties of the world and apply that impact to the receiving entity.

Pulse Types

Impulse

Physically launches things.

Needs Impulse Dir entity.

Can be facing, or radiate from entity point.

Collide

Informs the Reactor of a Collision.

This can do non-damage effects like destroy destructible objects.

Hit (Damage)

Attack Pulse. Passes on Attacker, weapon, damage rolls, etc.

Burned

Processes burn. Can alight the object, or melt.

This is not damage based but the physical effect of burn.

Can be combined with Hit for Burn and Damage. Status Effect for burning status.

Status Effect

Applies Status Effects, with their various modes of affecting the user. Toggle, Timed, Stacking, etc.

Can be combined with Hit & Burn.

Emotion

Emits an emotion to react to.

This could be putting garbage in a trash can (yay!), or harming a civiian npc (AHHH!).

Deflect

Weapon bounces off large objects/environment, interrupts Attack. Not a Pulse?

Could be used against Shields, Armours, Stone Beasts.

Using Pulses

API

Extending Pulses

1.2 - Reactors

Image showing the Reactor component, as seen in the Entity Inspector.

Pulse Reactor Overview

Functionality

All Reactor

Receives a pulse event and starts processing.

If incoming entity is a “pulse” tag.

Based on “canBe X“ evaluation, each valid type then checks for granular pulse tags:

• Impulse
• Hit
• Burned
• etc.

Unique Reactors

Perhaps we make custom clusters of Pulse processing based on common types:

• Unit
• Item
• Dynamic Object
• Field

These would still use canBe X booleans to enable and disable specific pulses, but would allow for less logic in any given Reactor.

Single Reactors

Would be a performance consideration. With Pulsors also being independent components, it may lead to quite a lot of components. But is an option.

Using Reactors

API

Extending Pulse Reactor

2 - Targeting

Image showing a Unit with Vision, Hearing, and TrueSight arragned from FoV and Radial Sense Fields.

Introduction

The targeting system is a, usually centralized around a unit, scanning and selection system that gathers information and sets up an array of values for easy processing by other systems.

Using “Targets” of different types allows the system to filter and categorize lists of targets based on what they represent.

Using an array of sensory fields, the system is able to scan the environment in different ways, and send targets to different sensory destinations in the categorization system.

GS_TargetingHandler

The central processor for the Targeting system. You only need one per source of sensory processing.

The Targeting Handler receives registrations from the Senses Fields, and gathers lists of targets based on categorical and tagging info around them. This creates a dense spatial context around the owner of the handler, usually Character Units, and allows for complex representation of the target through a sensory lense.

Memories, lack of skill to be aware, vision vs auditory awareness; all can be implemented as a means of depicting the world through fallible measures rather than through absolute representation of the world at all times.

Sense & Targeting Fields

A collection of collision volumes that detect and process targets that fall within and without their field of view.

Has Line of Sight features to better process targets.

Has filters to disallow certain overlaps, like self, select entities, or tags.

Targets

A simple but critical component to the targeting system. Targets serve as the element that makes the system awar of targets.

Extending from this class allows for basic functionality of overlap and registration. Followed by more unique processing through the child classes extended attributes.

Setup

Refer to the Interaction Set Up Guide in Get Started section.

Features

• Targeting Handler
• Senses Targeting Fields
• Targets
• Interaction Input

2.1 - Targeting Handling

Image showing the TargetingHandler component, as seen in the Entity Inspector.

Targeting Handler Overview

Functionality

Selection Offset

Knowledge Processing

Stat driven values that determine how long a target needs to be detected to beceome part of the “active knowledge” of the unit. Applies to players as well, as the targets will be non-selectable if unknown.

Memory Processing

Targeting Cursor

Interaction Range Field

A unique Sense Field.

Collider that defines the most immediate interactable targets.

Gives “In Interaction Range“ cross reference to the senses targets.

Setting Up Your Targeting Handler

API

// GS_TargetingHandlerIncomingEvents::Handler overrides
bool RegisterTarget(AZ::EntityId entity) override;

bool UnregisterTarget(AZ::EntityId entity) override;

bool RegisterInteractionRangeTarget(AZ::EntityId entity) override;

bool UnregisterInteractionRangeTarget(AZ::EntityId entity) override;

AZ::EntityId GetInteractTarget() override { return interactTarget; };

// Local Methods
virtual void CheckForTick();

virtual void ProcessClosestInteractable();

ProcessAllInteractables

Determines the closest target, then processes the type that target is: Interactable/Item. Then sets the SelectedTarget to that single target.

Get Nearest methods fulfil the Processing, as well as AI checks.

Has Target of type. Query the database.

Extending Targeting Handler

2.2 - Senses and Targeting Fields

Image showing an Interaction Field component, as seen in the Entity Inspector.

Sense Fields Overview

Functionality

Fields always need to point to their designated Targeting Handler. Because fields all use their own collision layers, it is not advised to have any fields on the main unit capsule root. As they would then be forced to use the Units physics layer.

Interaction Fields

A specific type of field that populates the “In Interaction Range” list, enabling very atrgeted interact distance, and sorting limits.

Can be a uniquely shaped collider, which gives more control than the sensors.

FoV Detector

Fulcrum shaped cone facing a direction. Resolution and range define the arch of the end of the Fulcrum.

Has Line of Sight toggle.

Radial Detector

Radial, range sets radius.

Has Line of Sight

Probe Detector

A shape/ray cast that returns all overlaps.

Has Line of Sight (prevents detection through walls.)

Mesh Detector

A new one, use a mesh to define a collider?

Has Line of Sight

Using Sense Fields

API

GS_TargetingInteractionFieldComponent

// PhysicsTriggerVolumeComponent
bool TriggerEnter(AZ::EntityId entity) override;

bool TriggerExit(AZ::EntityId entity) override;

Extending Sense Fields

2.3 - Targets

Image showing the Target component, as seen in the Entity Inspector.

Target Overview

Functionality

Interact Target

Item Target

Enabled from GS_Item on “#IF GS_INTERACTION“

Unit Target

Enabled from GS_Unit on “#IF GS_INTERACTION“

PoI Target

Using Targets

API

Extending Targets

2.4 - Interact Input Reader

Image showing the InteractInputReader component, as seen in the Entity Inspector.

Interact Input Reader Overview

Extends Input Reader.

This component is a standalone input detector utility to enable Interact Input firing outside of the GS_Unit Gem.

It intakes the Event Name for your chosen interaction input, as defined in your Input Profile and ignores all other input.

Functionality

Interact Input Reader needs to be put in the same entity as the Targeting Handler.

After firing the correct Input Event, the Interact Input Reader requests the current InteractTarget from the Targeting Handler. It then sends a DoInteractAction event, with a reference to its EntityId as caller, to the InteractTriggerAction component that should be present on the Interact Target.

The World Trigger and Trigger Action system takes care of the rest.

Setting Up Your Interact Input Reader

Assure that the component is placed on the same Entity as the Targeting Handler.

Image showing the Interact Input Reader Component alongside the Targeting Handler Component.

Fill the Interact Event Name with the Event Name for your chosen interaction input, as defined in your Input Profile.

So long as the Input Profile that’s set in your GS_OptionsManager has that event set. The rest should work as is.

API

// OptionsManagerOutgoingEventBus
void HandleStartup() override;

// Local Methods (Parent Input Reader Component Class)
void HandleFireInput(AZStd::string eventName, float value) override;

Extending Interact Input Reader

3 - WorldTriggers

Overview

The World Trigger System is a simple, but robust, pattern of using Trigger Actions as reactors, or nerve endings, to evaluate and fire off a triggering event to a World Trigger.

Using trigger channels, the Trigger Actions and World Triggers can target and respond to specific events, regardless of if they are arranged on the same entity.

The power of the pattern of Trigger Actions and World Triggers is that nearly any Trigger Action, can trigger any World Trigger.

Their extensibility allows for easy implementation of unique features, while allowing the underlying class structure to process, and handle, the interaction between the two component types.

Trigger Actions

The Sensory component of the World Trigger pattern. TAs (Trigger Actions) receive/or monitor for changes in the world state, then, if everything is right, fires off to the receiving World Trigger to enact the outcome back into the world. Hence the naming: “World” triggers.

There are a couple extended TAs to create some common sub-types for regular patterns in use: Interact Trigger Actions, and Collision Trigger Actions. They both follow the same triggering process, but have an additional layer of functionality to interface with Interaction, or Collision/Triggering processing.

World Triggers

The Output component of the World Trigger Pattern. WTs (World Triggers) receive Trigger or Reset events from the TAs, and process how they will affect the world state.

They can be as simple at toggling an entity on and off. Or as complex as holding a multi-staged Activation/Deactivation tree to display a changing piece of environment over multiple stages of growth or destruction.

Wts never need to know what is driving the reason for firing. They simply do the act of changing the world environment. Hence the naming: “World” triggers.

Setup

Refer to the Interaction Set Up Guide in Get Started section.

Features

• Trigger Actions
• World Triggers

3.1 - Trigger Actions

Image showing a Player Interact TriggerAction component, as seen in the Entity Inspector.

Trigger Actions Overview

Functionality

Action Types

Environmental

• Difficulty (Game, Dungeon, Quest, Boss)
• Population (AG Village)
• Time
• Record
• Dungeon In/Complete
• Quest In/Complete
• Has Quest
• Weather
• OnStart
• Player Stats
• Player HasItem
• Every Seconds
• OnQuestStart
• OnQuestEnd

Collision Fields

• Proximity
• Correct InWorldObject Conditions
• Unit Stats
• Unit Inventory
• Pulse React

On Unit

• OnDeath
• Has/HasNot Stats
• Has/HasNot Item/Inventory
• Has/HasNot Equip

Interact Trigger Actions

Specific Trigger Actions activated by The Interact Input.

Passes Source interactor to DoActonFromInteractor, which fires the regular DoAction.

Interact Types

Self Firing

• World Item Interact
• Carry
• Pilot Unit
• Bonfire/Menu Open

Triggering

• Select
• Give Item
• Channel
• Craft

Using Trigger Actions

API

//! Override to establish your own DoAction process
//! Call Parent DoAction to see if Action Succeeds. Then use returned bool to process final behaviour.
virtual bool DoAction();
//! Override to establish your own ResetAction process
//! Call Parent ResetAction to see if Reset Succeeds. Then use returned bool to process final behaviour.
virtual bool DoResetAction();

//! Override to establish your own evaluation criteria.
virtual bool EvaluateAction() { return true; };
//! Override to establish your own reset evaluation criteria.
virtual bool EvaluateResetAction() { return true; };

Extending Trigger Actions

3.1.1 - Record Trigger Action

Image showing the RecordTriggerAction component, as seen in the Entity Inspector.

Record Trigger Action Overview

A component that triggers when the a defined record is changed to a certain value. Useful for connecting events on story progression flags, world variables etc.

Functionality

Inheriting from the RecordKeeperComponent’s Incoming Event Bus. It will automatically take in record updates and call TriggerActionComponent’s DoAction() if the changed record matches the local record’s name and value saved on the component.

Using Record Trigger Action

1. Create an Entity and add the Record Trigger Action Component in the inspector.
2. Set the Trigger Channel to the channel where you want your trigger to fire.
3. Define the record name, this is the name of the record you are looking at for changes.
4. Define the record value, set this value to what value the recordName needs to be at in order to trigger the action.

API

From TriggerActionComponent

//! Returns true if the values of the changed record's data is the same as our local record (This runs when DoAction() is called).
//! Override to establish your own evaluation criteria.
virtual bool EvaluateAction() { return true; };

From RecordKeeperIncomingEvents

//! Calls TriggerActionComponent's Definition of DoAction() when the defined record is changed.
//! Override to trigger when your record is changed.
virtual void RecordChanged() { return true; };

Extending Record Trigger Action

3.2 - World Triggers

Image showing a PrintLog World Trigger component, as seen in the Entity Inspector.

World Trigger Overview

Functionality

World Triggers do the actual processing once an input fires.

Triggers can Trigger Other Triggers.

Triggers can have Reset Enabled or Disabled.

Reset can be by toggle, or by direct command.

Repeated Activations can just keep firing the same Trigger if valid.

Triggers have logic for:

• Trigger

• Sets Triggered

• Updates Listening

• Reset

• Removes Triggered

• Updates Listening

Some can have boolean logic like “Any“ or “All“ as requirements to finally activate. Allowing the need for multiple Switches.

TriggerTypes

Basic Types

• Toggle (On/Off)
• ProgressionSwitch (Count Up/Down)
• Make Sound
• Play/Stop Cinematic/Timeline
• Dialogue
• Item Spawn
• Spawn Object
• Spawn Pulse
• GS_Action
• SetRecord
• Play/Stop Animation

Unit Facing

Has various means of targeting a Unit.

• Equip Item
• Affect Stats
• Give Item
• Status Effect
• Level Up
• Change Stage (player only)
• Teleport

Repeater/Boolean Types

• Invert Trigger
• Any/All Trigger
• Timeout Trigger

Using World Triggers

API

// WorldTriggerIncomingEvents
//! Trigger intakes a list of channels to determine if it should fire.
//! If onlyOnce, will not fire a second time.
//! Call parent to determine if Trigger goes through before handling additional logic.
bool Trigger(AZStd::unordered_set<AZStd::string> channels) override;

//! Reset takes channels like Trigger, but processes the reveral of what the Trigger did.
//! If can't reset, will not fire.
//! Call parent to determine if Reset goes through before handling additional logic.
bool Reset(AZStd::unordered_set<AZStd::string> channels) override;


// Local Methods
// Utility that quickly checks for channels being fired.
virtual bool EvaluateChannels(AZStd::unordered_set<AZStd::string> channels);
virtual bool IsTriggered() { return isTriggered; };

Extending World Triggers