This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

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

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 - 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

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

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