Before I start recommending development methods for Longest Game entries, I figured I should describe them first. What follows is an incomplete list of tools for development:

Analytical Methods:

  • Calculate Probability – this is directly calculating the probability of different outcomes and ensuring that those meet your design goals. This method works best when the piece you are analyzing is entirely random, such as a die mechanic, a sequence of card draws, or the intersection of simple probabilities.
  • Estimate Biases – since games are played by humans (for the most part), you don’t just want to know what the actual likelihoods are, but you can use some of the research on statistical heuristics and biases to estimate how a person will perceive those uncertain events in play.
  • Statistical Players – many games have the outcomes heavily depend on player choices, whether revealed or hidden. This can provide intractable for a direct probability analysis, unless you first model the players as statistical decision makers – turning some archetypal play strategies into automatic or weighted random selections among the options. Statistical players can be a powerful tool to enable solitaire testing of parts of your game (see below).
  • Game Theory Methods – another way to handle player choice is to consider strategies and outcomes in a simple game. However, game theory works best in cases with definite, quantitative outcomes and a fixed number of decisions.

Experimental Methods:

  • Experimental Probability – with or without statistical players, you can repeat procedures of your game to determine the actual outcome likelihoods. There are two ways to do this, using a computer lets you run a huge number of tests quickly, but doing it by hand also tells you about things like how long and how mentally intensive your procedure is.
  • Pocket Testing – repeatedly performing any procedure¬† or other fixed section in your game’s life cycle can tell you more than probability, it can help you determine the enjoyment level and mental and creative effort of the procedure and can help you refine it in isolation. This can be done with live players, statistical players, or if your game permits in a regular solitaire mode.
  • Solitaire Testing – the easiest way to test a game in a protracted solitaire is if the game naturally supports it, otherwise statistical players are a powerful tool to enable it.
  • General Play Testing – this is what we normally think of as play testing. How much you get out of play testing often depends on the clarity of your goals in testing and your metrics, i.e. how the game is reported and measured.

Each of these methods is intended to give you useful data on how your game works and what might improve it. Always be careful about being clear in your goals for each method, and not compromising those along the way. For example, if you want to test your text understand-ability, explaining procedures to players during that test will undermine that goal. However, if you wanted to test those procedures than it is better to make sure they are followed correctly regardless of the text.

I introduced and discussed the concept of Pheonix Bound earlier. Now on to the subsystems.

Pheonix Bound has three major subsystems:

  • Collaborative creation of characters (including antagonists)
  • Semi-random situation generation
  • Blind-bidding task resolution using a fixed set of cards

The collaborative creation of characters works by listing categories for each body and enemy on index cards and then passing them around in a circle to fill out one answer at a time. This sort of approach is pretty popular at present for collaborative setting creation, but could benefit from a bit more guidance to spur creativity. If that guidance can also be a random table to act as an extra player, so much the better.

The situation generation is done by having the players decided what mundane task their phoenix is doing and (in classic maho shoujo style it appears) the GM randomly determines if today an enemy will appear and if so, which enemy. This harkens back to random encounters in D&D, but its important to note that random encounters work because they exist in the context of progress (typically travel). As I noted earlier, this game needs a goal for the phoenix in protecting her charge. This is one of the most important reasons – if the enemies don’t attack some sort of progress needs to be made to counter-point the danger. Otherwise there is really no tension in whether there is an attack or not, only marking time until it occurs.

The last, and arguably most unique, subsystem is the blind-bidding task resolution. This is done by playing a card from a small hand initially containing the numbers 2 through 10 (one hand for the GM and one for each player). I originally disliked this mechanic much more, but considering how the random situation draws also come from the GMs deck – and hence help to balance a large number of enemy occurrences by eating up high cards or conversely a period of quiet causing a reduced number of low cards. Likewise, the need for players to take some losses to clear the bad cards in their hand in order to redraw a new hand is also potentially interesting. The problem is there is only one mechanical consequence for the lower bid, other than the task failing, at least immediately – if your opponent doubles your bid you can be killed. This is too much, if you play your two you are already almost certainly going to lose, but now you are also almost certainly going to die – unless you weasel it into a non-lethal task situation. Instead there should be concessions or other impacts of failing your side of a task and those could lead to defeat or death, of you or your charge, but it shouldn’t depend on the amount you lose by. One possibility that comes to mind is a first to three wins, where the phoenix and the enemy can have a few setbacks before losing their goal for the day. In any case, this means wrapping this task mechanic into a wider conflict mechanic to determine the outcome of the enemy’s assault.

In my next feedback burst I’m going to talk about development tools which may help Phoenix Bound and some of the ways things can be tested with and without playtesting.

I’m trying to get back to the Longest Game participants, but its likely to be slow going at this point. Today I’m starting with Phoenix Bound by Samuel Purdy.

