Today I was starting to work on these damaged animations and I spent around an hour not knowing that I don’t know left from right:

I made the damaged walk forward “with left arm broken” animations last night. Turns out it was the right arm the whole time….

What should happen is that the left arm should stay raised (then I would make that a physics object so it would hang down).

I also improved the control rig for said animations.

This lets me can do some nice twists as needed:

Finally I’ve converted the project to c++ to let me do some more clever things with what gets damaged on the bot. Specifically I can flip specific bones to kinematic if I need to, flip specific bodies to simulated (which you could kinda do in blueprints). But the big thing was to be able to grab all bone names from any given physics asset.

TArray<FName> UBlackLaceCLib::GetPhysicsBodyBoneNames(USkeletalMeshComponent* SkeletalMeshComponent)
{
    TArray<FName> BoneNames;

    if (!IsValid(SkeletalMeshComponent))
    {
        return BoneNames;
    }

    UPhysicsAsset* PhysicsAsset = SkeletalMeshComponent->GetPhysicsAsset();
    if (!IsValid(PhysicsAsset))
    {
        return BoneNames;
    }

    for (USkeletalBodySetup* BodySetup : PhysicsAsset->SkeletalBodySetups)
    {
        if (!IsValid(BodySetup))
        {
            continue;
        }

        BoneNames.Add(BodySetup->BoneName);
    }

    return BoneNames;
}

Which honestly its not that complicated but for some reason you just can’t do this in blueprints.

Why do I need this functionality? Well its to enable adding in a location damage component for the bots. Essentially this component will call the function above to make an array of body parts that can be damaged and their individual health. Then the component has a “body part destroyed” event which the patrol bot can bind to. This lets me capture what got hit and ragdoll that specific body part.

Outside of improving the bot animations I’m still working on making a cohesive art pass but I’m still pondering what that means/how to demonstrate it etc.

Made an I-Beam. Was going for a quake 1 ascetic but now I think I ended up too much battle bit. Gonna go back to the drawing board here. I got creative with the UV mapping (at least more so than normal) so I could just kinda throw a single image at the problem. However, I build everything pretty wrong so the UV Maps are…odd:

Well anyways more todo on the general look of things.

its still crazy to me how a unified artistic vision can really make something look good. Quake 2 for example:

That picture looks SOOO much better than anything I’ve made and those were guys from early 90s without skeletal animations etc. really drives home how concept artist can drive the whole game.

It’s hard to tell just from pictures but the big differences are: the Root bone under the robot, the tail and head portions, and the overall flow goes from tail to head rather than spine to each leg. It’s easier to see differences when looking at the hierarchy differences:

Now what this enables is that unreal can actually tell what’s going on for the bot. The biggest benefit is that physics simulations start to become much more stable:

Also I was able to implement a control rig with way more body control than I had before.

This should enable better and more natural style animations. Specifically the walking animations, jump animations, aiming pitch/yaw and hit reactions should all be much more in tune with the rest of the game.

However now that I’ve re-rigged the entire bot I’ll probably need to recreate ALL of the animations….

On the mapping/animation front: I’ve been listening to a bunch of the quake 1 soundtrack:

and a bunch of pre-Year Zero Nine Inch Nails and now I’m feeling a low-poly rusty ascetic for the game. However, I think getting the “game” part finished first is still my priority.

In other news: my 555 synth project is still moving I just had to get some flux and a new solder tip. Progress is being made…

I also fixed a bunch of the shooting systems, re-worked the AI so it doesn’t try to reload in front of you. I added in some squad placeholders for future collaboration amongst units and started working on another overhaul of the basic bot so I can finally get physics based animations working.

Also:

(No idea how to make this look good yet…)

THE PLAN

So my goal is to make a simple oscillator for playing audio frequencies, which I’ll claim is 0.01hz to 2000hz. With a frequency that is controlled by microcontroller.

You might ask me “hey why don’t you just use the microcontroller as the oscillator? You can literally attach a capacitor to the pwm and use it as a pseudo dac” . Good point, I have three counter points:

