As a level designer, I would like to be able to place enemies of different levels into my waves so that I can challenge the players. (1)
This involved changing the way we set the levels of the enemies. Originally, we had multiple enemy prefabs for each level. Now, the levels are set in the Wave scriptable object.
I also added more error checking in the Advanced Spawner script. I was worried that the level designers may accidentally enter an incorrect value (which is easy to do), which would cause null reference exceptions.
I also gave detailed messages in the case an error occurs. That way, if we’re testing the game, we can immediately fix the numbers.
In the case an error is not caught during testing, the game should still run fine, since I assign default values in the case of some out-of-range exception.
As a player, I would like to see all of my buildings implemented within the game so that I feel as though I am playing a more complete game. (3)
This was simply importing the models for the new lair models into the game. Nothing really to say here.
As a player, I would like to see related particle effects for Level 2 implemented in the game so that it is brought to life. (3)
These particle effects used the same system as the other ones I did for Level 1, so it didn’t take very long to implement.
I also organized the particle effects folders, separating the placeable particle effects (for the level designers) and the non-placeable effects (that are programmed into the game).
As a player, I would like my Winter Minion to fire rapidly at enemies with snowballs so that I have variety in the minions I use to defend my Lair. (3)
The Winter Minion is pretty much a regular minion and the old rapid fire building combined. We never used the rapid fire building code, but I was able to easily transfer it over to the PlayerUnitAI script.
While the PlayerUnitAI script could be heavily changed to allow for this new type of attack, I opted for the simple approach of creating an Enum for the different types of attack a minion can do. When the minion is in an Attack state, it will check which type of attack it should perform through a switch case.
The whole rapid-fire attacks are handled similar to regular attacks, except that instead of instantiating a single projectile, it will invoke an IEnumerator, which will fire multiple projectiles within a fraction of a second.
As a player, I would like the Level 3 Lair implemented in the game so that I can see what I am meant to protect for that level. (1)
Again, all I did was add the new models into the project. Since we have no Level 3 (as far as I know) yet, there is no scene for the Level 3 Lair model.
IN PROGRESS
As a player, I would like tiles that have been targeted by an ice spell to encapsulate enemies that walk through it in ice to freeze them. (3)
Currently being verified.
This is a new spell that will freeze the enemy, which means they can’t attack or move for a certain amount of time.
Originally, I wanted to avoid the EnemyUnitAI script being reliant on any FreezeTile script. I changed the enemy’s variables (like speed) within the FreezeTile, and was using a KeyValuePair for some reason. This wasn’t really working for me, so I tried a more intuitive approach. The solution ended up working neatly.
Enemies have a state Enum (like minions). They can either be in an Attack state or a Move state depending if there’s minions nearby. When an enemy is frozen, they shouldn’t move OR attack, so I thought, ‘why not add another state for that?’.
When the enemy is in this Frozen state they visually do nothing. In fact, all it’s doing is decrementing a timer, and checking if the timer is less than 0 (and in that case you’d unfreeze the enemy).
The way FreezeTile communicates with the Enemy is by calling some of the Enemy’s new public functions, Freeze and Unfreeze. That way FreezeTile has no need to know about anything else about the enemy-- just call the functions and let the Enemy do whatever it needs.
No comments:
Post a Comment