The process of creating magic tricks is simply solving problems. Starting with the big problem, how to do an impossible thing, and working your way down to the nitty-gritty details, like how to hide a rabbit in your pants.
Programming is a similar process. You begin with the big problem you're trying to solve, which breaks down into thousands of mini-problems. Coding a web app, in my experience, is just like stumbling through a maze. You discover new problems, and solve as you go.
In my "Suitcase of Wonders" show I had a big problem; how to have a randomly chosen number be the combination to a lock. I ended up going about it like a programmer.
The world of programming, and the internet as you know it, relies heavily on "open-source" projects. That means people have published and shared the code used to create their software. Other people can see how it was made. Alternatively, closed-source would mean you could use and interact with software, but have no idea what's going on inside.
Magic is, for the most part, an open-source world. Through books and videos, the creators of magic are showing and sharing the process they used to create the end result. We get to learn from how they did it, and pick out bits and pieces, or make changes, to suit our own needs.
New routines are developed by building on the source-code created by those who have come before. For my solution I was inspired by the work of Murray Hatfield's "NMBR'D" (2015), which relies on the work of Paul Curry's "A Swindle of Sorts" (1974).
“MVC” is a programming practice which separates the Model (the data, or the “thing” you’re dealing with) from the View (what the end user sees) with a Controller (the logic) in between. It allows for flexible code which can be more easily changed.
In magic we have Effect, Method, and Presentation with a similar relationship. The Effect is the “thing,” the Presentation is what the audience experiences, and the Method is the stuff happening in between.
I started with blank cards and stuck on some numbers.
My creative process depends on looking at this “EMP” as three separate parts which can be swapped in and out. An effect can be achieved using different methods, or a presentation quickly swapped out while keeping the same method and affect.
In this instance I was keeping the method, the “Swindle Shuffle,” but applying it to a modified effect. My “model” became this packet of numbered cards, zero to nine, along with a couple mathematical operators. The goal was to get the cards randomly arranged into an equation that would equal my lock combination number.
My general workflow when programming is to write some code, run the program, and see what errors are generated. It (usually) gives me a specific line of code where the problem occurs, so I’m able to look for the source of the issue, and try to fix it. Code -> Run -> Bugfix. Over and over again, forevermore.
Unfortunately there are a lot of “buggy” magic tricks which still get published. The trick breaks if the audience is watching from the left. The method jams up if it’s too humid.
Having squashed these bugs is what makes a routine “real world” ready. Personally, I’m not comfortable performing a routine which may-or-may-not work right. That means it takes a lot of testing and trial-and-error to get it running without errors.
One big problem with my imagined effect of sorting cards into a mathematical equation was actually figuring out what order the numbers needed to be in to get the result! (or if it was even possible?)
Here’s your challenge:
- You have a set of digits 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
- You have the operators ( x, +, and -) to multiply, add or subtract. I ended up using only 2, since plus and minus would cancel each other out.
- Using no duplicates, how can they be arranged to equal the number 1089?
We’ll use the number 1089 as an example, but the target number could be whatever you need.
I’m not particularly skilled in mathematics, so I had no idea how to solve this problem using my brain. All I could do was trial and error. I shuffle the cards, and see if it happens to work out. Nope!
There are 479 MILLION ways to arrange 12 cards. There’s no way I could do this manually.
This is where my programming-magic metaphor becomes true magic by programming! I employed a computer to simulate millions upon millions of trials to discover which sequences worked out.
5614 x 7 - 38209 = 1089
61 x 358 - 20749 = 1089
681 x 39 - 25470 = 1089
648 x 90 - 57231 = 1089
702 x 54 - 36819 = 1089
69 x 570 - 38241 = 1089
690 x 57 - 38241 = 1089
462 x 87 - 39105 = 1089
6 x 8103 - 47529 = 1089
75 x 429 - 31086 = 1089
3 x 9078 - 26145 = 1089
My little program was able to take a virtual packet of cards, shuffle it randomly, do the math, and see if it matched my target. At the rate of 1 million attempts every 2.6 seconds!
This gave me some options for the final order of cards, but that’s only the half of it. I still needed to get those cards “randomly” shuffled into this order following the process I learned from “NMBR'D.” It’s a combination of real and false mixes to get the starting stack into the “random” order I needed.
Once again, the thought of doing this by trial-and-error seemed like too much, and I was already knee-deep into code, so I made a second program to simulate sorting and give me the dealing/cutting sequence to follow.
This code sample, pictured, shows how the code simulates a DEAL or MIX demonstration of a Swindle Shuffle.
This was a small part of a much more complex process, which took a full 10 seconds to run 1 million simulations. It was pretty good at reverse-engineering the mixing process, trying a few different variations along the way.
For example, here’s a couple sequences which start in different orders, use different moves, but end with the same result.
- Starting Order 
- Insert math cards [9x3047521-86]
- Shuffle: Mix - Deal - Deal - Mix - Deal - Deal - Mix - Deal - Deal [x9307452-186]
- Cut 3 cards from top to bottom [07452-186x93]
- Audience-directed false shuffle (reversing all) [39x681-25470]
- Starting Order 
- In hands mix (2,3,2,3) 
- Insert math cards [704521-86x93]
- Shuffle: Mix - Deal - Deal - Deal - Mix - Deal - Deal - Deal - Deal - Deal [07452-186x93]
- Display without changing order. [07452-186x93]
- Audience-directed false shuffle (reversing all) [39x681-25470]
You may notice, however, that the starting order looks pretty random. It would be much nicer to begin with a set of cards in sequential order. It turns out it was proving particularly challenging to simulate my way back to a perfect start. However, I’ve got dozens of options for final orders, and the ability to run millions of simulations every 10 seconds. I can let it run as long as it takes.
Eventually lightning strikes!
Okay, I have no idea what the odds are of my room full of blind monkeys randomly shuffling their way into new deck order, but it hasn’t happened yet. I’ll update this article if and when I get a successful hit.
The truth is, for my show, I didn’t land on a perfect starting order solution either. I just started with a pre-mixed packet. It’s a “nice to have” thing, but not a necessary feature.
Elegant code uses the fewest keystrokes. Much like a magic routine, the first draft, while functional, may be a bit of a mess of duct tape and bailing wire. It ain’t pretty, but it works.
However, messy code (and routines) are also less useful. They are more difficult to update and adapt, and require more resources to maintain and run.
Programmers go back to refactor their code. They untie the tangled knots they created while solving problems, make things more modular, and generally make things easier to understand.
My creative process in magic is a mess of prototypes and trials, but as it goes from the workshop to the stage things need to be cleaned up. As a “magician in progress” this refactoring is never ending. There is always room for improvement.
This routine was created for a specific show which, for reasons, hasn’t been performed in over two years. As I look upon it with fresh eyes there are a few things I’d like to work on.
In my performance video the mixing (and calculation) process takes three minutes, with a two minute preamble about random number generators. I certainly need to squeeze the dead air out of that. Especially since, in my show, this number is “revealed” as being magical until later in the show, so it doesn’t have a pay-off in that moment. It needs to be snappy!
I’ve also got an idea on how to generate my shuffling sequences in a more efficient manner. Maybe even better at honing in on perfect solutions!
Photo by Drew Monrad