• Then I would claim its a digital synthesizer not an analog one
• Way Less Cool
• Shut up

———-

Now that I have the plan in order I can take stock to see what I even have:

• Bunch of passive components (Inductors, resistors, capacitors)
• 555 timers (NE555)
• Misc op amps (LM358, LM324, NE5532, JRC4558)
• Voltage comparitors (LM339, LM393)
• Nand gates (74Hc00)
• Class A/B amplifier (TDA2030)
• Teensy 4.1
• Raspberry pi
• Arudino uno
• A bunch of 2n222a BJTs

————

Okay so selecting the Microcontroller is easy: Raspberry pi’s are lame (I don’t want/need networking, display out, linux, ext), My arduino Uno uses usb-b and I’m pretty sure I don’t have a cable, so that leaves the Teensy.

On the oscillator side I could use:

• A 555 timer as a vco
• A Faster LC Oscillator that I can mix down to audio frequencies
• Op amp multivibrator

————

After quick review, oscillator #2 seems…hard, oscillator #3 could work but it seems like more parts than I wanna use… Which leaves us with oscillator #1!

To be honest I haven’t decided the amp but generally it could be one of two things:

1.) An i2c controlled IC from digikey such as https://www.analog.com/en/products/max98425a.html (if I want to waste money)

2.) A transistor setup that uses a control voltage from the micro-controller

Most likely it would be #2 but I’ll dig into that later

555 timer..time

Building a voltage controlled oscillator from a 555 timer is a pretty cookie cutter experience:

How ever it gets a little complicated when you try to choose your target frequency range.

In my case I’m aiming for 0.01-2000hz. In college I would do some math to figure this out but most of the equations are already solved in various places online. There’s also a systems management level to all of this, where maximizing your frequency span can create some odd artifacts etc.

So instead of being totally analytical I decided to be more visual:

I made some AI slop where I can keep trying combinations until I get an output that I like. HOWEVER, I quickly realized the man problem of using a 555 timer: You really only get 5x of your lowest possible frequency. So in my case if my key frequency was 0.01hz, my highest frequency could only be around 0.05hz, if it wanted it to be 100hz, then my highest would be 500hz etc.

So how do we solve this? I could go back and figure out another oscillator type that has better control….OR I COULD THROW MORE 555 OSCILLATORS IN FOR COVERAGE!

So then to update the block diagram:

