Some Features Listed are pending GS_Interaction v2 implementation.
Overview
Setup
Refer to the Interaction Set Up Guide in Get Started section.
1 - Pulses
Pending GS_Interaction v2 implementation.
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
2 - Reactors
Pending GS_Interaction v2 implementation.
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.