blog.lukenoonan.com

Recently I have finally started using Blender (& Substance Painter) in earnest. I am starting to get a pipeline in place and have been doing all of the 3D art for the most recent RUST project. I wanted share a couple of insights that I picked up through this process.

Learning through osmosis works (to a degree)

As I have picked up these tools and had concrete goals in mind. (i.e. “make this specific model”) I have been getting better at it much faster than I thought I would. I actually credit this to having spent many, many, hours watching Anton model, and talking to him about the process. I wouldn’t say that I “learned” how to model through that process but I think it supplied me with a ton of information that is just recently getting connected with actual practice.

More Tools

“Give a small boy a hammer, and he will find that everything he encounters needs pounding.”

Looking back to earlier points in my career, the above quote by Abraham Kaplan seems comically relevant. I spent many years working on 3d games before I had any significant facility with a 3d modeling package. Not to toot my own horn but I am really good at getting shit working in unity. But looking back, some of the shit I spent hours getting working was just to avoid spending ten minutes modeling anything. For example; recently I needed to build a pointer for use in the game. because everything is stereoscopic 3D the way you do this is with a very thin piece of geo, like a cylinder. Unity has a primitive shape that is a cylinder but the origin point of it is the center. So, to use this you need to find the center point half way between the start and end of your pointer. Then do a bit of the angular math to get everything lined up and then scale up the object on the correct axis to the distance between your two end points.  Or is it half the length… I can never remember.

Now that I can fire up Blender and put together a cylinder with the origin at one end, rather than the middle, everything gets easier. Just place it on the object doing the pointing, pull the distance to the target from your selection raycast, and set the scale of the object to match. As a bonus, since you are drawing this thing half a centimeter wide you can specify a much lighter cylinder mesh than the built in one for unity.

The point here is that by expanding my toolbox I opened up my options for solving a given dev problem. The pointer “problem” has many solutions, but 10 minutes in Blender is better than the tedious programming solution.

Bottlenecks

Very few projects of any scale can be accomplished solo. Nothing kills the inertia of a project more than having to put everything on hold while you wait on something from a team mate. The broader your skills are, the less likely you are to get bottlenecked.  On the prototype I am currently working on, there are various points of the programming/dev process where I need feedback from my co-designer. The thing is, he is 9 time zones away. Being able to switch gears to get some modeling done while I wait for him to get to the office means that I can stay productive.

It is also really important for what I would call the “Emotional inertia” of a project. It is much easier to stay emotionally positive about a project when you are seeing regular progress. Often on the programming/development side of things one might spend hours doing necessary, but ultimately not-very-flashy bug fixes and improvements. “…well now it does exactly the same thing but won’t break in this eventual edge case” Being able to switch over bang out some art lets you rest your exhausted programming brain muscles and produces some more visible changes in the project. For me at least this helps me keep excited about it.

So I gave a talk at Unite 2016. I’m pretty pleased with how it came out.

“In C” by Terry Riley is a special piece to me. It  was one of the most important works in forming my creative practice.

In the piece Riley specifies 53 short phrases. Performers in the ensemble are to start at the the first phrase and start repeating it at tempo. Individually they each decide when it is time to continue on to the next phrase in the set. When they decide they move on to the second phrase in the set and start repeating that one. As the ensemble moves through this progression of phrases the overall sound shifts through a number of different textures and polyrhythms. When a performer gets to the final phrase they hold there until all of the performers reach the end, then the ensemble does a unified crescendo and decrescendo and then ends.

Why is this piece so compelling

In short, I find the way it uses algorithms and chance, to be amazing. The use of procedural algorithms in music composition is a common thing. Just looking at the musical staff, quantized discrete notes, Who could blame a composer for getting a little math-y? Some schools of composition, like Schoenberg’s twelve-tone technique and the rest of the Serialists used algorithmic operations fairly explicitly. It is easy to see something a like a symphony for the giant math puzzle it is. (I bet you could write an entire book on set theory using nothing but key signatures and theme & variation as examples.)

The use of chance operations, while less common, can be found through the history of western music. The “Musikalisches Würfelspiel” (German for “Musical Dice Game”) asked players to roll dice to arrange various sections of a composition. The most famous of these was supposedly written by Mozart. More recently we can see the work of John Cage and many of the computer musicians that followed as pushing the limits of chance in sonic compositions.

