The Bug That Killed Me

The game I was building allowed players to stack pieces. But this game wasn’t Jenga, so this challenge was blocking me from completing the project!

I had to get Unity to understand that when two puzzle pieces collide, it should move the newly offending piece back to where it was previously. As a designer, I knew instinctually that would feel right. But the actions I setup to detect collisions weren’t registering anything. Until collisions were detectable, I didn’t know how to solve the problem.

Gwen agreed to come over to help me fix this bug. When she first started out in programming, more experienced programmers took the time to help her fix bugs in her early games, so Gwen was excited to pay it forward. I told her I would probably never get to the point of mastery where I could pay it forward myself, so to rectify the karma imbalance, I bought her pizza. Pizza is the food that says, “So, uh, thanks for doing this shitty thing for me…”

When Gwen sat down at my desk to playtest Motion Picture, she really enjoyed the game. I figured she would, since she’s a terrific puzzle game designer. Gwen even attended a puzzle game designers meet-up in the park near GDC. (I was at the tiny games meetup across the park, which Gwen met me at later.)

However, she called out a few issues that had nothing to do with the stacking pieces. For example, there was a lengthy “Loading…” screen before a level started. You might imagine this had to do with loading a memory-intense video file, the basis for the video puzzle. But no, that wasn’t it at all.

The way the game worked was that all the pieces started in their correct spots as a solved puzzle behind a curtain image. One-by-one, the game rotated and moved pieces to different places on the board, then opened the curtain for the player. This technically worked, but waiting for every piece to actually move over to a different spot took time. (Also, sometimes the piece wouldn’t quite “hit its mark” and look sloppily placed.)

My solution was to put “Loading” on screen for five seconds, but like a true programmer, Gwen found a better way. Rather than tweening the pieces to their spots, she found an action that effectively teleported the piece to a spot. This saved so much time that the word “Loading” didn’t even show up on screen anymore after we implemented it.

Unfortunately, Gwen couldn’t program for me. Since I’m using Playmaker, a visual scripting tool, there’s no code to read and say, “Here’s your problem.” But I was able to understand her suggestions about how a mechanic should work and find appropriate Actions in Playmaker to fix the problems. She also showed me how to pause a game in preview mode and rewind step-by-step through the action blocks that make up my program, which was tremendously helpful in figuring out what was actually wrong with the stacking blocks.

You know that classic Three Stooges bit where Larry, Curly, and Moe all try to enter a doorway at once and get lodged in it? That’s what was happening to me. It’s called a “race condition.” In the split second when the player let go of the mouse and released the piece, so many different things were happening simultaneously in different parts of the program that the trackers I put to watch for collisions weren’t even running. Other stuff happened first, which prevented the collision from being detected. In that moment, I suddenly had more sympathy for air traffic controllers.

Gwen helped me figure out a smarter order of operations, which allowed my trackers to finally work, so I could solve the stacking bug.

Sort of.

Gwen and I got to a place where the pieces would no longer stack, but when she hovered a piece over another piece, the offending piece sometimes went back to where it came from. Other times it went to a space adjacent to the first piece. We had no idea why this was happening.

And then the pizza arrived, so no more coding. I thanked Gwen profusely. We enjoyed a few tasty slices from Delicious Pizza in LA. Very flavorful sauce, not too greasy.

That bug? Where the piece didn’t always go back to where it came from? That is the bug that killed me.

Much of the code in the game is built around the mouse moving in and out of game objects. When the mouse moves over the piece, important stuff happens. When the mouse exits a space, important stuff happens. The reason the piece was going to adjacent spaces is that whenever I dragged a piece over an empty space, the piece registered it as a cool place to go. So instead of snapping back to where it was originally, the code was like, “I’m going to send the piece to this empty space instead, because it’s a totally cool place to go.”

I decided to build a kind of air traffic control for the game board. The game would keep track of every empty and occupied space on the board, then tell the piece whether it was okay to land there. I spent a long time building that system. I have no idea why. If I had given it more thought, maybe I could’ve seen that it wouldn’t solve the problem. The issue was that I didn’t want the piece to go to just any free space on a list of free spaces. If the piece was on top of another piece, I wanted the piece to go back to where it came from. I got lost in the woods.

I decided to pivot away from that issue and add other features to the game. I put a few easy points on the board, like finding the right video clips (I settled on a royalty free movie called A Touch of Magic, an industrial film with a lot of silly, wonderful clips to loop endlessly) and fixing a bug with the “You Win” text that put the text in the wrong part of the screen.

When I came back to the evil bug, it was just as difficult to understand as before. I made tweaks to my air traffic controller, but that did nothing. At one point, I thought I just might have to ship with the bug. It wasn’t a game breaking bug. It just didn’t feel right.

And then I had a stupid idea. I remember thinking to myself, “There’s no way that will possibly work.” But I was out of ideas, and I knew the implementation would be quick, so I tried it. When the piece went over an empty space, it would register that space as a place to go and store its coordinates. So I thought, whenever the piece is over a non-empty space, like another piece, it could just erase all stored location data except the data for its original location. It was one of those ideas that’s like, “You probably tried that three months ago and it didn’t work, because how could you not have?” Sure enough, it worked perfectly. No open space tracker necessary. Just reset the data.

When I figure out a bug in a session or two, I feel a sense of pride. Bug fixed! I did it! But this bug must’ve taken me a few weeks to figure out. It was demoralizing, all told. This game was supposed to be a small gift. A game jam level project like this shouldn’t have taken months to complete.

In later reflection, I realized I was being hard on myself. I didn’t work on the project for five months straight. I was working on Motion Picture in small pockets of time after work. Sure, for an expert programmer, they probably could’ve made what I made in a weekend with late nights and energy drinks, but I’m not an expert programmer. To make this game, I had to learn so much, like how to click and drag objects, how to break a video into multiple pieces, how to animate objects, how to activate and deactivate objects, how to detect collisions between objects, and so much more.

In other words, I wasn’t just knitting someone a sweater as a gift. I was learning how to knit, so I could make a sweater as a gift. The next sweater I make will be that much easier.

🎲 Your Turn: What’s a great hurdle you overcame on a project? How did you feel about it after you cleared it? Have you ever given up on a project, because it was too hard? What was the straw that broke the camel’s back? I want to hear from you! Reply to this email or hit the orange button below to leave a comment the whole world can… and will??… read.

Image by pikisuperstar on Freepik