まずはゲームの仕様書を作ってみる

Pi STARTER（ラズベリーパイ用BASIC言語パッケージ）版
ひとりで遊べる人狼ゲームを公開中（要ラズパイ＆Pi STARTER）
http://www.ne.jp/asahi/chitose/net/download/jinrou/

それでは実際に私がどんな仕様書を書いたのか、実際に紙でプリントアウトしたものをお見せしながら説明していきます。ちなみによく言われるフローチャートは作りませんでした。プログラミングの作法からすれば邪道と呼ばれるかも知れませんが、自分としては作りたいものの姿を一度全部テキストに書き出した方が成果物のイメージが明確に沸いたのです。

なおこれは作り始める前の構想なので、実際にプログラミングしていくうちにいろんなことが変わっていきました。何せ１年以上かけて作ってたので、仕様が変わるのはしようがな…先進めましょ、先に。

信用値という構想は最初からありました。
これを決めとくと、例えば
　・投票で吊るされやすいとか
　・人狼に狙われやすいとか
　・ボディーガードが優先して守るとか
　・予言者が占う際の基準とか
というようなことがよりリアリティを持つと考えたのですよ。

この段階ではまだプレイヤー以外マジでB～Jだったらしい…。
後に名前の初期値を決め、さらにそれをユーザー任意で書き換え、保存しておけるようになりました。

各人の役職が決まるプロセスを記載しています。この時点でどんなプログラムになるのかをおおむね予測しながら書きました。
プレイヤーが人狼だった場合、パートナー人狼との会話があるという要素はコミック版の「人狼ゲーム」（原作：川上亮／漫画：小独活）より着想を得ました。たぶん実際に遊ぶ「人狼ゲーム」ではない要素だと思います。

実際の「人狼ゲーム」と違ってリアルに人間が会話するんじゃないから、コンピュータで動かすうえでどんなシステムにするのが良いのか、悩んだ末、「１人１日１回しかしゃべらない」という風に割り切りました。
「そんなん人狼じゃねーよ！」と言われるのは覚悟の上です。
しかしこうすることにより、口数の多い奴がターゲットをフルボッコにしてそいつの信用ダダ下げるみたいなことがなくなり、前述した「信用値」との相性が良いシステムになったと思っています。

本当に最初は会話の内容を乱数で処理してました。これは後に時間をかけて大きくリニューアルすることになりますが、とりあえず動くものを作るにはこれが最適解だったと思います。
会話内容と信用値の関係や処理の方法なども考えて記載しました。

ところで「人狼ゲーム」をプレイしたことのある方は実感として分かると思う（と言う私は現実にはプレイしたことがない）のですが、1日目と2日目以降では会話内容が大きく変わるはず。というのも2日目以降は実際に犠牲者が出たり、予言者や霊媒師が占ったりするためで、これによりプログラミングが一気に高度化します。実際これを書いている時点ではどうしていいか分からず「決め方は宿題」で逃げている部分が多いです。

プレイヤー以外の残り9人がしゃべったらプレイヤー発言です。

コンピューターの村人（B～J）がしゃべったら、いよいよプレイヤー発言となります。ここで書かれている「特定の人を選択する」処理は後に説明するサブルーチン「@WHO」にまとめられることになります。

いよいよ追放者を決めるための投票シーン。議論パートと違い、投票パートではプレイヤーの方が一番最初に投票する人を決めるようにしました。

ところで「人狼ゲーム」の指名の仕方って、「全員が同じタイミングで一斉に指差す」派と「各々がバラバラに指名する」派に分かれるみたいですね。私が参照したマニュアルだと「一斉に」のようでしたが、声優がやってる人狼対決みたいなの見てると「バラバラ」にやってるっぽい。これ、バラバラだと指名された者が指名した者にいい感情を持たないから、仕返し指名みたいなのが発生しますよね。これはゲーム性に大きく影響する部分です。
私のプログラムでは、結局「バラバラ」（というか変数順でA→Jの順に処理）を採用しました。これが正解だったかはちょっと分かりません。

ここで考えた「誰を指名するか」についての判断方法、すなわち
「全員の信用値に1d6（サイコロ1個振った値）を乱数で追加して、合計値比較して最も結果が高かった（または低かった）ものを選択する」
は、後に最大信用判定（@MAX）と最小信用判定（@MIN）にまとめられ、これ以外のいろんな処理で使われるコア的なサブルーチンとなりました。
実際のプログラムでは、最大信用（A～J[4]）が2、最小信用（A～J[4]）が1となっているので、たぶん作ってる最中に気が変わったのでしょう（笑）。