In C is built on a particularly elegant set of algorithms. One of the core challenges in generative and algorithmic art is constructing your processes so that they take you in interesting places but don’t spin out of control. It does this in a number of ways but I think the most interesting is they way it engages the performer’s judgement and intuition in the algorithm. Players must decide when to advance and when to hold on a phrase.

“Patterns are to be played consecutively with each performer having the freedom to determine how many times he or she will repeat each pattern before moving on to the next.”

They are encouraged to listen to the ensemble and modulate what they are playing based on what they are hearing.

“it is very important that performers listen very carefully to one another and this means occasionally to drop out and listen. […] The group should aim to merge into a unison at least once or twice during the performance. At the same time, if the players seem to be consistently too much in the same alignment of a pattern, they should try shifting their alignment by an eighth note or quarter note with what’s going on in the rest of the ensemble.”

Riley uses the player’s intuition as a self correcting pressure. As a creator who designs algorithmic art that is mostly executed by machines, the ambiguity in this score seems truly brilliant.

Infinite-C

Infinite-C is my loving interpretation of Riley’s “In C” In it I created an ensemble of 12 AI to play In C. While I had to take a couple of liberties and diverged from the initial instructions a bit I would say it Infinte C is a pretty straightforward interpretation of the original.

Process

First I tracked down a copy of the original score, which was pretty easy to do online. Then I transcribed it into Muse Score. Then I had to export each phrase as a midi clip being careful to maintain any rests in the phrase. From there I pulled them into Ableton Live and rendered out each phrase in each of the 4 voices of a string quartet.

With the stack of 200+ phrase clips I moved over to Unity and started assembling the scene. I built each AI performer to pick a duration to loop the current phrase for. after each repetition of the phrase they check to see if it is time for them to switch to the next phrase. I set the duration of to be within the 45-60 seconds that Riley suggested in the note for the original score.

When it came to the appearance and number of performers, I tried a number of different configurations. Initially I had four performers, to test the four different voices. The original performer notes called for 30-40 performers. When I tried that many it really just seemed to muddy up the sound. This may have to do with Unity’s audio implementation or it may have been how I rendered out the phrases. In the end I settled on 12 as enough to get the original compositions textural variations without getting muddy. Each of the performers appear as a pulsing column of colored light. This not only gave me a chance to use a recent new Alloy feature, the “tube lights”, but it also seemed appropriately minimal. I actually turned off rendering on the ground plane and just left two large metal spheres to in the middle of the ensemble to reflect the shifting lightscape generated by the performers.

I was pretty pleased with most of the project but I was still left with what sort of interaction(s) I wanted between the player and the performers. I played with a couple of ideas but in the end decided to let the player wander around the space taking the role of a conductor of sorts. The player can walk up to each performer and direct them to play louder or softer. I also wanted a more subtle interplay between the player and the performers so I slowed down the timers, though not the playback, of each of the performers based on distance from the player. This means that if a player hangs near one part of the ensemble they will hold on each section longer. I felt like this relationship seemed a reasonable substitute for the effect each performer had on each other.

After some playtesting, I decided to give the performers some color. I wanted an appropriately minimal way to give the user a little more feedback as to where in the performance they were temporally. I mapped the saturation of the color of the performers light to the volume they are playing. I mapped the hue to the position in the performance. This resulted in a wonderfully slow color shift which gave each part of the piece a distinctive visual feel to go with its sonic feel.

Reflections

This project was, first and foremost an experiment, a small one at that. I have been ranting about the state of game audio for the past couple of years, to lots of people in my circle. It’s not that it is bad, I am often somewhat intimidated by the amazing virtuosity I see in the game audio community. Rather, it is kinda boring. It just feel like game audio has ignored all the most interesting parts of the past 50 years of computer music. Videogames are not linear albums, yet we keep treating them like one. They are necessarily running on powerful computers that can do all kinds of cool stuff, but it feels like the most interesting thing you ever hear is dynamic layering, (“when you get to the boss fight … we turn on the drum track”) It seems like the game audio community (with some notable exceptions) hasn’t even done the “easy obvious stuff” yet.

So all this being said, how do I feel about the project? Overall I would call it a success. I think that the aesthetic results of the app are pretty compelling. Of course it sounds good, Riley knew what he was doing.

