この文章について
ITエンジニア・ボードゲーム愛好家のヴァレンティン・チェルノコフ(Валентин Челноков)氏は、様々な種類のボードゲームをコンピュータ上で簡単に実装するためのフレームワークの開発に取り組んでおられ、これを "Dagaz(ダガズ) Project" と名付けています。
同様のものとして1998年に開発された "Zillions of Games" というソフトウェアが極めて有名ですが、その仕様には問題点や限界が多く見られます。 チェルノコフ氏は ZoG の問題点を解決した新たなソフトウェアを開発すべく、これまでに5年以上の歳月をかけて本体・デモを合わせて総計数十万行に及ぶコードベースを実装し、極めて汎用的で利便性の高いフレームワークを構築してきました。
しかしそれにもかかわらず、その知名度はフレームワークの完成度に見合ったものとなっていないのが現状です。 その一因としては、ボードゲームマニアのコミュニティの間でDagazの存在が十分に周知されていないことが大きいと言えるでしょう。 氏が行っている宣伝活動は氏自身の母語であるロシア語での解説記事執筆が主であり、英語圏のコミュニティにDagazのインパクトが未だ届いていないのです。
今回チェルノコフ氏がボードゲームのオンラインマガジン "Abstract Games" 誌に執筆した記事 "Meet the Dagaz!" は、氏が Dagaz に関して執筆した2番目の英文記事であり、Dagazプロジェクトの概要・歴史・コンセプトを簡潔に説明したものとなっています。 本稿はチェルノコフ氏の許諾を得て、その記事を日本語に翻訳したものです。 特に補足が必要と思われる箇所については、注釈として訳注を付けています。併せてご覧下さい。 私の英語力は大変拙いものであるため、本稿には少なからぬ数の誤訳が含まれている可能性があります。 また意訳しているため、文の構成が原文と一致していない箇所があります。 誤りがありましたら訳者まで厳しくご指摘頂ければ幸いです。
なお、DagazプロジェクトはGitHub上で公開・配布がなされています（公式サイト(動作デモ有り)、本体リポジトリ、公式サイトのリポジトリ）。 ぜひ、公式サイト上のデモに実装されているゲームを色々と試してみて下さい。
- 原著者：Valentin Chelnokov
- 日本語訳：yumiya (stepney141)
- ソース：Dagaz - THE NEW ABSTRACT GAMES
※2022-12-09：誤訳や日本語としておかしい文章を修正
訳本文
私が名付けた "Dagaz" というプロジェクト名は、全23個の古代ルーン文字のひとつ"ᛞ"に由来しています。この文字が持つ意味の解釈の一つは「復活(revival)」です。 このルーン文字の形に私はボードゲームの駒を連想しますし、さらには「ゲームを遊ぶ人・ゲームを作る人双方のための汎用的なゲームソフトウェアを作り、これを用いてアブストラクト・ゲームにより興味を持ってもらいたい」――私のそのような考えが、文字の意味ともぴったり対応しているように思われるのです。
2つの出来事がきっかけで、私はボードゲームにのめり込むようになりました。 1つ目は、ドミトリー・スキュルーク氏（彼はロシアの作家で、囲碁・チェッカー・マンカラ系ゲーム（中でもアフリカに分布する系統のもの）の偉大な愛好家です）にお会いしたこと。 2つ目は、それと同時期に "Zillions of Games"（訳注：以下、"ZoG"と表記1）という汎用ボードゲームソフトウェアに出会ったことです。 運の悪いことに、私がこのソフトを知った頃には既に、ZoGに対する界隈の関心は衰え始めていました2。 ですが私はそんな状況を尻目に、ZoG上にいくつものゲームを実装しては、 ZoGについての解説記事を大量に執筆するという活動を続けました。 ZoGでゲームを実装する際には、 "Zillions Rules File"（以下、省略して "ZRF" と表記します）という独自のスクリプト言語を使用してゲームのルールを記述するのですが、 ZRF の強力さにはまさしく心を揺さぶられるものがありました。 ルールも見かけも全く異なる別々のゲームをこんなにも沢山作れるなんて、それ以前の私にはまるで想像もつかないことだったのです。
しかし、 ZRF の扱いに習熟すればするほど私はその欠点にもだんだんと気付いていくこととなりました。 その欠点とは「ZRF で簡単に実装することが出来るのは、極めて単純な――特にチェッカーやチェスに類似している――ルールのゲームのみである」ということです。 マンカラなどをはじめとしたより複雑なゲームを ZRF で実装しようとすると、ルールの記述は巨大で漠然としたものになり、動作も低速かつ信頼性に欠けるものになってしまいます。 この問題に直面した私は解決策を求めて、"Axiom Development Kit" を活用するようになりました。 これはグレッグ・シュミット氏が開発した ZoG の拡張プラグインで、DLLファイルとして ZoG に読み込ませることで動作します。 Axiom を用いることでリスモマチア(Rithmomachia)（AG15を参照）などの比較的複雑なゲームも実装できるようにはなったのですが、これを使っても実装はやはり難解で時間を食うものになってしまうのです。 まだこの他にも欠点があります。というのは、Axiom と ZoG はいずれも Windows 上でしか動作しないのです。しかし私が求めていたのは、クロスプラットフォーム対応でどこでも動く、何ならスマートフォン上でも動作するソフトウェアでした。
以上のような欠点を解消したいという視点で考えると、開発に利用できる技術は自ずと限られてきます。 ほとんどあらゆるモダンなWebブラウザがネイティブにサポートしているプログラミング言語と言えばただひとつ、それは JavaScript です。 Javaアプレットを触るという選択肢は取りたくありませんでした。何しろ、今や時代遅れで不便な技術ですからね。 Web Assemblyもまた、別の理由から私にとっては適しませんでした。 というのも、私の目標は「あらゆるユーザーが自由にオープンソースのコードを参照でき、ソフトの仕組みを理解して、ZoG 同様にしかしずっと簡単に自分でゲームが作れるようにする」ことだったからです。
もちろん完璧なアプローチというものは存在しない訳ですから、当然JavaScriptという案にも欠点はあります。C++やJavaといったプログラミング言語と比較して、JavaScriptでシステムを書くと、ユーザーが改造しやすくなる代わりにパフォーマンスが比較的低くなってしまうのです。 幾度も失敗を重ねた後、私は、ゲームを動かしながら ZRF を直接読み込んで解釈するというのは動作速度の問題から不可能らしいということに気付きました。 結局、私は ZRF を JavaScript に変換する "Z2J" というユーティリティを作ることでこれを解決しました。 Z2J で変換されたルール記述のコードは「自動生成臭」が強く、人間が直接編集するには不向きな難しいものですが、それでも ZRF のようにルール記述として解釈可能なようになっています。
図1：ロシアン・チェッカー
私はまず、ロシアン・チェッカー（ルールはこちらを参照）から実装を始めました。 個人的に、この系統のゲームはあまりに過小評価されているという思いを常に持っていたからです。 このゲームの複雑なルールをきちんと理解できなくては、これ以上のあらゆる開発は無意味でしょう。
このゲームの注目すべきルールとして、まず「着手の複数性」があります。 これは「一回の着手において、立て続けに複数回連続して駒を動かすことが出来る」という大変重要な決まりです。 チェッカー類に関して他に重要なこととして、「着手の優先順位」というルールの実装をしたことが挙げられます。 このルールは、もしも取ることが出来る相手の駒があるならば必ず取らなくてはいけない、というものです（例え相手の駒を取ることで自分が不利になるような状況であってもです）。 このゲームのために私が最初に考えた「着手の優先性」の実装は、後に他のゲームの実装に移った際に根本から再考・修正をしなくてはならなくなったのですが、ともあれこのメカニズムがDagazプロジェクトの基礎をしっかりと形作ることになりました。
チェスにおいては、「複数の駒が一回の着手で一度に移動する場合がある」（例：キャスリング）ということに私は気付かされました。 さらに、「駒が動けるからと言って必ずしもその駒を動かしていいとは限らない」という性質もあります――例えば、キングがチェックをかけられてしまうような場所に自分からキングを動かすことは決してやってはいけないことになっています。 このため、私はチェックメイトを判定するアルゴリズムを実装する必要がありました。 チェックメイト判定（禁止手排除）はチェッカーの「着手の優先性」よりも困難です。何故なら、禁止手排除は「駒を取る手」と「駒を取らない手」の両方に適用されるからです。 また、チェッカー系ゲームでは禁止手について様々な判定基準が存在しうるため、これも単純とは程遠いと言えます。 可能な限り多く相手の駒を取らなければならないというゲームもある一方、例えばフリジア・チェッカー（AG10を参照）などのゲームではそれに加え、「成った（昇格した）」駒を先に取るという優先順位が設けられています。
これらのとても複雑な概念をZRFの判定ロジックで記述することに貴重な時間を割き、さらにそれをJavaScriptに翻訳するなんて、例えそのやり方を知っていたとしてもそんなことをしている余裕は私にはありませんでした。 とにかく、そのようにしてZ2Jで得られるコードはまるで非効率だったため、直接JavaScriptで判定を書いてやる方がよっぽど理に適っていました。 というわけで、私はDagazにおいてあくまで駒の動きの基本的なルールを書くことにのみZRFを使い、複雑な判定は拡張機能として直接JavaScriptで書くことにしました。 ZRFで記述された基本的なルールに従って大まかな合法手の一覧を生成した後、ZRFでの表現が難しい処理を拡張機能で合法手に施してから、盤・駒の画面表示を更新します。 拡張機能では、複雑な判定や着手のフィルタリングなどといった様々な追加的処理を効率的にこなすことが出来ます。
図2：アタリ碁（ポン抜き囲碁）
アタリ碁3（ルールはこちらを参照）は、私が上で述べた仕組みの実例としてぴったりのゲームです。 囲碁の基本的な着手の仕方は大変シンプルで、石を盤上の空いた場所（交点）に置くだけです。 しかし、あらゆる場所に石を置けるという訳ではありません。自分の石の呼吸点がなくなるような手を自分から打つのは「自殺手」であり、そのような着手は禁止されています。 プレイヤーは、自分が石を置くと自分の石の呼吸点（石の上下左右方向に隣接する空白の点）が無くなってしまうような場所には、自分で石を置いてはいけません。また、石の一団が活きているためには、最低一つの呼吸点を持っていなければなりません4。 ゲームは次のように進行します――以上の原則を踏まえ、プレイヤーが着手した際、自分が置いた石によって対戦相手の石の呼吸点が全て潰されているかどうかを判定します。もしも相手の呼吸点がなくなっていたならば、相手プレイヤーの石を取り、盤上から取り除きます（アタリ碁では、一度でも相手の石を取った時点で自分の勝利となります）。 これらの判定と確認はZRFで記述するにはあまりに困難かつ厖大であり、ここで拡張機能の出番となるわけです。
Zillions of Gamesの動作を色々と試していた頃、私はZoGでの囲碁系ゲームの実装に関して他にも問題を見つけました。 大量の石を一度に取ると（このような状況が起こることは稀ですが、起こり得ない訳ではありません）、バッファオーバーフローが発生してソフトがクラッシュするのです。 ZoGは、各着手とそれによって発生する盤上のあらゆる変更を（ZSG棋譜という形式の）テキストとして保存します。 履歴には「この場所に石を置いた」という着手それ自体の情報のみならず、置かれた石とそれに隣接する石についてのあらゆる属性情報――どちらのプレイヤーの石か、石の位置はどこか、石は取られたか否か、など――も保存されるのです。 しかし囲碁においては、現在の盤面にたった一個でも石を置くだけで次に取られる石が完全に決定されるので、石がどこに置かれたのかさえ分かっていればそれで事足りるわけです。 囲碁やチェッカーなどのゲームでは、石を捕獲する際に石を盤上から除去する操作が伴う場合があります。Dagazではこのような捕獲を、着手の情報からゲームのルールに従って直ちに情報が求まる「副次的現象」としてみなしています。 プログラムのコア部分は、与えられたゲームのルールに則り、全ての変更と副次的現象をいつでも復元して自動で単一の変更の形に調整することが出来るようになっています。したがって、あらゆる情報を棋譜のテキスト内に詰め込む必要はありません。 結果、保存される着手の履歴は簡潔でスッキリとしたものになっています。
まだ他に1つ、Dagazが解決策を提示している既存の問題があります。それは、盤上の駒の位置をどうやって決定して画面に描画するかです。 ZoGでは「駒の属性を"Yes = 1"や"No = 0"のような感じで記述したビットフラグを複数持っておき、それらを各々の駒に割り当てる」という方法を取っていました。 これをチェスのキャスリング（ゲーム開始から今まで動いたことがないキング・ルークを一手で入れ替える操作）を例に解説しましょう。 ZoGのプログラムは駒に関するビットフラグを内部的に持っており、その中には「これらの駒は、キャスリング可能な条件から外れるような動きをしたか」というフラグも含まれています。キングやルークの駒が動くと、このキャスリング判定用のフラグがNoからYesに切り替わり、プログラムはこれを参照して「キャスリングは出来ない」と判断するというわけです。 Dagazは、ZRFが抱えていたデータ型に関する制限を回避しています。 真偽値以外にも、他のあらゆる種類の属性とそれに適する型の値を内部に持っておくことが出来るのです。 例として、穴(house)の中に入れる石(seeds)の数を表示するために整数型の値を使用しなければならない、マンカラ系ゲームの実装を見てみましょう。
図3：オワレ
オワレ（ルールはこちらを参照）はアフリカのマンカラ系ゲームの中でも最も有名なものです。 ゲームは穴(house)1つにつき各4個ずつ石(seeds)を入れた状態でスタートします。 各手番では、まずプレイヤーは自分の陣地である6つの穴（両サイドの一回り大きな穴は「スコアリング・ハウス」といいます）の中から1つを選びます。 次に、その穴の中にある石を全て取り出し、その1つ右隣の穴を起点にして半時計回りの順番で、取り出した石を各穴に1個ずつ落としていきます――このプロセスを「石撒き(sowing)」と言います。 ただし、スコアリング・ハウスには石を撒きません。またスコアリング・ハウスが石撒きの起点になることもありません。 「最後に石を撒いた穴が対戦相手の陣地にある」なおかつ「石を撒いた結果その穴に2個または3個の石が入っている」場合、自プレイヤーはその穴の中の石を全て捕獲します。捕獲した石は穴から取り除き、自分のスコアリング・ハウスの中に移します。 加えて、最後から1つ前の穴も上の条件を満たしていた場合は同じように石を捕獲し、さらにその1つ前も条件を満たしていればまた同様に...という具合で、条件を満たさない穴にぶつかるまで時計回りに遡って捕獲を続けます。 以上のルールに従い、より多くの石を捕獲して自分のスコアリング・ハウスに移すことを目指すのがこのゲームの目的です。
Zillions of Gamesでマンカラ系ゲームのロジックを実装するのは、様々な理由から困難です。 まず最初のハードルは、このゲームで使う石の画像がたった1種類・1枚だけであるということです。 ZoGでは、「一つの穴に同じ種類の石や駒が複数個存在している」という状態を描画することができません。しかも描画処理をユーザーがプログラミング言語で拡張することも出来ないため、ZoGにおいてこの問題を直接どうにかすることは不可能です。 このためZoGでは、異なる数の石が穴に入っているという情報は、それぞれ別の種類の駒が存在する状態として記述してやる必要があります。言い換えると、石が1個あるという情報は内部的には駒1個が存在する状態として、石が2個以上という情報は内部的にはまた別の種類の駒が1個存在する状態として、それぞれ符号化します。 この方法では、対応する個数の石の組を記述するために必要な画像の数が増える問題が生まれます。 ZRFには整数値や整数の演算に関する機能もないので、この方法においても通常の加算と減算をエミュレートするためにビットフラグを利用しなくてはならず、実装は依然として複雑になります。 Axiom Development Kitでは整数演算が追加されていますが、それを使ってもなおマンカラ系ゲームの実装は難しいままです。 Dagazでは、このようなゲームの構造をもっとずっと単純に記述出来るようにしました。 しかも、この方が動作がより効率的になる傾向まであるのです。
図4：カラム・チェッカー
ロシアン・カラム・チェッカー（詳しくはAG1などの号を参照）――バシュネ(Bashne)という名前でも知られています――もマンカラ系のゲームとよく類似していますが、ひとつだけ相違点があります。 それは、このチェッカーではマンカラのように石を一つの穴の中にただまとめておく訳ではなく、石を一つにまとめる順番も重要な要素になっているということです5。 特定の順序で配置された要素を持つ"列(column)"を表現するのは整数値だけでは不十分なため、私はDagazが内部で保存している属性により多くの種類のデータ型を追加しました。 一つの列の中に石がどのような順番で積み重なっているのかを記述するため、Dagazでは属性情報として文字列を利用しています。 実際の所、Dagazでは配列でも他のどのようなデータ構造でも利用可能なようにはなっているのすが、外部ファイルへの保存のしやすさを考えて、文字列を使うのがベターかと個人的には思っています。 ソフトウェアレンダリングを用いて駒や石を表示するというのは、駒や石をプログラムで制御する上で非常に強力な機能でもあります。 このオプションをどう利用するかの例を解説しましょう。 囲碁には「スーパーコウ（超コウ）」というルールがあります6。これは、以前の盤面の状態が再び出現するような手を打ってはならないというものです。 このルールに従った禁止手を可視化するために、「禁止手になるからこの交点には石を置けない」という意味として盤上の交点の上に四角形を描画します。この正方形は駒や石として扱われる訳ではなく、単に画像として盤上に表示されます。 連珠（AG5とAG6を参照）では局面に応じて禁止手も変化しますが、禁止手の可視化には囲碁と同じく、ソフトウェア側で描画される四角形の仕組みを採用しています。
図5：連珠
局面を前の状態に戻すことを禁止するゲームは、かなり複雑になりえます。 モラバラバ(Morabaraba)（ルールはこちらを参照）というゲームは、盤上の空いている場所に自分の駒（このゲームでは"牛"と呼びます）を並べ、自分の"牛"を3匹並べた列（このゲームでは"ミル(mill)"と呼びます）を作ることを目指すものです。 プレイヤーはミルを1つ作ったら敵の牛を1匹「撃ち」、その牛を盤上から取り除きます。撃たれた牛はその時点で二度と盤上に置くことが出来なくなります。 ミルを構成している牛は、相手の牛が全てミルになっていない限り撃たれることはありません。 別の新しいミルを作るために分解されたミルは、次の手番で再びミルになることは出来ません。 図6には赤いバツ印が描かれていますが、これは直前の局面で壊されたミルの位置を表すものです。 しかし、バツ印が付けられた場所であっても、この手番でミルを再び作り直さないならば、次の手番以降でそこに牛を置くことが出来ます。
図6：モラバラバ
この「盤上に駒や石とは関係ない画像を表示する」という機能は、反復同形を禁止する以外の用途にも利用することが出来ます。 ゲームの中には、ゲームに関する何らかの情報がプレイヤーに隠されたまま進行する種類のものがあります。 普通、そのような種類のゲームと言えばカードゲームなどが代表的ですが、チェス系のボードゲームでも同じ類のものがあります。 暗闇チェス(Dark chess)というゲームでは、プレイヤーは自分の駒が利いているマス以外のマス目の情報を把握することが出来ません。 同じアイデアを他のチェス系ゲームに持ち込むことも可能です。
図7：暗闇四人将棋
暗闇四人将棋は四人将棋の変種です。 四人将棋は、日本の有名な7四人向けゲームです。 小型・中型の盤で遊ばれる他の伝統的な将棋類と同じく8、四人将棋は「持ち駒」のルールがあります。これは、「獲得した相手の駒を自分が保有し、自分の駒として使用することが出来る」というものです。 盤上にある駒を動かす代わりに、プレイヤーは自分の持ち駒を盤上に新しく置くことが出来るのです。 四人将棋の場合プレイヤーは4人いるので、4枚ある王将が1枚取られてもゲームは依然として進行し続けます。 獲得した駒は王将も含めて全て自分の持ち駒となり、王将を持たないプレイヤーはそれ以上ゲームを続けることは出来ません9。 そして、四人将棋は「暗闇で指す」バリエーションもあります。つまり暗闇チェスと同じように、「戦場の霧」という概念――ここではすなわち「自分の駒が利いていないマスの情報を隠す」ということ――を導入したのが、暗闇四人将棋という訳です。
これらの「暗闇のゲーム」が持つ構造的な特殊性を発展させて、Dagazでは空のマス目・駒があるマス目の両方を隠すための2つの特別な機能が利用できるようになっています。駒を「半透明」の状態にできる上、必要に応じて、マス目が空かどうかに関わらず、新しいレイヤーを追加するようにしてマス目の上にさらに画像を被せることができます。 個々の駒の表示は、他の駒の利きに入っているか否かによって制御されます。 もしも敵の駒が自分の駒の利きに入っていないならばその駒は表示されませんし、自分の駒についても同じようなチェックが行われ、敵の駒の利きに入っていない自分の駒は半透明になって表示されます。 原則的には、このようなチェックをするだけで隠す必要のある駒は全て隠すことが出来るはずです。 しかし、マス目が空なのかそれとも半透明の敵駒があるのかまでも明らかになるわけではありません。 このため、私はあるユーザーから「自分の駒が利いていない空のマス目にも目印を付けて欲しい」という要望を受けることになりました。 その解決策として、盤上に「雲(clouds)」を描画するようにしました（図7参照）。 「雲」は、そのマス目が自分の攻撃の範囲外にあることを示すためにソフトウェア側で描画された画像です。 プレイヤーは、現在の手番で「雲」がかかったマス目の中に半透明の敵駒が存在する可能性があり、そのマス目が空であるかどうかは分からないことに留意します。 ですが、「雲」も駒も存在しないマス目が正真正銘の空っぽであることは明らかです。
図8：スラカルタ
このような抜本的な変更は、ゲームの表現をより良くすることのみに貢献している訳ではありません。 ガラ(Gala)（"農民のチェス(Farmer's Chess)"としても知られています）のようなゲームでは、駒が移動中に行き先を変えることがあります。 スラカルタ(Surakarta)（AG13を参照）というインドネシアのゲームでは、より興味深い状況が見られます。 このゲームにおける「相手の石の捕獲」の概念は、盤に描かれている合計8つのコーナーループのうち少なくとも1つに沿って自分の駒を動かし、相手の駒の上に着地してそれを取るという動作からなっています。 「捕獲」「非捕獲」のどちらの移動も、空のマス目を対象とした任意の方向への単一ステップとして実行されます。 このため、Zillions of Gamesのように「捕獲」の着手を開始位置から終了位置までの直線的な移動として表示すると、「捕獲」の移動が「非捕獲」の移動と混同されてしまう可能性があり、プレイヤーを混乱させるだけになってしまいます。 Dagazにおいては、駒の動きのアニメーション表示が可能なようにしました。 駒や石を動かすと、直線移動・斜め移動・曲線移動のいずれであろうと、駒や石が複数の地点を順番に通過するような動きをしても、その軌道全体がアニメーションとして表示されます。 スラカルタなどの一部のゲームでは、この機能は特に重要です。 また実用的な意味以外でも、この表示は視覚的に優れたグラフィックエフェクトとして機能します。
図9：ウル王朝のゲーム
最後に、ウル王朝のゲーム(Royal Game of Ur)について触れておきましょう10。 このゲームは長い年月の中でルールが完全に失われてしまい、発掘された当初は誰もその遊び方を知りませんでした。 歴史的見地から再現を試みたルールがいくつか提案されていますが、中でも私はこのルールが特に好きなのです。これは私の友人であり、作家でボードゲーム普及家のドミトリー・スキュルーク氏が考案したものでもあります。 当然ですが、Dagazプロジェクトではこのゲームを見逃さずに実装しているんですよ！
総括すると、私はボードゲームをより手早く実装するための便利なツールを皆さんにご提案したいと思っています。 DagazはZillions of Gamesプロジェクトのベースとなるアイデアを受け継いでいます。しかしZoGとは異なり、DagazはMITライセンスで公開されている完全オープンソースで無料のソフトウェアです。 現時点では、どのようなボードゲームでも遊べる汎用AIを搭載してはいませんが、思考エンジンをいくつか組み込んであり、必要に応じてそれらを全く別々のルール向けに改造することが可能です。 私は数年間もこのプロジェクトに取り組んでいまして、この短い記事でその全貌をお伝えするのは難しく、説明を端折った部分もあります。 もしも私のプロジェクトにご興味がお有りでしたら、お気軽にメールでご連絡下さい。 私のメールアドレスはDagazプロジェクトのGitHub Pagesをご覧下さい。
- これ以降の原文では、Zillions of Gamesは単に"Zillions"と略称されていますが、訳文では分かりやすさのため"ZoG"に統一しました。 略していない箇所はそのままにしてあります。また、原文では"ZRF"というドメイン固有言語の構文の制限を"ZoG"というソフトウェア自体の機能の限界として説明している箇所が多いことにも注意して下さい。↩
- 原文"Unfortunately, I got acquainted with this project quite late, when the main excitement around it had already begun to wane." ここでは"the main excitement"を「ZoGで色々なゲームを作ること」と解釈した上で意訳を試みました。↩
- Wikipediaの言語間リンクを見る限り、アタリ碁(Atari Go)は日本では「ポン抜き囲碁」と呼ばれているそうです。日本においては主に初心者の教育用であり、石を取る感覚を掴んだら卒業するものとされているようですが、個人的には9路盤でやると中々楽しいように思います（訳者が囲碁初心者だからかもしれませんが）。↩
- 訳者は囲碁のルールをほとんど知らないため、日本棋院と Wikipedia のルール解説を基にかなり強引に訳しています。誤りがありましたらご指摘頂ければ幸いです。↩
- ロシアン・カラム・チェッカーでは、取った石を自分の石の下へ順番に積み重ねていき、石の "列(column)" を作っていきます。実際にDagazのデモ実装で遊んでみるとどういうことかよく分かると思います。↩
- 『一般的なコウのルールと違い、1つ前の自分の着手時の盤面とだけではなく、対局開始からのすべての盤面との同形反復を禁止したルールのこと。三コウの問題が発生しない。』（参考：囲碁用語辞典） 中国や欧米で使われるルールのようです。↩
- 原文では"a famous Japanese games for four players." 言うほど有名か？変則将棋マニアしか知らんだろ、という気もしますが、日本語版ウィキペディアによればこち亀で紹介されたこともあったらしいので全く無名ということもなさそうですね。↩
- 原文："As with the other classical Shogi games which are played on small and middle size boards, Yonin Shogi saved the 'drop rule,'..." 古将棋の場合、持ち駒を使えるものはむしろ少数派に近いというのは明らかですが、原著者は将棋のマニアではないので仕方ないと思います。↩
- 原文"All captured Kings as well as other pieces are sent to the hand reserve, and the player left without a King cannot move his pieces." ただし日本版Wikipediaでは「詰められた王将はその場から動けず障害物とする」というような事が書いてあります。原著者がルールを誤解している可能性があります。↩
- このゲームの詳細については、英語版 Wikipedia の該当記事を参照することをオススメします。↩
