Hop 'Til You Drop: Finding the fun with rapid iteration

Fun—it’s at the core of any game design. But as anyone who has ever shipped a game can tell you, it can also be one of the trickiest things to get right. I’ve been on teams where we found the fun early, and teams where we wrestled with the fun until the bitter end. It should come as no surprise which of those projects ran smoother, were more satisfying, and resulted in a better game.

Since fun can be so elusive, there’s really no substitute for good old-fashioned trial and error, and that means rapid prototyping and iteration early in the process.  

The importance of iteration and prototyping was drilled into me since I was a kid. My dad, David Maynard, was one of the first programmers hired at Electronic Arts. He used to tell me a story from the early 80’s that demonstrated just how central iteration was to design. His co-worker was asked how long a game would take to complete. He pulled out a stopwatch and asked the lead programmer to compile a build. Then he multiplied the time by 10,000 to come up with the estimate.

The lesson? It will take 10,000 iterations of a game to get it right.

<>

Of course, back in 1982 my dad was working on an Atari 800, and it would take 45 minutes to compile one floppy disc that held 380 kilobytes of data. Today’s games can take days to get a new build into tester's hands, and the complexity goes up exponentially if you add multiplayer to the mix.

A two-person team at Manticore recently shipped a multiplayer puzzle game for PC called Hop ‘Til You Drop, that we developed in just two weeks using our Core platform. It’s a great example of the importance of rapid prototyping, and how it’s still possible in an increasingly complex development environment.

Our original inspiration for the game was a Minecraft mod called Musical Blocks, where players race to stand on colored blocks that are called out by the game. Once the progressively-shorter timer goes off, the other blocks disappear, and anyone who didn’t make it to the right color block falls to their death. It’s like a deadly musical chairs. 

<>

It was a fun starting point, and we were able to use the pre-created character models, physics, locomotion, animation, camera systems, and multiplayer networking in Core to essentially recreate Musical Blocks in about two days. Then we got to work playtesting.

We knew the core mechanic of racing to the right color block was already fun, but we found that as the game progressed the timing mechanic didn’t scale. Once you reach a certain point, players just don’t have time to navigate the map, and the game becomes frustrating.

We tried to find ways to ramp difficulty in the game that still felt skill-based for players, and stumbled upon a phenomenon called the “Stroop effect.” In psychology, the Stroop effect is the delay in reaction time between congruent and incongruent stimuli.  So basically, we’d put the word GREEN up, but it would be in white font. Players often instinctively race to the white block. It was a fun twist.

We thought the Stroop effect was a great way to ramp difficulty later in the match. But more playtesting revealed that it was confusing players who thought it might be a bug, not a feature.  We tried a number of ways to communicate this to players and ultimately landed on adding a wink emoji after instructions that used the Stroop effect. This did the trick.

More playtesting also found that while the game was a great test of reflexes, it lacked any meaningful strategy. So we played around with a few options and implemented a series of coins that would appear after the players made it to the right color block and the timer went off. They then have a short window to navigate a jumping puzzle between blocks to collect the coins. This added a risk-reward element, since every jump could mean a fall to their death.

With the coin mechanic in place, we started to rethink the ultimate win state, which had previously been the last person standing. We ultimately changed the objective of the game from surviving the longest, to having the most coins at the end of a match. A player could be aggressive in collecting coins, get eliminated early, but still win the round.

<>

In just two weeks the team was able to not only build and ship a high-fidelity multiplayer game, but we were able to make dozens of design changes based on our ability to instantly publish and playtest the game. At the end of the day, we did more than 100 iterations of the game - that’s more than 7 builds a day on average. And while Hop ‘Til You Drop is pretty simple, it’s a powerful demonstration of how rapid iteration can dramatically impact a game’s design, and make it easier to find the fun.

Check out the final version of Hop ‘Til You Drop here.