So if anything, this experiment showed me the value in getting off my ass and doing the “easy obvious stuff” myself. Infinite-C was not a big risk. I took a 50 year old score, of a well regarded piece of minimalist music, and turned it into a minimalist virtual space. Infinite-C was only a tiny little step but importantly, it staked out a staked out a little more of the territory I want to explore. If nothing else, I like how it sounds.

[this post originally appeared over on the RUST LTD. blog]

In the previous post I talked about the initial development of 1887 as part of my MFA thesis. Like many of the games from that period of my life, I had shelved 1887 to make way for other projects. As anyone who has done a graduate degree will tell you, once you are able to finally stop working on a previously all consuming thesis/dissertation project, it can be difficult to go back. This was worse for me because I had mostly left the academic life. Most games I had worked on during my MFA were interesting from an academic perspective but not all that compelling otherwise.

So last year I found myself chatting with my friend Marc ( @destem ) about working on a project together. I was pitching a couple of projects I had been mulling over but didn’t have time to work on. Among other ideas I pitched doing a digital version of 1887. It wasn’t a project I had thought much about.  It did have a couple of things going for it:

• It wouldn’t take a ton of art assets to get rolling. This was  good because neither of us are game art people.
• I thought it might be fun to work on the AI with Marc. Besides being a game designer he also studies stuff like Cognitive Science, Psychology and Computer Science. (Working on designing AI with someone like that sounded like my kind of good time.)

Multiple Pieces

Later that day Marc came back to me with a working prototype. That prototype had a little surprise. Instead of one piece per player there were two. I don’t remember exactly what Marc said when I pointed that out but it was something like “it seemed like there should be two”. As I played the prototype, I realized that having options for which piece to move dramatically increased the strategic depth. It gave the player approximately double the available moves and allowed for new tactics. I was a little embarrassed that the initial version of 1887 didn’t feature multiple pieces per player. That is the nice thing about working with other designers, sometimes it takes a fresh set of eyes to see the obvious.

The way Marc designed the system allowed for an arbitrary number of players on either side. Throughout the process of development and re-development that design pattern has persisted. Over the course of development I would test boards with more or less pieces.  I would also try asymmetric setups in which one player has more than the other. So far, the only time that these other setups have proven useful has been for tutorial maps.

Tree mechanic

A few days after the initial prototype I was thinking about the tactical possibilities that having multiple pieces afforded. One idea bubbled to the surface of a situation where one of a players pieces would get stuck and the other could come and free it. The forest tile mechanic is what I came up with. Here is how they work:

1. A player can not land on a forest tile.
2. When a player settles a tile which is next to a forest, it causes the forest to become a field.

This mechanic succeed in creating the rescue situations I had imagined. It also created some other cool ones. For example, sometimes you can manage to trap an opponent against a row of forests only to realize that if you move one of your pieces you will clear some of those forests and free them. Those are the type of interesting situations I am interested in creating for my players.

Development

Over the next couple of weeks development continued. I started thinking about what would be necessary to get this project from prototype to complete salable game. The prospect of writing the AI for the game sounded like fun so my plan was to have a “campaign mode”.  In this mode you would play against bots on a pre-determined sequence of maps. Local multiplayer was already working so that was an obvious choice. Online multiplayer was also something we were considering.

One of my major concerns when it came to this sort of scoping was the issues that multiplayer indie games run into. For example, I bought my copy of Nidhogg at launch but have only gotten to play it a couple of times for lack of willing friends. (wow that sounded sad … ). Even online multiplayer can be difficult to manage because you need a critical mass of players to maintain a community, and that can be difficult to create without a big marketing budget. Toward that end I was nervous to launch a game without enough content to entertain our friendless players. I wanted to make sure the game would still work with a small user base. Also, network multiplayer can be an intimidating prospect development wise.

It was with all these thoughts rolling around in my head that I came up with the idea of Puzzle mode. Puzzle mode would be a single player mode where the player attempts to cover as much of the board as possible before she gets stuck. Given the way we had architected things it was easy to put together a single player map. The first batch of playtesters seemed to love that mode. You know you are onto something when they wouldn’t give me back the tablet. Adding in the puzzle mode seemed to round out the game modes nicely.

In the next section I will talk about what inspired the Railhead redesign and what has happened since. If you want to keep up to date on Railhead news and development you should head over to the Railheadgame.com and sign up for the mailing list and follow the Railhead twitter account.

[this post originally appeared over on the RUST LTD. blog]

