i can see your point completely but if everyone shot their sacred cows i have a feeling that nothing really new or revolutionary would ever really happen

Another one I see a lot is stuff that goes in because of an assumption that's just how games are made.

Most folk design games so they look like other similar games. Attributes are separate from skills which may be separate from innate talents. Why? Because that's how rpgs generally do it. X is done because X is realistic, even though the game may not require realism, may indeed positively require it not to be there. Oceans of 1980s game design falls into this. Most games then strove for realism, some though only strove for realism because most of the others were.

Indie games often have dice pools, why? My guess is because other indy games have dice pools, it's another assumption of how things should be based on how others are doing them. But an indy game could potentially use a flat single die, percentiles, roll under or over, but time and again I see dice pools. Assumptions.

The best games throw those out. Sorceror doesn't look much like most other games. OtE certainly doesn't (though it has obvious inspirations). Castle Falkenstein throws out assumptions by the bucketload.

But most don't. People sit down and work out what kind of dice pool they will use or what attributes and skills will be needed, without first asking whether they need dice pools or even dice and whether attribute and skill separation are remotely relevant.

Hello,

The above two posts were split from Shooting sacred cows.

Best,
Ron

Ron Edwards wrote: Hello,

The above two posts were split from Shooting sacred cows.

Best,
Ron

Balbinus wrote: Did I go off topic? I thought I was following on from thoughts in the initial post.

Ah, thanks. I thought it was a current one and hadn't realised.

Not sure the dice pool point was made, though it is an example rather than the point itself. It seemed to me that the thread had got rather bogged down with discussion of how tough writing was, whereas Valamir's original point seemed to me more about sacred cows which could actually get in the way of actual game design.

Hence the thing about assumptions of what a game should look like, IMO one of the strongest obstacles to good game design that designers face. Most Fantasy Heartbreakers IMO owe a good deal of what is wrong to assumptions about what a game is and what it's contents should include.

Just as a point of reference, Balbinus did not ressurrect the thread. "thereformant" did. So, fear not, Balbinus, you've managed to postpone that day when you find out what arcane rituals of evil we perform on thread-resurrectors.

Thanks Paganini,

Is there anything much to say now though? I hadn't realised this was a done topic when I saw the previous thread. If anyone wishes to respond to my point that's cool and I welcome whatever points they have but otherwise I wonder if this should be allowed to rest in peace.

The thread is dead, long live the thread!

Seriously, Balbinus, I'd like to take your idea a step farther. The trend doesn't just occur because *RPGs* are designed a certain way. You see the same thing with d20 products, Storyteller, Silhouette and all the other "Home Systems" out there. The designers shoehorn in all the basic elements because "That's what our house system requires" without thinking first about the needs of the game they're writing. The most eggregious examples I can think of off the top of my head are the varying uses for Willpower in the Storyteller games and the almost compulsive need for new prestige classes every time a d20 book comes out.

I think this sort of thing really hurts the professional games. It's a lot of needless bulk added when it comes to a supplement to a single system, and it's just laziness when they come out with a new game.

The dice pool and skills/traits examples make me wonder a bit...

How certain are you that this is an assumption, and not merely a preference?
A lot of games use dice pools, indy or otherwise. Perhaps I lot of people just like dice pools.

