Cube Ball

Note: This one was harder to write than the others, mainly due to the massive amount of media I scoured to include relevant assets and remind myself about aspects of the development. Cube Ball is one of my all-time favorite games and the most evident field game in the ESC titles. Enjoy!

The early demo of the ESC Game Theater featured two games, SnB and Spotter (which would become Hat the Beast due to copyright concerns).

Note: Spotter was a wild idea. Ed shared an article about facial pattern recognition, perhaps centered around prosopagnosia, “face blindness.” I had created the game design documents for dozens of games, but none jumped out to the team. In response to Ed's inspiration, I suggested a Where’s Waldo and decided that celebrities and historical figures would be the most appealing to hunt for across multiple demographics.

The concept was simple: find a celebrity in a crowd. The first issue was that selecting a body with crosshairs felt violent. Angela Greene suggested that players place hats on them instead of clicking on them via a cursor (which was abstract and hilarious!). Players would get three or so celebrities to “hat.” If there were already hats, the hats would stack.

I created a basic prototype in Flash that panned around a collage of celebrity faces. We tried to use celebrity trivia instead of names, but that was too difficult for most players. The game was missing competitive elements, so we added an apple that could knock all the hats off of a celebrity’s head and a water balloon that would cover a part of the screen, making it hard to see. The game was a hit, but there was a problem. Getting a license for celebrity likenesses was prohibitively expensive. We changed it to animals for the commercial release, hence Hat the Beast, but the game was not as fun without facial recognition.

These worked well for the demo but didn’t feel like video games. One side believed it should be this way - ESC won’t have games like other systems, so our aesthetic and mechanic choices should be different. That was a hard fight, though, as the public (i.e., our playtesters) wanted games that felt… like games. Creating work that is too esoteric for a location-based entertainment product is difficult. We had enough challenges with folks thinking ESC was VR(!)

Note: Read the Robot Basketball article for a fuller context of ESC Games. The ESC Game Theater was conceived in 2010 and first shown to the public in 2014. The space was an immersive 30-player, local multiplayer system allowing everyone to play with and against one another on a 50-foot screen.

We knew we had two games, even though they ended up being on the weaker end of the ESC library. The following games we planned were based around SnB, one being Robot Basketball and the other being a defense game that was never released. Once we had momentum with the development of Robot Basketball and a small team of developers led by Kevin Harper , we decided to prop up some quick ideas for Ed to review. The process for getting games from ideation to completion was created as we went. Before installation, we had a concept for multiple systems with different attributes. I documented over a hundred game ideas for each variation. Then, I fleshed out two or three ideas as full game design documents before even seeing the demo in person. Those games were never made (alas!), but it was an excellent way to learn what was necessary for a game design document and what was overkill for our team.

All games started with some idea and a rapid prototype. The Spotter prototype was done using Flash (the only engine I was comfortable with at the time), and the SnB prototype was done with a Shopvac. Yes, a Shopvac (actually two). Before we had Kevin, who could spin out demos daily, we had to do our best with the tools we had. To prove that SnB would be interesting, Michael Schneider and I built a version out of cardboard, balls from Field TD, and two Shopvacs. The game worked, and the idea was sold, but it leaves me wondering if I should make more shopvac-based games.

Kevin gave us the ability to make things happen quickly in Unity. The original demo system was bespoke - Unity wasn’t on our radar when the project was initiated in 2010. Control Group built the games from scratch without too many game engine amenities, which is crazy to think about. The production version of the system required Unity to run as we wanted more developers and, therefore, needed a game engine.

Our initial paper prototypes set an expectation —any new games would first be rapid demos demonstrating the fun. I worked hard with Kevin to take ideas from the game book and build them into an instantly playable realization. This was harder than it sounds! The first time we had a prototype review, I believe we showed 12 different prototypes. Each was a primitive idea, mostly demonstrating movement and light interactions. Only one of those prototypes was ever made: Cube Ball.

Ed had initially proposed a game that would use the depth of the screen - that is, objects could be closer or farther away. This is tricky in a fixed-camera environment with up to 30 players (or any number of players). I had never opened Unity at this point and was mesmerized watching Kevin work. He was creating new objects one day, and I was inspired. Can you take one of those cubes (the default 3D primitive) and make it roll around on a plane (a flat surface) confined to a grid? The idea was that by moving this object around, similar to turning a die on a table, we could have a grid to broadcast the depth of the character easily. Kevin made it immediately, along with the ability to control it using one of our touchpads.

The game wasn’t a game at all yet. It was a demonstration of movement. The character (a cube) could roll around on a checkerboard-like surface. That was it. And that was enough. We showed our twelve ideas. Eleven were rejected or thrown back for more iteration. One was approved. Now, I just needed to come up with a game.

My idea was to make a soccer-like game. Cubes hitting a sphere around a plane felt right—it had a Supersonic Acrobatic Rocket-Powered Battle Cars vibe.

Note: This occurred before Rocket League, the successor to Supersonic Acrobatic Rocket-Powered Battle-Cars. The game was one of my favorites, but the online community declined over time.

The first iteration broke down almost immediately. I wanted the feeling of Supersonic Acrobatic Rocket-Powered Battle-Cars, so we used real physics for the ball, which made it impossible. There needed to be more control of the cube to nudge the ball with intention. The balls kept getting stuck in the corner, which wasn’t fun. The cube movement made sense, but the game would not work with lifelike ball physics, so we scrapped physics and changed the dynamic entirely.

The player would now pick up the ball on collision. They could double-tap the screen to “shoot” the ball in the last direction they moved. This made the ball move more like an arrow - it could only move rectilinearly, similar to the players. There were doubts this would work - it felt too simple. But once we got 10+ players rolling around, the ball movement made perfect sense.

