Vko6)Ygbyp8͚dE(a0(U~a%%ٲiG0){x2!%>K&#: )H)4CiI̒yB%꛹Ҋ$(23;}HHnQ|`ITg /$\P0ngԱ:sde>?DA?/ꋳxy[,f#/Y7A#4rRчǦX,j< j/̅ ݗOgj ȿ,<24 "jD+g] HŖG\@vC }D{fiۮFײ0TQBnmpPbitҬԓ$1-kh,1]k$\mkٶ4OcD"` 3 BnQhgt9KlaIuO̗aeR>h&RiEPݲ~M9D]x4DF<뺥0xŸv۶{=ѝ>tGB4Huǀ} 8N'qY1QbPaFg7dDQ-`H.G D1n[ġܠoyP8i_]'Ab֞AK;4@uB Xeբ慾My QN)e"< "|tcџ\WvMcoS+@4 yD4̕„#U.k]sJ>aR`.""+5t }m8g"%KF7=9<Ȗ'y{V,U}"A|Ëf7^XV+.ܶZNguبL]{sX.KtQ~ Z6?;y]2e20U2zw@PȍB*F:^.7]WT%oc> {v %G{(I%~'mOdݖ+[l!fFݏ@4&M\|\a?++7!sOOӚх0,wП spM jFB0]V)Dxf'aNR>>:R/~ƩxOJV.ؔ 0gm|WiX7U, fϜv+SNw:Rwo缌isew,(nMۛ[UTaՊc=hp$*7bE'j4grgTwی%q.

Speculative Physics

Desk Juggling: Designing Players and the Statistical Metagame

by Mendel Schmiedekamp
Mar 26,2003


Desk Juggling: Designing Players and the Statistical Metagame

Desk checking is a term often used in software development. It's meant to imply working through computer code, rather than running it on a computer. While in current times this method is used to help view the inner workings of different software bugs, it was originally developed to cut down on costly failed computer runs. At that time, computational resources weren't cheap. In game design we face a similar dilemma, the best way to verify a game is perform a well developed playtest, a very expensive prospect in terms of man-hours. So to try to repair more glaring problems, it's often necessary to turn to desk checking. But the problem, as with any sort of verification, lies in knowing how you want the game to actually work.

Asking the Wrong Questions

One major problem both with theoretical and experimental verification is a failure to define what a functional game is. Often an attempt to analyze a given mechanic ends up with a debate over whether the mechanic is correct or not. This brings in a wealth of implicit assumptions, while airing very few of them well enough to provide guidelines for further design. Ultimately nearly all mechanics are correct, it's just that some mechanics will be better suited to a given system-setting dynamic than others. A mechanic does what it does. This is neither correct or incorrect, but it depends entirely on the context of the game. Without making that context clear, there is no way to evaluate it's fitness.

For example, in my previous column, I mentioned the unintuitive effects of the power strike feat in d20. Several people commented on various ways to fix the mechanic. Others mentioned reasons why this mechanic had been chosen for this particular niche in the d20 rules. On the other hand, the power strike mechanic is not flawed, it merely is better suited to another form of attack. For example, one better suited to precision, to describe the synergy with smaller weapons.

Evaluating if a mechanic is flawed in it's current placement requires a careful consideration of what it's intended roll in the game is. In this case power strike is a part of a tool box for designing games using the d20 system. For this reason there are two immediate concerns. First, does the mechanic have a general utility. This is clearly the case, so there seems no reason to remove power strike from consideration in designing games using d20. Second, is the mechanic provided in a design friendly format. Here seems to be the fault. As a mechanic power strike is poorly suited to its context. Debate over whether power strike best fits the mechanical niche it was placed in ignores the key question. Is this niche something that needed filling? This is especially worrisome if power strike is the best fit, since it clearly does not do a very good job of expressing a "powerful strike".

Reading Between the Lines

Describing the context of a game is one of the most difficult obstacles in verifying that the game is functional. In order to develop this description, the final goals of a game should be considered. In the case of any recreational game, the most important result is player satisfaction. In RPGs this is still true, although in this case it is important to note that we are concerned with all players, even if the game puts some players under different titles.

A second concern in designing a game is the "in-the-box" enjoyment. Many purchasers of RPGs do not actually play the games they buy, but will incorporate ideas and elements of the game in other games, original or otherwise. This becomes the appeal to a reader, a distinct, but important element of game design.

A third concern is attempting to fulfill a recognized request or need. In some cases the game is being developed for an existing intellectual property, and so must fulfill the expectations of its fan base. Other times a game design project has been placed into a specified set of constraints, usually by the company or individuals who commissioned the game.

This third concern is, typically, easiest to meet. Often the requirements are described, and even if unclear, are at least overt. Further it is often very easy to further clarify the expectations and requirements of either a contractee or a fan base. Making them happy isn't necessarily simple, but it is usually easy to test if you've achieved it. While desk checking can help in testing, it's usually easier to do surveys or direct consultation to alleviate concerns.

The second concern is more complex, but can be verified in three arenas. First, the interest of the potential readers in the subject matter can be determined by polling. Second, the quality of the text can be improved. Lastly, the quality of the visual design can be improved. All of these are vital to meeting this need, but nearly all of this verification can be handled using the methods most literary publishers use these days. This is not meant to belittle these concerns. Production quality, including visual and textual design are very important for RPGs, as they are for all media. But there is very little unique to game design in this respect, so it seems unnecessary to simply repeat sound advice that can be had elsewhere.

The first concern is the real meat of the problem, especially since it is the least understood. Numerous theories of player satisfaction have sprung up in the past few decades. Many go into significant detail, categorizing play types, game types, and elements within the design process. On the whole these are very useful tools, allowing insight in the design of a game. But the natural admonishment follows, be careful when using tools, to know when it's the right time to use them and the right time to leave them aside. After all, "to a man with a hammer, everything looks like a nail."

Gaming the Gamers

One other risk of classifying player types, in order to determine the enjoyment of the game, is that most relationships between games and their players are dynamic. Doing a static comparison by, for example, relating the text of a game to the interests of the player type, often fails to grasp the dynamic nature of the system-setting interaction. A game may appear to promote creativity in terms of player choices, but in fact be very limiting because of how the setting works with the mechanics. A game of this sort could be mis-diagnosed as a large decision space game, and hence appropriate for creative players.

In practice this is what playtesting is used to determine, but alternative methods exist. Perhaps the most potent method for theoretically verifying a game's ability to provide player satisfaction is to simulate actual play. Simulations of this sort need to have two elements kept in mind.

First they need to adequately simulate the running of the game, which is not too difficult, though perhaps time consuming. This process is very similar to running the game proper, although not always identical, especially when the player being examined holds a game position like GM.

And second they need to adequately simulate the player decisions, reactions, and evaluations. It is this last area that most "simulations" lack foundation. Often simulations of game play assume a player style matching that of the tester. This is analogous to using a biased playtest group, except far worse. Often the insights gained in this sort of simulation fail to have any real bearing, especially since few gamers write games they would not enjoy playing themselves.

What is needed is a way to run the second part of this simulation in much the same way as the first. Namely it is essential to enact the role of the appropriate player type during the simulation. Fortunately most games are designed by people who have significant experience in adopting different roles.

This results in a sort of "Ur-Game" which consists of rules for playing players of RPGs.

Cruel Generalizations

In order to design an appropriate Ur-Game, it's first necessary to decide the relevant aspects of players to simulate. There are a variety of elements that can be included, some more difficult to express than others. We easily have as many choices as there are for attributes to reflect combat in a standard RPG, quite likely far more. Why do people enjoy games? Ask anyone and you'll get a different answer, and each of them could be relevant to your design philosophy.

But ultimately, a few key elements need to be chosen. One way to ensure relevance is to choose aspects which you suspect are directly related to the game. In particular, consider those elements of player enjoyment which are directly supported by the game, and also include any natural opposites these might have.

One of the simplest examples, is the desire to be successful in in-game actions. However, few players want to always be successful, so there exists a counteractive desire, one for failure. With too many successes and too few failures the game becomes boring. One way to simulate this accumulation of enjoyment is to decide that in a given chain of successes, the first three add to the enjoyment, the next two have no effect, and any further will be reduce enjoyment, as challenge is perceived to be lost. These numbers are simply based on the idea that after three of anything, you tend to forget the preceding events, so it seems you are consistently succeeding. On the other hand, consider for failure that the first two occur without a cost, but each successive one impairs enjoyment, as the failures take over recent memory.

Using this very simplistic player, we can then try to find a way to maximize its enjoyment using a variety of mechanics.

Which Makes Us Both Winners and Losers

Consider a simple random success method. We make it simple by fixing the chance of success at some value, S. Each action has chance S to succeed, and chance 1 - S to fail.

A naive approach to finding an optimal S, is to make the chance for a string of 6 or more successes, equal to a string of 3 or more failures, in order to minimize both occasions for loss of enjoyment. The chance of the first case, is S^6, the chance of the second is (1 - S)^3. Setting S^6 = (1 - S)^3 is equivalent to S^2 = 1 - S. The solution for S, then, is approximately 0.618. Note, however that this simply reduces the chances of losing enjoyment. It may be possible to gain enjoyment as well. To examine this try setting the chance for getting 4 victories in a row, equal to the chance of getting 2 failures. Working out the equations gives the same answer.

In either case, the result, approximately 3/5, seems counter-intuitive, especially since the optimal sequence of victories and losses is three victories, followed by one loss, repeated indefinitely. This pattern has a 3/4 chance for success, significantly higher than the one we calculated.

Enter the Metagame

Once a model for players is developed, the natural progression is to model a group of players, using a set of rules for interaction. These rules can be quite complex, attempting to put some of the unequal social dynamics that permeates most gaming groups, or can be relatively simple. Perhaps the easiest method to build these interactions on is the idea of limited resources.

With the above player model, two players may not find that they get the same mileage out of a given chance of victory. For example, it's reasonable to suggest that players will notice their friend's victories more than losses. So we can model the interaction as being the total number of victories in a row, while the losses subtract only if a single player has experienced a chain of losses. In this case we are ignoring any sort of synergy between the players, but that is simply to keep the model simpler.

Assuming that the player "trade-off" actions, we find that intuitively the players will derive less enjoyment from the solution to the one player case. Further more, they seem to benefit from a greater chance of loss, since we can afford 4 losses in a row before either player is losing enjoyment. This seems to indicate a chance of success closer to 1/2, since we want to get 4 loses in a row about as often as 4 victories in a row.

Adding additional players will likely cause a further movement in this trend, although it is unlikely for the chance of victory to fall too much more. One simple application of this is that for player enjoyment of a game, it is likely that the challenges should be made more than just proportionately easier with a smaller game group. It also suggests that it may be possible to consider game mechanics which help produce this sort of optimality, either via character creation, or through the mechanic directly.

Ur-Games and Other Questions

Mechanics are often analyzed without a significant idea of what they should do when "correct". Likewise key elements of the game are often ignored due to unconscious bias, either of playtesters or designers who are verifying the games. Bias however is a necessary aspect of any sort of analysis, but explicit bias allows a better picture of the actual game to appear.

For this purpose making explicit assumptions can be used to generate a simple set of mechanics to describe the player element of the game. Calling this an Ur-Game, it is clear that there is a variety of avenues to explore in this sort of verification. Simulation is a powerful tool, as well as one that has been used very little in RPG design. Use it wisely.

Next Month: Example of Desk Juggling: The Homeworld Project

TQo0~^DҒt< ek&Ǿ$\۵ZFȃuwݝIŃU QYir2HR2.u3MFoعq]4#A`pP5(b& )b)ⰾp7(i<[-2gL#5[f g?*rVGf8*)s'+20ϟ̑F}KB<7wSL\gbvm9WiRބYŜvd y0'p2I_Fc2>#o A )VL[Qk?3`)<У[(*W.JH ?tXCt谙 X:@ \0w ~LqĤE-rFkYœj4q 5AQ6[AxG [>w|?( fХθY䝛$c=_qNĦoǸ>O_|&/_Mi7"宥CЧk0dӷLh;TmuCGU-!Ul{ h<\bQX.~"O2*yPcz!ŠGg

What do you think?

Go to forum!\n"; $file = "http://www.rpg.net/$subdir/list2.php?f=$num"; if (readfile($file) == 0) { echo "(0 messages so far)
"; } ?>

Previous columns

Other columns at RPGnet

TQo0~^DҒt< ek&Ǿ$\۵ZFȃuwݝIŃU QYir2HR2.u3MFoعq]4#A`pP5(b& )b)ⰾp7(i<[-2gL#5[f g?*rVGf8*)s'+20ϟ̑F}KB<7wSL\gbvm9WiRބYŜvd y0'p2I_Fc2>#o A )VL[Qk?3`)<У[(*W.JH ?tXCt谙 X:@ \0w ~LqĤE-rFkYœj4q 5AQ6[AxG [>w|?( fХθY䝛$c=_qNĦoǸ>O_|&/_Mi7"宥CЧk0dӷLh;TmuCGU-!Ul{ h<\bQX.~"O2*yPcz!ŠGg