We recently announced a new game called Railhead. While I am super excited to share this project I wanted to start by talking about its history. Part of what excites me about this project is that it has actually been years in the making. Railhead started its existence years ago as part of my MFA thesis research. It was originally a traditional board game called 1887. In this post I am going to talk about its original inspiration and early development.

I was inspired by seeing a bunch of little wooden house tokens that had spilled onto a chessboard in one of the labs. Something about the mixture of scales spoke to me. For a game designer like myself the chessboard is an intoxicating artifact. The geometry of a chessboard, its 8×8 grid of alternating black and white cells, allows for staggering number of permutations. Rule permutations, movement permutations, board permutations. It is the perfect physical realization of two dimensional cartesian space. In chess the board represents a figurative or literal battlefield, occupied by 32 military units. Something about seeing the house token, dwarfed by the single cell it sat on, forced me to see the scale of the board differently. What if each tile didn’t hold a single person. What if each cell was a plot of land where a family lived. In that moment the board went from a battlefield to a landscape.

A lot of my design research at the time was in thinking about notions of space and control. How do we control space? In Civ and other strategy games you typically construct a building and your sphere of control spills across the board like a overturned bucket of paint. You own that territory. You are the only one who can build there. You are the only one who can move your troops there without starting a war. While it works well enough for these sort of strategy games, this “state boarder” notion of space is pretty alien to most peoples daily existence.

The national border I grew up next to was a friendly one but it happened to be aligned with a river and a bunch of lakes. The first time I encountered an international border crossing that wasn’t on a bridge, I was struck by how simple and plain it seemed. It was just a small checkpoint on a highway.  If I wanted to I could have parked down the road, gotten out of my car, and hiked to Canada. The only problem was actually, that if I was hiking in the woods I would not have been able to tell when I crossed over. There was no multicolored lines on the ground showing where one country ended and the other started. There are some borders where that is that case, where the lines are marked with fences or rivers or “demilitarized zones”. In general it is pretty hard to see these lines out in the world.

Practically, we tend to control space via access. We occupy space and deny others access to space. Me, my family and my guests are allowed to occupy the space I own. In some limited circumstances, police or emergency workers can gain access to it, everyone else is denied. What is it that makes a piece of land part of a nation? Citizens and guests of that nation can go there. Everyone else can bugger off and go someplace else.

1887 is a game about mobility. I had already been experimenting with the notion of a game predicated on manipulation of access to space. An earlier board game I had worked on used the mechanic, but turned out to be a generally boring game. In 1887 the idea crystallized, as you move you leave a trail of settled cells behind you. Cells which can no longer be occupied. The goal is simple: trap your opponent, prevent them from moving, while leaving yourself movement options. The last player to move wins.

Thinking about the image of a little homestead on a big flat landscape made me think of the American West. A couple days of reading lead me to the title “1887” In the late 1800’s Americans were in the process of “settling” the great plains. Importantly this was the decline of the cowboys. Huge parts of the countryside that were historically “open range” meaning anyone could graze cattle there, were being divvied up and settled by homesteaders coming from the east. As the rail lines extended further and further across the continent and brought more and more homesteaders, the “wild west” became increasingly domesticated, and crowded.

At points in the late 1880’s armed conflict actually broke out between private militias over issues of grazing and water rights. 1887 was the height of these “range wars”. This is where the name of the board game came from. The enclosure of the American West changed that landscape in a profound way. As a nod to the cowboys and to the game of chess I used a chess knight as the player piece. Besides looking like a horse, the knight is the chess piece most oriented toward tactical mobility. It can jump other pieces and is the hardest to pin down.

The expending of cells on the board, along with the narrative framing also brought in elements of environmental conservation. The policies of American manifest destiny was not just people moving to new parts of a continent. It was an entire nation waging war on the native populations and ecosystems. America chewed up and digested a continent. Those resources positioned America as a world power, but as we see with the current droughts over a hundred years later, the damage to the landscape has yet to be fully comprehended.

In 1887 both players start with a shared mutual resource, the board. They then have to burn that resource to stop the other player from moving. Positioning and struggling over an ever diminishing amount of space. Often at the end of the game there are only a couple of open spaces left. When a player ‘wins’ it is rarely by much.

In the context of my thesis work, 1887 was well received. I showed and demoed it at a number of events and the feedback was almost entirely positive. Most of the designs I worked on during that period were shelved as I traveled and worked to get RUST off the ground and paying the rent. It wasn’t until a couple of years later that development continued.