This is where I left off the oscillator bit. If I wanted to get a single tone out I could try using a single 555 timer with a mosfet to switch between a few capacitors (In the diagram above C1 is the major driver to your frequency range

Kinda doing dac stuff

So the teensy doesn’t have a dac. It it only has pwm, so how do I get an analog value out? Simple, just throw a capacitor (and resistor) in-front of the line and your square wave gets averaged based upon the capacitance of that capacitor (See this, again!). A.k.A you put a RC LowPass filter in-front of the pwm

Now there’s some issues with this approach:

• Your output will never be perfectly the level you want, a capacitor charges and discharges so if a square wave hits a capacitor you get some kind of voltage ripple
• The capacitor takes time to charge once you start hitting it with pwm, so if you choose capacitance that is too large it will take a long time to obtain your key voltage
• Your output voltage is limited from 0 to whatever the top level of your square is

————

So to summarize: my frequency range is limited by the control voltage into my 555 oscillator, which I can determine by a capacitance that I want to be big enough to stay stable when I choose a voltage but small enough so that when I choose a voltage it doesn’t take seconds to get the output to that voltage.

Again instead of doing math I made a tool!

Now I can visualize what my control voltage will be based upon the resistor and capacitor

Main things I was trying to do is ensure that the output of my teensy can properly hit the range of the voltage needed for all frequencies of the 555 oscillator. In this case I can go from 0 volts to 3.3volts, and choosing a 2uf capacitor and a 10k ohm resistor seems to be the best trade off of voltage ripple at steady state, and step response.

Next steps

So I didn’t take any picture here but I have the high band 555 timer laid out on a breadboard and hooked up to the oscilloscope to see it working. The teensy pwm stuff is pretty simple in my opinion so I wasn’t rushing to get code written. My next steps for this are:

• Put the 555 timer on its own board
• Make the other 3, 555 timer boards
• Figure out how to make a mixer (and buy some knobs for the mixer)
• Figure out how to make a decent amp
• Hot glue everything together
• Sell on etsy (not really)

————

I threw the tools that I made (claude made) here: https://github.com/wfkolb/EEUtils/tree/main if you’re interested. Its mostly pyqt and a little numpy in the mix. I’ll try to keep that updated as I get more math in, I’ll probably throw a mixer and amp tab in to help me out there.

I painted it red which I thought might be cool but really its just giving christmas vibes:

I definitely need to do another paint pass, also having nothing ontop of that pillar seems kinda crazy. The smoothness of that intersection leaves something to be desired, maybe a wire or some kind of power…pack…thing?

Finally as you can tell from the video the mantis stays still unless turning towards the player. The turret at the top is on its own aiming system. I’m not a fan of the turning on the body front, I have to figure out a way to lock the movement of the turret periodically. To demonstrate what I mean:

The turret looks like its skating across the floor, the patrol bot has this also but its on such a smaller scale it’s harder to see. I’ll definitely need to make some kinda scheme to stop movement on certain frames on animation.

So the gun on top of the turret aims in both azimuth and elevation. Both are controlled from the pivot point on the bottom of the gun. Originally I had everything inside a control rig across two different controls, but that proved to be pretty painful as gimbal lock would mess with everything. Instead of fixing the gimbal lock problem I basically ignored it and disabled the yaw control in the rig for pitch control only.

Which I think the springiness looks pretty cool, however this gives a different problem. If I just said “player is at 10 degrees from the tip of the barrel, turn bottom to 10 degrees” the barrel would never really point at the player. It would have some kind of vertical offset, then you might think “this is a trig problem!” however you miss one of the key side distances, because you’re not really sure what you need to set the angle to…. I tried drawing below what I’m talking about:

This is one of those things that it REALLY feels like I’m failing at some simple trig here. After making a few attempts myself I gave up, started consulting AI to see what silly mistake I made…it turns out I made a classic Inverse Kinematics problem by doing something a stupid way.

You essentially can’t figure this out with a systems of equations or any kind of trig because you don’t have that goal distance to the target. So in this case you need to basically keep guessing and checking the answer to converge on the proper value. Now writing this out I feel kinda dumber HOWEVER the only other way you could really do this is by making individualized animations for each position, knowing what the aim angle is at each position by per-calculating (a look up table of model poses).

Anyways here’s the rough algorithm:

Basically:
1.) Take your current elevation and determine how far your off on your Z plane and how far off you are on your XY plane (technically this is wrong but I can get away with it because my robot it always correcting azimuth, also its left hand XYZ if anyone is keeping up).
2.) Calculate what theta might be if we took the error distance and made an angle guess for the pivot point
3.) Run the algorithm again to further update theta.

So now I have a gun that tracks your elevation and azimuth.

On the actual game side I’m trying to figure out what I want the worlds to be, I think I’m leaning towards 90s fps alleyways more so than the destroyed corporate buildings I was going with. I started making a kinda warehouse level and I think I’m going to trash it:

The scale in generally all wrong (look how small each step is compared to that huge box) but I think iterating is going to be my friend here. Mostly I wanna keep pumping out trash maps for myself, learn why they’re trash, and make another map: rinse and repeat until I get something fun and playable.

“Okay that seems like not a big deal why do you care?” Fair question. I would classify a Modular rig as 3rd grade geometry where there’s a bunch of pretty buttons and shapes that you can drag/drop into the scene:

Control rigs are the math that someone for Babylonia made in 2000bc and was discovered by some guy in Europe 1000 years later who couldn’t figure out what was happening until a genius found out they could use that math to make lightning.

