new system needs plagiarism check

[Aaron M. Sturgill]

hello, all. I'm yet another aspiring writer, whose game is nearing completion -- or, at least nearing the stage where I can show it to people. but before that happens, I need to check to see how many people have done this before, or are currently doing it. (how embarrassing for two people to release two identical systems at the same time.)

in my search for non-dice randomizers, I came upon the local craft store, which sells fairly inexpensive bags of variously-colored glass beads, often used as bedding for flower pots and aquariums, I believe. put these in a bag, and you have an infinitely-customizable randomizer. if you keep the total number of beads at a multiple of one hundred, you can easily predict the probability percentage of each given outcome.

for example: my ability tree uses the FUDGE scale: -3 to +3, with 0 being average. for an ability test, the player draws one bead from the bag, and adjusts his ability score based on the color of the bead. (seven levels, seven colors of beads, or modifiers.)

so. sound familiar to anyone?

[Eero Tuovinen]

Sure, I've done my share of stone-draw mechanics. Last time was in IGC: Fantasy, where I had a pretty powerful mechanic centered on giving stone colors meanings and then utilizing them for narration. As players could add in stones and such shenaginans, the system did quite a lot more than just replacing dice.

You shouldn't use the word plagiarism so lightly, by the by; if you are plagiarizing something, you should stop, and if you aren't, there's no way anything we are saying  would change your work into a plagiarization. The worst that can happen is that you publish something that's not very original, but that's hardly a crime. Plagiarizing is a condition of your own volition, so you are pretty much the only one who can say if you do it. It seems to me that you're not talking about that at all.

[Remko]

