Simulations in simulationist games

[Kielan]

Hello Forge,

This is my first post here, so apologies if I get your terminology wrong, or if someone has posted something like this in the past and you've all discussed it to death. I've recently published a role-playing game as a hobby project, which I guess qualifies me as an "indie RPG designer" (it's called Hexicon Fantasy RPG by the way). Actually, given that I didn't discover this site until the final stages of the process, and had no idea quite how many other people do indie game design, I think my full title ought to be "very naïve indie RPG designer" but there you go. When I read the article on fantasy heartbreakers it made me chuckle and cringe in equal measures. And of course rejoice that with all those other games out of the way the time was now ripe for a serious attempt at fantasy RPG world domination. Or should that be fantasising RPG world domination.

Anyway, onto the point of the post. First I have to give a very little bit of background about the Hexicon system, which really is necessary for the serious design point that follows but may incidentally serve to advertise the game (it being mere coincidence that while Hexicon is already on sale in the UK, it will also appear in .pdf form on RPGnow on or around April 1st).

Hexicon is, I think, what you would call simulationist. It doesn't attempt to define any particular style of play, but is clearly old school in its basic fantasy pedigree and has a detailed combat system with fine-grain temporal resolution. We offer a few things free to download (e.g. the obligatory character generation software), and my co-author Dan has been working on a combat engine to supplement this. Initially, Dan thought that this would be useful for GMs dealing with big battles with lots of NPCs. The idea was that the GM could just set battles running between NPCs, then return to them from time to time to see how they were going and describe events to the players.

This software isn't ready yet, but it has got me thinking about the potential of simulations in simulationist gaming systems. Let me explain what I mean. Say I take this combat programme and get it to run a combat between two opponents. Next, I stick this combat in a loop and get the programme to run it 1000 times. I can then get some sort of summary statistic, such as "creature X wins 78% of the time". Now the first couple of things this might help with are quite straightforward:

1) Hexicon has a bestiary chapter, but if anyone buys the game we'll almost certainly end up writing a fuller supplement to pad this out. Lots of bestiary supplements have a rough index of how tough creature are, but with a software tool like the one I've described we could give much more objective stats, e.g. "creature X will beat a typical party of four 10,000 EP characters 75% of the time, will lose but kill one character 12% of the time..." etc. etc. We can't say for sure what will happen in any given game, but at least GMs can't say we didn't do our homework in producing a rating.

2) Following on, any GM who is planning a violent encounter and producing some NPCs will also be able to test in advance what the likely outcomes will be.  If it turns out that there's a 90% chance the party will get slaughtered, it might be worth making a few adjustments and running the simulation again (or laughing manically and planning the follow up for any survivors).

It's beginning to look like this simulation software could be quite a useful tool, but I think there may be more you could do with simulations. In fact, I think it might have been useful to produce this software right at the start of the design process, not right at the end. Hexicon kind of evolved as a game over a number of years. I came up with some rules, we tried them out, we scrapped the bits we didn't like and worked on the bits we liked and so forth. I guess a lot of games get made that way. Of course, there were lots of important issues that got fleshed out along the way. For example, Hexicon has got a fairly deadly combat system that can leave even advanced characters dead from a single blow. Like most combat systems, outcomes are a mixture of skill and luck, but where is the balance? How much difference does ten gaming sessions of accumulated experience have on the outcome of a fight? Is it better to wear heavy armour and move slowly or to go for light protection and remain manoeuvrable? The key point is, you can find out how a system answers these sorts of questions with simulations. Perhaps more importantly, you can then tweak the system to produce the sort of balance you, as a designer, actually want. For any combat system that involves more than a few dice rolls, this is very difficult to work out analytically in advance. Rather than spending a few years in playtesting to achieve your design goals, you can spend a few hours at your PC.

Now consider some other questions you might ask when designing a game. Many games have mechanics where you use points of some kind to purchase improvements for your character. In Hexicon, for example, you can use EPs to boost skills, learn spells and so forth. How does a designer balance the different advantages you can buy? I imagine for most systems these sorts of costs are set based on an educated guess and a bit of playtesting. By using a simulation, you could establish just how much increasing particular attributes helps a character out, and use this knowledge to balance the costs. Or unbalance them, if you like; the point is, you could make informed decisions during design.

