Phoenix Bound does not currently have elements which require extremely protracted playtesting. This could change if the impact of a phoenix in the lives of their charges contributes to a long term goal or become intertwined over the course of play. Even so, there are several parts of Phoenix Bound which could benefit from simpler development tools prior to proper playtesting.

The two most crucial elements of Pheonix Bound that can be tested and refined on their own is the collaborative setting creation and the task resolution mechanic. In the first case, the setting creation system is entirely quantitative so testing it requires multiple players willing to add creative inputs. I suggest testing this for a few round with a willing group before a full playtest to ensure that there is enough guidance and structure and that the procedure produces the desired styles of setting for the game. Otherwise problems in this system could disrupt and taint the results of several full playtest sessions.

The task resolution mechanic, which involves choosing cards from a deck involves too many player decisions to reduce to simple probabilities. However, in systems like this it is often useful to consider a statistical player who simply plays a random card from the remainder of the cards they have available. By simply repeatedly resolving against such a “player” it is possible to estimate the impact of counting or not counting cards, as well as other intermediate strategies. It will also give a reasonable idea how often the deadly – you get twice or more than your opponent – outcomes actually occur among the different ways to play. I suspect this will reveal card counting makes enough of a difference to become necessary for the players, which may be more mental load for a task resolution mechanic than suits this game.

At its root Phoenix Bound is an interesting game about supernatural champions. I suspect that by delving further into what it means to protect and guide your charge an even more compelling game can be created. But, ultimately the proof is in the testing.

Advertisements

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.

I should have known better when setting up this design and development challenge. What with computers going belly-up, work deadlines getting de-railed, and double whammy work travel I’ve been too swamped to lend my attention to the games and ideas folks have been talking about in this challenge.

And I really want to be able to give feedback and suggest development tools to use, since these games are often much more difficult to develop. At this point, I doubt I’ll be able to give much time to things the beginning of April.

So, I am extending the challenge, with the development progress report suggested on or around April 17th, and the revised drafts due at the end of the month.

I’ve been reviewing the blurbs you all have posted and I realized that the best feedback I can give in this challenge is to offer methods and ideas for developing and testing your game. While the idea of playtesting early and often is seriously good advice, a dozen multi-year playtests interspersed with redesigns requires a tremendous amount of patience and focus. Fortunately, there are numerous ways to test outside of the full scope, while still giving you valuable information: desk-checking solitaire techniques, micro-playtests, cognitive science analyses of event distributions. These work like computer modelling and wind tunnels do for aeronautic design, valuable tools before putting in the expense and effort of the full test flight. I want to offer what I hope will be useful suggestions in how to decompose and attack your game so you can make some real progress over next month.

Which is a good deal more effort on my part than just saying what I like about each blurb. Unfortunately, illness and work deadlines have thrown a spanner into my own planned deadline. in giving feedback. Still, I expect to be rolling out those discussions over the next few days.

I see there are many ideas percolating for long term gaming. You can post or link your Game Summary here or on the Google+ community I’ve set up to discuss designs.

And don’t forget to let me know if you want to discuss your game in person at Dreamation next week.