Closed ManvilleFog closed 9 years ago
I feel strongly that we should match the letters used for skills on the previous site. I don't think optimizing is as valuable as making returning players feel comfortable with the site UI, because i think returning players are our first (definitely not only, but first) target audience.
Of your proposed changes, though, i don't have a problem with changing plasma from P{,} to {,} --- seems unambiguous enough, and might as well retain a letter for later use.
I think I mostly agree with colubi1 on this one.
For skills that are used in recipes like Butthead, Crosswords and anthony, I think they should definitely retain their present symbols. It feels inappropriate to change them.
For skills whose proposed new symbol previously belonged to a different skill (like ^ for Stealth), then changing it will cause annoyance and confusion to returning players who think they know what a skill means and shouldn't have it changed out from under them.
For other skills, where the change won't alter any buttons in important ways, and where the new symbol didn't already have a different meaning, I'm neutral on whether their symbols get changed or not. If a returning player sees an unfamiliar symbol in a die recipe, it would be easy enough for them to look it up. But on the other hand, I'm not sure there's really enough wrong with the old symbols to bother changing them.
Is it strictly necessary for all skills to have single-character codes? Or would it be reasonable to have an alternate verbose syntax -- something like "
We've reserved grouping symbols in case we need multicharacter codes in the future. However, for the moment, we aren't quite there, and we /may/ be able to get away with Unicode codes (although that's a thorny issue we're leaving for the future).
In fact, we were just talking about this on IRC, and it's the rationale behind new ticket #358. Right now, the backend, the UI, and any other clients anyone writes, all need to parse the recipe to find out what skills the recipe has. So parsing the recipe needs to be super easy. If we communicate explicitly about what skills the die has, separate from the recipe, then it's less necessary.
However, i believe that at the end of the day, recipes do need to be uniquely parseable (i.e. it's not okay to have ambiguity in the printed recipe which only the longer recipe resolves, but it may be okay for the logic to parse the recipe into skills to be more complicated. Not sure about that.)
Thanks for the feedback. There are a couple of changes I'm still going to push. I think the old site users are intelligent enough that they'll be able to handle these differences. Here it goes: Rage: I doubt that if the old site wasn't set up so that R could only be used as a Swing Die Value, then there's no way Rage would have been stuck being coded as a G. I don't think Rage: R is going to confuse anyone. And, in fact, Rage: G was confusing enough to cause a few of the old site recipes to be improperly implemented. The Game: G use in the set were assumed to be Rage: G.
ah. My argument against Stealth: d , is that I think it's nearly as stupid a way of coding the skill as Rage: G. It doesn't match the skill's physical representation or have any phonetic similarity - it just has shares a first letter with a word that is used to describe the physical representation. Even that's lacking, because for that symbol to be Delta the dice needs to be placed upside-down.
Thinking on it more, avoiding the three-way switch involving Time & Space, and just going with Stealth: < isn't a really great solution, even if it more closely resembles Gripen. Being that I'm willing to give up on using dash for Trip, I'll through in the towel on changing Stealth.
But I think the arguments for changing Rage are better than those for keeping it.
I disagree. I think we should keep null, queer, time and space, rage, shadow, stealth, and trip as they were on the old site. The transition costs are nonzero, and i don't think there was a problem with the old way.
I'm thinking Take Five should be a button skill instead of a die skill. But while I was thinking on the coding of this, I was thinking of different ways to parse button skills.
As an example, the recipe for Brie without any skill coding is: (4) (6) (8) (10) (12) (12) (20)
Out of those 7 dice the player would choose 5 to be their live dice. I had two thoughts on the coding for this:
Take Five: T (just using the character T for this example) . . .
Brie: T(4) T(6) T(8) T(10) T(12) T(12) T(20)
This would allow fanatics like:
Nick: T(4) T(6) T(8) T(10) T(12) T(20) (7) meaning the (7) was always live and the rest were variable, or:
WTF: T(4)! T(6)! T(8)! T(10)! T(12)! T(12)! T(20)!
or Take Five: []
Brie: [(4) (6) (8) (10) (12) (12) (20)]
Which would still allow fanatics like:
Nick: (7) [(4) (6) (8) (10) (12) (20)] or:
WTF: [(4) (6) (8) (10) (12) (12) (20)]!
Do we want this? Or do we just want Take Five to be a button skill?
Thinking of Take Five as a button skill, I started thinking on something like this: Brie: [Take Five: (4) (6) (8) (10) (12) (12) (20)] which would also give us things like: Pappy: [Pappy: (4) (4) (10) B(20) (X)] and Sailor Moon: [TM(1): (8) (8) (10) (20) r(6) r(10) r(20) r(20)] and
I like this as a way to code button skills. It gets rid of the need for a button special flag and makes the fact that the button has a special easily visible as part of the recipe as opposed to something hidden in the database. I think it's great for the Sailor Moon / Tenchi Muyou! sets where their specials (iconic abilities) aren't limited to single buttons like most specials, and also have values associated with them, such as NV(4) for Jedite and NV(2) for Malachite.
So, should Take Five be implemented as a Die Skill applied to individual buttons, or a Die Skill applied to a group of buttons, or a Button Skill?
Also, thoughts on using this method of coding button skills?
How about T[5](4, 6, 8, 10, 12, 12, 20). This would open the door to making a 'Take n' ability for other recipes.
Andrew Senger asenger@gmail.com
On Thu, Dec 26, 2013 at 10:30 AM, ManvilleFog notifications@github.comwrote:
I'm thinking Take Five should be a button skill instead of a die skill. But while I was thinking on the coding of this, I was thinking of different ways to parse button skills.
As an example, the recipe for Brie without any skill coding is: (4) (6) (8) (10) (12) (12) (20) Out of those 7 dice the player would choose 5 to be their live dice. I had two thoughts on the coding for this: Take Five: T (just using the character T for this example) . . . Brie: T(4) T(6) T(8) T(10) T(12) T(12) T(20) This would allow fanatics like: Nick: T(4) T(6) T(8) T(10) T(12) T(20) (7) meaning the (7) was always live and the rest were variable, or: WTF: T(4)! T(6)! T(8)! T(10)! T(12)! T(12)! T(20)!
or Take Five: [] Brie: [(4) (6) (8) (10) (12) (12) (20)] Which would still allow fanatics like: Nick: (4) (6) (8) (10) (12) (20) http://7 or: WTF: [(4) (6) (8) (10) (12) (12) (20)]!
Do we want this? Or do we just want Take Five to be a button skill?
Thinking of Take Five as a button skill, I started thinking on something like this: Brie: [Take Five: (4) (6) (8) (10) (12) (12) (20)] which would also give us things like: Pappy: [Pappy: (4) (4) (10) B(20) (X)] and Sailor Moon: [TM(1): (8) (8) (10) (20) r(6) r(10) r(20) r(20)] and
I like this as a way to code button skills. It gets rid of the need for a button special flag and makes the fact that the button has a special easily visible as part of the recipe as opposed to something hidden in the database. I think it's great for the Sailor Moon / Tenchi Muyou! sets where their specials (iconic abilities) aren't limited to single buttons like most specials, and also have values associated with them, such as NV(4) for Jedite and NV(2) for Malachite.
So, should Take Five be implemented as a Die Skill applied to individual buttons, or a Die Skill applied to a group of buttons, or a Button Skill?
Also, thoughts on using this method of coding button skills?
— Reply to this email directly or view it on GitHubhttps://github.com/buttonmen-dev/buttonmen/issues/356#issuecomment-31226360 .
I like the idea of the button skills being part of the button recipe. And if we used the format ManvilleFog suggests, then I'd recommend calling it "Take(N)" rather than "Take Five", to go along with the TM(N) and NV(N) suggestions.
So... i think we need to put a big "representation vs. parsing" box around this whole discussion. Let me define how i'm using those terms:
In this discussion, we've been treating these as if they're the same thing, as in, we've been trying to decide on a fixed string of text for each button which will be (1) stored in a database, (2) parsed by each piece of software, then (3) displayed to the user. IMO, that's wrong, and we'll be much better able to reach consensus if we stop thinking about it that way.
Some less abstract comments related to this distinction:
In other words, the back-end parsing of die skills from strings only exists right now because it's convenient. Modifying that parsing to make it less convenient (by putting structured non-die data into it) doesn't make sense, because parsing skills from string representations is a hack to begin with. That doesn't preclude talking about how button skills should be represented to the user, and we should totally talk about that. But when we're done, we won't put them in the recipe field of the button table of the database and then parse them back out --- we'll put them in a separate database format designed to represent button skills.
At the moment, I'm undecided about how to represent button-level skills, and also how to deal with them in the backend. The one thing that we HAVE agreed on is that buttons need to be flagged in the database with whether they have special button level skills or not.
Here it is again, taking into account the proposed changes that didn't pass. With one exception the codes from skills implemented on the old site remain unchanged.
The emphasis of this list (other than implemented or not) is how the die types appear on physical buttons as opposed to their coding for the online game.
This should be a complete list of die types and their matching single-character ASCII codes. The first part is just a recap of die types from the old site. All these have been approved. The second part has die types from incomplete sets on the old site. These have already gone up on the database with no complaint, so are assumed to have met everyone's approval.
Please take a look at the final part of the list - die types from unimplemented buttons sets, and see if there's any problems or suggestions for change. Thanks! :)
DIE TYPES FROM OLD SITE THAT HAVE NO PHYSICAL BUTTONS
Chaotic: @
Doppleganger: D
Jolt: J
Maximum: M
Mighty: H
Morphing: m
Ornery: o
Plasma: {} -- CHANGED FROM OLD SITE: P{} (P in code seems unnecessary)
Radioactive: %
Slow: w
Value: v
Weak: h
Unique: u
Wildcard: C (note: can't find Las Vegas button set images)
DIE TYPES FROM OLD SITE WHOSE CODE IS AT LEAST CLOSE MATCH TO PHYSICAL BUTTONS
Berserk: B
Chance: c (physical buttons use copyright symbol)
Fire: F
Konstant: k
Mood Swing: ?
Null: n
Poison: p
Queer: q
Speed: z (looks close enough to a lightning bolt)
Time and Space: ^
Turbo Swing: !
Auxiliary: +
Twin: (,)
DIE TYPES FROM OLD SITE THAT DO NOT MATCH PHYSICAL BUTTONS
Focus: f
Rage: G
Shadow: s
Stealth: d
Stinger: g
Trip: t
Warrior: `
reserve: r
DIE TYPES LACKING ON OLD SITE THAT HAVE PHYSICAL BUTTONS TO MATCH
Game: R (since Rage has G)
Rebound: = (close match to button image)
Sleep: Z (as in ZZZZZZ)
Winslow: NOTE: *not* used in any button recipe, adds special rules to game play
DIE TYPES LACKING ON OLD SITE THAT HAVE NO PHYSICAL BUTTONS TO MATCH
Pai Gow: : (colon symbol to represent dominoes)
DIE TYPES FOR SETS THAT DID NOT EXIST ON OLD SITE W/ PHYSICAL BUTTONS PROPOSED CODE MATCHES PHYSICAL BUTTONS
Evil: E (Gaming Guardians)
Insult: I (Gaming Guardians)
Teleport: T (Gaming Guardians)
DIE TYPES FOR SETS THAT DID NOT EXIST ON OLD SITE W/ PHYSICAL BUTTONS PROPOSED CODE DOES NOT MATCH PHYSICAL BUTTONS
Armor: A (Nodwick; no symbol to match physical buttons)
Boom: b (Unexploded Cow; die frame is a bomb)
Deception: ~ (Gaming Guardians; labeled with a D)
Dodge: _ (unofficial Japanese Beetle; D represents die type and size)
Loaded: M (Gaming Guadians; same as Maximum)
Mad Swing: (&) (Unexploded Cow; represented by upside-down question mark)
Specialty: {I,M,p,s,z,t} (Gaming Guardians; labeled with an asterisk; see note)
Sideboard: S (High School Drama; extra die on left side of button)
DIE TYPES FOR SETS THAT DID NOT EXIST ON OLD SITE W/OUT PHYSICAL BUTTONS
Assassin: a (Order of the Dolls)
Attacker: - (Blademasters 2; pointy weapon?)
Cross: x (Blademasters 2; x as in multiply)
Defender: | (Blademasters 2; flat shield?)
Parry: I (Blademasters; same as Insult)
Thief: $ (Everything to Gain)
NOTES
AVAILABLE CODES:
. * < > e i K N O P U V W X y Y
NOTE: # ' " ; \
ARE NOT BEING USED BECAUSE OF SPECIAL MEANING TO DATABASE
: : : : : : THEY MIGHT BE CONSIDERED AVAILABLE IF PRECEDED BY ESCAPE CHARACTER
NOTE: DEPENDING ON SKILL INTERPRETATION, SHOULD HOLD * FOR SPECIALTY DICE
At the moment, it appears that die recipes are represented with parentheses around the die sizes. The UI is rendering recipes and dice with text like "(10)" and "cz(13)".
I think that for convenience of instant at-a-glance legibility, it would be nice if (in the UI at least, but probably everywhere for consistency) dice with simple numeric sizes did away with the parentheses, leaving them as just "10" and "cz13".
Naturally for swings or other dice where the symbol for the size could be ambiguous with the symbol for a (current or future) skill (such as "(X)" or "R(T=2)"), it would make sense to leave the parentheses in place.
Hmm... so, i was reasonably happy with the old site's method of distinguishing die sides from other skills by just not reusing characters between the two uses (e.g. if R is a swing die type, it can't be any other skill). But i think if we're going to use parens to mark off swing die sizes, we should use them consistently for all side counts (variable or not).
Are there still open questions here, or is this pretty much resolved at this point?
Specialty Dice need to be discussed to see if the Plasma substitute works. Gaming Guardians list its code as '*', but I'd rather not waste yet another die code on that set if it can be coded with an already existing die-type.
The Kubla Con set was added after this was completed, and introduces four new die types (for a two button set! They're worse than Gaming Guardians!). I think codes were discussed for these in another topic (or I just chose those that matched best among the few remaining available codes), but I should definitely add them here and get a ruling on their use.
I believe that this is complete for the moment. Closing the issue.
Just to be clear, by codes and coding I am referring to the characters used to represent the various die types. I don't know if that's the best way to word it, but it's what I've been using. Anyhow . . .
I want to get this out of the way before I continue putting button recipes into the database. I was told to use my judgment - but since I want to change some of the coding (for example, Rage should be 'R' instead of 'G') I think it's important to get feedback. Things I've considered while trying to come up with die codes are how the die type was represented on the physical buttons, what codes were used on the old site, and what does the die type do.
What follows is my most recent compilation of information regarding die types, containing all 62 die types I've found so far. FYI - I haven't coded the dice for Buzzing Weasel. I figure that can be handled with special button rules.
DIE TYPES FROM OLD SITE THAT HAVE NO PHYSICAL BUTTONS
DIE TYPES FROM OLD SITE WHOSE CODE IS AT LEAST CLOSE MATCH TO PHYSICAL BUTTONS
DIE TYPES FROM OLD SITE THAT DO NOT MATCH PHYSICAL BUTTONS
DIE TYPES LACKING ON OLD SITE THAT HAVE PHYSICAL BUTTONS TO MATCH
DIE TYPES LACKING ON OLD SITE THAT HAVE NO PHYSICAL BUTTONS TO MATCH
DIE TYPES FOR SETS THAT DID NOT EXIST ON OLD SITE W/ PHYSICAL BUTTONS PROPOSED CODE MATCHES PHYSICAL BUTTONS
DIE TYPES FOR SETS THAT DID NOT EXIST ON OLD SITE W/ PHYSICAL BUTTONS PROPOSED CODE DOES NOT MATCH PHYSICAL BUTTONS
DIE TYPES FOR SETS THAT DID NOT EXIST ON OLD SITE W/OUT PHYSICAL BUTTONS
*WITH PHYSICAL BUTTONS: OR VIRTUAL BUTTONS IMAGES NOT EXLUSIVE TO OLD SITE
*WITHOUT PHYSICAL BUTTONS: THEY MIGHT EXIST, BUT I CAN'T FIND THEM
*LACKING ON OLD SITE: SOME BUTTON SETS ON THE OLD SITE WERE INCOMPLETE OR IMPROPERLY IMPLEMENTED BECAUSE OF MISSING DIE TYPES
*IMPLIED DIE TYPES: THOSE CREATED TO IMPLEMENT SPECIAL BUTTON RULES (Japanese) Beetle: Japanese Beetle from official Japanese Beetle (Flyiing) Squirrel: Flying Squirrel from official Japanese Beetle Slow: Giant from BROM Socrates: Socrates from Fantasy Unique: Guillermo from Renaissance Take Five: Fightball set by Cheapass Games
*SAME AS, or SIMILAR TO: THERE ARE A FEW CASES WHERE THE SAME (OR NEARLY IDENTICAL) DIE TYPES WERE CREATED BY DIFFERENT GROUPS INDEPENDENT OF EACH OTHER Beetle (Japanese Beetle) = Parry (Blademasters) = Insult (Gaming Guardians) Maximum (Dana Huyler) = Loaded (Gaming Guardians)
*SPECIALTY DICE: IT MAY BE POSSIBLE TO IMPLEMENT WITHOUT GIVING A DIE CODE GAMING GUARDIANS INTRODUCE 6 DIE TYPES IN AN 8 BUTTON SET - GREEDY BASTARDS!
From the Randomdice Button Men Roster: Specialty Dice are labeled with an "*". Can be one type of dice from the following: Insult, Loaded, Poison, Shadow, Speed or Trip. QUESTION: Is this done randomly, or by choice? Is this done only when option, swing die are selected, or can it vary per turn? Is this like Plasma dice or like limited Chance dice?
SUMMARY OF PROPOSED CHANGES:
NOTE: Reasons for choosing L to code both Loaded and Maximum: 1) Loaded dice exist on buttons not exclusive to the old site. 2) L matches physical buttons 3) Five die types begin with M as opposed to one L, so it's more likely M will be needed for a future set's die type Reasons to keep M for Maximum and also apply it to Loaded Dice: 1) It's easier 2) Out of respect to Dana Huyler and the old site, as it was created for that site's one year anniverary NOTE: I feel very strongly about changing the codes for Rage, Stealth, Time & Space, and Trip, and strongly about Shadow. They seem like poor when compared to the physical button representations.
SHOULD THESE BE CHANGED?
NOTES: If uppercase K is closer match to physical buttons, change Konstant Dodge uses D on physical buttons, so maybe it and Doppleganger should swap I don't think a single quote can be used in die codes, so ` might be useful if Prime Swing dice are ever to be implemented
BUTTONS WHOSE RECIPE HAS A VISUAL RATHER THAN STRATETGIC MEANING:
CODE NEEDED FOR: Take Five The Fightball buttons have 7 or 8 dice listed on their recipes, but only five dice are chosen for play. This is at the beginning of the game and after a match is lost, the same as with swing or option dice.
AVAILABLE CODES: e i j K (or k) l M n O P U V W X [ ] . ~ NOTE: DEPENDING ON SKILL INTERPRETATION, SHOULD HOLD \ FOR SPECIALTY DICE