8/8/2021 Devlog - Grabbed by the Oozies

Warp Soldier - Nov 2021 Demo » Devlog

Share this post:

It is Sunday night over here in California. And a bunch of neat work has been done regarding enemy combat. So just for the heck of it, I'd like to show-off what I've been cooking up over the past week, along w/ a teaser for what I'll probably talk about next week~

Grappling

This is a mechanic I've been considering on-and-off for the past few months, but I finally found myself some time to implement and test it! Here's an example of it in action:

Pretty straightforward - an attack that literally take-hold of the player, followed by some release.

The implementation of it however is anything but straightforward. But also far from impossible.

The first thing I had to take into consideration was figuring out how to effectively mask the which parts of the thrower would be in the foreground vs the background when perform either a pummel or throw. Then I remember that my game was in monochrome and figured out an easy away to take advantage of that:

First, I had to give enemies that could grapple a 2nd sprite player:

The default "sprite" would now act as the background relative to whatever was being grabbed, while the "Grapple Vis Foreground" would be the foreground.

Next, I needed an efficient way to separate the foreground and background parts of a sprite:

This here is the monster's spritesheet. As you can see, some of the sprites are black and white, while others are either green or green+red.

The sprites that are black and white use the regular sprite-shader. The sprites that are colored, however, are sent to both the foreground and background sprite renderers.The parts in red indicate the parts of the sprite I wanna keep in the foreground sprite renderer, while the parts in green indicate the background parts instead.

Then, to prevent it from looking those colors in-game, I just assign a custom shader+material the 2-layered sprite players:

To many, this'll look like voodo, but all it really does is A. mask parts of the sprite that contain non-zero values of given color/channel, and B. output those values to either black or white given a step function.

The end result is a sprite that exist both in-front AND behind other sprites in-game!

There's one last thing that needs to be for grapples to work - dictating where the player's body should be during the animation. One simple way to do this involves setting-up a list of position values onto an animation time. But that takes a lot of context-switching and time. So instead I do this:

Using Unity's "Sprite Editor", I define some proxy-square-sprites to act as the player's location (which I can later reference elsewhere throughout the project as an Asset: "DarkHandGB_Hold_F00". The GB is a naming convention I use to indicate Grabbed Bodies. Incidentally, this is the same technique i use for specifying hitboxes on standard attacks (specified w/ the "HB" suffix instead).

With that finally completed, I spent the rest of the week looking into a more... high-octane enemy AI framework. This ended up being a much more complicated endeavor and warrants its own blog-post/postmortem for next week, but I'm quite happy w/ the results my work has put-out so far ( '3')