Crew Following

Today was all about trying to get the Crew/NPCs to follow the sleds. I had so many ideas on how to get the Crew walking next to the sleds and spent too much a decent amount of time trying to get things to work. I originally wanted to have them pick random points within a radius of their tether every couple of seconds, so they would kind of "wander" next to the sled. I got that implemented but, boy, did it look terrible. Unfortunately, I don't have a screengrab of that.

The main problem was that the positions I was generating were stationary in the world, meaning the Crew would be walking to a point that was being left behind by the sleds. Couple that with 50% of the points being generated behind the tether point and you had a lot of crew moving in really bizarre ways.

To fix that, I tried several different things: - Generating an offset to the tether point every few seconds so the point was always moving with the sled - This...sorta...worked, as it gave the Crew a point to actually follow, instead of just move to - However, because the actual walk speed of the Crew is faster than the sled was moving, as soon as the offset changed, they would "powerwalk" over to it, instead of keeping their same pace. This just looked really awkward - I think this had promise, but there was a lot of tweaking that would need to happen and I felt like I was burning too much time on this. Hopefully, we will be able to revisit it later - Moving the tether point - This had the same effect as generating the offset - Just following the tether point directly - This ended up looking the best, though it would be nice to have some variation on it. - I think to make this one look really good, when the Crew is spawned, it should pick a point around the tether point to spawn in, that way it breaks up the "rigidity" of the current system

I ended up just having them follow the tether point directly. Next, I needed to get them animating.

As mentioned the other day, Andrew did a lot of good work making sure the animations and everything were set up for the Crew, so getting the actual animations to play when they are walking was really easy. However, there was a slight issue with the facing. As you can see, they are doing a nice side-walk to show off their skills!

I saw that Andrew also had a "speed" variable set up in the Locomotion state to blend between running and walking. We don't really have running integrated yet but I figured I would see what it looked like just using the NavMesh Agent velocity as the speed value. Now they are showing off their sideways dancing skills!

I reverted that change and figured we would get there later. Everything was looking pretty decent except for their facing. A quick turn in the prefab and they were looking great. I was showing Terra my work and she pointed out that it looks really weird that they are all walking in unison. It kind of took her out of the immersion (as much as one can be with a completely empty world). You can see that in the gif below.

I tried implementing a couple of things that didn't quite work out. The gif below doesn't do it justice but they looked like the roadrunner, their feet a blur!

I ended up adding a small StateMachineBehaviour that I tacked onto the Locomotion state in the Animation Controller that gives each one a random offset to their animations. This made everything look way more organic.

using UnityEngine;

public class RandomizeAnimOffset : StateMachineBehaviour
{
    private bool _hasOffsetApplied;

    public override void OnStateEnter(Animator animator, AnimatorStateInfo stateInfo, int layerIndex)
    {
        if (_hasOffsetApplied) return;

        float offset = Random.Range(0f, 1f);
        animator.Play(stateInfo.shortNameHash, layerIndex, offset);

        _hasOffsetApplied = true;
    }
}

I also rearranged the sled spawn points to avoid a particularly awkward movement pattern when the sled was falling in line. Overall, I am pretty happy with how it all turned out.

Here are some of the oddities that are still lingering that I'm hoping to just avoid until we get to polishing everything.

Here is what happens when the Crew somehow gets trapped within the sled. I think this one happened because the back sled is too close to the front sled and the Crew spawned on the left-front tether point on the back sled. That would have put it within the bounds of the front sled and it is just ping-ponging within those boundaries. Better sled spawn positions (and/or some type of NavMesh check) would go a long way to prevent that.

The following gif was the awkward movement I mentioned above, and why I ended up putting the sleds more in line with each other. It is almost like the Crew is parented to the sled, but what I think is happening is that the tether is so close to the Crew that it tries to "orient" on it and it just ends up looking really awkward. I tried a couple of things, like manually dampening the movement, so it was "springier" (like the sled follow) but that just straight up didn't work. I even tried spawning the Crew off to the side (by the building) and that also looked goofy for a different reason. I'm sure there is a way to fix it but I had spent way too much time on this already, considering this is a game jam and needed to move on. That is probably the hardest part of the game jam so far...cutting losses early to avoid wasting time. "Good enough" is good enough!

End Tile Spawning Issue

Once I got the Crew manager and follow behavior checked in, I fixed a small bug I introduced previously where the "end" tile wasn't being spawned at the end if the "Desired Tile Count" (i.e. how many total tiles should the game cover) was more than three. I had tested it with two and three tiles and it worked just fine. It turns out that as long as it was below the "Max Loaded Tile Count" (i.e. how many tiles should the game keep loaded and in the scene at once) it would work fine.

This was because I was using the count of the loaded tiles to determine when to spawn the end tile and not the running tally of how many tiles have we spawned in total. Bonehead mistake that I remember going "I'll need to change that before checking this in!" and then promptly forgetting its existence. That was the primary reason that I had added the _totalSpawnedTileCount variable in the first place!

Reworking Spell Casting

I had a bit more time left in the day, so I spent it refactoring the work that Andrew did on the Warmth spell to make it more generic and to build up a system that we can use to make the other spells easier. Andrew had a lot of good code in his implementation, it just wasn't very modular. I made some good progress on breaking everything out and I am reusing a lot of the actual logic from the existing Warmth spell. Andrew did all the heavy lifting to get the spell actually working and I just need to finish "systemizing" it.

Ultimately, I am trying to get a structure similar to this:

SpellBase
├── RadiantSpellBase (Spells that radiate out from a point, "Sphere Cast")
│   ├── Warmth
│   └── Light
└── ProjectedSpellBase (Spells that project in a line out from a point, "Ray Cast")
    ├── Pulse
    └── Soothe

I have the SpellBase and RadiantSpellBase classes implemented as abstract classes that extend from ScriptableObjects and have the guts (pulled from the original WarmthSpell) stuffed into a WarmthSpell2 class (for now). I am trying to pull similar functionality down into the base classes (getting targets based on the cast type, handling cooldown timers, etc) to make adding the other spells much easier.

Next I need to work on getting the SpellCaster component figured out so I can actually try casting my new spell.