---

A “Roomba Fight Club” Postmortem

---

Roomba Fight Club is available for free here

Roomba Fight Club is currently being voted on here

A lot can change in a year. Just about one year ago I participated in my very first game jam, Ludum Dare 34. You can read about it HERE. I found the whole experience incredibly difficult, yet rewarding. Just a couple of weeks ago I decided to try it again with Ludum Dare 37. I wanted to see if the grueling game jam would treat me any differently now that I’ve had another year of game development practice under my belt. Did it? Well read on and see (or just skip to the end if you’re lazy).

The Game

The theme for this past Ludum Dare was “One room”. I decided to make a video game version of the Roomba knife fights videos from YouTube called “Roomba Fight Club”.  The premise to the game is very simple. You have a Roomba with a knife strapped to the front and three balloons strapped to the back. The goal of the game is to protect your balloons while popping all of your opponent’s balloons. This task is compounded by the intentionally difficult tank controls and scattered furniture around the room.

The Development

Development for this idea started really rough. Like incredibly rough.  I could not think of an idea for the “One Room” prompt. I lost about 2 hours of development time just pacing back and forth in my room trying to think of a game that would only take place in one room. I had learned last year that you can’t go too outside the box with the theme ideas. I had a couple of commenters let me know that they dinged me points for “Safe or Sorry” because while the meta game was played with only two buttons, the actual game was not.  I wanted to avoid that if at all possible and let the player know that I had indeed stayed on theme.

My first idea was to do some sort of multi-dimension thing ah la “Rick and Morty”. Something where there were a huge number of identical rooms in parallel universes, but that would require a bunch of ideas for each universe and time to implement them all. This was a no go for a game jam idea. I then came up with a bunch of plays on  the word “room” such as “The elephant in the room” or “Wiggle room”, but game mechanics weren’t apparent in either idea. I finally settled on Room-ba based room combat in a living room.  Hopefully the theme didn’t get lost on people this time.

This year I focused way more on “planning before execution” than i had the previous year. Before I started coding anything I had a basic idea for how the game would play. I had a basic idea of the shape of the room and the aesthetic for the game. I even picked out a color palette to stick with using http://www.colourlovers.com/ before I ever even started coding. This is in stark contrast to last year where I just started coding right out of the gate. I think what changed this year is that I was at least a little familiar with the process.  I wasn’t so scared that I would run out of time that I felt that every moment needed to be put toward creating a tangible asset. Once I had my basic plans laid out I still didn’t just jump right into code. First I grey boxed everything.

I laid out the basic perimeter of the room and cordoned off the areas where props such as the couch and TV would go. This took a few tries to get right. I didn’t want the room comically large, but I also wanted it big enough to move around in.

Once that was done I moved into the pawn setup for the Roombas. I played with making them all physics driven, but that turned into a nightmare quickly. It was too easy to get flipped over or to create really weird physics issues. I eventually just had them inherit from the default Unreal Character class, but in doing so I wound up getting the default capsule collider which caused a few problems of its own. I even had the balloons on strings originally with forces constantly pulling them upwards. It was cool, but it made them impossible to stab with the little knife, and extremely unpredictable.

Once I got movement down I built out a really simple AI for your Roomba opponent. It’s a behavior tree with three nodes.

1. Turn towards player
2. Dash forward a random distance
3. Wait a random amount of time.

By making some of the parameters random the AI feels a little less predictable, but all in all it took me the least amount of time in this project. I played around with making the AI smarter, and making it use Unreal’s path-finding, but I found out quickly that the game was way more fun when the AI just smashed its way through the environment like some 90’s kool-aid man.

Next came round after round of polish. By designing first, then coding, and leaving aesthetics till last, I ensured that I could take all the time I needed doing the art. I didn’t have a lot of code left hanging over my head.  My asset creation pipeline looked a little something like this:

1. Create BSP volume in Unreal the approximate size of the asset I wanted.
2. Export BSP as static mesh to use as a size reference
3. Model basic mesh in Zbrush using Zmodelor and dynamic subdivision.
4. Kick back to Blender to clean up, UV and Assigning materials.

That was about it. I skipped texturing which saved me a ton of time. Other than the wallpaper which I generated using a tile generator, every material is just a single color. Last year I used Substance designer to create my textures, but the amount of time I lost didn’t seem worth it for the final outcome.

The music for Roomba fight club was generated in Bosca Ceoil. The same as it was last year. Sound effects were created by a combination of recording noises on my cell phone and using www.bfxr.net .

What Went Well

• Boxing out the room first
  • Boxing out the room first meant that I didn’t have to make zero hour design choices and updates. I played around with everything while it was ugly, so that once it looked nice I could just leave it alone.
• Using a Pre-Determined Color Palette and Skipping Textures
  • By deciding I wasn’t going to waste my time this year with textures I freed up a lot of time to send on other aspects of the game. Because I stuck with a pre-determined color palette the game still looked pretty nice even as flat colors.
• Multiplayer
  • Multiplayer wasn’t one of my original design choices. It got added to the game on the Sunday morning before turning it in. I had to call a buddy to bring over a Gamepad just to test to see if it even worked. This turned out to be an easy win due to how UE4 is set up. I just had to spin up a second player controller and that was about it. Most of the work the engine does right out of the box.
• Destruction
  • Like multiplayer this feature was added late in the game but made a huge improvement. Originally couches were unmovable and the furniture was just something have to work around but I kept getting stuck on it. It was trying to figure out a solution to that problem that lead me to make the whole room alter-able. The effect was easy to implement and it made the game way more fun.
• Juice
  • I tried adding a little Juice to this project. I added some time dilation and screen shake on balloon pops. I also added a confetti style particle effect. None of that was very hard to implement, but I think it makes it feel better when you score a hit.

 

What Did Not Go Well

• Lighting
  • It turns out I had a lot to learn about lighting. I probably still do. Every other game I’ve worked on has either been outside, so the lighting was pretty much handled by the Sun (directional light) or has been intentionally dark. I found it really difficult to get the indoor light to look natural. I wound up just using a post process that added tons of ambient light, but I doubt that’s the right way to do it.
• Unfinished features
  • There was a lot I wanted to implement that I did not get a chance to implement. I wanted to make the balloons semi transparent on the player’s Roomba so the player could still see it. I had intended there to be a choice of 3 weapons to extend the games play-ability. I also wanted there to be more than two Roombas in a game. Maybe I’ll come back to this game one day and implement these features but for LD37 I just ran out of time
• Controls
  • I had intended for the controls to be a little clumsy. I had wanted the controls to be a little clumsy, like an old school tank controls type game. Unfortunately I don’t think I implemented them well. Turning isn’t great, and the camera is locked to the Roomba’s rotation, so turning always feels a little jarring. To make matters worse enemy AI Roomba turns instantly and accurately. It’s hindered b the distance it can travel, but it’s got pin point accuracy making it very frustrating in single player mode.

Conclusion

There’s an inspirational quote floating around on the internet that goes something like “It doesn’t get easier, you just get stronger.”  I feel like that really applies here. I feel like my entry for this Ludum Dare is heads and tails above what I turned in last time, but I don’t feel like it was any easier to create. If anything I feel like it was harder. There are a lot of systems in play for this game that did not exist in the simple survival horror game I made last time, but I don’t think I would have attempted something this ambitious had I not already done the game for LD34. So to answer the question from the beginning, yes. I feel like this Ludum Dare treated me different. Not better. Just different.