My game system (which I didn't design by myself, but which I had a good deal of influence over) uses dice pools, but it certainly didn't come from any assumption that it needed to. (In fact it was based on an outline of what I wanted it to accomplish rather than what mechanics it should include) Dice pools just happen to work well.
But would you have any way to realize that, or would you just be making assumptions about my "assumptions"?

I also have both skills and attributes in my game. They reflect different things that are only sometimes related. For instance, fighting is a skill. Just because you are strong or graceful doesn't necessarily mean you fight well. Just because you fight well doesn't necessarily mean you're strong or graceful. But having seperate skills and attributes allows the use of your fighting skill to be influenced by your natural strength or grace.
On the other hand, performing an action doesn't necessarily mean someone's using a skill (hence "unskilled labor"), so many task resolutions would be inappropriate for basing on a skill, rather they resolve based solely on an attribute. You don't need a skill to pick up a heavy rock or break down a door. All you need is a strong back or rugged shoulder.
This is the way I prefer the mechanic to work, not an assumption that it has to work this way. But again it sounds like it might get dismissed as such.

This is something I've wondered about a few times.
How much of what is written off as "assumptions" is actually something the designer just might have thought twice about and simply used a method similar to many other people's choices because it was the best choice in their view, or even just a personal preference for a particular way of doing things?

I question whether making the assumption that every game that does things similarly to a common method does so because to the designer's "assumptions", isn't at least as invalid as the supposed "assumptions" being targeted in the first place.

To be clear, I'm not attacking anyone's viewpoint. Everyone is entitled to their own opinion of course. But I do question the reasoning behind many of these statements about "assumptions".

Madelf, I think the cry of "Assumption! Assumption!" is usually based on the accompanying game text, rather than the actual mechanics themselves. If you take V:TM frex, the text is full of assumptions. Most of the time when people post ideas to IGD that contain repetitions of common RPG design techniques, the first reaction is not to cry "Assumption!" but to find out if it's an assumption. Ralp and Mike, for example are constantly asking the question, "Why did you decide on this way? Was it just because other games do it? If so, you might want to rethink."

Paganini wrote: Madelf, I think the cry of "Assumption! Assumption!" is usually based on the accompanying game text, rather than the actual mechanics themselves. If you take V:TM frex, the text is full of assumptions. Most of the time when people post ideas to IGD that contain repetitions of common RPG design techniques, the first reaction is not to cry "Assumption!" but to find out if it's an assumption. Ralp and Mike, for example are constantly asking the question, "Why did you decide on this way? Was it just because other games do it? If so, you might want to rethink."

As far as what assumptions and how to identify them, that' sa big hairy deal. It's too late for me to even try, tonight. ;)

But, from a game design perspective, there's always the question of whether or not an existing game can do what you already do. Should you modify an existing game, or design a new one? It might be that attributes and skills and classes really are what you want. But, you better have a good reason that your attributes and skills and classes are more interesting or focused or something than the umpteen other systems out there with the same construct. If your game uses the same mechanics as the game that people already have, why would they switch to yours? What makes it special?

I don't know about all this questioning. I mean, a current technique might not be perfect, but does it have to be? I think the important thing is to question those things which are just bad for you, just as if you suddenly realised your an alcholic or gambler, you might realise that the slueth system your building shouldn't really focus on such a big combat system, and should actually have skills. Avoid the unhealthy and self destructive stuff.

Also, in terms of valamirs original post, he was talking about how he was struggling on with an idea that had become dead weight. Although the technique was fine, it just was dragging him away from what he wanted to do. I don't think one should decide all things should be questioned, some are okay. The trick is, in certain contexts, okay technique becomes really unhealthy technique.

Then again, perhaps I'm questioning questioning.

I think that the D20 argument fits in here. Why are people reputedly attracted t D20? because that way they don't have to relearn a different system each time that you change settings.

I think the same can be said about certain rule sacred cows. They do the job, they're immediately familiar, they don't really suck and there's little to be gained from shooting those sacred cows.

While sacred cows are dangerous I actually think that the converse; being different for the sake of being different, is also a problem.

Mr. Analytical, the problem with saying "it's so they don't have to relearn the system" is that the statement isn't true. Feats, prestige classes and basic classes are part of the system. Feats are all just little rules, and there sure heck doesn't seem a lot of thought that goes into them. Classes and prestige classes are rules, too, and again a lot get tossed in there. Why? Every d20 book puts in these little rules and you have to track them somehow. It's not as bad as Shadowrun or Rolemaster, where rules you need to play the game are scattered across half a dozen books, but this stuff does burden players at character creation and at least every couple of levels.

Death from a thousand cuts? Straw that broke the camel's back? Not sure which one is right, here :)

I can't believe that every d20 book needs a handful of prestige classes to communicate its theme. The only possible reason they're there is that designers think "This is kinda cool" and throw it in. That's great as far as it goes, but this stuff can go too far (open up some "Rifts" books if you don't believe me). Heck, a lot of the new feats and classes kind of suck if you ask me.

