Bug Fixes, Small Features, and Penrose Tiles

Clockwork Sword

The last two weeks have been spent mostly on fixing a wide variety of small bugs, making small features, and optimizing the game.

Bug Fixing

There were two major bugs with the attack system (which is used by the player, boss, enemies, and traps to deal damage). The first issue was related to how obstacles that block attacks are detected. The existing code had two main flaws, it used the origin rather than the bounding box center for line trace destinations, and it never 0ed out the verticle axis, and thus the raycast could sometimes collide with the floor or miss the colliders entirely when the collider had a bad origin.

The other major attack issue was related to how the attacks were being linked to animations. This bug was caused due to a lack of regression testing, as attacks were originally only allowed to have durations if they were linked to animation, however as the game was developed we found that the vast majority of attacks were not linked to animations, but still required durations for gameplay logic. Because of this, I added the ability for attacks to have a set duration, but this inadvertently broke their ability to copy the duration from the animation they were linked to.

Of course, there were also many other bugs but they were far less interesting.

Minor Features

This week I also implemented two new minor features: Activation Areas and Enemy Locks. Activation Areas are areas that group enemies in a room together so that they share an agro state. I recorded a tutorial for the level designers so they could use it. I also created enemy locks which can be added to interactives like doors to prevent the player from using them while enemies are agroed to them. This was made to prevent the player from rushing through the level and skipping combat.

*When I mentioned at the end of the video that enemies will not activate if they take damage, I meant that they will not be activated by taking damage, not that damage will prevent them from activating (this was a source of confusion for a couple of my teammates).

Optimizations

Our game had major lag spikes whenever the player picked up items. I used the profiler to figure out the source of the lag. It showed that the biggest time sink was the processing that our mesh outline plugin was doing to build its shaders. I remembered seeing that the plugin allowed for outlines to be pre-baked, however, our current code was adding the outline components at runtime. This was an easy fix, but the lag spike persisted. The next biggest sink was the Unity collision code, but I wasn't doing any collision detection during the refresh, but I was adding mesh collider components at runtime. I figured Unity probably did something similar to the outline plugin and would pre-bake collision data if the component was instantiated as part of a prefab rather than added at runtime. This proved to be correct and was once again a quick fix. However, it still took 9ms per workbench in the level when picking up a new item due to all of the prefabs being instantiated. I figured the easiest solution was to modify the workbench so that there was actually only 1 workbench that would teleport around the level to be at the closest location to the player. This worked very well and now instead of having a 200ms lag spike every time an item was picked up, it was only 9ms which was a huge improvement and made it so that the lag spike was unnoticeable.

VFX

We only have one VFX artist on our team, and while he is very skilled, he is still very overworked so I wanted to take one item off his list of tasks. Our exiting item pickups were just the item mesh half inside a semitransparent geen sphere with no FX. I made a new set of VFX that had 3 parts: a background glow that would scale to match the bounding box size of the item mesh, an abient particle emitter shaped to match the item, and a burst emitter and animation for when the item was picked up. Here is the final system I settled on after receiving feedback from several other team members:

Misc. Side Projects

The other week I stumbled across this video:

It inspired me to try making my own Penrose renderer using the algorithm that was alluded to in the video because I thought it would be really cool to have a game or procedural generation system with a Penrose tile grid. So far my progress has been slow, as I have run into several issues including float precision errors and I've had to restructure my approach several times. But, I think I'm very close as I have a system that can correctly generate the spokes of a Penrose pattern. I just need to fix some issues relating to how I am picking the nearest intersection point between two lines where both are not passing through the origin.