I think it would be better to use the word "Originality" as opposed to plagliarism. I bet you would like to know if you can claim your system to be 'one of the few' or 'the only' that uses this type of randomness (for whatever reason... personally, I'd say it's more important to yourself whether you've thaught of it and from my experience is pretty rare to use such a system).

Other thougths: pretty cool mechanism (Eero, your mechanism is also pretty cool... can it be that I've seen it in some Iron Game Chef Competition entry?).

[Aaron M. Sturgill]

Thanks, Euro and Remko. 'Originality' is definitely more appropriate, and you're right -- I'm really only concerned with whether or not I thought of it, independently of others' input.

Like I said, I'll be posting samples and/or a URL when I have them ready. Right now, I'm in the middle of the initial playtest phase, so there's mucho re-writing going on. . . .

[Aaron M. Sturgill]

[More of which I thought while trying to sleep. . . .] Euro, your IGC: Fantasy system sounds very intruiging, and a lot like something I toyed with doing at first, with the various colors of stones. But in particular, I was wondering how common it is to strictly replace dice with the stone-draw mechanic, to allow for (as I mentioned) customizable probability. . . specifically, using the FUDGE scale for base attributes.

Maybe this is too specific, and/or something that not many people care about. But I'm curious.

[Eero Tuovinen]

Yep, I've relinquished myself to being Euro here. Simply can't help it. Just don't expect me to start worrying about the stability of the currency.

But in particular, I was wondering how common it is to strictly replace dice with the stone-draw mechanic, to allow for (as I mentioned) customizable probability. . . specifically, using the FUDGE scale for base attributes.

I can't say that I've seen that specific combination before. Certainly any stone-draw game utilizes probabilities at least implicitly, but putting FUDGE in there is new to me. So the chances are that you have something more or less original there.

Now you'll just have to build a functional game around it; remember that being original is a rather minor virtue in the context of game design. It's much more important to be entertaining and efficient.

[Doug Ruff]

Ephemere,

This goes a bit beyond your original request for feedback, but I hope you'll find it useful.

(By the way, welcome to the Forge!)

The reason for using beads for resolution (rather than dice) should be more than cosmetic. One thing that you can do with beads that you can't easily do with dice, is to adjust the probability by adding or removing beads from the pool as a consequence of previous play.

For example, if there are 5 each of 6 different types of beads in the pool, and I don't replace them after each draw, then once I've drawn all of a particular colour of bead, I won't draw it again until the pool is refreshed.

But if I roll a 6-sided dice 30 times, there is no limit to the number fo 6's (or 1's) I can roll.

So using pools can be a good way of "evening out" the random factor in a game.

Another example, using the 7 colours as -3,-2,-1,0,+1,+2,+3. A GM could reward players for "heroic" play by adding additional +1/+2/+3 beads to the pool, increasing the chance that these get drawn later on. This is different to giving players immediate bonuses to die rolls, and also different to giving them discretionary "Drama Points" to spend on increasing specific rolls later on.

Finally: if the pool is shared between all players, that in itself has a significant impact on resolution - if I'm pulling all the high value stones, my mates are more likely to get screwed when it's there turn to draw.

Why am I mentioning all of this? If you're going to use beads in your game, I think you should be exploiting some of the differences that using them offers to you. If you're going to use 100 beads, and refresh them each time, you may be better off using percentile dice.

(Note: changing the base probabilities can be done with percentile dice just as easily as with beads. What beads allow for is making the outcome of a "roll" conditional upon the outcome of previous "rolls".)

In other words, non-dice randomisers are great, especially when they don't behave like dice.

Regards,

Doug

[Aaron M. Sturgill]

Isn't it funny how much we don't read? Apologies, Eero. And many thanks to Doug for an inspiring post. I had considered many of your ideas in the early stages of design, and am now re-thinking them to some extent.

How important do you feel it is that the probability of any given draw be a known quantity? I.e., if stones are not replaced when drawn, and if the GM is adding stones based on skillful play (which is a great reward mechanic. . . or am I misunderstanding the definition?), then the probability is obviously changing all the time. Is it viewed as a feature that this probability is unknown, or should the GM strive to keep track of the stones present at all times? I guess this is a request for an opinion, rather than some objective response as to which is correct.

[Doug Ruff]

I can give you an opinion, but as the designer, it's your own opinion that will count more - if you like it, it's a feature.

Having said that,  I'd advise not to keep a strict count. A bigger decision is when to refresh the pot.

And "bonus" beads should be given for whatever behaviour the GM wants to encourage amongst the players: it's as simple as that. This could be good tactical play, "roleplay", following genre cliches (a good choice, IMO).

One thing: if the GM is using a random factor for their NPCs, then rewarding the players won't work unless the GM has their own pot. Another advantage of having a GM pot is that the GM can simply take a bead from their own pot and put it in the players pot (or exchange it for a lower valued bead.)

Also, if whenever the player draws a bead, they give it to the GM (and vice versa) then you don't have to refresh the pot ever, the beads just get exchanged.

Of course, at this point, you may not need 7 colours of bead - if there are 4 colours (for +0 to +3) but the players and GM both draw, then you have a similar range of outcomes.

[Aaron M. Sturgill]

Two things: even if the switch from percentiles to one hundred stones is merely cosmetic, I feel that the process of gameplay is different enough to warrant consideration. . . obviously, especially if the total isn't static (if the stones are removed).

And, also. . .

Of course, at this point, you may not need 7 colours of bead - if there are 4 colours (for +0 to +3) but the players and GM both draw, then you have a similar range of outcomes.

. . . would you mind expounding on this?

[Doug Ruff]

Of course, at this point, you may not need 7 colours of bead - if there are 4 colours (for +0 to +3) but the players and GM both draw, then you have a similar range of outcomes.

. . . would you mind expounding on this?

Sure.

Drawing once from 7 colours in a single pot gives 7 different possible outcomes. You've used these to represent -3/-2/-1/0/+1/+2/+3

Drawing from 4 colours, gives 4 different outcomes. Let's call these 0/1/2/3.

So, if I draw from the player pot and the GM pot, adding the score of player bead and subtracting the score of the GM bead, I get 16 different outcomes, but these can be slit into 7 groups:

(In all of these, the player score is listed first.)

1 outcome with total -3: (0,-3)
2 outcomes with total -2: (0,-2);(1,-3)
3 outcomes with total -1: (0,-1);(1,-2);(2,-3)
4 outcomes with total 0: (0,0);(1,-1);(2,-2);(3,-3)
3 outcomes with total +1: (1,0);(2,-1);(3,-2)
2 outcomes with total +2: (2,0);(3,-1)
1 outcome with total +3: (3,0)

Note that these outcomes are identical to the potential outcomes of rolling d4-d4 - it's just that having a varying number of beads will change the likelihood of each outcome.

Also note that making two draws automatically skews the results towards 0 (but only if there is a roughly equal chance of each bead appearing.)

Hope this makes more sense, my original comment wasn't very clear at all.

[Aaron M. Sturgill]

Thanks, Doug. Your input is much appreciated.

Next opinion question: when to refresh?

[Keith Sears]

Thanks, Doug. Your input is much appreciated.

Next opinion question: when to refresh?

One method of determining that is to put a single stone in the bag that is a different color from the others. When that stone is drawn, all the stones drawn gp back in the bag.

[Aaron M. Sturgill]

Good idea. . . although I've decided that beads will be exchanged between the players' bag and the GM's bag, and both the players and the GM will add beads to their bag throughout the game (so, no beads will ever actually be removed).

I think, based on my campaign style, that it's best to never refresh the bags until the campaign is over.

[Keith Sears]

Good idea. . . although I've decided that beads will be exchanged between the players' bag and the GM's bag, and both the players and the GM will add beads to their bag throughout the game (so, no beads will ever actually be removed).

I think, based on my campaign style, that it's best to never refresh the bags until the campaign is over.

Not refreshed through an entire campaign? Whoo....  You'd have to do some long-term planning or the system would have to feed the players new stones  aggressively. In the stone system I was trying to design for Luna, I tried to find some kind of rough balance so that some stones would flow through the players hands while others would remain as a permanent randomizer.