Long story short, the control rig is the output of the modular rig”and if making a modular rig fails then you need to build out your control rig yourself. In my case it wasn’t that bad (but that was because of my previous experience with the bot).

Above is the construction script which takes those red circles from the rig and puts them under each of the legs.

This segment is the forward solve section where IK is applied to each limb. Honestly not that bad to make but the mental gymnastics I was doing to basically say “hey this easy thing (modular rigs) should be easy” made me rip my hair out for a few hours.

The final result:

This worked out so much better now I just gotta make like 30 animations and we should have a good boss room fight.

Here’s a few that I was able to get done pretty quickly:

Cut me some slack on that last one, might move it to be more physics based rather than animating whatever I guessed to be gravity.

Unreal engine has its quirks. A big one I found is the idea of “additive” animations (see this). Which essentially take the animation you made and subtracts it from a reference pose or animation. This is how you can easily blend ontop of an animation instead of getting some weird median between two existing animations. I use this technique all the time, in the weapons I use it to add a fire animation ontop of the idle animation so you dont get weird glitching from recoil back to a relaxed state. In the bots I use it for everything that pretty much isn’t a “movement” state. Such as pitch tiling and hit reactions. In this case the hit reactions seem to be blending poorly with the rest of the animations.

I also added in bullet tracers which add a much needed element of feedback to shooting so you don’t feel like the gun is disconnected from the rest of the world. The problem here was that I was mixing a bunch of domains at the same time. When adding an animation there’s local space, and mesh space, and if you throw some IK stuff into the mix you hit issues where a vector of length 3 units in one space does not equal the same number of units in another space. In this case I was adding a bunch of animations in local space ontop of my IK rig which was manipulating everything in mesh space. This was harder to catch because I naturally assumed that each operation was isolated (akin to keeping each part of a math problem in parenthesis) however it seems like when ever I start playing with bones the manipulation strategy seems to stick onto the bones. So if I messed with something in local space, the next addition is assumed to be local space, so by switching everything to mesh space its working fine:

In other news I somehow made the mags that the bots spawn on reload really big, which I think is probably a similar domain transfer issue.

Finally after all that talk about control rigs and modular rigs I’m hitting issues animating the mantis bot.

There are things called “pole” controls (see this) which act as a place for elbows to point to (in this case the robotic knees) and for some reason unreal put them VERY far away so they’re pretty un-weidly to handle. I’m going to have to remake the control rig for this model in order to animate it properly. However even with that kinda broken, half finished animation I think I’m on track to hit what I want from the mantis bot.

It still isn’t that great but it’s probably as good as I wanted it to be. The big thing is that I can put the bots on ramps and they look kinda right:

The basic idea too complicated: essentially you draw a line from the tip of the leg downward, then try to move the tip of the leg into that position. However, directly moving the leg ends up being weird because the rest of the leg doesn’t move along with it. To solve this you use some IK! From the game perspective this is essentially the process of taking a target and working how the limb will get there, rather than attempting to move the limb to the target.

In unreal there’s a thing called “IK rigs” which do a bunch of the work for you but I had NO idea how to properly implement these until I went through it once. Now I think I have a “handle” but there’s some witchcraft in the background that I have no idea why its working. But anyways here’s the trace logic:

Generally this fires from a bunch of sockets I put in the mesh, then the feet find their way to meet up with the end of those traces.

The thin red lines are the traces and red square are the “goals” that I want to move the legs to.

Now I just gotta give them some interesting things to walk on…

Another map

I tried my hand at making a much much bigger map:

The thought was that the huge white cubes would be some kinda skyscrapers, the cones would be some kind of rubble breaking up sight-lines to make the game play a little closer range. I wanted the player to start at the edge of the city and have a set of terminals to control.

