およそ9ヶ月前の記事にて、AIが行動するマイクロワールドを作ることを宣言しました。
この記事では、そのマイクロワールドをプロシージャルに、つまり数式や処理を組み合わせて生成する方法について考察し、実践していきます。
その記事というのがこちら↓
simplestar-tech.hatenablog.com
「頑張って言葉にすると、AIが行動するマイクロワールドを作り、それを観察できるオンラインゲームを作ってみたいと考えています。」
大目標は、観察するとまるで自律的に行動する知能がそこにあると錯覚するようなエージェントをマイクロワールド内に登場させることです。
大枠で必要になってくるのは次の三つです。
１．マイクロワールド
２．それを観測して、影響を与えられるアクションが実行できるエージェント機構
３．ワールド・エージェントそれぞれの制御ロジック
素人がAIについて考えると、１．２．の部分の構想をおろそかにして、３．のエージェントの制御ロジックに焦点を当てて議論を始めます。
過去の研究者がそうでした。
AIによって、現実世界の問題を解こうとする研究者もまた多くいます。
その方が、世の中のためになり、お金になる未来があるからですが
しかし、そこには現実世界を100%正しく認識するという、きわめて難しい課題が存在しています。
この課題は、半世紀以上、人類が頭を悩ませ続けても、だれ一人完成させることができませんでした。
断言できるのは、ここで私が努力を続けても、絶対に解決できないということです。
そこで、私は仮想世界の問題を解こうとするエージェントを用意し、仮想世界を100%認識できる機構をあらかじめ用意することで
これまで人類が到達できなかった課題の解決を先送りにして、さらに先にあるエージェントの制御ロジックを考えてみることを思いつきました。
なので、今、世界中の研究者が行っている次の三つの必要項目を
１．現実世界
２．現実を観測して、影響を与えられるアクションが実行できるロボット機構
３．ロボットの制御ロジック
繰り返しになりますが、私は次の三つに置き換えて
１．マイクロワールド
２．それを観測して、影響を与えられるアクションが実行できるエージェント機構
３．ワールド・エージェントそれぞれの制御ロジック
AI研究をするなら仮想世界の構築から行う必要がある、というメッセージを持って、これに従って行動していくことにしました。
では、その仮想世界（マイクロワールド）をどのようにして作っていくのかを考えていきましょう。
マイクロワールドの構造
前提として考えておかなければならないことを次に列挙します。
１．私のやる気と時間が限られたリソースであること（これ、一番大事）
２．コンピュータもメモリとハードディスクと計算量は限られたリソースであること
１．を考慮したとき、マイクロワールドの構造の現実的な回答は、要素シミュレーションによるプロシージャル生成になります。
例えると、宇宙空間にビックバンインパクトを巻き起こして、200億年ほど原子とその相互作用を計算し今のような世界を構築するといった、神が行ったアプローチに似た手法です。（詳細は知らないけど）
つまり、世界の構成要素を一つ一つ手作業で作りこむことはしたくないということです。
２．をここで考慮すると、世界をモデル化して、かなり大きな粒度で相互作用を計算する仕組みが必要になってきます。
例えると、マインクラフトのような1m立方のブロックで構成された世界を、視野に収めたブロックの部分だけが最長16ブロック単位でだけ相互作用する構造です。
あと、Unity で作るというのも私にとって必要なことですね。
まずは、こうした誰でも思いつくようなマイクロワールドの構造を、提供してくれるようなUnityアセットを探してみましょう。
うーん、残念ながら AI 向けに、ブロック情報を取得しつつ、絵を出すようなアセットは見つかりませんね。
多くは、見た目重視のテレインの自動生成ツールばかりです。
www.denispahunov.ru
www.terraincomposer.com
調べ方を変えて、マイクラ風な地形生成で調べてみたところ、パーリンノイズを使った手法が多数ヒットしました。
ワールドの初期状態決めについては、こうした地形生成が良さそうですね。
さっそく試してみました。
なるほど、地下深くまで掘り下げているわけではないですが、かなり描画負荷が高いですね。
マインクラフトは描画を高速化するための、かなり軽量化するアイディアが詰まっているものと思われます。
歴史的に、プロシージャル技術の初期の狙いはメモリ使用量の削減でした。
そこで、これから作るマイクロワールドの設計について、人類がまだ近代科学に至る前の思想を用いて
次のアイディアを盛り込もうと思います。
１．Unity 表示非依存のモデル（データ空間）におけるマイクロワールドの記述
２．格子状のブロックで構成される
２－１．平面充填（へいめんじゅうてん）は三角形（マインクラフトの四角形とは異なる）
２－２．ブロックは三角柱
２－３．ブロックには基底クラスが割り当てられ、面接続された上下2つのブロックと周囲3つのブロックを参照できる
３．ブロックの種類は四元素（火、風（空気）、水、土）があり、五行説（木、火、土、金、水）によって直接作用し合い、日と月の影響を間接的に受けて変化する
雷（電気）は、ひとまず保留します。
ブロック同士の作用を考えながら、基底クラスに必要なものを創り出していきます。
Unity 非依存なので MonoBehaviour は継承することはないです。
Unity ゲーム内にてブロックを表示することになったりすると、様々なコンポーネントを追加するために
MonoBehaviour を継承したブロック操作クラスは必要になりますが
何も、この基底クラスを継承して作ることはなく、単に情報を引き出す形で紐づけるだけで良いはずです。
重要なのは、まだ議論に出てきていない、エージェント・アーキテクチャの部分です。
エージェント・アーキテクチャとの関係
エージェント・アーキテクチャとは、車の運転免許試験の教本の表紙に書かれているような
認知→判断→行動
の仕組みのことです。（終わり）
どうも、この運転教本に載ったあたりまえのフレーズを、高尚な表現としてゲームAIの業界ではエージェント・アーキテクチャって言うらしいですよ。
まぁ、もう少し付け足すと、認知（認識）モジュール、判断（思考）モジュール、行動（アクション）モジュールに分けて、それぞれを短期記憶装置（ブラックボード）とのメッセージのやり取りで実現する、ゲーム内のキャラクターの制御機構といった感じです。
モジュールを分割することによって、集団で開発する際に並列作業が行いやすくなり、変更の影響範囲が限定できることから、デバッグも行いやすくなるという設計となっています。
このエージェント・アーキテクチャに概ね従う形で、作っていくとして、マイクローワールドがどのように、このエージェント・アーキテクチャに関わるのかを考えていきましょう。
認識モジュールでは、マイクロワールドのどの情報が、どのようにアクセスされるのか想像してみましょう。
最も重要なことは、感覚器官に正しい経路で、正しく情報が伝達されることです。
感覚器官は全部で五つ、視覚、聴覚、嗅覚、触覚、味覚です。
中でも、視覚
これが知能にとって最も難しい認識処理となります。
カメラを設置してカメラ画像のようなものを思考モジュールに与える？
確かに現実問題を解くにはこの方法が正しい情報の伝達となります。
gym.openai.com
このように OpenAI でも Minecraft のカメラ画像を入力とするチャレンジがあります。
しかし、残念ながら、画像だけ入力することによる機械の正しい認識は、生涯叶わない夢であると、私は早々にあきらめているので
ここでは、画像ではなく意味を受け取ることにします。
例えば、視界に入った木のブロックが燃えているならば、認識モジュールには、目の前の木が燃えている、という意味が正しく伝わるようにするのです。
エージェントへの情報の伝達経路
さて、ここで視界に入るとは、どのようにして実現されるのでしょうか？
考えてみましょう。
エージェントからレイ（光線）を飛ばして、空気を通って当たった最初の不透明なブロックの情報を引き出して、エージェントにそのブロックに起きている情報を与える
そのほか、視野空間としての円錐の中にあるブロックの情報をすべてを取得し、すべての情報を受け取るなど、方法はいくつか考えられます。
ここで、透明なブロックとは空気やガラスといった材質のブロックのことですね。
重要なのは確実さと、速度ですので、効率的にブロックの隣接するペアをたどっていく形式とします。
少し楽観的ですが、これで方向と距離をたどることで、視界に入る必要な情報すべてを手に入れられるとしましょう。（少なくとも調査対象のブロックは列挙できるものとします。）
次は聴覚についてです。
音が空間を伝わると考えたとき、これも音源から空間をたどって周囲のブロック、場合によっては壁越しに音が伝わるとします。
ここで重要な概念として、音などのメッセージの種類と内容が周囲に伝播する仕組みが必要になることが見えてきます。
このメッセージの種類と内容というのは、そのまま思考モジュールに渡るのではなく、認識モジュールのフィルタリングを経て、ブラックボードに書き込まれ、これを思考モジュールが必要に応じて取り出し、アクションを取るべきか判断します。
さらに重要なことが見えてきました。
それは、ブロック間を伝わるメッセージは認識や思考モジュールが利用するメッセージと同じ形式ということです。
嗅覚も同様、においというメッセージが空間を伝播することにより、周囲の認識モジュールにて拾われることになります。
触覚は触れなければならないので、エージェントの身体とも呼ぶべき「構成物体」が隣接したときに、確かなメッセージとして伝わります。
最後の味覚に関しては、オブジェクト？をくちに入れるなどして、味覚としてエージェントが認識します。
これは、対象をくちに入れる、入れられるというアクションによって起きる現象ですね。
甘味、苦味、酸味、塩味の４つの基本味と、さらにうま味の混合パラメータをオブジェクトからメッセージとして受け取れると良いですね。
ここで、新しい概念が登場しました。
オブジェクトです。
世界を構成している四つの元素ブロックの他に、それらによって作り出されたオブジェクトという情報単位が、物質として世界に存在します。
それらも世界を構成する時は、ブロックの中に配置され、混合物として可視のものとなります。
ブロックは複数のオブジェクトによって構成されていることになりました。
オブジェクトもまた、複数のオブジェクトによって構成されることはあるのでしょうか？
例えば、葉オブジェクトが集まった草オブジェクト、その草オブジェクトが集まった…なんですかね？
た、例えば、石オブジェクトが集まった砂利オブジェクト、その砂利オブジェクトが集まった…なんですかね？
うーん、混合物というものは、すべて同一の粒度のオブジェクトによって構成されているとは限らない、とするなら
良い例は思いつかなくても、オブジェクトは何らかのオブジェクトによって構成されているということで問題ないはずです。
人工物なら、説明がしやすいのですけどね。
カバンの中に財布がある、財布の中にお金がある。
といった具合に、カバンオブジェクトによって構成される、貨物ボックスというオブジェクトも定義できます。
また、それ以上分割できないプリミティブなオブジェクトというものは存在できず、どこまでも構成要素として分割できるとして
それは観測する側の限界分解能において、それ以上分割してメッセージを処理する必要がないものとします。
いつか、バケツに入っているのが水であるならば、そのバケツを倒すと、その水がこぼれることを予想するように
オブジェクトの構成要素にも注意をはらう人工知能が作れることを願い、オブジェクトの包含関係を記述することとします。
そろそろ構想してきたものを形にして、実際に動かしながら不備を見つけていきたいと思います。
次回は、マイクロワールドを構築するプログラムを設計、実装していこうと思います。
