月下人狼の闇鍋における陣営の適正分布

月下人狼では、「闇鍋」というモードの人狼がよく遊ばれています。これは、月下人狼に存在する役職をランダムに配役するモードです。

闇鍋における設定項目のひとつに「闇鍋セーフティ」があります。これは「なし」「低」「中」「高」などがあり、高くなるほど配役に対する制御が強くなります。現在では、このうち「低」が最も広く使われており、それ以外が使われる頻度はとても低いです。この理由として、まず「なし」はゲームが成立しない危険性が高いこと、そして「中」以上は村人陣営有利になりすぎることが指摘されています。闇鍋セーフティ「中」以上では各陣営の出現数に対する制御が行われます。「中」以上で村人陣営が有利になる理由はこの制御に問題があると考え、今回これを見直すことにしました。

そこで、まず現在までに開催された闇鍋45356部屋のデータを集計し、参加者のうちの各陣営の割合と、その陣営の勝率との関係を調べました。その結果が以下の図です。

f:id:uhyouhyo314:20170712235215j:plain

また、全体での村人陣営の勝率は50%程度であることも分かっていおり、これはセーフティ「低」のときの勝率とほぼ同じです。これに合わせるには、村人陣営の割合は55%〜60%程度がよさそうということが分かります。(実際は、闇鍋セーフティ「中」以上では占い師の出現率に高い補正がかかりますから、もうすこし厳しくてもいいと思います。)

その他の結果については以下のツイートを参照してください。

分析としては、村人陣営が55%〜60%はやや少ないような気もしますが、実際はその他に分類される役職がいくらか混ざることでちょうどいいバランスになると推察されます。人狼陣営は30%〜40%程度出現するのがよさそうです。妖狐陣営や恋人陣営は1人出現するくらいがちょうどいいように思います。

この結果をもとに近いうちに闇鍋セーフティ「中」以上を改修します。 7月13日に改修しました。

UbuntuでBluetoothマウスの接続時に自動的に速度の設定を変更する方法

環境

概要

Bluetoothマウスの接続時に自動的にxinputコマンドが走ってマウスポインタの移動速度の設定を変更するような設定をする方法を調べました。

結論

ファイルを3つくらい作ります。

/etc/udev/rules.d/50-mouse.rules

ACTION=="add", KERNEL=="input*", SUBSYSTEM=="input", ATTR{name}=="ELECOM BlueLED Mouse", RUN+="/usr/local/bin/mouse-help-script.sh"

ELECOM BlueLED Mouseの部分は自分のデバイスの名前に合わせて変更してください(デバイスの名前の調べ方は後述)。

以下の2つは実行可能にしてください。

/usr/local/bin/mouse-help-script.sh

#!/bin/sh
at now -f /usr/local/bin/mouse-help-script-2.sh

atを使用しているので、atが入っていない場合はインストールする必要があります。

/usr/local/bin/mouse-help-script-2.sh

#!/bin/sh
DISPLAY=":0.0"
HOME=/home/someone/
XAUTHORITY=$HOME/.Xauthority
export DISPLAY XAUTHORITY HOME

DEVICE_NAME="ELECOM BlueLED Mouse"


for i in `seq 0 9`
do
        if /usr/bin/xinput list | grep -q "$DEVICE_NAME"; then
                /usr/bin/xinput --set-prop "$DEVICE_NAME" "Device Accel Constant Deceleration" 2.0
                break
        fi
        sleep 1
done

HOMEとDEVICE_NAMEは自分の環境に合わせて適宜変更します。 また、ここではxinputによって"Device Accel Constant Deceleration"の値を2.0にしていますが、変更したい設定に合わせてここも適宜変更してください。

説明

Ubuntuでは設定からマウスポインタの移動速度を変更することができますが、マウスによっては移動速度を最低にしてもまだ速すぎる場合があります。 その場合の対処法はいくつかあり、AcrhWikiのマウスのアクセラレーション - ArchWikiが詳しいです。

xorgの設定に書く方法とxinputで設定する方法がありますが、自分の場合なぜか前者はあまりうまく行かないので後者で設定しています。実はxinputによる設定は一時的なものであり、システムを終了して次回起動したときには設定は元に戻っているためまたxinputで設定する必要があります。 前述のページではこれに対処するために.xinitrcにコマンドを載せておいて起動時に自動的に実行されるようにする方法が紹介されています。