The building facades were things I made for a previous project that I never did much more with (see https://willkolb.com/?p=979). Then I applied the fence tool I made (see https://willkolb.com/?p=1146) to give me the ability to quickly spin up those buildings. If I added some randomization tools to the model I think I would have a tool I probably distribute, but I’d have to re-write in C++ to make distribution cleaner.

The map is MUCH bigger than anything I made so far and it showed a few holes in what I was thinking. The big one was that its kinda boring walking long distances without some kind of sprinting.

Sprinting (and Footstep audio rework)

I added a few things here, the sprinting (obviously) the head bobbing and the audio playback tracks. The foot steps are still not amazing, it should be the same footsteps just a bit faster and pitched differently. However I’m just mixing between two sounds at the moment. You can see the audio graph below

It seems like a lot but really all it really has is that the red “Sprinting” input block feeds an audio mixer that goes from walking footsteps to running footsteps. Everything else is just for sound levels and multipliers. I’m still new to the metasound stuff but there’s some info here if interested (https://dev.epicgames.com/documentation/en-us/unreal-engine/metasounds-the-next-generation-sound-sources-in-unreal-engine). Interestingly enough this is probably the most applicable thing to my day-job. If metasounds worked on embedded targets my life would become exponentially easier.

Boss Doors

This is kinda wierd to demonstrate visually but basically those two white blocks are “boss doors” that will only go down once you capture all points on a map. What that buys me is a place to put all of those overpowered bots I made such as the rocketeer (see https://willkolb.com/?p=750). I have it in there in a very hacked manner where essentially the cubes are marked as “boss doors” and then just straight up delete themselves if there’s no more points to capture. In the future I want to put more of a process to take down the doors once the controls points are captured.

Weapon Handling/Damage

I realized one of the most annoying things is that shooting has WAAYYY to much recoil and its very hard to hit targets so I increased damage and lowered recoil so you have a bit more power on your side. My thought is that I want the player to loose around 5% of health per encounter and each encounter with a bot should take around 5-ish seconds. I have no way to characterize these numbers but simply going by feel. At the end of the day this is something I need to catch if I send out copies to friends for play testing (maybe I should add telemetry?)

Mantis Turret

The turrets kinda suck in the boss area at the moment they’re just sticks with tubes on the top:

Not very menacing and they’re more annoying than anything. So I started thinking about how I would build a kinda moving turret and I came up with this guy:

Which fits the same idea that the bots have where the top gun can be pretty much whatever I want just by modeling some kind of mount for it. The gun in this case is a new weapon I’m currently modeling/rigging.

Which takes some inspiration from Helldivers Autocannon (https://helldivers.fandom.com/wiki/AC-8_Autocannon) But really is more of a Barrett M82 (https://en.wikipedia.org/wiki/Barrett_M82) turned upside down with a Bren gun style sight (https://en.wikipedia.org/wiki/Bren_light_machine_gun).

The gun is far from complete but the Mantis side is rigged and in game:

It was surprisingly fast to get working because I found out the proper way to use control rigs and modular rigs (https://dev.epicgames.com/documentation/en-us/unreal-engine/modular-control-rigs-in-unreal-engine , plus see See the wrong way to use these here: https://willkolb.com/?p=661). Originally I thought it was a binary choice but I realized the modular rig is really just a way to auto generate a complex control rig. So now I probably should go back through my models and rework them, but really I think I’ll keep going with what I have. I still have a dream that all of the bots are physically animated (such as gta4) but I think that dream is becoming a nightmare of technical debt.

Future thoughts

I think my primary map for gameplay testing will be that small alley-like map instead of the large city. Mostly due to the smaller size which should lead to a quicker gameplay loop, I need to add more complexity to the boss room, add some rooms in windows and maybe some map destruction elements (such as windows, wall breaking etc.). Finally I wanted to try to add some vertical elements to each of the bots. I might throw on some more artifacts to make the game less about trying to hit a small horizontal line on the screen. Also a new name is warranted, “BlackLace” was from cyberpunk and any of those elements are straight up gone now.

A bunch to do and I’m aiming for a June-ish first build to send to people for gameplay testing, not for any reason just to give myself a bit of pressure. Good think it just started to get cold in Massachusetts, now I can justify hiding inside on my computer all day.