RAS Syndrome

冗長。

ボードゲームはプログラミングしやすい

前回の記事でゲームについて考えた。

ikngtty.hatenablog.com

結論だけ抜き出そう。

ゲームとは、 「プレイヤーが、以下のルールに沿って、アクションを選択し、結果を決める営み」 である。

// ルール1: 初期状態
def initialState(): GameState

// ルール2: アクション定義
def createAction(args: Any): GameState => GameState

// ルール3. 可能/禁止アクション
def isAvailable(action: GameState => GameState, state: GameState): Boolean

// ルール4. 結果判定
def getGameResult(state: GameState): GameResult

// ルール5. ゲームの状態のアクセシビリティ
def getGameStateInformation(state: GameState, player: Player): GameStateInformation

今回は、ボードゲームをプログラミングに落とし込むことについて少し考えてみる。

ゲームについてプログラミングでできること

以下が考えられるように思う。

機能1. ゲームの状態の管理

ボードゲームで言えばボードの代わりである。 ルールの演算などは全てプレイヤーに任せ、コンピューターは関知しない。 真っ白なキャンバスとして使うようなものだ。 アクションの可能/禁止も勝ち負けも気にせず、自由に状態を弄れる。

例えば詰将棋を作る時などは、この機能だけの方が都合が良いだろう。

機能2. ルールの施行

審判や、いわゆるゲームマスターのような役割を担う。 開始状態をセットアップし、プレイヤーの可能なアクションのみを受け付け、勝敗を判定する。

例えば将棋のオンライン対戦アプリなどは、機能1と2の組み合わせと言える。

機能3. プレイヤーの代行

いわゆるCPUプレイヤーだ。

例えばCPU対戦ができる将棋アプリは、機能1, 2, 3の組み合わせとなる。 また、CPU同士で戦わせて棋譜を量産しながらCPUのAIを強化する、なんてのは最近のトレンドだろう。

プログラミングが難しい/向いていないパターン

思いつくままに挙げてみる。 尚、私が個人で開発することを想定した難易度判定なので、最先端の商業ゲームが普通に実現しているようなことも挙げる。

アクションが肉体を使った物理的なものである

スポーツ全般が当てはまる。

肉体の操作は基本的にパラメータが非常に多く、情報量が多い。 まず、肉体の操作を正確にコンピューターにインプットさせるのも大変だ。 最低限、kinectだとかswitchのJOYコンだとかが必要になる。 インプット後も、物理演算等で計算量は多い。

代わりに情報量を減らすと、今度は再現度が減り、物理世界で行うゲームとは段々かけ離れていってしまう。 例えば、CLIの腕相撲ゲームを想像してみてほしい。 「相手は80kgの力で押してきています。あなたは何kgの力で返しますか?キーボードで数値を入力してください。」 紛うことなきクソゲーである。

また、CPUとの対戦は、やりがいが無いかもしれない。 何せ相手の力が80kgが800kgかはマシンパワーと設定変数次第なのだ。 こちらが苦労して何年も筋トレしたところで、CPUは一瞬のチューニングで追い抜いてしまう。

アクションがトークである

テーブルトークゲームというジャンルだろうか。 人狼やキャット&チョコレートなどが当てはまる。

機能1は簡単だ。 チャットでのやり取りをそのまま表示すれば良い。

機能2も簡単である。 ゲームマスターの真似をして、「それではみなさん投票してください。」と問いかけるだけだ。 しかしそれは即ち、大事な判定処理を人間に委譲するということである。 結果、コンピューターは大してやることが無い。 簡単だが効果が薄いのである。 コンピューターの最も得意なことは計算であるが、ここでは計算処理は出てこない。

では、判定処理をCPUが行うとどうなるか。 例えばキャット&チョコレートで言えば、説得力をCPUが判定するのである。 すると途端に難易度が跳ね上がる。 自然言語処理をした上で、人間の感情などを扱わなければならない。

また、機能3も非常に難易度が高いことは説明不要だろう。

アクションが絵である

「アクションがトークである」に近いが、プレイヤーの入力がめんどくさくなりやすいことも挙げられる。

ゲームの状態が複雑である

物理世界や現実世界を利用する類のゲームが当てはまる。 物理世界の難易度は「アクションが肉体を使った物理的なものである」でも述べているので、 ここではそれ以外の現実世界に関係するゲームを考える。

例えば、「ツイッターで先に100RT稼いだ方が先」みたいなゲームが当てはまる。 実際にツイートさせて測定できるなら簡単だが、コンピューターがRT数をシミュレーションしなければいけないとしたら大変だ。 フォロワー数、各フォロワーの趣味・嗜好、フォロワーとの関係性、世の中のトレンド、自身のツイート履歴による文脈、 などなど挙げだしたらキリがない。

また、仮想世界における政治シミュレーションゲームなども、リアルにすればするほど状態変数が増える。 かといって単純にするとクソゲーになる。

アクションにリアルタイム性が求められる

のは、実はそんなに難しくない。 例えば以下ではリアルタイム性のある早押しクイズをシミュレートしている。

早押しクイズでNode.jsの非同期処理とかイベント駆動とかを試す

まあでも、ターン性だともっと簡単なのは確かだ。

ボードゲームは簡単か

ボードゲーム(board game)とは、ボード(盤)上にコマやカードを置いたり、動かしたり、取り除いたりして遊ぶゲームの総称。盤上ゲーム盤上遊戯とも呼ばれる。

ボードゲーム - Wikipedia

とのことである。

ボード上の駒を指で弾いて相手のゴールにシュート!みたいなゲームだと大変だが、そうでない限り物理が出てくることは少ない。 サイコロやルーレット等は物理と言えば物理だが、これはランダムな値をコンピューターが出すだけで問題無いだろう。

ゲームの状態は基本的にボードで表現できる範囲の静的な情報しかない。 アクションもほとんどがコマやカードの操作だ。パターンは限られる。

総じて情報量が少ないのがボードゲームの特徴だ。 加えて、ターン性であることも多い。

上記のプログラミングが難しいパターンはほとんど回避できる。 また、ほとんどのボードゲームにおいて、先の展開を読んだ上での戦略的決定が重要となる。 そのため、コンピューターの演算能力が発揮できる場面は多い。

結論

ボードゲームは個人の趣味プログラミング対象としてとてもコスパが良い。 まあ、特に考えなくてもなんとなく分かっていたことではある。 だからなんだという感じだ。 なんだったんだろうこの考察。

おしまい。