しかし、自分の場合はこの方法は使えませんでした。なぜならBluetoothマウスなので、マウスが接続されるタイミングはシステムの起動より遅いです。実はxinputは接続されている機器に対してしか設定を行えませんので、起動時に設定を行う方法では対処できません。また、接続解除→再接続とすると、やはり設定が戻ってしまいます。 そこで、Bluetoothマウスが接続されたタイミングでxinputを実行できるような方法を調べました。

そのためにはudev rulesを作ります。udevはデバイスの接続を管理してくれる何かで、udev rulesを作ることによってデバイスが接続されたときに処理を走らせることができます。作ったudev ruleは所定の場所(Ubuntu 16.04 LTSの場合は/etc/udev/rules.d/以下)に置きます。

ACTION=="add", KERNEL=="input*", SUBSYSTEM=="input", ATTR{name}=="ELECOM BlueLED Mouse", RUN+="/usr/local/bin/mouse-help-script.sh"

中身はこれで、大雑把にいうと「ELECOM BlueLED Mouseという名前のデバイスが接続されたら/usr/local/bin/mouse-help-script.shを実行する」という意味です。(ここに書くべき内容を調べるためにudevadm monitorするなどの苦労もありましたが、省略します。) なのでこのシェルスクリプトにxinputコマンドを書いておけば解決かと思いきや、実はひとつ罠があります。 実はこの処理が走るタイミングは、xinputコマンドで当該デバイスの設定を変更可能になる(デバイスが認識されて利用可能になる)よりも早いです。したがって、用意したシェルスクリプトの中でxinputを実行しても設定変更できません。

これに対する対処法は、1秒待つことです。1秒待っている間にデバイスが認識されて、xinputから設定を変更可能になることを期待します。しかし実は、udev rulesにより実行されるスクリプトはudevの処理をブロックします。つまり、スクリプトの実行が完了しないとデバイスの接続時の処理が進まないため、sleepで1秒待ったところでデバイスが利用可能な状態にはなりません。

そこで、今回の方法ではsleepしてからxinputで設定変更するスクリプトをさらに別に用意し、それをatを介して実行します。この方法では、/usr/local/bin/mouse-help-script.shの実行はatにジョブを登録するだけなので一瞬で終わり、デバイスの認識処理はちゃんと進行します。atによって別に実行された/usr/local/bin/mouse-help-script-2.shは1秒待ってからxinputで設定を変更します。(実際には1秒たっても認識されていない可能性も考慮して、デバイスが認識されるまで最大10秒くらい待ち続けるようになっています。)

なお、atを使用する代わりに

nohup /usr/local/bin/mouse-help-script-2.sh &

とするような方法も考えられますが、これはやはりudevの処理をブロックしてしまうのでだめなようです。

バイスの名前を調べる方法

いくつかあると思いますが、次のコマンドで出てきた一覧から探すのが楽です。

xinput list

参考リンク

getBoundingClientRect()を使って要素のページ内座標を取得するよい方法

結論

function getAbsolutePosition(elm){
  const {left, top} = elm.getBoundingClientRect();
  const {left: bleft, top: btop} = document.body.getBoundingClientRect();
  return {
    left: left - bleft,
    top: top - btop,
  };
}

解説

Webページ中で、JavaScriptからある要素のページ内での位置を取得したいという需要がときどき発生します。 そのための方法は主に2通りあり、1つはoffsetTop, offsetLeft及びoffsetParentを用いる方法です。 もう1つがgetBoundingClientRect()を用いる方法です。これらはいずれもCSSOM View Moduleで定義されています。

後者のほうがより簡潔に記述できる上用途に適していると考えられますので、この記事では後者を取り扱います。 getBoundingClientRect()はある要素の位置や大きさの情報を返してくれるのですが、この位置情報は現在のviewportに相対的なものとなっています(CSSOM Viewをざっと読んだだけであまり理解していないのでこれが正しいのかどうか自信がありませんが、広くそのように理解されています)。 つまり、ブラウザの表示領域の左上を(0, 0)としてそこからの相対位置で示されています。 要素のページ内座標を取得するには、この値をページ内の位置に変換する必要があります。 従来広く用いられてきた方法は次のようなものです。

