Prototyping a digital playground game

Designing an unofficial pick-up game of Johann Sebastian Joust for smartphones in HTML5 and JavaScript

(This essay is about game design and interaction design, not a coding tutorial on cloning a famous game in a weekend using only JavaScript. If you’re already familiar with Johann Sebastian Joust, you can skip to Interaction design for smartphones.)

Johann Sebastian Joust

“This may be my favorite game,” said Rami Ismail of Vlambeer of “a game that has become nearly legendary at gaming events,” as Ben Kuchera describes it.

It’s October 2012, and there is almost no chance you can experience the game they’re talking about. Nearly zero. Practically zilch.

That game is Johann Sebastian Joust (click through to watch their promo video if you haven’t seen it). Holding your own PlayStation Move controller steady, you try to jostle other players enough that they move their controllers, pushing them “out.” The amount of movement needed to do that changes in time with classical music that plays faster or slower.

That’s it. It’s a playground game: a little flag football, a little freeze tag, a little last man standing. It’s almost not a game at all, but performance art: designer Douglas Wilson shows up at events, unpacks MacBooks and Moves, an “incontrovertibly awesome” experience is had by all, and then he packs it all up and takes them away.

I think it’s been played in Austin, TX only once.

That is, until last weekend.

Johann Sebastian Joust.js

I don’t know if you’ve been keeping up, but smartphones can do a lot of stuff these days. And web browsers can do a lot of stuff these days. And sometimes, web browsers on smartphones (and tablets) can do all of those things, together.

From a technical perspective, Johann Sebastian Joust requires accelerometers, vibration, lights, changing the playback speed of music, and a way to synchronize all of that across 2-7 players. And, it turns out, emerging web standards like DeviceMotion, Vibration, Web Audio and WebSocket let you do that in the browser without needing a native app. My theory was, you should be able to visit a website to set up a pick-up game of Johann Sebastian Joust and just play it, right there with your friends, just like a real playground game, except using your smartphone. iOS 6 Safari supports all of these except for Vibration, as does Firefox Beta on Android.

So, Dave Massey and I built just that, during a two-day Music Hackathon here in Austin last weekend. We knocked-off Johann Sebastian Joust in HTML5. It works. You can play JSJ in your iOS 6 Safari or in Firefox Beta on Android, there’s music that speeds up and slows down, and it’s fun. Dave spent around four hours testing the various APIs ahead of the hackathon, we reused some code from another browser-based accelerometer toy I had made for the front-end, a crude Django app hosted on PythonAnywhere provided the game setup, and after perhaps 8-10 hours of development and a few hours on design, we had a prototype. Here are a couple of photos:

This isn’t about the code; any competent JavaScript developer should be able to figure it out. (I estimate about 40 man-hours total to get something production-quality, not counting having an artist make it pretty.) This is about how I tested a playground game.

Make friends and play together

In the upcoming third issue of Distance (which you should subscribe to), I make the argument that designers — particularly web, user experience and interaction designers — don’t prototype enough, and don’t share their work enough. We make lots of assumptions and guesses and maybe even do some research, but we don’t get our hands dirty and try things with real users enough. Worse, we don’t interact with enough other disciplines to be able to prototype really complicated things, like, say, playground games. (Playground games are complicated, not because the mechanics are complicated, but because the complications are emergent out of the fact that human beings are involved.)

In the game industry, I believe there’s an old vanguard of game designer which behaves similarly: they “just know” what’s fun and what isn’t, even when the critics and the players and the market disagree. I suspect many indie designers almost exclusively do hands-on, practical testing, eschewing academic research, which has its own problems. There’s a place for both.

I’ve never designed a playground game. I once designed a UI for a word game, but not the gameplay itself. I had no idea what would be involved, but I knew how to find out.

Interaction design for smartphones

My design and development plan was this:

  1. Make sure it was at least theoretically possible to do this
  2. Read everything about Johann Sebastian Joust so I understood the mechanics in theory (having never played it)
  3. Theoretically apply those mechanics to the smartphone model
  4. Get the accelerometers working
  5. Playtest to find reasonable ranges of motion to test gameplay with
  6. Turn those ranges into safe/warning/out signals
  7. Playtest those safe/warning/out ranges until it was fun
  8. Add support for “rush” times
  9. Playtest
    At this point, it would mean we had the technical framework for the game, from a mechanics perspective. Note the lack of support for music; we’ll get to the reason for that later. With a basic technical prototype completed, we would be able to focus on polish (as much as you can polish a game made in two days):
  10. Design the end-to-end user experience
  11. Add support for music
  12. Playtest

A few hours of testing and Dave determined it was theoretically possible with the hardware we had between us.

I determined the core mechanics were:

  • “slow motion is fun”
  • last man standing
  • slow music = extremely sensitive
  • fast music = less sensitive

Everything else was emergent or stylistic.

Playing Joust on a smartphone instead of with a Move controller means different constraints. First, only iOS 6 devices support the Web Audio API necessary for speeding up and slowing down music; this excludes all other brands of smartphones, un-upgraded iPhones, iPad 1 and all other tablets. The fact that you are playing on a smartphone without a mediating computer meant synchronizing the music and the “rush” times across multiple devices; even WebSocket can’t guarantee you that.