In the next section I will talk about bringing 1887 to a digital format and what the initial months of that development taught me. If you want to keep up to date on Railhead news and development you should head over to the Railheadgame.com and sign up for the mailing list.

If you are interested in playing the original version of 1887 you can download the rule sheet here I would love to hear any comments and feedback you have.

A few months ago a couple of articles bubbled up on Marilyn vos Savant and her famous analysis of the “Monty Hall Problem”. Never being one to shy away from a famous puzzle, I sat down and tried to intuit my way though it. When I failed to do that, I started talking to my friends about it. Since most of my friends are all either game designers or people who married/date/hang out with game designers we ended up creating a bunch of alternate scenarios. I don’t know how helpful they were but I did find them entertaining so I thought I would share them.

Variation 0: “The Original Monty Hall Problem”

You are going on a game show hosted by Monty Hall. The grand prize, a Cadillac, is behind one of three closed doors. The other two of the doors both have a goat behind it. (In this scenario you would really like a car and don’t like goats.)

First you are asked to pick one of the doors. Then Monty, who knows what is behind each of the doors, opens up one of the two doors you didn’t pick revealing a goat. Finally you are given the opportunity to either “stay” and get what ever was behind the door you initially chose, or “switch” and get whatever was behind the other unopened door. What is the best strategy to win the car?

So the intuitive answer is “it doesn’t matter you have a 50/50 shot” and that is wrong. The correct and counter intuitive answer that earned vos Savant decades of abuse is “always switch”, which yields a 2/3’s chance of getting the car.

The permutation space is small enough that we can actually just use counting to prove vos Savant correct. In the chart below I enumerated all the possibilities for car placement and initial player choice. I also showed what the result of either switching or staying would be in each case.

If we total up the Switch column we see that there are 3 goats and 6 cars. The stay column, predictably, has the inverse.

After reading though this explanation I saw that vos Savant was correct. It still didn’t make any sense to me. So I started coming up with other similar situations to see if any of them might help my understanding.

Variation 1: “The Marvin Hall Problem”

In this variation the game show industry is not what it used to be. The studio has hit some hard times and the quality of employees have gone down hill. Monty quit a couple of years ago, so now his slacker step brother Marvin Hall is hosting. You show up for the game and one of the stage hands left the middle door open and you can see there is a goat behind it.

Marvin: “God dammit Steve, you had ONE F****** JOB! … [takes a deep breath and turns to you]… Just pick one of the other two and I can still catch happy hour”

You: “ummm door A”

Marvin: “Now do you want to keep it or switch?”

Aside from the smell of cigarettes coming form Marvin’s polyester suit, this situation seems pretty similar to the original. You are still staring at a goat and choosing between two closed doors, one with a goat and one with a car. What is the ideal strategy?

We can see it is a 50/50 shot either way.

Variation 2: “The Jay & Kay Problem”

In this variation you are playing the original version and after you made your initial selection, Monty reveals a goat behind the middle door. Then an alien come running out from stage left and moments later explodes into a blue gooey mess. Once the smoke clears  Tommy Lee Jones and Will Smith stand up from where they had been sitting in the audience and explain all about aliens and stuff. Once the goo is cleaned up they get the audience’s attention and neuralize everyone.

At this point Monty turns to you:

Monty: “I don’t remember which one you picked”

You: “Neither do I”

Monty: “Well, which one would you like?”

At this point we are at the Marvin Hall Problem yielding a 50/50 shot. But, if Will Smith leans in to you on his way out and says “You picked door A” then you would be back to the original Monty Hall Problem and your best bet is to switch to door C.

Variation 3: “The Howie D Problem”

After the success of “Lets Make a Deal” and “The Newlyweds Game” network execs announce a new gameshow called “Trust Me!” hosted by Howie “Howie D.” Dorough of the Backstreet Boys. In this show a team of two tries to win a Cadillac. You and your college roommate get a chance to compete.

The show starts with you in the “Booth of Silence” where you can’t see or hear anything else that is going on. While you are in the booth your roommate is presented with three doors, one has a car and the other two have goats. Your roommate chooses one of the doors and Howie D. opens one of the other doors revealing a goat. Then your roommate is sent to his own Booth of Silence and you are brought to the stage.

At this point Howie D. gives you two options: either trust your roommate and go with his choice or to ignore your roommates choice and pick between one of the remaining choices, without knowing what your roommate chose. Which option will maximize your chances of getting the car?

