Adventure Fitness VR Archery System

1 Introduction

The archery related blueprints can be divided into three camps:

  1. Core blueprints that without them archery would not work.
  2. Secondary blueprints that are realted to challenges, targets, obstacles, etc.
  3. Aid blueprints that are either provide getter functions, or to add polish.

For the first camp we have the following blueprints and needed interfaces:

The second camp is comprised of the following blueprints and interfaces:

The third has the following blueprints:

The interfaces are used to path communication between all of the above blueprints without requiring casting and hard references to their respective classes (thus we only use references of class AActor).

2 Core Blueprints

Just a brief high-level explanation of how the interactions appear before diving into greater detail of each blueprint.

The player first grabs the quiver, attaching into onto himself and grabs the bow. Then going for the quiver, the player can grab an arrow then nocking it into the bow, pulls the string and releases setting the arrow loose. All the attaching events, gripping and so on are being mediated by the beforementioned interfaces.

So, without further ado a deeper explanation of each blueprint.

2.1 BP_Quiver

This blueprint handles the mechanism of feeding arrows to the player.

It has an active grip enabled volume that listens to “grip events” handling them to it’s discretion.

There are only two settings that one needs to be aware of to further tweak this blueprint behaviour:

One can find this beforementioned settings at category Settings|Haptics.

For a first grab the blueprint will call “AttachQuiverToPlayer” that does the following:

  1. Sets flag “bHasAttachedToPlayer” as True.
  2. Forces the player to drop the quiver.
  3. Tells the player’s pawn blueprint to attach this blueprint to itself trough “BPI_ArcheryPlayer”.
  4. Further grip events will cause the blueprint to check if the player has a bow (BP_Bow) equipped and if such bow does not have an arrow (BP_Arrow) already attached to it. This uses both the beforementioned interface and BPI_ArcheryWeapons.
  5. If both responses are positive then it will trigger “SpawnAndAttachArrow” that is sent trough BPI_ArcheryPlayer interface.
BP_Quiver with respective functions and variables.

2.2 BP_Bow

This blueprint core functionality is to attach arrows (BP_Arrow) to it’s string and setting them loose. Keeping track of the state arrow attached/not attached..

It keeps track of further the string has been pulled (animating the string in the process and playing feedback haptics if necessary) and uses that displacement to drive the arrows’ velocity.

This blueprint has a few settings that directly impact it’s gameplay feel.

The draw distance variables controll how much one needs to pull the string to fully draw the bow. That is, how further does the hand that gripped the string needs to travel to pull the string. Currently EasiestDrawDistance is being in use. These draw values are being in use by “GetDrawDistance” function.

bUseLongBow switches the skeletal mesh that the blueprint uses, along with switching the animation blueprint. This is due to the two skeletal meshes in use do not share a skeleton.

Currently the Longbow might need a bit of polishing on the right hand socket and a more in depth tweak to it’s animation blueprint (the string displacement needs further refining on it).

After the bow is grabbed it will remain attached to a player’s hand trigger forced grabs when needed (the go trough BPI_ArcheryPlayer).

BP_Bow with respective functions and variables.

2.3 BP_Arrow

This blueprint is just a projectile with not much added functionality added to it.