I sketched out three alternatives for the smartphone-only model:

  1. Don’t support music. Rather, let it be more of a visuals-oriented balance game, with the screen changing color from white (safe) to yellow (caution) to red (out) as you moved it. You’d have to keep your screen in your peripheral vision at all times.
  2. Support music through a conference call. The server plays the music through the conference call, ensuring everyone is generally in sync. This also means you could play Undercover Johann Sebastian Joust, with everyone listening through headphones and strangers not understanding what’s going on, a la Big New Ideas’ Undercover Capture the Flag. However, you would still need a data connection, and some carriers can’t do both at the same time.
  3. Push both music and accelerometer handling to the client. Rather than have a server receive accelerometer events and send music change events, push the song and the accelerometer handling into the browser. This means (best case) you only need to synchronize the start, and for players to notify the server when they’re out.

I really liked the idea of Undercover Johann Sebastian Joust, and Twilio was a sponsor of the hackathon, but for simplicity of implementation, we went with #3 and #1: pushing all accelerometer handling onto the client, and not supporting music until that worked well enough.

Once the accelerometers were reporting data, Dave picked up his phone, I picked up my Nexus 7 tablet running Firefox Beta, and we started walking around the open space in the thirteen23 office, watching accelerometer values. We moved our hands around. We moved our arms around. We walked faster and slower. We feinted at each other. We did this all while watching our screens, and it felt like a ~20% change in accelerometer values might be enough to test pushing someone “out” with, so we implemented that.

Our first new design decision was whether that 20% should be absolute or relative. Reading descriptions of real Johann Sebastian Joust gameplay doesn’t tell you if you can very slowly transition your Move controller between a vertical and a horizontal position. It could be “set on the floor” in either orientation. Given that you needed to be able to see the screen at all times, I hypothesized it should be absolute: you’d hold your phone in an initial position when the game started, and have to maintain that position throughout the game. This is what Dave implemented next.

With that working, I added in background color changes to make your standing obvious, and recruited a new tester. Local UX designer and developer Ansa Copeland played on her iPhone against me on my tablet. She picked the idea up quick, but voiced concern she had to move too slowly to make reasonable progress against me, granting that she might get used to it over time.

I changed the “out” sensitivity to ~25%, with a warning at ~15%. I added in “rush” times, decreasing sensitivity to motion to within ~35%, with a warning at the previous “out” zone of ~25%. With everyone visiting the same pre-generated URL at the same time, our (pre-generated) random rush times were approximately in sync.

This created a second new design decision: how would gameplay change if everyone’s rush times were different? Was synchronization necessary? I decided to keep the stock mechanics for the time being.

Playing this version resulted in the four-person gameplay photos you saw above, repeated here:

It was fun.

End-to-end UX, and music

At this point, now after lunch on the second day, Dave returned to clean up our UI based on my end-to-end designs, and see if we could shoehorn music in.

The original complete design, shown below, assumed full client-server interaction: a pushed music file to the client, server-sent events to change your local music playback for “rush” times, the client sending all accelerometer data to the server for computing states and recording “out” players, and ultimately pushing your status and the status of the winner.

The simplified prototype design with all client-side handling, shown below, meant once the server had generated the rush times, the client could speed up the music, set your local state, and determine if you were out. The winner would be the last person without a red screen. All the players had to do to be in sync was to press the “Start” button on their screens at the same time.

I designed wireframes for both states using my last stock of sadly cease-and-desisted Notepods. These paper prototypes were reviewed with local UX designer Kevin Walorski for coherence, and only minor changes needed to be made.

With only a few hours to go, we decided to use a controlling desktop PC to add music in quickly. The desktop browser would create the game and load up the song, smartphone players would visit a proscribed URL, and all players plus the desktop PC would press “Start” on their screens at the same time: players’ screens would change color in time with the sped up and slowed down music being played on the desktop PC.

With some last-minute hiccups, this also worked, but a third new design decision cropped up once a dozen or so spectators tried to play: the game design isn’t self-evident.

In theory, you can watch a playground game like freeze tag for a few minutes, get it, and play yourself. But, in these wireframes and as implemented, smartphone HTML5 Johann Sebastian Joust doesn’t make it obvious how to play. Everyone tells you to press “Start” at the same time, and so you do, and then how do you know what’s going on? People were complaining about going red almost immediately.

How self-evident is the real Johann Sebastian Joust? Is it obvious that “small moves, Ellie” is the way to play? It took many minutes of socialized instruction to get some people going, and others would hit “Start” frequently to reset themselves, resulting in their playing against themselves more than against others in the room.

I think self-evidence in games is an area where really interesting design work can be done. A tutorial mode or a grace period isn’t really self-evidence; it’s hand-holding. And, there’s a danger in proscribing behaviors in a tutorial, or changing the name of the game to “Move Slowly” or “Jostle Others” or “Shoving Match” to make it more self-evident: it may mean people are less likely to think outside the box. Some of the most interesting matches demonstrate a lot of emergent gameplay behaviors.

Finally, in the group setting, even though the music worked, it seemed essentially irrelevant to gameplay. An all-visual version, with possibly asynchronous “rush” times, might be interesting an interesting variation to pursue, and would support a wider variety of smartphones.


Dave and I split development pretty evenly, both working on front-end and back-end, and I did all of the design, testing and analysis you see here. Three new design issues were discovered: absolute versus relative movement, synchronization of rush times, and the self-evident nature of the game. We have no plans to make the code available, but the paper wireframes will be posted soon, along with concept visual designs from a local illustrator.

Thanks to Douglas Wilson for a fascinating game concept, and to the hosts of the Music Hackathon. I’m Vitorio, it’s October 11, 2012, thanks for reading.