Results 1 to 7 of 7

Thread: Living Game Rules BETA v0.3

  1. #1
    Senior Member Cetonis's Avatar
    Join Date
    Jul 2010
    Location
    Vernon, CT
    Posts
    3,375

    Living Game Rules BETA v0.3

    - The best way to view this document is in plain old notepad, with word wrap turned off. It is a .txt with no special formatting whatsoever.

    - This is a highly technical document, intended more as a reference or a last resort for the hardest rules questions. It is not for teaching someone how to play.

    - These rules will be in BETA for a period of time. This means that rules situations at events may be handled in ways that are external or conflicting with this rulebook, in cases where something was omitted or not covered properly.

    ----------

    LGR 0.3

    ----------

    Summary of changes - Nothing earth-shattering. Mostly just filling some holes from v0.2:

    :: Cycling rules for small deck formats added

    :: X cannot be negative in any case whatsoever

    :: Attacks that are turned face down get dropped / aborted

    :: Searching all game zones includes face down cards in the card pool

    :: Added a small clause to prevent lawyering surrounding illegal blocks

    :: "Playable by either player", "playable while committed", "draw up to", "printed blank text box", and references to a player's "character" are all now properly defined.

    :: Better / more solid rules support added for Nobel Prize / S Class Hunter, Stand Off, Gen-Ei Kyaku and similar cards

    :: Fixed an issue where Tribal Protector and other "multi-commit" foundations technically could not be used in some cases. Now (as it was prior) you can commit one of these cards even if you are only one foundation short. Other forms of "over-committal" are, of course, still not allowed.

    ----------

    (Link to the original LGR update thread, for reference)
    Last edited by Shaneth; 05-23-2016 at 03:37 PM.

  2. #2
    Member sdejarn2's Avatar
    Join Date
    May 2015
    Location
    Baltimore, MD
    Posts
    167
    :: Fixed an issue where Tribal Protector and other "multi-commit" foundations technically could not be used in some cases. Now (as it was prior) you can commit one of these cards even if you are only one foundation short. Other forms of "over-committal" are, of course, still not allowed.
    3.5.2.3 If you decide to commit cards:
    E.3.5.2.3.1 Determine the number of cards needed by subtracting the final value of the control check from the difficulty needed.
    E.3.5.2.3.2 Commit character and/or foundation cards in your staging area only until you have committed at least that many cards. Committing these cards is a single game event.
    Note: "Only until" means that you may not commit additional cards if you have already met or exceeded (i.e. due to effects) the required number.
    Your explanation of the change here makes perfect sense and I get the spirit of the rule of course but I don't think the rules document is as explicit on this topic as you might like it to be on the intended ruling. I realize I'm a newbie around these parts but I've rules lawyered a time or two in my days of gaming. The above quoted line change and the "Note" line seem to be the only things added/altered from v2 to this section that I noticed and do not read to me as explicitly and/or clearly ruling out the capability of a 1 foundation "over-committal" when a check falls short by a value of 2 or more and Tribal Protector (or a card that shares the same general ability) is used to pass the check.

    i.e. I attempt to play an attack with difficulty 5 and flip a 3, I initially choose to commit 1 foundation to close the gap needed to 1 and then choose to commit Tribal Protector which by it's ability counts as 2 so I've now "met or exceeded" the requirement. At this point I'm not allowed to commit more cards since I've now met or exceeded the target.

    To me this example order of events is how the game plays and the rules document reads to perform this task as there is sort of an implied "commit things one at a time" by the wording used even though by the rules these committals are considered a single game event and in theory happen simultaneously from a game state perspective. So this problem case you may believe to be handled under that interpretation as the game state could be checked for unnecessary committal but if so I don't believe it to be as clear as we might like it to be from the document.

    If this is perhaps an intended interaction the wording used in the note is fine of course but if not as seems to be indicated by your post I would suggest trying to be more specific about the case(s) where exceeding the target value is going to be allowed and how one can get into such a state.

    In thinking about it I believe the intention is for the only case where exceeding the target value is ever going to be allowed is if every foundation involved in this committal process counts as more than one foundation. If I attempt to play a 5 difficulty attack and flip a 4, I can commit 1 copy of Tribal Protector to pass the check. If I attempt to play a difficult 6 attack and flip a 3, I can commit 2 copies of Tribal Protector if I really want to in order to pass that check. I would think these cases are the only ways in which you want to allow the value to be exceeded so I'd imagine there could be a line item in the rules document more explicitly detailing these cases.

    Just my 2 cents of course.

  3. #3
    Head Judge
    Join Date
    Jun 2010
    Posts
    2,605
    I'd honestly prefer a functional errata of Tribal Protector to make its effect 'optional' instead of mandatory.
    hay guise, im ofishul

    Oldschool Deck articles! I II III IV V

  4. #4
    Senior Member Cetonis's Avatar
    Join Date
    Jul 2010
    Location
    Vernon, CT
    Posts
    3,375
    sdejarn: Yeah, we went over a few different options, but there are some interactions / technical hurdles (including some idiot's oddball champ character *cough* oops *cough*) that made it difficult to do things the way we'd ideally have liked. Sometimes the blessings of a solid technical doc come with a curse or two. Ultimately being a little looser with these cards is better than the reverse.

    Tag: That is effectively what this setup accomplishes, without adding to the errata list. I can see the case for choosing the latter, but all other things being equal having one less line of text on future cards is a strong tiebreaker.

  5. #5
    Member sdejarn2's Avatar
    Join Date
    May 2015
    Location
    Baltimore, MD
    Posts
    167
    Ok, I'm still confused after your replay so what exactly is the official ruling on that interaction in the first example I gave then? Is that "over-committal" scenario actually allowed as I suspect it is from the document as written or no?

  6. #6
    Senior Member Cetonis's Avatar
    Join Date
    Jul 2010
    Location
    Vernon, CT
    Posts
    3,375
    Yes, you can "over-commit" using Tribal Protector, but no more than whatever over-committal is provided by said Tribal. You can technically commit 1 blank foundation and 1 Tribal, as if your Tribal was one foundation. The only time you might not be able to "opt into" using Tribal as a single is if you have multiple copies of it, i.e. you can't commit 2 Tribals when you need 2 foundations total.

  7. #7
    Regular Member
    Join Date
    Aug 2014
    Posts
    252
    Quote Originally Posted by Cetonis View Post
    Yes, you can "over-commit" using Tribal Protector, but no more than whatever over-committal is provided by said Tribal. You can technically commit 1 blank foundation and 1 Tribal, as if your Tribal was one foundation. The only time you might not be able to "opt into" using Tribal as a single is if you have multiple copies of it, i.e. you can't commit 2 Tribals when you need 2 foundations total.
    Might want to add that to the Rules Q&A forum in the tribal thread.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Single Sign On provided by vBSSO