First lets look at what your odds are if you choose to trust your roommate:

We see that you end up with a one in three chance of winning.

Now lets look at what our odds are if you choose not to trust you roommate and select one of the two closed doors at random. For the sake of space lets say Monty revealed a goat behind second door:

We can see that the coin toss yields a 50/50 shot at the car. Which means you should never trust your roommate.

Variation 4: “The Double Cadillac Problem”

In this variation there are 4 doors, two with Goats and two with Cadillacs. You pick one, and Monty reveals a goat in one of the other doors. You can then choose to stay with your original choice or to switch to one of the other closed doors. Staying has 1/2 chance of getting a car while switching has 2/3 chance. Always switch.

If however Monty revealed a Cadillac instead of a goat, that would give switching 1/3 chance. So if Monty shows you a car, stick with your initial choice.

Variation 5: “The Chauffeur Problem”

You don’t have a driver’s license, and you don’t own a car. You are presented with three sets, each with two doors and you get to choose one set and keep what’s behind both doors of the set.

• One set has a Cadillac behind each door. (This does you no good since you can’t drive)
• Behind another there are two drivers. (This does you no good since you don’t have a car)
• Behind the third there is a Cadillac and a driver. (This is perfect)

You pick Set A. Monty flips a coin and opens one of the two doors revealing a Cadillac. What are the odds you are still taking the bus home after the show?

The intuitive answer to this would be that since you know you didn’t get the set with both of the drivers, there is a  50/50 chance that you got the one you need. This is wrong.

First lets look at our three doors:

Now we can see all of our options:

Since we saw that the revealed option was a car we can remove all the other options, which leaves us with the following:

We can see that there is a 2/3 chance that you will be taking the bus home. This is actually a re-skin of another famous puzzle called the Bertrand’s Box paradox.

This was a game that my Dad showed me years ago.

Rules

Materials: It is played on normal graph paper with a pen or pencil. It works best with 1-4 players

Setup: You draw a race track on the board.

• There needs to be starting line.
• It has to fit on the paper.
• You usually want it to have a loop.

Other than those, there are no real rules about what the track looks like. After you play a few races you will get a sense of what will be a fun track.

Play: Players start by marking their car’s place on the starting line. A car sits on a grid intersection, and they can occupy the same intersection. We would usually give each player a different symbol or use differently colored pens.

At the start of the race, each car starts with a speed of (0,0). On each turn the car can accelerate or decelerate by one unit on each axis, which changes it’s speed. At the end of the turn your car moves according to its speed. Here is an example showing movement:

Players take turns. On each turn a player moves his or her car by marking its new position and drawing a line between the new position and the previous position.

If you cross the line and go off the track you “crash” and are either out of the race or forced to restart, burning some time.

Winning: When a player crosses the finish line the rest of the players are allowed one more turn to try and finish. Once the rest of the players have had their turns and the player with the car the farthest over the finish line is the winner.

Thoughts:

I really love the lines that this game generates. The curves seem like plausible paths for a car or motorcycle. At the end of the game they seem to tell the story of the whole race. Unlike board or card games, Pen & Paper games like this one often serve as their own “analytics” system. In the image above we can see that Blue was driving much more conservatively, while orange was recklessly overshooting the turns and nearly crashed into the outside wall on the last turn.  You can almost hear the orange driver saying “oh crap, oh crap oh crap” as she slams on the breaks.

Another thing I really like about this game is that is works just as well as a single player game as is does a 4 player game. You can play against the clock to see if you can make it around the track without crashing in a few turns as possible.

When I started writing this post I decided to poke around the internet to see if any other versions of this game existed. I was pleasantly surprised to find that it not only has a decent sized Wikipedia page, but it has been around since at least the 1960’s and everyone else’s rules seem pretty close to the ones I learned. There were even links to online versions.

For a long time I have had a particular curiosity with games that are played entirely by talking. There are lots of games that involve language, or text, or even talking+other stuff, but I am referring to games that are made up almost entirely of wordplay. Games that don’t need Scrabble tiles or a condemned stick figure drawn on a chalkboard. These are games which are in some fundamental way about language, specifically the spoken language.

They come in a variety of different flavors.