function getAbsolutePosition(elm){
  const {left, top} = elm.getBoundingClientRect();
  return {
    left: left + window.scrollX,
    top: top + window.scrollY,
  };
}

すなわち、ブラウザの表示領域の左上のページ内座標はページのスクロール量に一致すると考えられるため、それを足すことでページ内座標に変換するという方法です。

この方法はうまくいくように見えますが、実は問題がありました。 スマートフォンやタッチパネル付きのタブレットPC等で2本指のジェスチャーによりページを拡大・スクロールした場合、window.scrollXwindow.scrollYは正しくスクロール量を返す一方、getBoundingClientRect()はなぜか表示領域の左上ではなくページの左上を起点とするようになり、この方法だとスクロール量が2重に加味されてしまいずれた値が返ってしまいます。 なぜこの挙動になるのかは調査してもいまいち分かりませんでしたが、iOS10上のSafariLinux上のChrome46が共にこの挙動を示すことを確認しました。

この問題を回避するのが冒頭の手法です。 document.bodyは常にページの左上に位置すると考え、そことの差を取ることでページ内での座標を取得します。 この方法では要素の位置とページの左上の位置をともにgetBoundingClientRect()で取得するため、getBoundingClientRect()が基準とする座標がずれても問題なく動作できるという利点があります。 もしかしたらパフォーマンスが違うかもしれませんが、未検証です。

余談

要素のページ内での絶対座標を取得したい場面でよくあるのが、マウス等のイベントでマウスの要素内での位置を取得したい場合です。自分も今回そのケースで悩んでいました。 定石はイベントのpageX, pageYと要素の絶対座標から求める方法ですが、よく考えたらclientXclientYがあるのだからそれとgetBoundingClientRect()でいいのではないかという気がしてきました。

余談2

仕様書を読むとleftとかtopよりもxyを使ってこうしたほうがいいと思うのですが、ブラウザ(少なくともChrome)が対応していませんでした。

function getAbsolutePosition(elm){
  const {x, y} = elm.getBoundingClientRect();
  const {x: bx, y: by} = document.body.getBoundingClientRect();
  return {
    x: x - bx,
    y: y - by,
  };
}

量子人狼のルール

量子人狼のルールです。

量子人狼はもともとCISRA Puzzle Competition 2008 - Quantum Werewolfで紹介されたのが始まりと考えられています。ここでは月下人狼に実装されているルールを扱います。 月下人狼ルールはQuantum Werewolfにだいたい忠実に作ってあります。

まずこの記事では量子人狼のルールを説明します。

前提知識:人狼

量子人狼はその名の通り、人狼ゲームの一種と見なすことができます。ベーシックな人狼ゲームは、大雑把にいうと次のようなゲームです。

  • プレイヤーは村人陣営人狼陣営に分かれる。各プレイヤーには村人人狼占い師などの役職が与えられ、役職によってどの陣営に属するかも決まる(例えば、村人・占い師は村人陣営。人狼人狼陣営)。各プレイヤーの役職は本人のみが知っている。
  • 昼と夜の2つのフェーズを繰り返す。各フェーズでプレイヤーが死亡し、生存者が減少する。
  • 人狼が全滅した場合、村人陣営勝利人狼以外の数が人狼の数以下まで減少した場合、人狼陣営勝利。なお、人狼ゲームはチーム戦であり、勝利した陣営のプレイヤーは死亡者も含めて全員勝利となる。

人狼は会話ゲームであり、昼フェーズでは生存者による話し合いが行われます。これは、オンラインの人狼ではチャットや音声通話により行われます。オフラインの人狼、すなわち対面人狼では直に顔を合わせて話し合うことになります。昼フェーズの終わりには投票が行われ、最も多くの票数を集めた参加者は処刑され、死亡したことになります。 夜フェーズでは、いくつかの役職が秘密裏に活動できます。その中でも人狼たちは、話し合いのうえ誰か1人を襲撃して死亡させることができます。人狼たちの話し合いはオンラインの人狼では文字によって行うことになりますが、対面人狼では他の参加者が伏せている中で密かに起き上がり、ジェスチャーにより行うのが普通ではないかと思います。

