Kilan Larsen
Card Garden - Sprint 3
My Completed Tasks:
​
-
As a player, I would like for my units to be able to have typed levels so that they can specialize in different kinds of damage and give me options.
​
The first thing that I worked on for this sprint was typed levels, such as fire, lightning, or ice levels that can be added to a minion/tower in addition to the normal leveling system. This works similarly to multi-classing in D&D, where the unit can have levels in many different classes, but can only have 20 total levels. To test this, I set up Debug lines for when I pressed keys on the keyboard. 'B' increases the base level, 'F' increases the fire level, 'L' increases the lightning level, and 'I' increases the ice level.
​
Following this​ implementation of the typed level up system, we needed a method for the player to increase these new level types. Introducing... SPELL CARDS!
​
-
As a player, I would like spells to modify specific types of other cards and their respective buildings/minions temporarily or permanently.
​
-
As a player, I would like to be able to select a tile on which to cast a spell by playing a card.
I was worried that this system was going to be very complicated, as Spell cards can do a wide variety of different things. However, I was able to come up with a system which is easily modifiable for each Spell card in the game. Here's the basic framework:
Whenever a spell card is 'played' (via the CardPlacement script), it will call a StartCoroutine( ) on the ActivateSpell( ) method of the Spells script (shown here). It must pass in the enum for the Spell to cast and the Activation Time (both of which are stored on the card being played), as well as the location to activate the spell (this could be a tile, building, or minion depending on the spell). After waiting for the proper activation time of the spell, it calls CastSpell to actually choose which spell to cast. Because each spell is unique, they will need unique functions which are called from the Switch statement depending on the value of the Spell enum.
​
With this setup, each new spell card will need a corresponding enum, CastSpell case, and method in order to be used. This allows us to manually change the functionality of different spell cards.
These are the three different spells that are built into the game at the moment, separated by spell type.
Next, I was planning to add more functionality to the level types system, but due to development changes on that feature I decided to work on enemy targeting instead.
​
-
As a player, I would like enemies that are nearing my Lair to be targeted by surrounding Buildings and Minions so that my defense is stronger when I am more severely threatened.
Previously, Towers would always target the 'first' enemy to enter their range, but this isn't always the enemy that is closest to the player's lair that they are trying to protect. I thought about solving this issue with a distance check to the lair, but realized that this solution also would not work. I drew up a diagram that explains this dilemma:
Given the situation shown above, we want our Tower to attack enemy[1], therefore we need to find which enemy has the shortest path to the lair. Or so I thought. It turns out that trying to get the distance of a NavMeshAgent's path is complicated, and involves calculating the corners of the path to the lair and the adding up the distances between each corner. Implementing this proved computationally expensive and prone to errors.
Instead, I added a 'distance travelled' variable to the EnemyUnitAI script which sums up the displacement of the enemy between frames. Then from the TowerAttack script, for each enemy in range we find the one with the greatest 'distance travelled', and thus fire upon the enemy closest to the lair. Phew!
After that was completed, I began work on a basic win and lose screen so that players in our prototype will know when the game is over.
​
-
As a player, I would like a temporary basic visual of when I have won the game so that I am aware of the fact.
​
-
As a player, I would like a temporary basic visual of when I have lost the game so that I am aware of the fact.
​
These tasks *should* have been really fast to implement, but I made the unfortunate mistake of seeing another team mate's UI code and thinking "I can improve this!". The main thing I wanted to change was to turn an array and a list of indexes into an enum so that the index for each element in the array did not have to be looked up each time in order to make new UI implementations. However, I failed to communicate this change with the person who wrote this code and did not realize that it was already being used to handle the Start Menu functionality. In essence I broke his code and his scene and ended up having to revert everything back to the way it was. Lesson learned!
​
​
The last thing I did for this Sprint was to implement card upgrades. This means that playing a second card of the same type can level up an existing unit (for example, playing an Arrow Tower card on an existing Arrow Tower levels it up by 1).
-
As a player, I would like to be able to upgrade an existing unit by playing a second copy of that unit's card so that I have the power to strengthen my units.
This feature went quite smoothly, and was primarily just an adjustment to my CardPlacement script. In the case that the selected card matches the card data of the highlighted object, then clicking will call the LevelUp script attached to that object and level it up by 1.
My next task starting in Sprint 4 will be:
​​
-
As a player, I would like cards, and any units/buildings/spell effects summoned by them, to store an element so that I can feel like I have lots of options in the types of cards I can play.
​
And my other tasks following that will be:
​
-
As a player, I would like to be able to earn new cards as I progress through waves of enemies so that I can feel rewarded as I go.
​
-
As a player, I would like to hit all enemies with lightning when I cast my Deus Ex Machina Spell so that I can feel all-powerful.
​
-
As a player, I would like to have a new hand after every Encounter so that I can strategize in new ways every time.
​
-
As a player, I would the game to pause between Encounters and wait for me to start it before moving on so that I have a second to breathe.
​
-
As a level designer, I would like a stable build of the game so that I can work in it and make progress off the Collab.
​
-
As a player, I would like to be able to play a card to cast a Bee Spell.
​
-
As a player, I would like to be able to play a card to cast an Oil Spell.
​
-
As a player, I would like to be able to play a card to cast an Ice Spell.
​
-
As a player, I would like tiles that have been targeted by an ice spell to slow down enemies that walk through it for a certain amount of time so that they have a lasting effect.
For Sprint 4 it looks like I'll be re-working the leveling type system again, adding new spells, and adding new functionality to the card drawing system. Sounds like fun :)