It has a volume that will trigger attaching events (that is, attaching to the bow if bow does not already has one attached to it) and another volume that handles collision events (they are being handled by BP_HitReactionComponent and BPI_HitReaction.

A few settings exist that impact either the gameplay or just the interactivity of the arrow:

When BP_Arrow attaches to the bow it will detach itself from the player’s hand. It uses GripOrDropItem from BPI_PlayerCharacter to do so.

BP_Arrow with respective functions and variables.

2.4 BP_HitReactionComponent

This blueprint handles collision events.The only setting to be aware of is DelayBetweenCollisions (this is just a delay for the case the projectile pierces multiple objects and we might not want to trigger too many events in a row).

It works as following:

  1. It’s owner blueprint reports a collision.
  2. Checks if it collided against an actor,
  3. Checks if it hasn’t recently collided with said actor.
  4. Checks if hasn’t collided recently.
  5. Checks if collided actor implements BPI_HitReaction interface.
  6. Sends all collision information to collided actor trough said interface.

2.5 VivePawnCharacter_ARnBox

This character handles all archery related player interactions.

They are all attaching events barring one (InputAction SwitchPreferredHands).

Only two settings affect gameplay:

The InputAction SwitchPreferredHands event just triggers a drop of the bow from the current hand reattaching it right after to the new set hand. (Just a flip/flop).

VivePawnCharacter_ARnBox with respective functions and variables.

2.6 VivePawnCharacter_Child

Parent class of VivePawnCharacter_ARnBox and child of VivePawn_Character.

Has no added functionality that directly affects archery.

2.7 VivePawn_Character

This blueprint comes from the VRExpansion plugin by MordenTral.

It implements all player required interfaces:

No settings are used by this blueprint.

Event GripOrDrop item is implmented here.

2.8 GM_SteamVR_ARnBox

Has BPI_ArcheryGame mode interface.

Only one setting to keep aware off:

Implements SpawnNewArrow that spawns a provided ArrowClass and outputs the resulting spawned actor.

2.9 BPI_ArcheryWeapons

Communication done to BP_Bow and BP_Arrow is done trough here.

Two categories of functions and events exist here:

BPI_ArcheryWeapons functions.

2.10 BPI_ArcheryPlayer

Communication done to player character regarding archery is done trough this interface.

A category exists for each element that interacts in game with this character.

BPI_ArcheryPlayer respective functions.

2.11 BPI_ArcheryGameMode

Communication to the GM_SteamVR_ARnBox is done trough here.

Currently only one function is there, just to spawn an arrow and to provide a reference to it.

BPI_ArcheryGameMode respective functions.

2.12 BPI_HitReaction

Interface used to mediate collision events between actors (in order to have them linked).

BPI_HitReaction respective functions.

2.13 E_Hand

Enum with two entries:

This enum is provided by the engine.

3 Secondary blueprints (Challenge Blueprints)

On this section all archery challenge related blueprints are present, same for target blueprints and all related interfaces and structs.

A higher level explanation on how the challenge is played out:

The player enters the challenge platform. This prompts the challenge controller to start reading the provided timings data table. When each timing is due it will trigger a spawn event on the challenge spawner. Challenge spawner will then in turn read the provided data table that holds information on which object to spawn and which pathing spline said object should follow. If the spawner has been set to spawn a fake target then instead it will spawn said fake target passing along to it the data table spawn information. When a fake target is spawned it will attempt to reach it’s goal destination, which is the first point of the pathing spline. When the goal is reached the fake target will then prompt the challenge spawner to trigger a spawn using the fake target’s saved spawn data. At this point with the correct target then spawned it will fetch the provided pathing spline using it to create it’s flight path which will promptly follow. If the target has any behaviour built in it will activate it at this point. The target is despawned when either the player shoots it with an arrow or the target reached the end of it’s flight path.

3.1 BP_Pathing_Spline

This blueprint holds a spline component that is later fed onto actors of BP_ArcheryTarget clase that will use it to build their flight path.

A few settings might be of interest depending on art direction and challenge design. To this actor can be added static mesh components that would act as visual cues (ie: lit/unlit torches, lights flickering) that could aid the player to know from where the targets are coming from and to where are they headed.

This would be more helpfull if the spline has more complex designs for the flight patters.

The settings to be aware off if applying said Visual Cues are the following:

BP_PathingSpline with respective functions and variables.

3.2 BP_ARnBoxChallengePlatform

The challenge platform consists of two meshes (Platform and Wall). Platform is only used to play visual effects that get triggered when a new target is spawned.

Wall is used to trigger the challenge start when the player’s overlapps it while also confining the player to it’s bounds for the challenge duration.

Currently there are two shapes that can be toggled: a square shape and a circular one.

Just two settings to be aware off:

BP_ARnBoxChallengePlatform with respective functions and variables.

3.3 BP_ARnBoxChallengeController

When this blueprint gets activated the challenge starts. It will read the provided timings datatable, evaluates each timming checking if they should be altered by any given amount, and when each revised timing is due it will trigger a spawn event to occur.

It also keeps track of currently alive targets (ie: targets that where neither hit nor have finished traversing their pathing).

Just a few settings need to be tracked:

BP_ARnBoxChallengeController with respective functions and variables.

3.4 BP_TargetSpawner_ARnBox

This blueprint has all the required logic for spawning the challenge targets with the correct data assigned to them.

It holds the data datable with information on objects to spawn and spline pathing to assign while also holds data of the chosen challenge objects and the pathing splines that exist in the level.

There’s a few settings to be aware of when setting up the challenge, they are as follows:

BP_TargetSpawner_ARnBox with respective functions and variables.

3.5 BP_Fake_Target

This blueprint will attempt to go towards a goal location (which in turn is the starting point of a BP_PathingSpline actor) and when reaching said goal it will trigger a spawn event.

Thus spawning an actor of BP_ArcheryTarget class. In order to mask this spawning event a mesh component is placed at the spawning event location.

Everything is already set up in place such that when BP_TargetSpawnerARnBox spawn this actor it will have the correct settings. But is always good to be aware of the following variables:

I would add that only the two variables in the Visual Effect category are needed to further refine the challenge as they happen a lot during the challenge and their visual impact is significant.

BP_FakeTarget with respective functions and variables.

3.6 BP_ArcheryTarget

This actor has all the logic needed for it to function. The children blueprints only have their behaviours implemented and override any needed functionality.

A few of it’s settings are set when the actor is spawned while others are set at editor time.

BP_ArcheryTarget with respective functions and variables.

3.6.1 BP_ArcheryTarget_Accelerator_Deccelerator

This actor has a random bool with weight node that will select if it should accelerate or deccelerate when it’s behavior is triggered.

It basically applies a custom time dilation to “simulate” it as changing the InterpToMovement node proved unsuccessful

So the only setting to keep track it’s the weight to be applied.

BP_ArcheryTarget_Accelerator_Deccelerator with respective functions and variables.

3.6.2 BP_ArcheryTarget_CorckScrewMovement

This actor uses a RotatingMovement Component to Rotate the mesh around the movement path.

No settings to be tweaked.

BP_ArcheryTarget_CorckScrewMovement with respective functions and variables.

3.6.3 BP_ArcheryTarget_Kamikaze

No settings to be tracked. This blueprint uses a projectile movement component to home in on a target position when it’s behaviour is set.

BP_ArcheryTarget_Kamikaze with respective functions and variables.

3.6.4 BP_ArcheryTarget_WaveMotion

This blueprint uses a timeline to simulate a waving motion. It basically displaces the mesh either sideways (on Y axis) or up/down (on Z axis) or both at same time (albeit for having both perhaps using separate timelines might be advisable).

Few settings to be aware off:

BP_ArcheryTarget_WaveMotion with respective functions and variables.

3.7 BPI_ArcheryChallengeController

Communication to the challenge controller is done trough this interface.

BPI_ArcheryChallengeController respective functions.

3.8 BPI_ArcheryChallengeElements

Communication between all archery challenge elements (barring the controller) are done trough here.

So in sum, the spawner, platform, pathing spline, targets and bunker.

BPI_ArcheryChallengeElements respective functions.

3.9 F_TargetSpawnData

Struct that holds Object Spawn Data. Comprised of the spline track and the index of object to spawn.

3.10 F_TargetSpawnDataArray

Struct that holds an Array of object Target Spawn Data entries.

4 Aid Blueprints

4.1 BP_Bunker

This actor has active volumes that check if a target is residing inside them. Thus controlling a door state: either opened/closed. If opened it can close when no targets are there.

This state is fed onto an animation blueprint to animate doors opening/closing.

BP_Bunker with respective functions and variables.

4.2 Steam_VR_Player_Controller_ARnBox

This actor has the interface BPI_PlayerController implemented on it. It is used to pass along Play Haptic Feedback commands.

It calls Play Haptic Effect (which is native to the engine).

Steam_VR_Player_Controller_ARnBox with respective functions and variables.

4.3 BPFL_VRFitnessControlers

This blueprint function library has a few functions that can help retrieving the VivePawn’s GrabSpheres, GraspingHands and GrippingControllers. It can also perform checks to see if references we may have are from a left or right hand.

It also has a function to retrieve the VivePawn.

BPFL_VRFitnessControlers respective functions.

4.4 BPML_VRFitness

This blueprint macro library currently has two macros in it. One controlls execution providing a ForLoop with a delay setting to it. The other checks the validity of an actor by testing if it has both the correct interface and tag assigned to it.

BPML_VRFitness respective functions.

4.5 BPI_PlayerController

Currently just has one event in it. Meant to implemented in Player Controller blueprints.

BPI_PlayerController respective functions.
Joao Jordao Avatar

Posted by

Leave a comment