ここで霊媒師のための処理、すなわち「夜に追放されたのはどのプレイヤーか」の要素を入れています。
あとここでゲームの決着がつく可能性があるため、ゲームエンド判定を入れています。

いよいよ夜のイベント処理ですね。ドキドキ。
最初はボディーガードが誰をガードするかを決める処理を書いています。
なお「前日選んだ者は連続でガードできない」というルール上の縛りがあるので、各ブレイヤー変数に「前日守られたか？」の要素を追加しました。
作っていくと考えることいろいろ出てくるもんだなぁ。

続いて人狼の処理。やることいっぱいあって大変だなぁ。
まずプレイヤーが人狼でなおかつ仲間が生きていると、仲間が「こいつを襲わないか」と提案してきます。これマニュアルだと「アイコンタクトやジェスチャーで襲う人を選んでください」とかしれっと書いてあります（笑）。実際のプレイではどうしてるんでしょうねこれ。
また人狼が襲う者を決めたら、今度はそいつがボディーガードに守られているかどうかも判定しなきゃならないんです。うわーこんなにめんどくさいゲームだと思わなかったよマニュアル6ページしかないのに（汗）。
なお朝の発表タイムのため、このとき食われたプレイヤーが誰なのかを記録しておかねばなりません。ふぅ。
この書面では信用値を-1するとなっていますが、実際のプログラムでは信用値を後にエンディングで使う構想があったため、プレイヤー追放／死亡フラグ変数（A～J[6]）の方をいじって解決しています。
こんだけ仕様書から逸脱しまくってて、これチーム開発してる案件だったら打ち首ものですよね。

続いて予言者処理。ここで登場する「預言者専用変数」なるものは占われた中に人狼が何人いるかをチェックしている…のですが、最終的には活用されなかったような（汗）。でもプログラムにはこの変数が残存しています。こういうのはバグではないにせよ、いつかちゃんと直さないとなぁ。

なお、実際のプログラムでは人狼処理の最中で予言者処理に飛ばし、割り込み的に予言者処理から先にやっています。この理由は、人狼の仕事が済んだ後だと殺されたプレイヤーが占いの対象とならないためです。者は人狼が誰を食うか分からない状況で占いを行なうため、人狼が仕事をする前に占いだけ済ませとく必要があります。これはマニュアルの記載された処理順序（人狼→予言者）と逆になりますが、プログラム上必要と判断しそのようにしました。実際作り始めてみないと分からないものですこういうのは。

今度は霊媒師処理。夜は続くよどこまでも。
さすがに疲れてきたのか、この仕様書は思いっきし間違ってますね。
追放された人は既に決まってるんだから調査するも何もないっつーの！
ここは機械的に追放されたものが人間だったか人狼だったかを表示するのが正解です。もちろんプログラムはそうしています。

霊媒師の方にも「霊媒師用変数」なるものがあるけど、プログラムを見直す限りこれも不発弾っぽいなぁ。いずれアップデートする日が来たら見直すことにしようっと。

あたーらしい、あさがきた、きぼーうのーあーさー♪
夜明けに待ち受ける運命は、はたして希望か絶望か。
いよいよ諸々の処理が終わって犠牲者の発表タイムです。
ここでゲームエンドか翌日に続くかの判定を行っています。

エンディング処理。仕様書と完成物では内容が全然変わっています。
なんかえらく裏切り者にドラマチックなラストを考えていたんだなぁ、作っている最中はそんなことすっかり忘れてたわ（笑）。
でも裏切り者がこのゲームの中で立ち位置一番難しいと思います。皆様そう思いませんか？

と、いうことでラストまで一気に仕様書をスキャンしてコメントしました。
これからプログラミングする方に向けての参考資料（いやむしろ悪い見本）と自身に対する備忘録でもあります。

ちなみにこれで全部じゃありませんからね。
後に2日目以降の会話パターン（誰かが予言者宣言したらそれに呼応する奴が現れるとか、嘘吐きの存在が確定したときの会話内容追加とか）、それに投票が同数だった時の決選投票などの処理が加わるので、これと同じくらいの枚数が追加仕様として加わることになるんです。ほんとこれが仕事だったらプランナーは切腹ものだなぁ。

ともあれ最初に決めた仕様書に基づくと、いったいどれくらいの変数が必要になるのか…次回は変数表、いってみたいと思います。