Magic vs Juggling

This is a post about magic and juggling, how they’re different and how they’re the same. This is also a post about game designers.

I suspect that many game designers enjoy one or the other. Some game designers like both. Why is that important? I’ll posit that whichever one you enjoy is indicative of the type of designer you are.

Penn and Teller have a great bit about the difference between juggling and magic (trick starts at 1:58 mark).? https://youtu.be/pd3_HFvQeXQ?si=U-AqseImb5zvK38r

Jokes aside, it does show the fundamental difference between juggling and magic. Juggling is a systemic performance whereas magic is non-systemic.?

A juggling pattern can continue indefinitely, barring only the stamina of the juggler. In fact, a way to describe juggling is siteswap, where numbers are used to describe one iteration of the pattern. Popular siteswaps are 423, 51, and 3. It gets much more complicated, but the fundamental goal is the same, to describe the system in a way that other jugglers can visualize and communicate with.

Magic tricks, on the other hand, are usually once through. In fact, the adage of, “Never repeat a trick” is taught so that the audience cannot figure out how it’s done. Magic is, without irony, all smoke and mirrors. I used to be really into magic, wanting to know how to perform tricks, until I found out that many tricks are duct tape and some stagehand off to the side. I’m being facetious of course, but magic, in many of its forms, is far from systemic.?

So how does that relate to game development? Well, if you’ve done any development, you can probably see where this is heading. Systems designers are like jugglers, setting up economies and other systems for the game to exist in. As a system designer, I take great pleasure in setting up a system that I don’t need to mess with a lot after implementation. I say to people, “the best systems are the ones you can walk away from.” They just work.

That’s not to say that system design is superior. Systems are a framework, but at the end of the day, it’s the player experience that matters. Systems that are poorly made can create a player experience that is stifling, grindy, or trivial.

This is where magic comes in. Magic is a performance art that really is about the audience experience, by whatever means necessary. Whatever it takes to achieve that effect is on the table. The best example of this in a game development setting was this excellent article about fighting Baldur for the first time in God of War(2018). https://blog.playstation.com/2018/08/16/fighting-a-god-behind-the-scenes-of-god-of-wars-first-boss-battle/

The part that stuck out to me is where they talk about how much they slide the characters around so that they land and end up in the right place for the next part of the sequence. Large actions mask small actions. Misdirection keeps the audience entertained and focused on experience and not the mechanics.

(Side note: when the player goes from focusing on the experience to the mechanics, that’s an indication that they’ve left the flow state and are either bored or have mastered the game. It’s an interesting place for the designer and the player to be in, which we can talk about another time.)

Granted, the fight isn’t all magic. The basic combat itself is still a system and that needs to work at the end of the day, but the fight itself is bespoke in many parts.

One last thing philosophically between the two disciplines is that in juggling, there’s a saying, “Good throws are more important than good catches.” It emphasizes that systems that are stable are better than heroic efforts to solve a problem when it arises, because heroic efforts are not necessarily repeatable or sustainable. But on the flipside, “the show must go on” and sometimes you don’t need a system, you just need some duct tape and some smoke and mirrors.