Phoenix Bound is a game where the players are phoenixes reborn into recently deceased bodies to protect something that person cared deeply for during life. Arrayed against the phoenixes are forces of the Shadowlands. When a phoenix is pushed against the ropes they can tap fully into their mystical powers, but begin to burn through their body. When they leave their body they emerge as full phoenix for a short while before passing to a different recently deceased body.

To my mind this expresses the root of what is compelling about phoenix bound. On one hand a phoenix is reborn and is called to do so by tapping into her spiritual might. On the other she is compelled to protect, and perhaps do even more, her body’s most cherished person, place or thing. But this whole situation becomes less compelling if the only reason the charge needs the phoenix’s help is because the phoenix is there in the first place and is attracting the forces of the shadowlands.

One of the important parts about long form games is that the players get the chance to change the world. This is not just creative collaboration of what the world is, but through effort, cunning, and sacrifice coming leaving the world different in ways that re-emerge in the future. In that vein, I suspect what Phoenix Bound needs is to heighten the responsibility of the phoenixes, not just to protect someone or something, but to complete an unfinished goal or enable a personal transformation during the short span the phoenix gets to persist in the body. This would mean that a player can look at each cycle and see what was accomplished and what fell short. And the consequences of these outcomes are then available to be reincorporated in future collaborative creations of lives, enemies, and situations.

In my next feedback burst, I’ll be delving into some of the sub-systems in Phoenix Bound: collaborative setting creation, random situation creation, and the blind bidding.

Campaign length games are pretty uncommon among Indie community games, I’d like to see that change.

The Premise: Design a game meant to be played in regular sessions over the course of one or more years with an Indie community sensibility to it, meaning that your game should have a system that matters, and matters in new ways over the course of months and years of play.

The Challenges: To spur your creativity and make this challenge more interesting, I’ve worked out five challenges. You must pick at least one challenge as part of your design, but you can attempt as many as you like, even all five. These are also the criteria under which the games will be judged.

  • Flexible Footprint Challenge – a common criticism of long form games is that they represent a significant social footprint, requiring folks to commit to regularly attending many sessions over months and years with each other. The challenge here is to turn this on its head, being flexible about who attends, how long the sessions can be, and the ways in which players can contribute to the game, all to adapt to changes in player lives and schedules.
  • No Advancement Challenge – the most common campaign arc for RPGs is the advancement arc where characters accumulate power, wealth, or skill over many play sessions. The challenge here is to not fall back to this approach, to let characters change but not to simply make them better, but keeping an engaging evolution.
  • Indie Extrapolation Challenge – hacking one game to build the foundation of another is an essential part of the Indie community. The challenge here is to take a short form Indie community game and build and translate from it into game which spans a year or longer, while still retaining some of the essential nature of the original game.
  • Self-Transforming Challenge – during long form games the rules of play often evolve as the players build their own play culture, often solidifying into traditions and house rules. The challenge here is to support the evolution of your game into a system unique to the particular group, while keeping this transformation from coming to an end or hurting the player’s enjoyment of the game.
  • Pure Innovation Challenge – some folks look down on innovation for its own sake, I don’t. The challenge here is to discover or re-discover largely unexplored design territory within your game, while still making sure your game works.

The Ingredients: In addition to the challenges here are four terms to use in inspiring your game. For the initial draft, choose at least three and for the revised draft you must keep at least one of these ingredients.

  • Fever
  • Tree
  • Occupation
  • Fool

Milestones: As a departure from most design challenges in recent years, the Longest Game occurs over two months, February and March. In February you will come up with your design inspiration and write a basic, albeit possibly incomplete draft of your design. During March you will develop your game, doing micro-playtests and other analyses to understand what your game does and to decide which parts might work and which definitely do not. By the end of March, you complete a revised draft, ready to be playtested for its full-length. Along the way I (and others if they wish) will be helping you by providing feedback and assisting in development where possible.

  • February 1st – The Challenge Begins
  • February 15th – Deadline for Game Summaries: a 30-second plug line, a brief description of what play looks like, and a brief plan for the system. If you get yours in by this point, I’ll get back to you with feedback on it by the next weekend (in person if you’ll be at Dreamation).
  • February 28th – Initial Drafts
  • March 15th – Development and Micro-Playtesting Reports: let us know how your development process is going and where you need help.
  • March 31st – Revised Draft, ready for proper playtesting

Erasure

August 9, 2007

Many games, especially ones that tell a story involve the addition of ideas or contributions till a certain mass is gained and the story continues. Consider turning that idea on its head. Design a game based on erasure, where periodically a rich spread of ideas and elements are made available, and then the players work together to trim and prune the possibilities into what the story becomes.