以上のように、村人陣営の武器は処刑人狼陣営の武器は襲撃です。ただし、処刑は必ず人狼を処刑できるとは限りません。人狼ではない人を処刑してしまえば村人陣営は不利になります。

なお、以降の説明のために占い師についてさらに説明をしておきます。占い師は村人陣営の所属で、夜フェーズごとに生存者を1人指名し、その人が人狼であるか否かを教えてもらえるという能力を持ちます。

量子人狼のルール

次に、量子人狼のルールを説明します。

まず、量子人狼で登場する役職は、村人人狼占い師のみです。(他の役職による拡張を考えることも可能です。狩人や妖狐などはいけそうですね。)

量子人狼においても、昼フェーズ→処刑→夜フェーズ→……という流れは変わりません。違うのは、各プレイヤーの役職が定まっていないということです。普通の人狼の場合は、開始の時点で役職が決定されます。しかし量子人狼においては、これは定まっていません。このとき、全ての可能性が存在しています。例えば3人の場合、Aさんが村人でBさんが占い師でCさんが人狼、という可能性も、Aさんが人狼でBさんが村人でCさんが占い師という可能性も、全て存在しています。この場合(プレイヤー数3、配役:村人、占い師、人狼)は、可能性は{ 3! = 6}パターン存在することになります。

量子人狼では、各プレイヤーの行動に伴ってこの可能性が消失していきます。最終的に各プレイヤーの役職が定まり、その役職にしたがって勝敗が決められます。 人狼では夜フェーズに人狼占い師が能力を行使できますが、量子人狼では誰が人狼で誰が占い師か定まっていないのでした。そこで、その可能性が少しでも残っている人は全員能力を行使できます。

ただし、量子人狼では能力の行使の結果は確定したものではなく、代わりに可能性に影響を与えます。量子人狼のポイントは、パターンの書き換え・削減収束です。まず各役職の性質という観点から、パターンの書き換え・削減について説明します。

人狼の性質

人狼の場合は、襲撃対象として選択した人が死亡するのは通常の人狼と同じです。ただし、襲撃者が人狼であるパターンのみに影響します。つまり、3人量子人狼を考えて、可能性のパターンが以下の通りとします。

Aさん Bさん Cさん
1 村人 人狼 占い師
2 村人 占い師 人狼
3 人狼 村人 占い師
4 人狼 占い師 村人
5 占い師 村人 人狼
6 占い師 人狼 村人

Aさんが人狼の襲撃先としてBさんを選択した場合、影響するのはパターン3と4のみです。パターン3と4において、Bさんが死亡したということになります。

Aさん Bさん Cさん
1 村人 人狼 占い師
2 村人 占い師 人狼
3 人狼 村人(死亡) 占い師
4 人狼 占い師(死亡) 村人
5 占い師 村人 人狼
6 占い師 人狼 村人

この場合、Bさんは直ちに死亡とはなりません。まだ生存している可能性があるからです。

もちろん、BさんやCさんも人狼の襲撃先を選択します。例えばさらにBさんがCさん、CさんがBさんを襲撃先として選択した場合は以下の結果となります。

Aさん Bさん Cさん
1 村人 人狼 占い師(死亡)
2 村人 占い師(死亡) 人狼
3 人狼 村人(死亡) 占い師
4 人狼 占い師(死亡) 村人
5 占い師 村人(死亡) 人狼
6 占い師 人狼 村人(死亡)

このように、人狼パターンの書き換えを行う性質があります。

占い師の性質

次に占い師は、パターンの削減を行う性質があります。占い師の場合は、占い結果を得る必要があり、そのためには占い結果を決める必要があります。例えばAさんがBさんを占った場合を考えます。上の表ではパターン5と6ですね。このとき、Bさんが村人という可能性と人狼という可能性が両方存在します*1。このとき、占い結果はランダムに決定されます。この場合Bさんが人狼である確率*2{\displaystyle \frac{1}{2}}ですから、占い結果は50%の確率で人狼、50%の確率で村人になります。

ここでは、占い結果が村人に決定したとします。Aさんには村人という占い結果が通知されます。このとき、パターン6はその結果と矛盾するため、削減されます。つまり、占い後の可能性は次のようになります。

