This sprint, I mostly worked on finishing up the last remaining spells in the game. I also redid how the player moved in order to prevent the player from shaking on walls, which I’ll talk about first. I started using VS Code this sprint as well. It’s nice, since it doesn’t take 10 hours to open up like Visual Studio 2019.
Player Movement
Originally, the player moved by changing the position of the player directly. This wouldn’t be a problem if we had some kind of pixel-perfect collision checks going on, and to be honest that would be overcomplicating things. It’s Unity. With everything you do, there is probably an easier way. (At least with my experience with Game Maker Studio 2 and PICO-8). Rather than changing the transform position, I change the player’s rigidbody velocity. This cleans up the code, and also automatically handles collision in a visually natural way. See Figure 1.
Figure 1. I am using a testing scene of the project to do my work, but this also works in the actual game scenes.
Fire Spells
The next thing I did was 3 fire spells. The Flamethrower uses Bezier curves to move the cluster of projectiles. I already had pre-existing code of Bezier curves in another spell, so this didn’t take long. The combustion spell was somewhat complex, since it involved finding all enemies in a room, and then Igniting them. I had an idea of how to do this, but my experience with using ScreenToWorldspace-type functions has not been enjoyable. It took me awhile to get it working right. See Figure 2 for my implementation of Combustion.
Figure 2. I grab the dimensions of the top left and bottom right of the screen, and convert those into world space. I then create a big physics check on the whole screen. If the collider has an EnemyBase script, it’s an enemy, so I apply Ignite to it.
The final Fire spell, Ember, I found to be easy to implement, and also visually cool-looking. I spawn a bunch of flames (circles) around the player, and after three seconds, each flame hurls themself towards the nearest enemy. See Figure 3.
Figure 3.
Shadow Spells
Finally, I worked on six Shadow spells. Some were slightly more complicated than I first imagined, but they turned out cool. Miles thought the Black Hole spell would be a challenge. I did come into some hiccups, but I was able to get it working within about 20 minutes. The Black Hole pulls enemies towards the center of the spell, as you might guess.
Dealing with enemy layers was annoying. For some reason, the enemies have many different layer names. Two are assigned “Enemy”, one is assigned “FlyingEnemy”, and one of them is “Water” for some odd reason. That’s just one example of how messy the project has become.
Most of the shadow spells rely on the number of cards on your discard pile. For example, Implode deals damage to X+1 enemies, where X is the number of cards in your discard. Implode was one of the more complex spells to implement. I used the previous combustion code to create a list of all the enemies on screen. I then sorted the list according to how close they were to the mouse position, using a Comparison function. See Figure 4 and 5.
Figure 4.
Figure 5. Ripped-off from the Internet, no shame.
After prioritizing the enemies based on closeness, I had to apply damage to the X+1 nearest enemies, and then I had to spawn 5 projectiles at each enemy. The effect looks interesting. See Figure 6.
Figure 6.
The other more complex Shadow spell was Siphon, and is probably my favorite spell I’ve done this Sprint. It targets the nearest enemy to the mouse position, “pulls” projectiles out of that enemy, and towards the player. For each enemy hit by the projectile, the player heals 1 hp. That’s a lot of steps. To visually make it so the player knows how much they’re healing (somewhat at least), I increase the alpha of the green “siphon orbs” when they collide with an enemy. See Figure 7 for the video.
Figure 7.
Concluding Thoughts on the Project
I have some complaints about how the game is turning out. We noticed after the first playtest that the game has problems, and have done little to fix them.
First off, the spells are spammable without much strategy. I think we could use mana, and/or the ability more or less than three cards in your hand. Yes, you ALWAYS need three cards in your hand, which is strange, and has never been addressed.
Second off, the enemies are as dumb as rocks. They just move towards the player like zombies until they die. We are adding new enemies into the game for the final build, which should remedy the issue.
List of cards completed:
As a player, I would like to stop shaking on walls, as well as not be able to overlap with the wall. (1)
As a designer, I would like 3 Fire Spells to be added. (3)
As a designer, I would like 3 Shadow Spells to be added. (3)
As a designer, I would like 3 Shadow Spells to be added. (3)
No comments:
Post a Comment