• Constrained Speech: Where you have to speak without using certain words/sounds/letters (ex. speak only using two syllable words)
• Messing with Strangers: These are language games played amongst an unsuspecting public (ex. see how long you can fake an accent while talking to a stranger on the train)
• Lexical Gymnastics: Games that exploit the quirks and nuances of the language being spoken. (puns are likely the simplest form of this sort of play)
• Trivia/Brain Teasers: Games that rely on a mess of external knowledge or other mental abilities (ex. mental chess or 20 Questions)

I plan on doing a series of posts that highlight the “talking games” that I have come across. I don’t know exactly how many I will do or how in depth I will get with them, but I am excited to see what sorts of conversations they may start. One of the first games I ever helped to design (that was ever played by anyone not in the room with me 😉 ) was a word game that I would place in the “Lexical Gymnastics” category.

Name:

Synonym/Homonym

How to play:

Play starts mid conversation when one player speaks a word or phrase.

“… just like the balloons in Mario Kart”

the second player repeats the phrase and makes a suggested change typically by changing it to something that has a similar meaning  (synonym) or something that sounds similar (homonym):

“Mario Kart OR Mario Andretti Racing Experience?”

The first player takes the suggestion and makes a further suggestion:

“Mario Andretti Racing Experience OR The Jimi Hendrix Experience?”

The second player then responds:

“The Jimi Hendrix Experience OR Deep Purple?”

This back and forth can go on for quite a while. Different groups have different endings. In the original games we always ended with a shot at George Bush. (“Teaching monkeys to talk OR the State of the Union Address”)

History

This game started in a high school history class with a good friend of mine. Originally we started riffing off something that was said in class but before long the game would spontaneously break out in random conversations. A few months later, we happened to play a round in front of my dad, who is a lover of wordplay. Once we explained the previously unspoken rules, he joined right in. Rounds of this game almost always started spontaneously and would often suck in everyone in the room. I have found that playing with 3-4 people was actually a bit easier. You could wait to jump in with a response when you had a particularly good play.

Over time the game spread through parts of my friends and family. More than a few games broke out at the dinner table. As I played with various people over the years it became fascinating to see the differences in how it was played. In many groups the obligatory George Bush joke was dropped. Given the varied literacies of players, the density and flavor of cultural references was always different between groups. Even the tone shifted. In some groups the game had a competitive vibe of one-upmanship and in other groups the game has a much more collaborative feel. Games involving my little sister usually took a psychedelic turn as she would famously make strange poetic associations while the rest of us were busy making political jokes.

Pair Solitaire is a delightfully simple game which was released a couple of weeks ago on iOS (and eventually Android).  Designed by Vitaliy Zlotskiy and featuring audio by Shannon Mason the game has a “instant classic” feel to it. I could just imagine my grandmother teaching it to be at her kitchen table with a physical deck of cards.

After a few dozen games on a recent flight I decided I was going to:

1. Do an analysis of the game, and 
2. Teach my grandmother how to play with a physical deck of cards (likely at her kitchen table)

How to play

When you start a game you are presented with a stack of playing cards.

Pair Solitaire 1

The goal is to clear as many cards as possible. You can clear a card it it is exactly one card away from another card that matches it in rank or suit. so in the example screenshot you could clear the 7♣ because it is one away from another club (the 9♣). When you clear a card it goes away and the stack compresses. The game ends when you can’t clear any more cards.  You get a score that is based on which cards you cleared, with higher ranks being worth more points, and a multiplier which is based on how many total cards you cleared.

Beatability

Without knowing the developers or decompiling the source code I can’t tell for sure but it looks like each game is a randomly dealt stack of cards. My first questions were about beatability.

1. Can any stack be beaten?
2. Can every stack be beaten?

Answering the first question the first one was pretty obvious. I played a bunch of games and eventually got it down to two cards. There was one additional multiplier thingie so I would assume that if your final two cards matched you would get a perfect score.

The next question is a little trickier to answer. I have played plenty of games I failed to win. But in theory I might have been able to beat it had I played differently. To answer this I tried to find an initial shuffle that would have no possible matches.

If I was dealt this stack, I would 100% not be able to beat it.

It is possible that the game is not using a pure shuffle. They could be filtering out un-beatable shuffles or constructing the stack not via a shuffle algorithm.

Solver

The next step, naturally, was to write an auto solver. My goal here was to see if I could write a program that could generate or input a sequence and output a series of moves which, if possible, beats the game.

I wrote a recursive solver in a couple of languages. Here is the relevant parts of the C# version:

