Videogames That Go Squish - my talk from Bees In A Tin

This is a heavily-edited version of the talk I did at Bees In A Tin on Friday. There's also a recording of the original, with slightly different jokes.

I've realized recently that I seem to have made a lot of games have both digital and physical components. And having realized this, I felt I should have learnt something and have some kind of generalizable lessons about making them to share. So it is that I present this list of universal, always-applicable and entirely transferable principles for the design of games with both a physical and a digital component. Ready? Okay, here we go:

You get to design the entire experience

I come from videogames, where traditionally you a) make some software and then b) you sell it to people. The hardware, the input mechanisms, the expectations people have when going in: all of these you have only very limited and distant control over.

So digital/physical games are great! You get to design pretty much all of:

• the software
• the hardware
• and the context it's experienced in

As I've said before: If you have some control over it, and it affects the player's experience, you should either design it, or think very hard about why you're not going to. When designing one of these elements, you can fix problems or reinforce things happening in another element. Defects in the experience can slip between layers. For example, in Fabulous Beasts, there are some pieces that have very powerful effects in the digital boardgame. One reason they're not overpowered is the physical design of the pieces make them really difficult to place on top of a wobbly tower. The task of balancing these pieces (in the game-design sense) happens across both the physical design of the pieces and their digital effects.

Another example: we wanted to explain how to play Doom Piano. The traditional way to convey this in a videogame would be onscreen prompts that explain the control mappings. But modding Doom is a pain to do, and people who can't play piano won't know what the keys are called anyway. So we just wrote the controls above the keys with a marker pen (on some tape, so as not to permanently damage the piano. It's a rubbish old piano, though, so it doesn't really matter). That's a simple fix that's a bit of a bodge - but it works perfectly. Similarly, one of the keys on the piano had busted strings and only made a "thonk" sound when hit. We made that key the "use" key (I did say it was a rubbish old piano).

Including, importantly, the framing

There's a quote I first heard from Tassos Stevens that I love:

"A play begins when you first hear of it, and ends when you forget it"

This also applies to games where you don't get control over the hardware: but when you do, it's common to have a lot more control over it. Ultimately, you're not designing a game, you're designing the experience of playing it. When I gave this talk I was still in the pink apron I wear when I run Punch The Custard - I wear it because it enhances the sense of occasion when approaching the table to play. That's also why I put stray wooden spoons, bright cheery tablecloths, and leftover tin foil on the table - it adds to the sense of an out-of-context kitchen experiment. It's a much more distinctive thing to approach than "a weird game which uses custard".

To use a mainstream example: Guitar Hero is more fun when you play it standing up and play-acting a bit than when you play it sitting down on a sofa by yourself. It gets even more fun if you're on a stage and people are cheering as you play (or so I imagine, anyway). It's the same software and the same hardware in both cases, but the context has shifted - resulting in a vastly different experience. We can take inspiration from playground games - they're as much about the rituals, the "eenie-meenie-miney-mo", the lining up and preparing to play as they are about the actual game that lives in the centre of them. Often, what you're really trying to achieve with a game is to provide a social experience, with the game as an excuse. The game is just the grit in the oyster that the pearl forms around.

Tell a good joke

Games are generally best when they're built around a single appealing concept. If everything else has to build on, or support, that single idea, then you have a very useful tool for deciding what work is important or necessary, and what work is unnecessary or is a distraction. In my case, I find it clarifying to think of my games as jokes, and then decide what's worth doing based on whether it makes the joke funnier.

Doom Piano is basically a joke. It's the experience of being able to play Doom on a piano. I think that's funnier if you can use every single key of the piano to do something - so I argued for that and consequently ended up spending a few hours soldering wires onto endless strips of copper tape.