Obviously there are a lot of limitations to this kind of approach. Simulations will only apply to particular aspects of roleplaying, and many of the improvements on offer may be outside the scope of what your programme simulates (e.g. balancing an increase in the damage a character inflicts against the ability to communicate in another language). I've only talked about simulating combat, probably the easiest part of game play to simulate, and even there you need to make a lot of assumptions about the decisions that combatants make. Nonetheless, I wonder if there is there mileage in this sort of approach to game design? I'd be interested in your thoughts.

Cheers,

Kielan.

[Mike Holmes]

Welcome to The Forge, Kielan. Somehow you got "lucky" enough to draw me to your first post. I tend to be a tad forthright, so don't interperet the following as be being dismissive. It's just how I operate when discussing.


As a statistician, myself, I can certainly apreciate your concept. I think that there are some cases where the usefulness of the data that a simulation is warranted. But I think that, like all statistics, they're only as useful as the assumptions that spawn them.

Many game designs these days overcome some of the obstacles that your statistics would try to solve simply by not posing the problems in the first place. For example, is it really OK to have even only a 10% chance to die in a particular encounter (nevermind the 90% you pose)? If you use this as a benchmark, then by the time you've gotten to 7 encounters, the party has less than a 50% chance of being alive. This is the problem with many fantasy hearbreakers. In order to make it so that characters can live to be "high level" either the GM must fudge a lot, or the odds of winnig a fight have to be 99%. At that rate, the characters have a 50% chance of making it past 66 combats.

Check out your progression rates to see how many combats it takes at these odds to advance. 66 might be light for many games. Certainly for D&D, it's a low figure to get to high level.

Now, the problem is one of two things:
1. Your players can improve their odds by good play, in which case, the statistics you produce will probably not show the results of said good play (as you say, hard to guage for this). Or
2. They can't increase their odds which, in addition of being synonymous with having eliminated gamism, the odds of winning each combat have to be so high that there can't possibly be any tension to the fights in terms of winning or losing.

Basically you're stuck with the age-old dilemma of character continuity vs. combat tension, when combat relies on potential character death as the loss condition. So your tool is only going to tell the GM how problematic this is. He'll have to choose boring or character death (which is also boring).

With the game Hero Quest, for instance, you eliminate the problem by eliminating character death as the neccessary loss condition of losing a fight. This is the point at which one typically protests that combat can't be "realisitic" or "dramatic" without the possibility of character death. Yet I and many other people play HQ, and love it - I'd say the combats are better than D&D and such.

The point is that, basically, HQ doesn't need the simulation tool, because there's no problem to be solved by it. You can literally throw any size opponent at your players, and the results of the conflict are always fun. Not only do you not need the simulation to come up with accurate "Challenge Ratings", you don't need the ratings at all.

Now, HQ's solution might not suit you. But the point remains that I think that there are far more elegant solutions to the problem of coming up with ways to make "balancing" encounters non-problematic from the start. So that's where I'd start, personally. Not with coming up with tools to analyze the problem, but with a way to eliminate it altogether.

Does that mean that the sort of statistical analysis that you talk about isn't useful ever? No, there are probably places where it can be used. I'm just not seeing any here.

Mike

[Kielan]

Okay, I take your point regarding the role of character death in a gaming system. I suspect that discussion has been had elsewhere, so the only point I'll make is that while systems like HeroQuest (which I must admit I've never played) clearly have an audience, systems where characters die also have an audience, and that may not just a matter of habit. Aside from producing a feeling of tension during the game, when I reminisce with friends I've roleplayed with over the years, we often end up laughing hysterically about the ways in which particular characters met their grizzly ends. If you accept that some people do want to play this kind of game (as opposed to simply not having experienced the alternative) then surely any tool which helps the GM work out how deadly encounters actually are is useful? At the very least, it can inform them about whether to provide alternative routes to avoid particular combats. I don't think that many systems actually require you to fight in order to advance your character do they? This approach is just an extension of having knowledge about how dangerous it is to do things in the game world. If scaling a sheer cliff has a 50% chance of death, you might not want to place five sheer cliffs on the only route towards completing the adventure, at least not without giving the characters a chance to get some rope first.