Aさん Bさん Cさん
1 村人 人狼 占い師
2 村人 占い師 人狼
3 人狼 村人 占い師
4 人狼 占い師 村人
5 占い師 村人 人狼

このように、占い師にはパターンの削減を行う性質があります。このパターンの削減により、量子人狼には占いの結果と矛盾しないように役職が定まっていくという特徴が定まっています。あるプレイヤーの役職が占い師に確定した場合、そのプレイヤーの今までの占い結果はすべて正しい結果となります。

処刑の性質

次に、処刑に目を向けましょう。量子人狼においても処刑があります。処刑された参加者は、確実に死亡します。つまり、全てのパターンにおいて死亡となります。ここで量子人狼のもう1つのポイント、収束が発生します。収束は、死亡率が100%になった(全てのパターンで死亡した)場合に発生します。多くの場合収束は処刑により発生することになります。

収束では、占い師の場合と同様に、死亡した人の役職をランダムに決定した上で、それと矛盾するパターンが削減されます。ただし、処刑により死亡が観測される場合は、逆に言うと処刑までは生きていたということになるので、処刑の前にすでに死亡していたというパターンは事前に削減されます。

例えば、次の表の状態を考えます。

Aさん Bさん Cさん
1 村人 人狼 占い師(死亡)
2 村人 占い師(死亡) 人狼
3 人狼 村人(死亡) 占い師
4 人狼 占い師(死亡) 村人
5 占い師 村人(死亡) 人狼

この状態からCさんを処刑した場合を考えます。まず、Cさんが既に死亡しているパターン1が削減され、次のようになります。

Aさん Bさん Cさん
2 村人 占い師(死亡) 人狼
3 人狼 村人(死亡) 占い師
4 人狼 占い師(死亡) 村人
5 占い師 村人(死亡) 人狼

この状態でCさんが死亡し、同時にCさんの役職が収束します。ですから、Cさんの役職が村人に収束する確率は25%、占い師も25%、人狼は50%となります。事前にパターン1が削減されたというのがポイントです。パターン1を消さなかった場合、村人20%、占い師40%、人狼40%となり確率が変わってしまいます。

特に、2つ上の表(Cさんを処刑する前の状態)からBさんを処刑した場合を考えてみましょう。このときパターン2〜5は全て削減され、Bさんは必ず人狼に収束することになります。

決着

量子人狼の決着については、基本的には普通の人狼と同じです。ただ、勝利条件が満たされているパターンが存在しているだけでは決着とはなりません。全てのパターンで決着条件を満たす必要があります。

まず、人狼が全て確実に死亡した場合は村人陣営勝利となります。逆に人狼陣営勝利となるのは、人狼と確定してかつ生存中の参加者が存在し、その数が生存者の半数以上となった場合です。このように生存中にも関わらず役職が確定しているという状況はいくつかの場合に発生します。例えば、最初の状態からAさんがBさんを占い、人狼という結果を出した場合を想定します。つまり、下の状態です。

Aさん Bさん Cさん
1 村人 人狼 占い師
2 村人 占い師 人狼
3 人狼 村人 占い師
4 人狼 占い師 村人
6 占い師 人狼 村人

ここでAさんを処刑し、占い師に収束した場合、次の状態になります。

Aさん Bさん Cさん
6 占い師(死亡) 人狼 村人

このときBさんが人狼である確率は100%となり、生存中にも関わらず人狼と確定した参加者が出現しました。このときは人狼勝利となって終了します。

この場合はパターンが1通りに決まってしまいましたが、より複雑なゲームの場合不確定性を残しつつ人狼が確定するということも起こり得ます。

ちなみに、このような収束に起因する連鎖としては、もうひとつよくあるパターンがあります。それは、参加者が人狼に収束した場合、その人が過去に襲撃対象に選択した人も同時に死亡するというものです。

確率表

量子人狼において重要なのが、確率表です。今までの説明において参加者が得られる情報は、投票結果と自らの能力の行使結果のみです。

参加者が得られる情報はもう1つあります。それが確率表です。確率表は、現在のゲーム状態を“確率”という形で参加者に提示するものです。例えば、次の状態