Punch The Custard is also a joke (it's also a game with a deadpan, straightforward title. Apparently I make a lot of these). The hardware is shonky and could do with being improved (when your reliability is improved by shoving in a sock, you're not operating at a high level). The software and graphics were bodged together quickly. I've not improved them : partly because it wouldn't make the joke funnier, and partly because I'm quite lazy, and Punch The Custard is a small game and only likely to be run at events.

They're usually small, because they're usually made for events

This is even less universal than the other non-universal principles in this list of universal principles. But most of the games I've made have been made for events. The reasons for this are largely economic - it's hard to make a physical thing, and it's even harder to make lots of them at a price that a consumer could pay. It's hard to sell a thing, too. This leads to a local maxima, where lots of these games are built for novelty - they're small, they're weird, and they're jokes.

Fabulous Beasts, which we're developing now, is an attempt to break out of this, and build a game that's large, deep, and can be actually sold to players. I'm excited for the new problems we're already tackling. For most of the games I've made, though, they're made for events, and as such, ought to be good games-to-run-at-events. That means answering questions like these:

• does it attract players from across the room?
• is it fun to watch people playing?
• how much do you need to know before you can start playing?
• how long does it take to learn?
• can you learn from watching it?
• how many people can play at once?
• how long does a game last for?
• does it need to be constantly staffed? (this is tiring to do)
• does the structure of the game encourage the circulation of players?

I'm going to take a quick digression and talk about this using the example of Doug Wilson's game JS Joust, even if it's not technically using custom hardware. When you play JS Joust at an event, you typically play for a few rounds and then bow out. At large events, a natural circle forms - everyone stands, watching the players face off against each other inside this arena. While you're watching, you're getting the idea of the game. You might not quite twig that the sensitivity depends on the speed of the music, but you'll at least get the aim (and it's likely that a nearby spectator will fill you in on any details you've missed). When a player feels like they're been playing too long, they can just offer up their controller to the people standing around the circle, and step out and become a spectator. There's continuity between players from round to round (which is important, so you can form grudges against the other players), but there's constant circulation of players. And the atmosphere the circle creates is wonderful - right now, I am smiling remembering the magical experience I had playing and watching Joust in the front storage hold of an ex-German fishing trawler. I can't imagine you could design upfront such a beautiful emergent behaviour for your game, but you can absolutely do your best to give one the space to emerge, and then tend to it if it does.

Where should I look?

At any one time, people are generally capable of attending to about one thing. They can sometimes keep an eye on another thing, and they can often switch between things quite quickly and fluidly, but they're only usually attending to one thing. If you're making a game that's got multiple interesting things to attend to at once (for example, on the screen and also in your hands) then you need to deal with this. This applies to typical videogames, too, but the problem wears off: once you're expert, using the controller becomes second nature and your attention can focus entirely on the screen. It can take a long time to become expert, mind - typical game controllers are not comfortable things for people who aren't from games - and mouselook is really confusing until you're used to it. It can be simpler for touch screen games where there's a one-to-one input mapping or a simple (approaching one-button) control scheme. My game A Bastard is an example of competing demands - the controls need attention, the minimap needs attention, the first person view needs attention and your opponent needs attention. The game is very much about trying to decide what's worth attending to at any particular moment (and also squabbling over the controls). This extends up into high level play - attention is the ultimate resource to be managed in Starcraft.

The simplest way to deal with this problem is to clearly indicate where attention should be paid. In Jumpotron there's a single place you should be attending to at any one time, and everything else becomes inert to avoid distracting you. You go from adjusting values using the controls and the screen (the split there isn't problematic, because there's no time pressure and there's an immediate 1-to-1 mapping) to pressing the big "Prime" button to jumping on the pad to watching your robot jump to receiving a receipt printout. At any one time there's only one thing you can be doing, and it's clear what that is - even at the expense of allowing more people to play the game in parallel. This wasn't an accident - when we were designing the game flow it was with this principle in mind.