That said, what about the alternative design uses I mentioned? When designing a combat system, simulations could be used to tweak the rules to fit your design ideas. For example, you might believe that taking on a swordsman unarmed is an extremely difficult fight (a fairly realistic proposition) but then again you might want to produce a game in which having weapons doesn't make much difference (as per a wushu film). Or simulations could be used to balance the cost of improvements, albeit only those improvements that affect what you are modelling, i.e. combat. I accept this is all premised on combat being a key feature of your game, but I don't think that's such an outrageous concept for a lot of roleplayers. Most roleplaying reproduces genres from popular action films and books, and there are not too many of these which don't have any fights in them. Anyway, as a broader level I'm sure it's possible to define an alternative outcome (other then character death) and model that if you so wished.

Cheers,

Kielan.

[Mike Holmes]

I was afraid that you'd read my comments this way.

I'm not saying "don't have character death." I'm saying that there are likely other ways around the question of calculating character mortality chances that might improve the game while not requiring programming solutions in order to provide the GM with a reasonable way to create proper challenges in adventures.

OK, I'm going to propose another solution, and one that's ridiculous, just so you don't think that I'm actually suggesting that you use it. The object of this excercise is to show how you can get around the problem without having to use the solution that you propose. So, for example, if you have a combat system in which the result of combat is to roll a d6 and get under a particular number, say 5, then you can "simulate" the results easily, right? That is, you know that the character will survive 66% of the time, so you can easily calculate the odds of survival in the long term without resorting to a simulation (you could run the simulation, but it would just tell you what the simple math tells you already - the simulation is just doing the math).

Now, if you say, "But Mike, that's too simple a system nobody would like it," then you've missed the point. I'm not saying "don't have death, or don't have complicated rules." I'm saying that if you do some deep thinking about your system, I'll bet you can come up with a way to improve the system that both makes it more of those things you want from it, while also managing to make it easier to use at the same time.

How to do that with a real example? Well, I'm not designing the game myself, so I'm not going to even try to do this. I'm not saying it's easy. I'm saying I think it's a design challenge that you should take on yourself. Because why should I play your game, and have to download the simulation software, and program it with the characters and encounters for each time, when I could play, for instance, D&D that already has the challenge ratings worked out? Because the D&D challenge ratings don't work well? Well, true, but D&D is the least innovative of games that I could mention, most do even better than that in most ways. I can mention many games where the "lethality" indexes are even better related than D&D.

Take TROS, for instance - that game has lethality galore, all sorts of combat detail (few games take combat to as detailed a level for combat), and yet all I have to do to check out how dangerous a combatant is to another is to compare their Combat Pool size and perhaps strength or armor. etc. And better yet, I can count on Spiritual Attributes to make the contest as dramatic as I need it to be. Other systems have similarly innovative systems. Will any of these other systems that don't include the programming ever account for all of the permutations possible in actual play or with responses by players with certain characters? No, but then, as you admit, neither will your software.

(Interestingly, this all said, TROS does have a simulator. It's just used to play, not for statistics.)

My point is that you're avoiding system innovation, and just putting in what seems to be a better tool for implementing the less innovative methods to substitute. It's like putting a V8 in a Ford Pinto. It'll still drive like a Ford Pinto. Want to make some real money? Put the D&D assumptions into your program, and sell it as an aid for D&D. Want to sell a game to players? Create some innovation that makes it so that the game doesn't require such a tool.


As to your suggestion that the simulator can be used for design...well, I think you're using the scattershot method again. That is, yes, you can design a game where the percentages will all finally come out the way you want them - or you can start with what you want as an outcome, and work back to how to get there in the rules. Working from this sort of assumption, I find that the mechanics that people come up with are more "foolproof." That is, you don't even have to check the odds on the outcomes, because every outcome is one that enhances play. The system simply can't produce bad outcomes no matter what you throw at it. Again, as an example, you just can't "break" Hero Quest that I've seen. I'm sure that the did a little playtesting to make sure that the results weren't so wild as to be incomprehensible, but otherwise, it just wasn't neccessary to look at the precise percentages, I'm sure.


If your question is, "given these very limited assumptions, is a simulator a good tool" well, yeah, I'd agree with you. Again, I even kinda like the idea, from a programmer POV. It's simply the assumptions that I have some trouble with. If you're absolutely sure about your assumptions, then don't listen to me, and do up the simulator.

Mike