choose codes for all die types

[ManvilleFog]

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

Chaotic: @
Doppleganger: D
Jolt: J
Maximum: M, same as Loaded, PROPOSED CHANGE: L
Mighty: H
Morphing: m
Ornery: o
Plasma: P{}, PROPOSED CHANGE: {} (P in code seems unnecessary)
Radioactive: %
Slow: w (implied die type)
Value: v
Weak: h
Unique: u (implied die type)
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 (should perhaps be K)
Mood Swing: ?
Null: n, PROPOSED CHANGE: N (to more closely match physical dice)
Poison: p
Queer: q, PROPOSED CHANGE: Q (to more closely match physical dice)
Speed: z (looks close enough to a lightning bolt)
Time and Space: ^, PROPOSED CHANGE: > (both match physical button)
Turbo Swing: !
Auxiliary: +
Twin: (,)

DIE TYPES FROM OLD SITE THAT DO NOT MATCH PHYSICAL BUTTONS

Focus: f (no changes proposed)
Rage: G, PROPOSED CHANGE: R
Shadow: s, PROPOSED CHANGE: _ (note: s is used on some later sets)
Stealth: d, PROPOSED CHANGE: ^ (both d and ^ for Delta used on button images)
Stinger: g (no changes proposed; no ASCII symbol to match physical buttons)
Trip: t, PROPOSED CHANGE: -
Warrior: ` (no proposed changes; no symbol to match physical buttons)
reserve: r (no proposed changes; no symbol to match physical buttons)

DIE TYPES LACKING ON OLD SITE THAT HAVE PHYSICAL BUTTONS TO MATCH

Game: G (Rage will no longer need it; can't comfirm match to button image)
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

(Japanese) Beetle: I (implied die type; same as Insult Dice)
Pai Gow: : (colon symbol to represent dominoes)
Socrates: S (implied die type)
(Flying) Squirrel: q (implied die type; q for squirrel?)

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)
Loaded: L (Gaming Guadians; same as Maximum)
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: d (unofficial Japanese Beetle; D represents die type and size)
Mad Swing: & (Unexploded Cow; represented by upside-down question mark)
Specialty: {I,L,p,s,z,-} (Gaming Guardians; labeled with an asterisk; see note) 
Sideboard: s (High School Drama; extra die on left side of button)
Take Five: CODE NEEDED (Fightball; implied die type; choose 5 from listed dice)

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: t (Everything to Gain)

*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:

Maximum:        M  ->  L ; M free for potential future use
Plasma:       P{}  ->  {}
Null:           n  ->  N
Queer:          q  ->  Q ; q now used for Flying Squirrel
Time and Space: ^  ->  >
Rage:           G  ->  R ; G now used for Game Dice
Shadow:         s  ->  _ ; s now used for Sideboard Dice
Stealth:        d  ->  ^ ; d now used for Dodge
Trip:           t  ->  - ; t now used for Thief

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?

Konstant:     k  ->  K
Doppleganger: D  ->  d
Dodge:        d  ->  D
Warrior:      ` -> CODE NEEDED

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:

Hodge Podge:
Butthead:       B(U) t(T) H(3) @d(5)
 translates to  Thief(T), Chaotic Dodge(5)
 or becomes     B(U) T(T) H(3) @D(5)
                Teleport(T), Chaotic Doppleganger(5)
 or becomes     B(U) -(T) H(3) @^(5)
Crosswords:     c(R) o(S) s(W) o(R) d(S)
 translates to  Sideboard(W), Dodge(S)
      or        c(R) o(S) S(W) o(R) D(S)
                Socrates(W), Doppleganger(S)
 or becomes     c(R) o(S) _(W) o(R) ^(S)
FANATICS: 
anthony:        v?(X,X) vst(16) stomp(10) {zf,Bp}(V) fF(15)
    becomes     v?(X,X) v_-(16) _-omp(10) {zf,Bp}(V) fF(15)
  or translates to:
    stomp(10):  Sideboard Ornery Morphing Poison Thief(10)
    STomp(10):  Ornery Morphing Poison Socrates Teleport(10)

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

[cgolubi1]

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.

[AdmiralJota]

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.

[AdmiralJota]

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 "10" being equivalent to "pz10" -- and then not worry about making sure every brand new skill has a proper single-character abbreviation?

[blackshadowshade]

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).

[cgolubi1]

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.)

[ManvilleFog]

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.

[cgolubi1]

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.

[ManvilleFog]

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?

[yawetag]

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 .

[AdmiralJota]

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.

[cgolubi1]

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:

• Representation: what is the most concise format in which button recipes and die recipes are shown to people?
• Parsing: how does the software (backend and frontend) which implements the site figure out what skills a given button and its dice have, in order to take game actions/figure out what to display/etc?

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:

• I believe (but please correct me if i'm wrong) that the discussion on this ticket is ultimately mostly about representation --- if i am starting a new game and trying to decide whether to select Socrates as a button in that game, i should be able to see that Socrates has a special attack. In the same way that 'z' is the representation of the text that reminds me that a die has the speed skill, what is the best representation of the text that reminds me that a button has the Socrates skill?
• When i was implementing the UI for chance and focus, i ran into the issue in which the UI code needs to know which dice in a recipe have chance and/or focus skills, so the UI had to parse die recipes to figure that out. James and i decided that's no good, so we opened #358 --- the point of that ticket is that the backend should communicate to the UI about die skills by passing a dictionary of die skills, not by passing a recipe which the frontend needs to parse.
• Right now, the backend figures out a button recipe by parsing the "recipe" field in the button database table. This has the implementation advantage that we can paste a bunch of existing button recipes into the database, but there's nothing good about it otherwise. We have a database, so there's no point in encoding new information in strings and making the backend parse them. It's much better for new information to be put in a useful data format that can easily be encoded in a database (such as an internal representation of button skills as different from die skills, and a link between a button and any button skills it may have).

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.

[blackshadowshade]

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.

[ManvilleFog]

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

---

• 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
• 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 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?

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

[AdmiralJota]

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.

[cgolubi1]

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).

[AdmiralJota]

Are there still open questions here, or is this pretty much resolved at this point?

[ManvilleFog]

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.

[blackshadowshade]

I believe that this is complete for the moment. Closing the issue.