Precious Villain wrote: Mr. Analytical, the problem with saying "it's so they don't have to relearn the system" is that the statement isn't true. Feats, prestige classes and basic classes are part of the system.

Precious Villain wrote: Mr. Analytical, the problem with saying "it's so they don't have to relearn the system" is that the statement isn't true. Feats, prestige classes and basic classes are part of the system. Feats are all just little rules, and there sure heck doesn't seem a lot of thought that goes into them. Classes and prestige classes are rules, too, and again a lot get tossed in there. Why? Every d20 book puts in these little rules and you have to track them somehow. It's not as bad as Shadowrun or Rolemaster, where rules you need to play the game are scattered across half a dozen books, but this stuff does burden players at character creation and at least every couple of levels.

Death from a thousand cuts? Straw that broke the camel's back? Not sure which one is right, here :)

I can't believe that every d20 book needs a handful of prestige classes to communicate its theme. The only possible reason they're there is that designers think "This is kinda cool" and throw it in. That's great as far as it goes, but this stuff can go too far (open up some "Rifts" books if you don't believe me). Heck, a lot of the new feats and classes kind of suck if you ask me.

Mr. Analytical,

I believe I see your point now. The drawback of having rules that don't quite fit is worth it if those rules have some other virtue. On balance, d20 is superior in a lot of respects. However, very few of the "spinoff" games use d20 straight from the box. They've all got little tweaks and changes.

Now that doesn't invalidate your basic point! It's still easier to learn a new d20 game by just looking at a handful of differences. But it also supports my point: you've got to look at all the elements of d20 and decide which of them really fit YOUR game and which are there because they've always been there. I feel that the balance tends to fall on the side of inertia/tradition/whatever. However, you are right that it's not going to hurt these games much.

MadElf,

My point was that it's there because everyone else puts it there. It can be optional and still fit that description.

Mr. Analytical's point (by the way, what's your name?) is significant; and I think that it goes deeper than it appears.

If you tell me that you're using dice pools, all I really know is that I have to roll a handful of dice to find out what happens. I've played with dice pools, and I don't find them objectionable in play; but I think they're a designer's nightmare. You've got multiple variables--how many dice, how many sides, what target number, and how many successes are the obvious ones, but there are others such as whether there are botches. Beyond that, you can have opposed and unopposed pools, and the opposed pools can be handled several different ways (high wins after ties are eliminated, each pair represents win/loss/tie, ties go to defender, et cetera). Thus if I play your dice pool game, I have to learn how it is that you use the dice pool.

There's another step to it, though. If I play your game, when I come back next week or next month or next year to play again, I'm going to have to remember the nuances of how you did it. I don't always remember some of the nuances of games I played regularly for years. The more different you make your game, the more difficult it's going to be for me to remember, and the greater the bar against repeat play.

That's an argument for using things already familiar to your players, and varying them in very limited and rather obvious ways.

I'm not disagreeing with the execution of cows (although our Hindu friends might prefer we find a different metaphor); but Analytical is right to recognize that familiarity can be an important feature in a game design.

--M. J. Young

My point was that it's there because everyone else puts it there. It can be optional and still fit that description.

If you tell me that you're using dice pools, all I really know is that I have to roll a handful of dice to find out what happens. I've played with dice pools, and I don't find them objectionable in play; but I think they're a designer's nightmare. You've got multiple variables--how many dice, how many sides, what target number, and how many successes are the obvious ones, but there are others such as whether there are botches. Beyond that, you can have opposed and unopposed pools, and the opposed pools can be handled several different ways (high wins after ties are eliminated, each pair represents win/loss/tie, ties go to defender, et cetera). Thus if I play your dice pool game, I have to learn how it is that you use the dice pool.

M. J. Young wrote: Mr. Analytical's point (by the way, what's your name?) is significant; and I think that it goes deeper than it appears.

[SNIP]

I'm not disagreeing with the execution of cows (although our Hindu friends might prefer we find a different metaphor); but Analytical is right to recognize that familiarity can be an important feature in a game design.