Punch The Custard plays with attention. As you're putting the effort into punching and your attention is shifting entirely onto keeping your weary arm moving, you can be caught out by the instruction flipping from "PUNCH" to "DON'T PUNCH". There's a number of reasons for the split in attention - it keeps the focus on the videogame part of the game, it means you're paying attention to your respective scores, it's funny to get caught out, you need breaks or else your arm would fall off and it's more exciting if there are peaks and troughs of intensity. But if you become overwhelmed or distracted and you stop paying attention to the screen, your attention can be called back when score-up sound effect changes to a score-down sound effect or when your opponent stops. And if you still fail to notice the state change the game fails open - you'll lose some points, but you can carry on just fine and you'll still end with a positive score. Ultimately, this mild split in attention is there to mildly overload your ability to pay attention - this feels exciting, and intense, and the experience is short enough it never becomes irritating.

Tenya Wanya Teens goes the whole hog (though I can't claim design credit here). You have too many things to pay attention to - moving your character around on screen, remembering what the button mappings are - and then on top of that you have to look down at the controller, so you're sure they haven't just changed out from underneath you. It's a very silly game, and it's deliberately overwhelming - which nicely captures the feeling of being an awkward, uncertain teen boy.

Magic

You can also think of these games as a magic trick. You approach a technology that's implicitly promising an experience, and it does something unexpected and wonderful and outside of your everyday experience. That's a satisfying thing! If you can smooth out the rough edges of the interaction, then you absolutely should do so. This was a guiding principle in our work on the prototype of Fabulous Beasts.

But there's another way that magic tricks can be satisfying - hearing how it's done. Penn & Teller have made this a trademark - first you show the trick, and that's pretty thrilling, and then you show how it's done, and that's a different sort of enjoyment. When people see Punch The Custard, their follow-up questions are always about how it works. Doom Piano is an impressive object to approach and interact with, but there's also another sort of impressive once you unbuckle it and show all the shining copper and dangling wires (and bits of sticky tape) on every single hammer inside. Also, there's a neat trick where we use the brass soundboard as a common ground for all 88 hammer-switches. Still pleased about that! Don't be afraid to get technical with people, if they seem interested.

Mind, I'm not arguing for a tech-first approach, here - focus on building the experience you want, as straightforwardly as possible. But if that technology is non-obvious, then there might be satisfaction in seeing your workings.

Actually making stuff: boxes are hard

The hardest part of making the Tenya Wanya Teens controllers was just building two wooden boxes. Enclosures are difficult. If you can find a way to not make them, go for it. Shove your electronics in an old custard can (then add a sock to keep them in place), or bolt them into an upright piano.

Electronics are easy

Punch The Custard could just be a Makey Makey board (it's an Arduino with Firmata on it and a few resistors in a breadboard instead). Tenya Wanya Teens is just LED buttons and boards bought from Ultimarc (highly recommended for arcade controls). Jumpotron was a matter of first looking up how to wire up encoders, then doing that. None of the skills you need are ones you can't pretend you have after an afternoon of Googling.

Programming is ... alright?

I dunno. It depends what you're doing. Hard stuff is hard, easy stuff is easy, things are generally simple until they suddenly get very complex. Try to keep your requirements simple, and get the most effect possible from the simplest code.

I come from a background as a programmer on videogames, so I probably have a skewed point of view on the difficulty of coding. For me, programming is easy, and making boxes is hard. I'm envious of the skills of carpenters. Design your project around the skills you have or can stretch to. Use what you know - the obscurest skill or interest could be the germ of a great game. There's no standardized skill set for making this stuff.

---

Despite what I said at the start, please don't take any of this as prescriptive. I hope it has offered up new ways to think about making these exciting hybrids of hardware and software. It's very much biased by the games I've made and the things I am interested in. I'm not sorry. When you're designing for the whole stack, and trying to create something truly new, received wisdom is even less useful than it usually is.

As always, the important thing, and the most practical and universal advice I can give is:

• think quite hard about the problem you're trying to solve
• and then try something out and see if it works

Fri Jun 19, 2015