My most beautiful bug

While working on DEBASER‘s enemy AI, I found a bug that is so miraculous that I almost want it to be a feature. Due to a series of coincidences, I have unintentionally programmed my enemies to become contact jugglers.

Beautiful, isn’t it? They can even do it with longer items:

There’s no animation or trickery here, this phenomenon is completely physics based. The enemy’s collider is juggling the item.

The Cause

This juggling is the result of an enemy trying to pick up a gun that is on his head.

To perform any action, the enemy starts by moving to the target (the gun) and performing the action (picking up the gun). However, for the performance stage to begin, the enemy must be within a certain range of the item. This distance is measured from the root transform of the enemy, located at his feet (after all, items usually fall to the ground). The problem with this scenario is that this range happens to be slightly shorter than the height of the enemy. So the enemy can’t pick up the item until he arrives, but he can’t get there if the item is on his head: it’s a catch-22.

You may ask, “but why doesn’t the gun fall off the enemy? Surely it’s not being balanced on its exact center of mass?

That’s a perfectly reasonable, yet incorrect assumption: the enemy is balancing the item exactly on its center of mass. Does this mean my enemy AI has become self aware? No. The reason for this goes back to my system for picking up items. Most gun / swords models have their origin located in the handle:

The object origin is on the right.

This means that if we were standing close to the tip of this gun, we can’t pick it up because the distance is being evaluated all the way from the handle. To solve this problem, I needed to evaluate distances from some kind of center. Since all item drops have a Rigidbody component and approximately accurate colliders, I figured I would just use the center of mass if it was available.


The enemy is juggling items almost perfectly because he’s in a negative feedback loop: by trying to pick up the item he is always moving towards the center of mass, canceling any movement in the item. This is kind of how control systems for rockets and planes work.

Who said rocket science is hard? I just did it by accident.

DEBASER | Devlog 1

In this entry, I’ll be going over what my new project is, how it started, and how development has progressed in recent memory (screwups included).

The Elevator Pitch

A video of DEBASER.

The game is called DEBASER. It is my attempt at creating a first-person version of Hotline Miami, one of my favorite games of all time. I want to make a brutal FPS with a unique focus on precision and speed. The goal of the game is less to beat the level, but to get the fastest and most stylish play-through.


Camera Comrade in its full glory.

DEBASER’s development started with a 2019 game jam submission called Camera Comrade. In it, you play as a soviet operative in the cold war, tasked with infiltrating the CIA and destroying their coffee machine. It featured a primitive stealth / hiding system, combat, parkour mechanics, throwable cameras, and a cute aesthetic. It was a lot of fun to work on, and a great way to learn my way around Unity. DEBASER is the result of many iterations on Camera Comrade over the past year.

Artificial Intelligence

The pathing system of my AI.

Camera Comrade’s enemy AI was based on a three-state Finite State Machine: Patrol, Search, Attack. It was simple enough for a throwaway game jam submission, but for DEBASER I needed a system that scaled better. I’ve moved to Goal Oriented Action Planning (GOAP). With GOAP, instead of spending exponential time on writing the transition function, I can simply specify the prioritized goals and possible actions of the agent and have it automatically generate a plan. There’s a great paper on this system by the developers of F.E.A.R. that is definitely worth checking out. Suffice it to say that if you need an agile way to create game AI, GOAP is the way to go.

Inverse Kinematics

Image result for inverse kinematics animation gif IK rig
The FABRIK system I failed to replicate on my own.

Often during game development I find myself sidetracked by cool technologies. Last month, that sidetrack was Inverse Kinematics. It all started with this GDC talk by Ubisoft showing their full body procedural animation using “IK rigs.” The system was so mindblowing to me that I spent weeks of precious development time diving into talks, papers, videos, and interviewing experts. It took me weeks of prototyping to finally realize that the system I was building was just thinly veiled procrastination, a fool’s errand. In my haze, I had forgotten the real goal: making the damn game. So, with sadness, I scrapped my IK prototype and just downloaded FinalIK by Root Motion. For $90 I now never have to worry about IK again. Thank god.


Honestly, at this point I have no idea where the graphics are going. I wanted a simple aesthetic like Super Hot, but instead I got sucked into substance abuse. Or rather, Substance Designer, a great piece of software for node-based 3D material creation. Even as a relative noob, I’d say I’ve managed to create some damn-good visuals so far. However, this comes with a problem: the current subway level featured in the video took me FOREVER to create. I feel that while I like the look of it, I won’t be able to make materials fast enough if the fidelity is this high. In the future I must move towards minimalism, so I don’t find myself stuck doing digital art all day instead of making the game.

The biggest change I’ve made to Camera Comrade is that the enemies are no longer capsules, but real men! It took many painful iterations to get to my current system of animation. First I manually rigged / animated the enemies with Unity’s builtin animator, which fell apart quickly as I realized I’m not an animator. Then I used slightly-incompatible unity assets that did not play nice with my modifications. I then heard about Mixamo, a tool that takes in arbitrary humanoid meshes, and returns a consistent set of royalty free animations! I was blown away by the quality and quantity of animations on the site. It took a little bit of finagling to get Mixamo to work with Unity, but once it did the efforts were well worth it.

Another notable change is that I’m using blender to create levels. It was tricky at first, but now that I’ve gotten the hang of it I see the advantages. It’s definitely easier to design levels with an established modelling tool, rather than with ProBuilder. Blender allows me to create pipes, fix UV maps, and add procedural modifiers like Bevels, which make the scene more finessed while keeping editing simple. On top of that, the materials work the same as in Unity, so importing is a breeze. Switching to blender has been the best change I’ve made so far.

Moving Forward?

My goal for the next devlog is to have refined combat mechanics, and a working level. Given the COVID-19 situation, college will be online for me for the remainder of the semester. The silver lining is that, pandemic willing, I should be able to make serious progress on DEBASER. Stay tuned.