Aさん Bさん Cさん
1 村人 人狼 占い師
2 村人 占い師 人狼
3 人狼 村人 占い師
4 人狼 占い師 村人
6 占い師 人狼 村人

に対応する確率表は以下のものです*3。確率表は、昼になったタイミングと夜になったタイミングで表示されます。

Aさん Bさん Cさん
人間 60% 60% 80%
人狼 40% 40% 20%
死亡 0% 0% 0%

この表の作り方は単純です。例えばAさんが人狼である“確率”は、{N}を全パターン数、{W_A}をAさんが人狼であるパターン数とすると、{\displaystyle \frac{W_A}{N}}で求められます。なお、確率表では村人と占い師は「人間」としてまとめられています*4。人間である確率や、死亡率も同じように求められます。

これはなかなか興味深い結果ですね。AさんがBさんに人狼判定を出したにも関わらず、Bさんが人狼である確率が上昇するだけでなく、Aさんの人狼率も同じだけ上昇しています。この結果は、Aさんは占いを行うことで自らが占い師である確率を下げ、相対的に人狼である確率を上げたと見ることができます。

なお、Quantum Werewolfでは、確率表に「Aさん」などの名前が表示されずに「プレイヤー1」「プレイヤー2」のように匿名化され、各プレイヤーは自分の番号のみ知ることができます。

ドミナント人狼

量子人狼には、ドミナント人狼という概念があります。

配役のうち人狼の数は、常に1人ではありません。人狼では、プレイヤーの人数が増えた場合、それに合わせて人狼の数を増やすことでバランスを取ります。

ところが、人狼が複数人いた場合でも襲撃できるのは1人だけです。今までの説明を適用してしまうと、人狼1人あたり1人が襲撃された計算となってしまいます。そこで登場するのがドミナント人狼です。

量子人狼では、人狼の間に内部的に序列をつけておき、異なる役職とみなします。そして、人狼の襲撃は、生存している人狼のうち一番序列の高いもののみ有効とします。生存しているうちで一番序列の高い人狼ドミナント人狼と呼びます。

人狼が複数いる場合のゲーム状態の例を見てみましょう。ここではプレイヤー数は4、配役は村人、占い師、人狼1、人狼2とします*5

Aさん Bさん Cさん Dさん
1 村人 占い師 人狼1 人狼2
2 村人 占い師 人狼2 人狼1
3 村人 人狼1 占い師 人狼2
4 村人 人狼1 人狼2 占い師
5 村人 人狼2 占い師 人狼1
6 村人 人狼2 人狼1 占い師
7 占い師 村人 人狼1 人狼2
8 占い師 村人 人狼2 人狼1
9 占い師 人狼1 村人 人狼2
10 占い師 人狼1 人狼2 村人
11 占い師 人狼2 村人 人狼1
12 占い師 人狼2 人狼1 村人
13 人狼1 村人 占い師 人狼2
14 人狼1 村人 人狼2 占い師
15 人狼1 占い師 村人 人狼2
16 人狼1 占い師 人狼2 村人
17 人狼1 人狼2 村人 占い師
18 人狼1 人狼2 占い師 村人
19 人狼2 村人 占い師 人狼1
20 人狼2 村人 人狼1 占い師
21 人狼2 占い師 村人 人狼1
22 人狼2 占い師 人狼1 村人
23 人狼2 人狼1 村人 占い師
24 人狼2 人狼1 占い師 村人

このように、人狼2人が人狼1と人狼2として区別されています。ここでは、人狼1のほうが人狼2より序列が高いとします。

ここで、AさんがCさんを襲撃した場合、次のようになります。

Aさん Bさん Cさん Dさん
1 村人 占い師 人狼1 人狼2
2 村人 占い師 人狼2 人狼1
3 村人 人狼1 占い師 人狼2
4 村人 人狼1 人狼2 占い師
5 村人 人狼2 占い師 人狼1
6 村人 人狼2 人狼1 占い師
7 占い師 村人 人狼1 人狼2
8 占い師 村人 人狼2 人狼1
9 占い師 人狼1 村人 人狼2
10 占い師 人狼1 人狼2 村人
11 占い師 人狼2 村人 人狼1
12 占い師 人狼2 人狼1 村人
13 人狼1 村人 占い師(死亡) 人狼2
15 人狼1 占い師 村人(死亡) 人狼2
17 人狼1 人狼2 村人(死亡) 占い師
18 人狼1 人狼2 占い師(死亡) 村人
19 人狼2 村人 占い師 人狼1
20 人狼2 村人 人狼1 占い師
21 人狼2 占い師 村人 人狼1
22 人狼2 占い師 人狼1 村人
23 人狼2 人狼1 村人 占い師
24 人狼2 人狼1 占い師 村人

