Week 6 - Crash Test Dummies

This week, The plan was to begin creating the AI for the game. I have been dreading doing this because in my experience in my project last semester, I found that AI was very difficult. Especially so when it came to behaviour trees.

I focussed instead on a different aspect of my AI, which was getting them to interact with the spells. This was done through blueprints which I personally find to be a more enjoyable part of using Unreal Engine.

That's a lot of Damage!

The first aspect of my AI that I worked on was getting them to take damage. Since projectiles were the primary way of dealing damage, that is where I began.

Going back to my projectile blueprints, I had to give them the ability to recognise they had hit something, as well as disappear when they reached the end of their range.

I created a new event within my projectile blueprint interface. This event was for "Executing" the projectile when it was spawned. By this I mean, setting it up so that it had functionality. This event is called when the spell is cast.

Over in the projectile blueprint, this event then takes the current spell data and stores it in another data structure that can be used for other events such as when the projectile hits something. If the projectile does not hit anything after a certain amount of time it is then destroyed. this amount of time is determined by the range attribute of the spell which is actually just a length of time.

The hit is triggered by an overlap event if the projectile hits another game object. When it hits something, it calls an event within the projectile master blueprint, bringing the spell data with it.

I created a new blueprint interface called "Damage Effects" to handle these exchanges between the AI and the Spells.

When the projectile hit event is called in the master projectile blueprint, it first determines whether the object it has hit can be damaged by a spell. If it can't, then the projectile is scaled to show the hit (For testing purposes), and then destroyed.

If the object can be damaged, it first calls the "Damage Type" function, and then the "Projectile Damage" function. These are 2 events that will occur within the AI blueprint.

Is it Getting Hot in Here?

While setting up these systems, I focused on my fireball spell. This meant that Fire would be the damage type to be implemented first. Before Setting up the damage types, which will be used to create the status effects, I implemented plain old damage.

In the AI master blueprint, I answered the message sent out by the projectile on a hit. This would take the damage attribute of the spell and subtract it from the health variable of the enemy. I also added a death mechanic for the enemies when they reached zero health.

Now that the simple stuff was out of the way, I moved on to implementing the damage types.

I had to add more variables to the spell data structure in order to accommodate this new functionality. I also added some other variables for features that I knew were next in line to be implemented.

For damage types, the most important addition was that of "Spell Effect" and "Status Count". This would be the effect that is being caused, and the length of time it would last.

I also added some more functions to my blueprint interface. Each of these is tied to a different spell effect.

I now have a way of telling the AI master blueprint what to do with each of the different spell effects! At this point, The only one with functionality is Fire but I'm very happy to have the core mechanic in place.

The last thing I needed before I could implement the actual effects of the burning status was to set a counter. This function can be seen in the scene shot above, occurring before the actual effect is caused.

This function uses a map which assigns an integer to each damage type. It first checks if the enemy has a counter for that effect, and if it doesn't, adds an amount determined by the spell. I found that this was another way to use a map instead of having a long list of variables or another data structure.

Burn Baby, Burn!!

Finally, we make it to the status effects!

When the Burn Status event is called, it first checks what the current status counts for Wet, and Burn is. I used a neat little macro that simply checks if the count is 1 or higher and returns a boolean value. The first branch is actually the beginning of my combination system, but for now, it just ends the execution.

If the enemy is burned, then it takes damage. I chose to start with fire because of all the effects, it is the simplest, just doing damage to the enemy.

The blueprint destroys the enemy if this damage would take its health to 0. If it doesn't, it waits for 1 second. Then, it decrements the integer value of the map by 1, using a function I made. this then loops back to the start of this process. This process will repeat until the burn count has been reduced to 0.

This Week in Review

Once again, I am feeling behind. Filling out this blog usually makes me feel a little better. Going through the week's work and seeing what I have accomplished, puts it into perspective. Most of the time during the week, however, I am constantly plagued with worry that I am not doing enough.

Maybe the system I am trying to create is needlessly complex or I don't have the skill or knowledge to pull it off.

This kind of doubt is draining and sometimes spirals into thoughts of giving up on the project. I hope that things take an upwards turn and that all of the work that I have put in so far pays off. Next week, I will start preparing a presentation of my progress so far and hopefully find time to start working on possibly the most important mechanic in my game, Combinations.