Week 5 - Variety is the Spice of Life

Now that the groundwork is done on my spell system, I have started adding the different types of spells.

The three main categories of spells in my game are:

Projectiles - Spells that cause damage and inflict status effects on enemies.

Defensive - Block incoming projectiles and change the composition of the battlefield.

Traversal - Allow the player to move more freely and traverse traps and obstacles such as

pits.

So far, I have only created projectile spells, so this week I started on the other two types. Like with projectiles, I plan on creating one version of each type of spell as a base that can be duplicated and modified to create a greater variety.

This includes:

Dash - Traversal spell

Rockwall - Defensive spell

Run like the Wind!

The first spell that I tackled was the Dash spell.

This spell, and most other Traversal spells, allow the player to cover a much greater distance than they could by just using the movement mechanics. A lack of gravity during these manoeuvres means that they can be used to traverse pits and traps. This will take the place of a jump mechanic which I will not be including in the game.

This mechanic was inspired by dash/evade mechanics often seen in games such as Dark Souls or Hades. Many of these games include invincibility frames but for this first spell, I wasn't going to include this feature.

When creating this mechanic, I referenced the following tutorial from Matt Aspland on Youtube.

https://www.youtube.com/watch?v=XjKKUV8SwP8&t=343s

This formed the basis for how my dash mechanic would work.

As you can see in my blueprint, when the spell is cast, I first disable input. I want the player to have to commit to the dash and not be able to perform any other functions while in the dash. The code then launches the player character slightly into the air and then forwards in the direction that they are facing. Once the dash is complete, input is reenabled.

As I knew that different versions of this spell would have different ranges, I set the forward launch to be tied to the range variable of the spell. This means that when I created different spells with higher ranges, I only have to edit this variable.

Hitting a Brick Wall

Compared to the dash spell, The defensive items were a little more complicated.

First, I added a component to my Player character blueprint. this was an arrow that would mark the place where the defensive item (In this case a rectangular static mesh), would spawn. Because these defensive items needed to sprout from the ground, I used a line trace to shoot down from this spawn point. The hit location of this line trace would serve as the spawn point for the defensive item.

Inspired by the Cryosis mechanic from Breath of the Wild, I wanted to limit the amount of these defensive Items that the player could have at any one time. A classmate who was a part of my group for another module gave me some very valuable insight into how he had achieved this mechanic in his prototype from last semester. It was with his help that I got this mechanic off the ground very quickly, so thank you very much, Ryan Blair!

I created an empty array variable called "DefensiveItems" within my Character blueprint. Each time that a defensive item is spawned, it is added to this array. Once the array reaches the maximum number of defensive items allowed, the first item on this array is destroyed and removed from the array.

In Your Face, Interface!

Blueprint interfaces have become an invaluable tool within this project. For spells, they allow my character blueprint to interact with all of the different spell blueprints that I have created.

Depending on the type of spell, each blueprint uses a different blueprint interface. Using the above system, My character blueprint can determine what kind of spell is being cast. While this might seem like an unnecessary step, and it might well be, it really helped me personally in terms of breaking up the spell types, and visualising the flow of the code. It's kind of like a safety net, letting me know exactly where the execution line is going each time a spell is cast.

It was also a great way of getting information from one place to another. such as here in the Rockwall spell, I can carry through a reference to the Character blueprint without having to cast to it.

I used Blueprint interfaces in my project last semester and found them to be super useful, hence why I might have gone a bit overboard in this project. Anytime I got confused or wasn't sure if they could be used the way I wanted to, I found lots of help from Matthew Wadstein's youtube channel.

https://www.youtube.com/c/MathewWadsteinTutorials

Switching it up!

Now that I have a collection of different spells that my Character can use, the next task was to create a way of switching through these different spells at will. Being able to do this was another core mechanic for my game and was next on the agenda.

Ready...?

First I had to do some preparation. I created several variables that I would need.

The first was my "SpellBook" array. Last week, I decided that the best way to "equip" a spell was to spawn an instance of that spell and attach it to the player character.

For testing, I have been telling the system what spell to spawn when the game begins. To change the spell at run time, I need to be able to give it a list of possible spells that it will be able to spawn.

The "SpellBook" variable is an array of actor classes which contains all of the spells that the player can currently choose from.

I created a "Current Spell Class" variable, also an actor class variable, which will be set when the player changes spell, and a "Current Spell Index" variable (Integer), which identifies which spell from the spellbook needs to be referenced. "Current Spell Actor" is used to keep track of the instance of the spell that was spawned and attached to the player character, and "Current Spell Data" is used to store the range, damage, damage type, etc, of the currently equipped spell so that it can be easily referenced later.

Lastly, I created two more variables to use in my spell switching system. The first was an array of data structures that contains the data for all of the spells in the game.

The second is a Map variable that is comprised of an actor class and an integer. I had researched maps in my last project but wasn't sure how to properly implement them. I have Matthew Wadstein to thank again for clearing up my confusion.

Set...?

Now that my variables were ready to go, I just had to implement them. Below is the blueprint that I created for my character blueprint to allow the player to change the index of the spellbook. I made it in a way that if the player reaches the bottom or top of the list, then it will loop back around.

Once the index has been changed, it gets the associated spell class from the spellbook and sets it as the current spell class.

While creating the next part of this blueprint, I realised that I could collapse it to a function that could then be used in other parts of my character blueprint and avoid redoing the same code.

In the first part of this function, the spell that is being unequipped is destroyed to make room for the new one. (The is valid node was put in place to stop any potential errors occurring in the event that no spell was currently equipped.)

Once the way is clear, the new spell is spawned and attached. The actor is set to be hidden and has no collision to avoid any issues with character movement.

Between the spawning and attaching, I added some code to update the Current spell data structure. Originally, this code had come after attaching the actor. For some reason that I was unable to discern, this was causing issues. Reordering the code solved this but I am still unsure as to what caused the issue in the first place.

GO!

I now have a functioning spell selection system! As seen in an image above, this system relies on a print string to show which spell is currently equipped. While sufficient for testing, this highlights the need to add a HUD and UI to my game.

For now, I am just happy to get this core mechanic implemented. Here is a quick demo of my current array of spells, including the character switching between them using this newly implemented system.

This Week in Review

I am still feeling the effects of Week 3. I feel that these features should've been functional last week or even the week before. That said, I am very proud of these features. They work more or less exactly as intended and I feel as though I have implemented them well.

While working on the spell switching system, I put a bit of thought into how I am going to create my UI. One of my big inspirations for the Spellbook UI is MMORPG games such as World of Warcraft.

I don't think that I'll be able to reach the graphical quality of this UI, and obviously, my system will be much simpler, only featuring 5 slots. I do think that I will be able to reach a stage where the player is able to recognise the style of UI and use it in a similar way.

An issue that I have once again stems from having to create a dual input system. I created functionality for both a controller input and for the mouse scroll wheel, although as of now, my scroll wheel code is still giving me issues.

After testing and troubleshooting, it seems that the scroll wheel is constantly giving input, even when it is not being touched. This could be an issue with my mouse but I'm still not sure, so for now I have disconnected the code to allow testing with the controller.