まず、パターン14とパターン16が削減されています。この理由は先ほど説明していなかったのですが、人狼人狼を襲撃することはできないため、人狼に襲撃された人が人狼であるというパターンは消えるからです。また、Aさんが人狼2であるというパターン19〜24は変化しません。これは、Aさんがドミナント人狼ではないからです。

一方、次の状況を考えましょう。

Aさん Bさん Cさん Dさん
1 村人 占い師 人狼1 人狼2
2 村人 占い師 人狼2 人狼1
3 村人 人狼1 占い師 人狼2
4 村人 人狼1 人狼2 占い師
5 村人 人狼2 占い師 人狼1
6 村人 人狼2 人狼1 占い師
7 占い師 村人 人狼1 人狼2
8 占い師 村人 人狼2 人狼1
9 占い師 人狼1 村人 人狼2
10 占い師 人狼1 人狼2 村人
11 占い師 人狼2 村人 人狼1
12 占い師 人狼2 人狼1 村人
13 人狼1 村人 占い師 人狼2
14 人狼1 村人 人狼2 占い師
15 人狼1 占い師 村人 人狼2
16 人狼1 占い師 人狼2 村人
17 人狼1 人狼2 村人 占い師
18 人狼1 人狼2 占い師 村人
19 人狼2 村人 占い師 人狼1(死亡)
20 人狼2 村人 人狼1 占い師
21 人狼2 占い師 村人 人狼1
22 人狼2 占い師 人狼1 村人
23 人狼2 人狼1(死亡) 村人 占い師
24 人狼2 人狼1 占い師 村人

やや人為的ですが、初期状態からいくつか人狼1が死亡した場合です。ここで同様にAさんがCさんを襲撃すると次の結果となります。

Aさん Bさん Cさん Dさん
1 村人 占い師 人狼1 人狼2
2 村人 占い師 人狼2 人狼1
3 村人 人狼1 占い師 人狼2
4 村人 人狼1 人狼2 占い師
5 村人 人狼2 占い師 人狼1
6 村人 人狼2 人狼1 占い師
7 占い師 村人 人狼1 人狼2
8 占い師 村人 人狼2 人狼1
9 占い師 人狼1 村人 人狼2
10 占い師 人狼1 人狼2 村人
11 占い師 人狼2 村人 人狼1
12 占い師 人狼2 人狼1 村人
13 人狼1 村人 占い師(死亡) 人狼2
15 人狼1 占い師 村人(死亡) 人狼2
17 人狼1 人狼2 村人(死亡) 占い師
18 人狼1 人狼2 占い師(死亡) 村人
19 人狼2 村人 占い師(死亡) 人狼1(死亡)
20 人狼2 村人 人狼1 占い師
21 人狼2 占い師 村人 人狼1
22 人狼2 占い師 人狼1 村人
23 人狼2 人狼1(死亡) 村人(死亡) 占い師
24 人狼2 人狼1 占い師 村人

先ほどとの違いは、パターン19と23です。このパターンでは人狼1がすでに死亡しているため人狼2がドミナント人狼となり、Aさんの襲撃が有効となります。


以上が量子人狼のルールです。

*1:パターン5ではBさんは死亡していますが、それはここでは考えないことにします

*2:正確には、各パターンの確率は同様に確からしいとした場合の、Aさんが占い師であるときにBさんが人狼である条件付き確率。

*3:ただし、確率表の作り方はQuantum Werewolfでは指示されていません。ここでは月下人狼で採用している方法を説明します

*4:もちろん、村人と占い師を分けて表示することもできます。月下人狼ではそのような拡張ルールも搭載されています。

*5:本当は人狼を2人にする適正人数は8人とかですが、プレイヤー8人の表を書くのはつらいのでここでは4人とします。