Monday, September 29, 2008
Attribute Restriction
I'm pretty certain at this point that the attributes I talked about in the last post should be restricted to "How" a trait works or "Why" a trait works, rather than any old additional information.
Thursday, September 25, 2008
Attribution
A thought occurred to me the other day, after a long discussion of Traits, ranks and such. I don't want to take away the flexibility of Traits, but I do want them to be less nebulous (so you can get a better idea of the "literary power" of a given Trait), and to simplify the Auction evaluation algorithm. So here's my compromise:
A Trait is a short descriptor of a quality of the Character who has it (think of it like an Adjective from Grammar school). All Traits are useless in a context that they don't apply in, so they normally have a value of 0. When they do apply, they are given the value of 2.
However, a Trait may also have sub-Traits (lets call these Attributes to distinguish them) that give more information about the Trait that they modify.
For example: "Acrobat" is a Trait. While "-Parallel Bar Specialist" and "-Since he was 5" are both potential Attributes of "Acrobat". Which would be written like this on the character sheet:
Now, this is a Trait with 2 attributes. It doesn't really matter what they are to the computation, but it is used to determine if the Trait is applicable in the current contest. If any of the Attributes doesn't apply, then the whole Trait doesn't apply. However, when they do apply, you compute the value as 2^(number of Attributes + 1). That way, Traits are valuable, and non-comparable ones are treated separately, while at the same time, things that have had a lot of emphasis in the development of the character are appropriately stressed. Multiply the results
Example computation:
Gunman tries to Shoot a Gymnast.
Gunman has the following Traits:
And Gymnast has the following Traits:
Now, if these are the only Traits that these folks have, lets take a look at how it'll play out if Gunman tries to shoot the Gymnast with a Revolver from in a crowd.
Now, Gunman declares that he's going to "shoot the Gymnast suddenly while drawing his Revlover" and bids the following:
he does not bid "Professional Soldier" because the "spent 800 Hours at the Rifle Range" does not apply while he is not using the skill set associated with the Rifle (as in he's using a different kind of firearm, and he isn't really taking time to aim).
The value of his bid is: Trickshot * Steady Hand = 2^3 * 2 = 2^4 = 16
The Gymnast, having already apparently noticed the gunman gets a chance to react and dodge, declares, "I'm gonna try to dive out of the way" and bids:
He does not bid this "Acrobat" Trait, since he is not doing anything that his "Parallel bars" skill set will help him with (as in, he is not doing something that requires upper body strength).
The value of his bid is: Fast Reflexes * Fit as a Fiddle = 2 * 2^2 = 2^3 = 8
Now, since the Gunman has 16, and the Gymnast has 8, the Gunman shoots him, and inflicts a Wound of some sort.
Note to self: figure out a less nebulous way to figure out if a Attribute applies or not. Also, explain the margin of victory... Maybe Attributes should be restricted to answering "How" or "Why"?
A Trait is a short descriptor of a quality of the Character who has it (think of it like an Adjective from Grammar school). All Traits are useless in a context that they don't apply in, so they normally have a value of 0. When they do apply, they are given the value of 2.
However, a Trait may also have sub-Traits (lets call these Attributes to distinguish them) that give more information about the Trait that they modify.
For example: "Acrobat" is a Trait. While "-Parallel Bar Specialist" and "-Since he was 5" are both potential Attributes of "Acrobat". Which would be written like this on the character sheet:
- Acrobat
- Parallel Bar Specialist
- Since he was 5
Now, this is a Trait with 2 attributes. It doesn't really matter what they are to the computation, but it is used to determine if the Trait is applicable in the current contest. If any of the Attributes doesn't apply, then the whole Trait doesn't apply. However, when they do apply, you compute the value as 2^(number of Attributes + 1). That way, Traits are valuable, and non-comparable ones are treated separately, while at the same time, things that have had a lot of emphasis in the development of the character are appropriately stressed. Multiply the results
Example computation:
Gunman tries to Shoot a Gymnast.
Gunman has the following Traits:
- Professional Soldier
- Plays by the rules
- spent 800 hours on the Rifle Range
- Trickshot
- Revolver Specialist
- Quickdraw
- Steady Hand
And Gymnast has the following Traits:
- Acrobat
- Parallel Bar Specialist
- Since he was 5
- Fast Reflexes
- Fit as a Fiddle
- From Intensive Gymnastics Training
Now, if these are the only Traits that these folks have, lets take a look at how it'll play out if Gunman tries to shoot the Gymnast with a Revolver from in a crowd.
Now, Gunman declares that he's going to "shoot the Gymnast suddenly while drawing his Revlover" and bids the following:
- Trickshot
- Revolver Specialist
- Quickdraw
- Steady Hand
he does not bid "Professional Soldier" because the "spent 800 Hours at the Rifle Range" does not apply while he is not using the skill set associated with the Rifle (as in he's using a different kind of firearm, and he isn't really taking time to aim).
The value of his bid is: Trickshot * Steady Hand = 2^3 * 2 = 2^4 = 16
The Gymnast, having already apparently noticed the gunman gets a chance to react and dodge, declares, "I'm gonna try to dive out of the way" and bids:
- Fast Reflexes
- Fit as a Fiddle
- From Intensive Gymnastics Training
He does not bid this "Acrobat" Trait, since he is not doing anything that his "Parallel bars" skill set will help him with (as in, he is not doing something that requires upper body strength).
The value of his bid is: Fast Reflexes * Fit as a Fiddle = 2 * 2^2 = 2^3 = 8
Now, since the Gunman has 16, and the Gymnast has 8, the Gunman shoots him, and inflicts a Wound of some sort.
Note to self: figure out a less nebulous way to figure out if a Attribute applies or not. Also, explain the margin of victory... Maybe Attributes should be restricted to answering "How" or "Why"?
Tuesday, September 23, 2008
Refreshing Alternatives
Given how important the concept of scarcity is in defining a game based around the mechanics of resource auctions, you'd think that there'd be an obviously correct way of implementing it, but I have yet to find One Way to Rule Them All.
Right now, I'm looking over the available alternatives, and I'm coming up with different ways to model scarcity. Let's list the pros and cons for each:
Right now, I'm looking over the available alternatives, and I'm coming up with different ways to model scarcity. Let's list the pros and cons for each:
- Direct Expiration: in this model, which is the default one from the Quick-Start guide, each trait is simply unavailable for bidding after being bid for a set amount of time. Pros: simple, requires no randomizer, correctly models scarcity by making things unavailable when they would like to use them; Cons: lots of numbers to keep track of, players may not take "dramatic" liscence without breaking the rules.
- Approximate Expiration: in this model, we replace the set timer based expiration discussed above with a probabilistic timer. For this model, at the end of each round, the player rolls a d100 for each trait that is not currently available for auction, and if the roll is less than some number (determined for the column, so there's only like 4 numbers to keep track of), then that trait is refreshed. Pros: only 4 numbers to track, very simple, accurately models scarcity; Cons: lots of potentially tedious die rolling (O(n)--it grows linearly with the number of traits spent, and is done every round), introduces dice into an otherwise diceless system.
- Exact Buyback: in this model, we do away with the whole expiration model, and we replace it with a point-based refresh system. After you spend a trait, it does not naturally refresh, unless you pay a certain number of points for it. These "points" are abstract units only used for the buyback system (this may involve dice). You get a certain number of them each round, and you can spend or save them as needed. The cost is associated with the column, so there are only 4 numbers to track. Pros: simple, no repetitive die rolling; Cons: introduces new mechanics that are not used elsewhere, may allow for the RPG version of button-mashing because it does not properly assign a higher cost to more desirable traits.
- Inexact Buyback: in this model, as the Exact Buyback model above, you have a cost and all that, but you don't get to choose which trait comes back when you pay the normal rate, one at random from the column refreshes (based on a die roll of some sort), but they can also buy back a particular trait at a higher cost. Pros: can be managed entirely by players, penalizes button-mashing; Cons: requires strange dN die rolls, still has dice involved.
- Probabilistic Blind-Auction Buyback: in this model, instead of having a set price for a particular trait, we have a Uniform Random Variable in a range indicative of the relative difficulty of refreshing (basically, you have a die-roll and the refresh rate, and some formula that turns the two into a number). What the player does is, as he gets more points back after his round is over, he has the option of buying back any traits he has listed as spent. However, the way that he does this is by bidding a number of his points on each of them, and for each trait, you roll a die, and come up with a cost. If his bid is less than the cost, he loses those points and gets nothing, if it is equal or more than that cost, he gets the trait back. Pros: great way to model cost--with more valuable traits costing more, can be done by players without the ST doing the rolls (provided that they don't cheat on the rolls); Cons: requires 1 roll per trait, may just annoy players.
Friday, September 19, 2008
Notes on refreshing time
So here's the dig, two topics: time and refreshing traits.
The mechanism of refreshing is designed to keep powers from being abused by rendering them scarce. Scarcity drives the economics of the auctions, and keeps the game running, so it's pretty key.
Here's what I have to say about time: the idea of rounds is kind of clunky, I'd prefer "action frames", which would be a logical unit of time definable in terms of the current situation. If we look at combat, they're basically equivalent to rounds, but if we scale back to an evening filled with debate, they're roughly analogous to volley's of debate. In either case, the die-roll based refresh will work. The actual mechanics of the alternative system didn't scale well outside of combat, but with the dice, there's a chance that you'll be able to reuse an ability rather sooner than the actual time allotted, while at the same time the scarcity is maintained.
The mechanism of refreshing is designed to keep powers from being abused by rendering them scarce. Scarcity drives the economics of the auctions, and keeps the game running, so it's pretty key.
Here's what I have to say about time: the idea of rounds is kind of clunky, I'd prefer "action frames", which would be a logical unit of time definable in terms of the current situation. If we look at combat, they're basically equivalent to rounds, but if we scale back to an evening filled with debate, they're roughly analogous to volley's of debate. In either case, the die-roll based refresh will work. The actual mechanics of the alternative system didn't scale well outside of combat, but with the dice, there's a chance that you'll be able to reuse an ability rather sooner than the actual time allotted, while at the same time the scarcity is maintained.
What to call it?
After that last post, I think I'm gonna try and come up with a better name for the system which is only "mostly diceless". Here's some names I'm kicking around, let me know if you like any (try sticking them into "The ______ Game System" or something like that):
- d100
- dN
- dZero (written out instead, to differentiate it from having no dice at all)
- dSpoon
- Ludibrium/Ludus/Ludi/Lud (all derived from the Latin for a trivial game) http://en.wikipedia.org/wiki/Ludibrium
- Flying Crowbar (taken from "Because of its combination of high speed and low altitude, Pluto promised to get through to targets that manned bombers and even ballistic missiles might not be able to reach. What weaponeers call "robustness" was another important advantage. "Pluto was about as durable as a bucket of rocks," says one who worked on the project. It was because of the missile's low complexity and high durability that physicist Ted Merkle, the project's director, called it "the flying crowbar."")
- Bucket of Rocks (also from the same quote, because I like it, from http://www.merkle.com/pluto/pluto.html)
- Narrative Vomit
- Simple Auction
- Narritive Auction
- Narritive Masturbation
- Yet Another RPG Thing, Now With Less Dice -- abbreviated as YARTNWLD (pronounced yart-en-wald?)
- Generic Game System Lite!
- Mad Arab (http://en.wikipedia.org/wiki/Abdul_Alhazred)
- Unspeakbly Dull Auction System (UDAS!)
- "Shuggoth Slapping: The Live Action Role Playing Game"
- Green Decay: The Game! (http://en.wikipedia.org/wiki/Glaaki)
- "Hastur! Hastur! Hastus! Generic RPG System" (HHHGRS)
Adding Dice into a Diceless System?
I hate to admit it, but I may have jumped the gun by naming the system d0. After a long and thoughtful discussion over on the Forge (see the last post), it seems like I might have to include dice after all.
Here's the short of it: The auction system needs testing thoroughly, and until I do that I won't try redesigning it. However, the refresh system has one nasty little shortcoming: too much book-keeping. When you bid a handful of traits on each auction, and you have one or more auctions each round (like, say, combat), then you have to keep track of the refresh info for each trait individually. For a game with at least 8 traits in your primary pool and 10 others in other pools, all with different refresh rates and bidding occurrences, you have an awful lot of tedious book keeping to muck with. My solution: replace the manual tracking with probabilistic tracking which approximates the same behavior. In short: at the end of each round, instead of decrementing check marks, you just roll a d100, and check to see if it's less than a certain number. That way you need only keep track of whether the trait is available for bidding or not. The "certain number" by the way is not variable, it's fixed for each column, and written at the top for reference. So, that trims off 2 of the 3 things that people need to worry about with Refresh Rates.
Any opinions or feedback?
Here's the short of it: The auction system needs testing thoroughly, and until I do that I won't try redesigning it. However, the refresh system has one nasty little shortcoming: too much book-keeping. When you bid a handful of traits on each auction, and you have one or more auctions each round (like, say, combat), then you have to keep track of the refresh info for each trait individually. For a game with at least 8 traits in your primary pool and 10 others in other pools, all with different refresh rates and bidding occurrences, you have an awful lot of tedious book keeping to muck with. My solution: replace the manual tracking with probabilistic tracking which approximates the same behavior. In short: at the end of each round, instead of decrementing check marks, you just roll a d100, and check to see if it's less than a certain number. That way you need only keep track of whether the trait is available for bidding or not. The "certain number" by the way is not variable, it's fixed for each column, and written at the top for reference. So, that trims off 2 of the 3 things that people need to worry about with Refresh Rates.
Any opinions or feedback?
Subscribe to:
Posts (Atom)