Author: Matthew Chadwick

Date: 12/1/2023

Whenever a player start's their first game of CyberSiege, they are spawned in a tutorial level to start. The tutorial introduces the player to the concepts and mechanics used throughout the main game. The first iteration of the tutorial relied solely on collisions to advance through the steps. This resulted in a stiff and linear progression that could easily break or be manipulated. One specific issue is that the wave timer for the enemies started when the player spawned, which resulted in the enemies spawning before they were supposed to. To fix this, I implemented "Quest Activators", which was a combination of a component and an interface that could be bound to a step in the tutorial. I was able to use these activators to manipulate objects in the world, control the wave timer, and teleport the player to the starter map. This resulted in a more enjoyable tutorial that game the player more freedom to explore the map or take their time with the steps.

Video showcasing the quest activators preventing the wave timer from resuming, opening a door, and loading a new level.

My initial idea for the quest activators was to create an interface that each type of "activator" could implement on its own. This would allow me to call the "Activate" function from the Quest Manager, which would perform whatever activation logic was implemented for that activator. However, I ran into an issue when I realized that I may want multiple activators on a single class, or I may want separate instances of the same class to have different activation behavior. I also ran into a secondary issue when I realized that the activator interface would need access to variables, which interfaces in Unreal Engine are unable to use. To solve this, I created a component that implemented the activator interface which I could then attach to various actors that I wanted to have an activation behavior. This gave the interface access to variables stored in the component, but issue regarding the different activation behaviors was only amplified since now only the component was implementing the activator interface.

To solve this second issue, I decided to change the way the activation behaviors would be implemented. Instead of each activator having its own custom behavior, I decided to create an array of function pointers that would be used as the different activation behaviors. To do this, I first declared some constants that would serve as the array max size and the indicis for the separate activation functions. I then declared a integer variable that can be changed in the editor to modify what behavior was used in the game. I also added a second integer variable that could be accessed by the quest manager to determine which step the activator needed to be linked to. The combination of the activator component and interface allowed me to create interchangeable behaviors that could be changed in the editor and dynamically bound during runtime.