December 14, 2022
A ton of things were added in the final week leading up to the Gold code, so I’ll focus on the major items and wrap up with a reflection.
This is an enemy type I’d wanted in the game from the start— a burrowing worm that moves with appropriate snake-like movement. I originally thought to make this by designing a worm and placing some number of bones in it and animating the armature, but that seemed like a very complex solution. Instead, I went with modelling and worm head and worm “node” (left and right images respectively). Then, the instance of a worm would be a head with a number of nodes following it.
Programming the snake-like movement was surprisingly difficult. There were a number of tutorials for it in Unity, but they were mostly in 2D and often didn’t rely on proper rotation of the nodes. I eventually figured out a solution where each node (including the head) would define a “back” point that the previous node would point towards and follow. Getting the worm to behave as a single enemy was another issue, as the nodes couldn’t be parented to the head as the head’s transform would affect the nodes. Instead, the nodes have to all be separate objects in the hierarchy that communicate to each other via a shared Worm class instance. There was also work to be done to make sure that a single sword swipe on multiple nodes don’t count as multiple instances of damage.
Overall, it was a time-consuming enemy to make (a full day all-in), but I think it’s very visually striking and I was able to re-use it in multiple places throughout the project.
The other unique enemy type (not including the boss) that was added was the Pyramid, which charges a long-range laser that loosely tracks the player and fires after a delay. While the model itself was simple to create, the laser particle effects and Pyramid recoil animation did take a bit of tweaking. This was also my introduction to using Raycasts in Unity which seemed to be intuitive enough.
Variations of other enemies were also added, such as the bigger, longer Boss Worm and the Lava Golem which smashes in the large circle rather than a rectangle, both of which also look visually different.
The main cornerstone of my game that drives the fun and variety between runs is the runes. I needed to have a good number of them to make sure players could make a build that they wanted and not have the same ones every run. I ended up implementing a total of 17 runes (more were planned, but scrapped for time), which include some with pretty complex implementations, like Precision, which makes every 4th attack deal significantly more damage but has to work with magic abilities that are AOE and deal multiple instances of damage. Overall, I’m very happy with the number of runes I was able to implement and I think there’s a great variety.
Magic, on the other hand, fell a little short. The plan was to have half a dozen magic spells to choose from, but unfortunately for the sake of time I only ended up with 3. Lightfire, a long-range AOE magic ball; Flurry, a rapid homing barrage of bolts that apply on-hit effects; and Mending, a supportive AOE heal for allies. I’m happy with the three I chose to implement, as the dichotomy between Lightfire and Flurry mirrors that of the runes Precision (focusing on big single hits) and Hemorrhage (focusing on many small hits). There is also a supportive healing spell for team players as the third slot. If I work on this game further though, I’ll certainly add more.
I needed to make the most of my time in the last week, so I decided I will probably get a net benefit in efficiency if I spend a little overhead to make a Sandbox mode that has some respawning training dummies and has all runes and magic spells available to test. So, I did exactly that, and it was well-worth it. It was very easy to jump in and see how the implementations of runes and magic were working without messing around with adding test enemies to the scene and giving the player certain runes in code to start with.
