Turning Bugs Into Features

This post will review how I took a bug that I needed to fix and turned it into a standout feature for our game.

This August marked my first time working on a game development team built up of more than just programmers, with a goal to create more than just a tech demo. With that in mind, we came into the project part-way through, initially tasked with cleaning up the code work done by designers, rather than programmers. During that cleanup, I found a bug that was funny enough to share with other team members, to the point where some of them asked if I was able to make that a feature instead. To be brief, the player character is able to possess objects in the game in order to mess with surrounding victims. The bug occurred when the player would sometimes leave the objects, and the objects would launch themselves in a random direction.

First, design work was required. How was this issue going to be turned into a player action? The basic idea was an object that the player could possess and launch at the victims, as a projectile rather than a new mode of transport. Because we want this object to fit neatly into a system of other objects like it, it’s important to work as much within the system as possible. For instance, each possessable inherits from a parent possessable class, with it’s own serialized requirements. Below is what that looks like in the inspector.

Once we have the basic idea and this system requirements, we can actually begin creating this object. The MovementSystem type determines what happens when the player uses WASD to control the object. For this object, since the goal is to launch it, it didn’t make much sense for it to move on its own, so it has its own aiming movement type. This just rotates the object with A and D. Next was a way for the player to see where they’re aiming, which as a placeholder worked as a simple geometric shape in the direction the player faces. This early model looked something like this.

The launching is next. Objects can have an ability, like pulling victims toward them, that the player can activate. In this case, that would be the launching. The code here is relatively simple to start, merely to apply force in the direction the player faces.

The more difficult part is actually triggering an interaction with the victims. The system at the time would activate a trigger sphere around the object to scare victims in the vicinity. Initially, I attempted a design where the player would exit the object as they launched it, to seem more like it was thrown. But because of system limitations, the zone to trigger wouldn’t be accessible if the player were not possessing that object. So instead of reworking the framework of the entire project, I thought to try changing the design instead. This came in the form of a trigger zone that worked on a timer, and during that time would affect any victim in it’s radius. This became known as a LastingEmotionZone, and is still used elsewhere in the project.

This implementation worked decently, but two problems came about. The first was that other branches were moving along, and new changes to the system meant new ones were needed in my design as well. Most notable was the change making possessable objects kinematic while not being possessed, which meant that the player leaving before launch wasn’t going to work the same. The second was determining when the player could launch, as without a ground check, something like this could happen:

 The first problem was not so hard to solve, as the design was just changed so that the player remained in the object on launch. This resulted in leap-frog type movement that felt fun and different. The second was not as easy as it seemed. I looked at multiple ground check options, firstly being a layer mask. Though consistent, the issue is that I am not in charge of the art team, so while they add assets and make changes to the scene, it can be difficult to ensure that everything the player is supposed to land on has the correct layer tag. The second method was a sphere check, but the sphere was either too small, getting the player stuck on ledges, or too big, and giving false positives way off of the ground. I ended on a checkbox, as it got the closest size I wanted with the least conflict. (As a side note, the design had been fleshed out to a desk bell, which would make a ‘ding’ sound upon striking a victim).

The last key problem to fix in testing was balance. Though the object functioned, it wasn’t very easy or fun to use yet. It was hard to actually hit a victim with the small object. To remedy this, I added a homing function, so when the bell got close it would be pulled to the victim for an easy hit. With this, the object was finally available for testing! We brought the game to a showcase at one of Indiana University’s First Thursdays, and the bell was a resounding success! After multiple iterations and facing some tough bugs in implementation, it was great to see success on the other side, having now turned a bug to fix into a flagship feature for our project.