At GDC 2012, I had the pleasure of playing a game called Hokra at a party. I had never heard of it before, but I watched a game from across the room, and it looked like some easy fun. And it was! Playing was awesome, but even more striking was just how fun it was to watch other people play and get caught up in the moment-to-moment action. Later that year, at IndieCade, I got to see the designer, Ramiro Corbetta, and a few other awesome dudes give a presentation about eSports, and I resolved: I was going to make an eSport of my own. When the 10-day CREATE gam jam for OUYA games was announced, Hokra was the first game that came to my mind. Here was my opportunity to make a simple eSport for a platform that’s actually built for local multiplayer.
In keeping with that focus, I started the design in a way that I never have before: Not by imagining a feeling or a mechanic, but by envisioning the particular social setting for the game. The IndieCade eSports panel pointed out the enormous differences between games built for the screen versus those built for the stadium (or for streaming online). I wanted to make a game that could be the perfect background tournament game at a party, like Hokra was when I first saw it. I wanted a fast-paced, highly dynamic, skill-focused game that would be clear and compelling even for someone just glancing at it from across the room.
There were some obvious steps to take towards this end, like adding movement trails and an enormous scoreboard. The gameplay-oriented choices were more difficult, since I had to balance the desires of the players (control, fairness, skill) with the desires of the hypothetical audience (dynamism, unpredictability, speed). As I discussed in the dev diary halfway through the contest, the need to balance the game for the players initially led me to nerf the players’ level of control over and over again, hoping to make a game that couldn’t be dominated by any strategy that was uninteresting to watch. I eventually realized that this was a mistake and reversed course, giving the players more power until it was balanced, which works better for both groups. Another example involved the interesting problem of figuring out the game’s optimal level of chaos. At one point, the explosions were so powerful and the ball was so light that players would get lucky goals without even trying. When I tried to fix this, the game ended up feeling sluggish instead. The solution was to have both very high-powered explosions but also very high drag on the ball; it would zoom away at high speed, but come to a stop before it could reach the opposite goal. This stayed fair, but also moved the action around the map much more.
Getting art and sound assets was a challenge, especially under a tight deadline, and I wanted to make the presentation as audience-friendly as the gameplay. I knew I wanted some upbeat, high-energy music, but good, game-appropriate, free-to-use music tracks are digital needles in an internet haystack. This time, thankfully, I had friends helping me search, and I got lucky besides. I ended up with three distinctive tracks that fit the game’s feel perfectly. The visuals, on the other hand, were more difficult, since they couldn’t just be found online. Aside from the movement trails, I had no idea what to do for art in the game. I couldn’t recruit a dedicated artist on short notice, so I picked a set of interesting constraints and made the best programmer art that I could. I chose to use highly saturated colors with no outlines; the sharp edges that the game required would be colors-on-white instead of my usual darker lines. I’m sure it’s not the best look the game could have, but it’s different, and the brightness captures attention. The music pumps you up, the graphics catch your eye, and some buzzer sound effects here and there hopefully cater to the audience that I envisioned at the start.
The biggest flaw in this design process was the almost total lack of playtesting. I was rushed. Ten days isn’t long, and I needed all of that time just to finish the game. This failure to test the game with a variety of other people means that A) I made a few mistakes, like making the AI too difficult for first-time players, and B) I never got to evaluate whether the game would actually work in its intended setting. I hope to be able to test it out properly at some point, and I hope the contest judges experience it in the way I originally hoped.
I’m also not sure what level of interest the game could sustain on a larger scale. My ambition was to create a game that could support a hardcore following of dedicated, skillful players. I think the gameplay is there, but the rounds are so short (two minutes) and the game so simple that I can’t imagine people casting games or streaming them or creating a community around them. Bombball fits the same niche as Hokra, but the IndieCade eSports panel pointed out that “sports” are pretty diverse and may just be a cultural label for competitive games with some cultural importance. I chose to label Bombball as an eSport because of the competitive focus, spectator angle, and high skill ceiling, but I realize that the label can look a little silly for a simple game coming out of a 10-day jam.
In the middle of development, I re-read my old notes from the IndieCade eSports panel. As I went over the various suggestions and “rules” for designing such games, I was pleased that Bombball already featured so many of them: an obvious score, the possibility for comebacks, visual clarity, real-time action, close calls, opportunities for demonstrations of great skill, etc. I usually have a sense for whether my games really work or not. It’s possible that the game will just get lost in the usual game jam crowd, but this one works. I pursued a vision, and in the end, I’m proud of how close to it I got.