Another consideration was defense - how would one player steal the ball from another? We settled on a double-tap to sprint the cube forward two spaces without the ball. If a player from the opposite team occupied either of those spaces, they would be destroyed. If that player had the ball, the sprinting player would immediately steal it. This solved any challenges with teams creating walls to block out the opposing team - teammates could clear the way for the offense.

The final primary choice was to present an alternate way of scoring. We had two main actions - shooting the ball into the goal and destroying other players. I wanted something else. What if a player is right next to the goal - there is no way to shoot if their last direction is up or down. They should be able to jump into the goal to get more points, which would present the advantage of putting them back on their half of the field. What if they didn’t have the ball? They should be able to get a small reward for simply sacrificing themselves for the goal. We now had four scoring methods: destroy, sacrifice, touchdown, and shoot.

We presented the concept to Ed as we progressed through the first build. He loved the game but had two main changes. The first was that players should not be rewarded for destroying one another. Even though this part of the game was essential, we shouldn’t celebrate it. It was the right call and cleaned up scoring a lot, as this meant all scoring centered around the goal. The second change was that the goals should not be goals; they should be giant mouths. And the mouths should move every time a point is scored.?

We all chuckled about the lip concept for a long time - but Ed was right. We were making something fantastical, and it needed a hook. It needed to stand out. There had to be a story. The lips brought a sense of whimsy to an abstract and generic game. The mouths added narrative to the sport-heavy tropes. Rolling into the goal was a sacrifice - what kind of dystopian world is this?

Note: There’s a version of history where ESC somehow managed to be the biggest game company in the world—and as such, we break out into other mediums. One is inspired by the video game-based Saturday Morning Cartoons of the 1980s. In this timeline, we get Robot Basketball stories about post-civilization steampunk robots enjoying human activities, Feudal Football stories about modern competitions in a high-fantasy setting, and Cube Ball stories about geometric objects that sacrifice themselves for sport (among other properties). Jet Tawara was responsible for the look and feel of almost all ESC Game Theater games, and she did an incredible job!

Further Note: We did plan crossovers between all of the games. It was a good time for imagination.

The cast was set. Players had three ways to score: shoot the ball, roll in with the ball, and roll in without the ball. The dash and destroy mechanic stayed in but did not add to the team score. We used the smashes and other meaningful stats to inform end-of-game superlatives. From then on, the fundamental game design remained the same when we released it commercially.

Cube Ball and Robot Basketball were done first, so they were tested the most often. Even when we were focusing playtests on new games, we would play a game or three of the first two. Robot Basketball was perfect for new players, and Cube Ball was the most popular for returning players. We had a team of Cube Ball aficionados who prided themselves on crafting new, dominating strategies. It was fun to see our testers get obsessed with the game.

Note: It may be obvious, but playtesting with 10-30 players every week (and often multiple times a week) was difficult for a new startup. We mitigated this by creating a party atmosphere in the studio. Regulars would come for beer, games, and companionship, and we would host after-parties for Playcrafting events and NYC-based festivals.

Cube Ball was the second most played game over the lifetime of the ESC Game Theater. Robot Basketball was the go-to introductory game because it was easy for all players to learn and could even be played with a single player. Cube Ball was optimally balanced for eight to twenty players. Three on three worked but was sparse, and fifteen on fifteen was glorious chaos. Despite this limitation, the game was a hit. Players would demand a rematch immediately, which is always a good signal. The game's success interfered with other games getting air time - facilitators often played along because they enjoyed the game so much and chose what was on the screen. I had to remind them to switch it up and play Fruit Tattoo and Feudal Football (among others) now and then.

There was one main design flaw in Cube Ball. We strived to keep the control as simple as possible, so we used swipe for movement and double tap for dash/shoot. Unfortunately, interpreting a swipe versus a double tap added slight action latency in an often fast-paced experience. The players wanted the dash to trigger immediately, while the controller had to wait a critical moment to gauge the second tap correctly. Also, false positives often occurred - especially when the players were most frantic. Another frustration with the dash/shoot was that players would go in the last direction they moved. This initially felt like an excellent mechanical choice, but it influenced the gameplay and strategy too much. The players needed more control over where they shot the ball.

After releasing the ten initial ESC games, we could circle back and make Cube Ball: Pro Edition. This version added a dash/shoot button to the right side of the screen and a joystick area on the left. The movement would still work with swipes, but the player could now swipe and hold, which made the controls intuitive and more comfortable. Swipe and hold even allowed direction change, so players didn’t have to slap the screen with their thumb constantly. The dash/shoot button would respond to the direction of the player's virtual joystick, so they were no longer bound by their last movement choice.

Beyond eliminating the double-tap, we added a new charge mechanic for the dash/shoot. Holding the button would increase the shot's speed or the dash's distance. This introduced a risk/reward aspect that the initial version needed. Players could leave themselves exposed while they charged to get a faster shot. We over-emphasized a charge by having the cube gyrate and jiggle while filling with light. Defenders could anticipate strong shots and move accordingly.

Both game versions were available at our installations, and the PE version quickly became the main variation. We added several maps and allowed the facilitator to alter the number of balls. Unfortunately, the game theaters were shut down shortly after PE’s release.

I miss playing Cube Ball. Most of my games are physical, and in the real world, so I’m used to the ephemeral nature of work. But video games generally continue to exist. The heartbreaking truth of ESC is that the games depended on a system that no longer exists - trying to resurrect them without the supporting backend is challenging, if not impossible.

I plan on recreating this game someday. I’m only a hobbyist developer, but it’s only a primitive and a plane. How hard could it be?