Fixing Refactor Issues

Today was spent making sure I didn't break anything when refactoring the Glimmerstalker.

Errors with the Harassment Actions

When I went to configure the new basic Harassment Action in the Inspector yesterday, I ran into an error when hovering over the add/remove buttons for the Potential Morale Modifiers list. I was able to add one element to the list before it stopped working completely.

Trolling around online, I came across that private nested classes don't play well with ScriptableObjects. I was using a private nested class to get the "Dictionary" behavior in the Inspector so I could pair the Morale Modifiers with their chances of being selected. I've used this pattern several other times without any issues but apparently they work because Unity is not wholesale serializing those objects like they do with ScriptableObjects. Changing the nested class to be public resolved a couple of the errors being shown but there were still one other error.

This one was harder to track down but from a Unity forum post, it looks like this error was introduced in Unity version 6000.0.51f2 and hasn't been resolved yet. For now, it is not blocking our work, so I won't worry about upgrading to Unity 6.2.

Crew Not Protected by Lights

Once I got the HarassmentAction working I went to test it in game. I quickly ran into a problem where the Glimmerstalker would almost immediately switch over to the Stalking state and wouldn't harass. I didn't have the Stalking state doing anything yet, just switching over to it if there was an applicable target.

It took a bit to figure out what was going on. I didn't really have good messaging for when the Glimmerstalker changed states so at first it just looked like they weren't doing anything. I ended up expanding the debug panel to include the Glimmerstalker state and target. It made it obvious that the Glimmerstalker was moving to the Stalking state almost immediately but not why. To help figure that out, I added more info to the debug panel. Now I could see which characters were in the light and which ones weren't.

Here is what that looked like at the end. You can see that the Glimmerstalker starts Stalking Lee once they have been out of the light for long enough.

Note: This gif is from after I fixed the problem explained below, I just wanted to show the panel working here and I didn't have a "before" gif

What I found when looking at all the info was that none of the Crew were ever shown as being in the light. This meant that they were all unprotected the entire time and as soon as the stalking timer elapsed, the Glimmerstalker would pick one and start Stalking them.

This problem turned out to not be related to my refactoring. The Crew had never been protected by the lights, we just didn't know it because we never had logic to change the Glimmerstalker to the Stalking state before. After a lot of Debug.Log(...) this turned out to be an easy fix. In order for a trigger collider to fire, one of the two objects needs to have a RigidBody component. Neither the Crew nor the light had a RigidBody. We didn't notice it before because the Player and the Glimmerstalker both a RigidBody on it and they were triggering the debug logs, so the lack of the Crew triggering them was buried.

Putting a new RigidBody on the Crew fixed the issue.

Random Movement to Origin

One thing I noticed was the Crew and the Glimmerstalker would periodically move to the world origin instead of a random point. I didn't see this behavior on the Crew until we added the Terrain. This makes sense to me because the original logic for finding a point on the NavMesh didn't take verticality into account. My hypothesis was that the point we were testing was actually underneath the terrain and not close enough to the NavMesh for it to pick it up.

The fix I added was to move the point I'm testing for up by some amount then try raycasting down to see if it hits something.

This allows a lot more flexibility when the Crew or Glimmerstalkers pick new points to move to. So far I haven't seen the same issue.

Too Short of a Leash

From the beginning, we've wanted the Player to be "tethered" to the caravan to prevent them from running off the edge of the map or (more importantly) not running too far ahead to reach the end or too far behind and having the tile unload underneath them. Andrew got that implemented and it works well...too well, in fact.

Once you take the snow spawning into account, the tether was too short and almost all of the "energy" snow (used to refill your spell energy) was outside the tether. I wanted to increase the distance, but I had no idea how the numbers correlated to the scene itself. Was 10 enough? What about 100?

I needed a way to visualize the tether range. Luckily, I've already done this a few times! Instead of making a new DrawCircle method, I ended up just using the existing DrawArcs methods I had and configured them to draw a circle instead (i.e. two arcs of 180°). Now I could see where the tether ended and could adjust it appropriately.

This felt a lot better to play. However, when showing Terra the functionality she brought up a really good question.

Are we going to ensure that the energy snow only spawns within range?

This was a tricky question to answer but a good one. When testing, it was incredibly frustrating to see energy snow just outside your reach!

We couldn't just say it should only spawn within X units of the caravan because the snow is spawned when the tile is spawned. Another compounding factor is that the path the won't necessarily be straight, as seen above. This means that if we just make it X distance from the center, there will be some spots where the snow just ends as the caravan moves further away from the center line.

A potential solution we came up with would be to have a box of colliders that follow the caravan along the x-axis. Since it is locked to the x-axis, it will keep up with the caravan but it won't move off the tiles in the z-axis. This would allow us to use the full breadth of the tiles (or at least a more controlled area) to spawn the snow in.

In the graphics below, the green are the tiles, yellow is the caravan, and the blue are the proposed colliders. You can see from the first graphic that even though the caravan is off-center the colliders are still centered in the z-axis.

We want to run the idea past Andrew as well to get his suggestions for the tether problem. For now though, some quality of life to make the Stalking testing easier.

Adding Debug Commands to Debug UI

One of the problems I've been running into while playtesting everything is that sometimes I don't want to deal with the cold or maybe I don't want the caravan to move (or to move faster!). The real answer is to actually tune the game so everything doesn't happen as fast but that doesn't sound like as much fun as adding new features!

I added a couple more keybinds that are only active if you have the debug panel open. These keybinds affect the global warmth depletion rate and the caravan speed.

Action	Key
Zero Warmth Rate	NumPad 1
Normal Warmth Rate	NumPad 2
Double Warmth Rate	NumPad 3
Zero Sled Speed	NumPad 4
Normal Sled Speed	NumPad 5
Double Sled Speed	NumPad 6

You can see them in action here. Along the top of the debug panel it shows the current value for those modifiers.

Maybe tomorrow I'll stop procrastinating and work on the actual Stalking behavior!