I represent the deck as an array of integers.  The checkStack()  function accepts an array of integers (which encode the rank and suit) and, if appropriate, it ‘makes a match’ (ie. remove the card from the array) and calls itself with the smaller array. It exits if there are no matches to be made.

If there are no matches to be made because it got to the end of the stack. It returns the string “end” which triggers the upstream functions to collate the sequence of moves that cleared the stack. If it exits because there are no moves left without winning, it returns an empty string which pops up the chain and continues the recursive search.

This is a pretty brute force approach. Assuming I implemented it correctly, it will find a winning solution if one exists. The problem is that so far I haven’t managed to run it long enough for it to finish.

Stack Generator

As I wrote earlier, I don’t know how the stacks are being created. I decided to work up a few ways that the stacks could be generated.

Pure shuffle

This method is pretty simple. It works just like a physical deck of cards. You start out with an array of all 52 cards shuffle the cards. In my solver I used Fischer Yates shuffle to generate the stack. This approach has the advantage of being simple to implement and pretty cheap computationally.

The downside of this approach is that, as we established above it will sometimes produce un-beatable card arrangements. As a designer this wouldn’t bother me but I could imagine wanting to guarantee a beatable stack so that if a skilled player would always have an opportunity to win.  If I wanted to make sure the stack was always beatable I would likely try one of the following approaches.

Filtered shuffle

This approach is the obvious but dumb approach.

1. Do a pure shuffle
2. Run a solver to see if it is beatable
3. If it is not beatable, go to 1
4. Otherwise you have a beatable stack

This approach has a few problems. First off we don’t have a solver that doesn’t take days to finish so each game would take a long time to start.

Setting aside that problem, even if we had some magical function that told us if the stack was beatable, this approach is technically still not guaranteed to finish. I don’t know how many of the possible arrangements of the deck are beatable but the random shuffle could keep randomly spitting out bad ones indefinitely. Practically speaking, this means that this algorithm could take milliseconds or it could take minutes. Since locking up the CPU on a mobile device for that long would likely crash it, and would also get it rejected form the app stores, this approach is not advisable.

Perfect Sequence

This approach is aims to generate a sequence with at least one way to beat it. That way we know that every stack is technically beatable.

You start with all of the 2’s in the deck (you could start with any rank)

At this point the stack is completely solvable. For the next step you randomly pick another card from the set of remaining cards (lets say 9♣) and starting from the front you find the first spot that it would fit and still leave a beatable stack. In this example it would be between the 2♥ and the 2♠.

At this step the stack is still beatable. ( 9♣ -> then the 2’s)

If our next random card was a K♦ it would land between the 2♠ and 2♣

At this step the stack is beatable. (K♦ -> 9♣ -> then the 2’s)

This would continue until the entire deck is built. At every step of the process the stack is beatable. We can see that it produces stacks that have multiple solutions. If we look at the stack:

You could play: 2♥ > K♦ > 9♣ ... or  K♦ > 9♣ > 2♥... and both would work. We can see that it also sets up failure states. You could select the 2♣ first and not be able to remove the 9♣. When designing these sort of systems it is important to check to see if you are making your puzzles trivially easy.

We can also see that from a performance perspective, this “Perfect Sequence” method is totally reasonable. It runs in linear time and since we could implement it without crazy stuff like recursion, it should have a tiny memory footprint.

Why do this sort of analysis?

As a working designer/developer with a company to run, why do this sort of analysis on someone else’s game?

One of the nice things about getting some years of experience under your belt is that you start to assemble a tool chest of design patterns. When you encounter a situation like ABC, one way to solve it is XYZ. This tool chest can make the design/development process easier and faster which is great. The risk is that you can slip into using those tools in situations when they might be sub optimal. This can send your design work into a rut where your design starts to feel same-y.

Doing this sort of analysis, besides being a fun brain teaser, helps to add new tools to the tool chest. It also gives me an opportunities to try my existing design patterns in novel situations. I see it as a way to “cross pollinate” my design practice without stating new side projects.  I may never need to write a stack generator for Pair Solitaire but the approach of working backward through the game to make sure every step works could be useful in all sorts of other puzzle games. I may not have much use of an automatic solver but it is useful to think about the next time I need to write a hint system or AI.

Grandma Analysis

I ended up showing my Grandma the game on my iPad while I was home for the holidays. She got it right away, and the first game we played together broke my previous high score. 🙂