I'm Chris Eck, and I'm the tools developer at HBS for the Battletech project. I've recently been given permission to write up articles about some of the things I work on which I hope to post on a semi regular basis. Feel free to ask questions about these posts or give me suggestions for future topics. However, please note I am unable to answer any questions about new/unconfirmed features.

The last few weeks I've been in an unofficial bug fixing contest. A bug fixing contest is a lot like a pie eating contest. The reward for fixing a bug is you get more bugs to fix. >.< I cleaned up some performance fallout, worked on updating region labels, and put some finishing touches on drop pods. Of those, drop pods are the coolest so let's talk about that.

Drop Pods

The Urban environment is a lot more cramped than the open terrain maps of old. Tall skyscrapers sometimes prevent a dropship from coming in to drop off mechs. The dropships are so large that the wings will clip right through the buildings in the flyby animations and that just won't do.

Someone modeled a bomb like drop pod. Someone else modeled the open drop pod. Will worked up a VFX and designed a ParticleSystem that had the flaming Drop Pod slamming into the ground and then kicking up a huge cloud of debris (and built a separate one for each biome). Rob worked on new sound effects. And I wired it all up for the designers and spawn it during the game. 

First, I had to add a new SpawnMethodType so that designers could specify when a lance should spawn with this new animation. When Drop Pods is selected, they need to plummet from the sky during spawn. I instantiate the prefab at the UnitSpawnPoint location and the VFX plays out. Here is the particle system in action.

ParticleSystems don't have a method for communicating events so I had to watch the VFX and write down when different things happened (when the pod hits the ground, when a cloud is big enough to hide the mech teleporting in, when the effect was over). After I had numbers in constants for different events, I wrote a Coroutine to wait the appropriate amount of time. A coroutine is like a function that has the ability to pause execution and return control to Unity but then to continue where it left off on the following frame. 

My first test had all the pods landing at the exact same time. I didn't like that so I introduced another constant that would put a delay between each one. I still wasn't satisfied so I added a random delay on top of that. Now there won't be a regular pattern and if two lances spawn drop pods at the same time there will be some variance instead of their units landing in the exact same pattern in the exact same timing. It's very jarring when it happens.

private const float dropPodImpact = 1f;
private const float dropPodSpawnDelay = dropPodImpact + 2f;
public IEnumerator StartDropPodAnimation(float initialDelay, ParticleSystem dropPodVfxPrefab, GameObject dropPodLandedPrefab, Action unitDropPodAnimationComplete, int sequenceGUID)
{
    // Only do work if we actually have a unit to spawn.
    if (HasUnitToSpawn)
    {
        // Wait a random amount of time before starting
        float delay = Random.Range(.5f, 1.75f) + initialDelay;
        yield return new WaitForSeconds(delay);

        // Play the sound effect
        WwiseManager.PostEvent(AudioEventList_play.play_dropPod_projectile, WwiseManager.GlobalAudioObject);

        // And start the VFX
        if (dropPodVfxPrefab != null)
        {
            ParticleSystem instance = Instantiate(dropPodVfxPrefab, transform);
            instance.transform.position = hexPosition;
            instance.Play();
        }
        else
        {
            LogError("Null drop pod animation for this biome.");
        }

        // Wait until the drop pod hits, play the sounds, and kill whoever is standing in the spot
        yield return new WaitForSeconds(dropPodImpact);
        WwiseManager.PostEvent(AudioEventList_play.play_dropPod_impact, WwiseManager.GlobalAudioObject);
        yield return ApplyDropPodDamageToSquashedUnits(sequenceGUID);

        // Wait a bit more and teleport the units in and spawn the landed drop pod.
        yield return new WaitForSeconds(dropPodSpawnDelay);
        TeleportUnitToSpawnPoint(dropPodLandedPrefab);

        // Wait a couple more seconds for the drop pod vfx to finish playing then we can say we're done.
        yield return new WaitForSeconds(2f);
    }

    unitDropPodAnimationComplete();
}

If you aren't familiar with how Coroutines work this might look a little weird with all these yield returns. Basically you're yielding control back to the caller and will continue doing work on future frames. Here's the Coroutine documentation if you're interested in learning more:   https://docs.unity3d.com/Manual/Coroutines.html

While testing, another thing that I noticed is that we bunch our spawn points up but the physical drop pods are pretty big and they overlap each other like so.

To give the designers some in editor indication I added some code to the UnitSpawnPoint "Gizmo" (or in editor widget). Lookup Unity's OnDrawGizmos for more information. It gives you ways to draw things in the editor's scene view.

After stringing everything together, here's what it looks like. (in my super ugly all-flat test level). Also I'm in the editor so pay no attention to the lag spike. *jedi hand wave*

There are definitely some Rule of Cool physics going on here. Any person inside the cockpit of that drop pod animation would be turned into strawberry jam, and the mech would be a mass of twisted metal and myomer. Drop Pods are supposed to split up in the atmosphere and then jump jets and parachutes are supposed to let the mech drift safely down. I brought this up as a concern, but I also said I wouldn't change anything after seeing the drop pod animations in the game. B)

New Hatchetman Variant

It was announced that we were releasing a few variants and one of those is a brand new Hatchetman variant. I was tasked with stating it out so I did some research but most of the variants are all way past the 3025 era. I saw the HCT-5K and that sounded pretty interesting so I designed an earlier prototype version the HCT-3K. There was some lore debate on whether or not a Kurita variant would be this far "south" in the periphery so after the forum goers read about the 3X consideration they demanded that we change it. In lore the X stands for experimental. But for me it stands for 3 Ecks (Me, my wife, and my daughter). I can't wait for this to ship because I can finally point at something concrete in the game and said I MADE THAT!  Also, there's a small chance it will get added to Battletech cannon so it's yet another cool thing about #livingthedream.

Blood Bowl Update

In more casual news, I've been streaming my Wood Elves and finally won a couple of games. It's vastly different from my typical bashy-ork play style but I feel like I'm learning. The league that I joined TRBBL (Totally Relaxed Blood Bowl League) has a cool bunch of laid back coaches in it. Season 3 will be starting soon and I plan to stream those matches when I play them (roughly every other week). Lately I've been streaming sporadically about once a week. Feel free to come hang out when I do: https://www.twitch.tv/eck314 or you can check out the matches that I upload on Youtube: https://www.youtube.com/watch?v=VQaN12XU5Wg&list=PL2M43bS2cfSMNvtzWDR0DxuQgh0Ky7yrA

If you're interested in playing Blood Bowl 2, there's a big steam sale for all Games Workshop related products. I think Standard Edition costs like $5 and Legendary Edition is around $15 which comes with all the teams. It's a good time to pick it up. https://store.steampowered.com/sub/192166/ 

Links

• Previous Journal: https://www.gamedev.net/blogs/entry/2267220-battletech-developer-journal-06/
• Next Journal: Stay tuned!
• Twitter Post: https://twitter.com/Eck314/status/1130221812179185664