メモリを備えたモジュラーアリボット

実装を夢見ていたプロジェクトの1つは、メモリを備えたモジュール式タスクボットでした。 このプロジェクトの最終的な目標は、独立して集団として行​​動できる生物がいる世界を作ることでした。

以前はワールドジェネレーターをプログラムしていたので、AIを使用して動作と相互作用を判断する単純なボットを世界に投入したかったのです。 したがって、世界に対する俳優の影響のおかげで、その詳細を増やすことができました。

私はすでに基本的なJavascriptタスクパイプラインシステムを実装しました（人生が簡素化されたため）が、より信頼性が高くスケーラブルなものが欲しいので、このプロジェクトをC ++で作成しました。 subreddit / r / proceduralgenerationで手続き型庭を実装するための競争は、私をこれに導きました（したがって、対応するトピック）。

私のシステムでは、シミュレーションは、世界、人口、およびそれらを接続する一連のアクションの3つのコンポーネントで構成されています。 そのため、この記事で説明する3つのモデルを作成する必要がありました。

複雑さを増すために、アクターに世界での以前の経験に関する情報を保持し、将来のアクションでこれらの相互作用に関する知識を使用してもらいたいと思いました。

世界のモデルを作成するときに、単純なパスを選択し、Perlinノイズを使用して水面に配置しました。 世界の他のすべてのオブジェクトは、完全にランダムに配置されていました。

母集団モデル（およびその「記憶」）については、いくつかの特性と座標を持つクラスを作成しました。 これは低解像度のシミュレーションであると想定されていました。 メモリはキューであり、ボットは見回され、環境に関する情報を保存し、キューに書き込み、メモリの解釈としてこのキューを管理します。

これら2つのアクションシステムを接続するために、個々のエンティティが世界で複雑な動作を実装できるように、タスクキューの階層システム内にプリミティブタスクのフレームワークを作成したかったのです。


サンプルマップ。 水は意図せずに完全に川の形を取りました。 他のすべての要素は、蟻塚を含めてランダムに配置されています。蟻塚は、この種では端から遠くにずれています（ただし、川はきれいに見えます）。

草を集める葉の中のアリの束は、基本的な機能（およびタスクキューシステム全体）の実装の信頼性を保証し、メモリリーク（それらの多くがありました）を防ぐ優れたテストモデルになると決めました。

タスクシステムとメモリの構造をさらに詳しく説明し、（ほとんど）プリミティブな基本機能から複雑さがどのように作成されたかを示します。 また、アリが草を求めて円を描くように狂ったように走り出したり、じっと立ってプログラムを遅くしたりするときに遭遇する可能性のある面白い「アリのメモリリーク」を示したいと思います。

一般的な構造

このシミュレーションをC ++で記述し、レンダリングにSDL2を使用しました（以前にSLD2の小さなプレゼンテーションクラスを既に作成しました）。 また、GitHubで見つけたA *実装（少し変更）を使用しました。 実装が絶望的に​​遅く、理由を理解できなかったためです。

マップは、2つのレイヤー（パスの検索に使用される土壌レイヤー）と（相互作用と検索パスを完了するための）塗りつぶしレイヤーの2つのレイヤーを持つ100×100グリッドです。 ワールドクラスは、草や植物の成長など、さまざまな化粧機能も処理します。 この記事では説明されていない部分のみがこれらであるため、今私はこれについて話している。

人口

ボットは、単一のクリーチャーを記述するプロパティを持つクラスに属していました。 それらのいくつかは化粧品であり、他のものはアクションの実行に影響を与えました（たとえば、飛ぶ能力、視界の範囲、食べるもの、クリーチャーが着ることのできるもの）。

ここで最も重要なのは、動作を決定する補助値です。 すなわち、各クロックサイクルでカウントする必要がないように現在のパスA *を含むベクトル（これにより計算時間が節約され、より多くのボットをシミュレートできます）、および環境を解釈するクリーチャーを定義するメモリキュー。

メモリキュー

メモリキューは、ボットプロパティのサイズによって制限されるメモリオブジェクトのセットを含む単純なキューです。 新しい記憶が追加されるたびに、それらは前に押し出され、背後にある境界を越えたすべてのものが切断されました。 これにより、一部の思い出は他の思い出よりも「新鮮」になります。

ボットがメモリから情報を呼び出したい場合、メモリオブジェクト（要求）を作成し、それをメモリ内のものと比較しました。 次に、リコール関数は、クエリで指定された条件のいずれかまたはすべてに一致するメモリのベクトルを返しました。

class Memory{ public: //Recall Score int recallScore = 1; //Memory Queryable? Array bool queryable[4] = {false, false, false, false}; //Memory Attributes std::string object; std::string task; Point location; bool reachable; 

メモリは、いくつかのプロパティを含む単純なオブジェクトで構成されます。 これらのメモリプロパティは、互いに「関連付けられている」と見なされます。 各メモリには「recallScore」値も与えられます。この値は、リコール機能によってメモリが記憶されるたびに繰り返されます。 ボットはメモリを記憶するたびに、古いメモリのrecallScoreが新しいメモリのrecallScoreよりも高い場合、順番に1パスのソートを実行します。 このため、一部のメモリは「重要」で（メモリサイズが大きい場合）、キューに長く保存される場合があります。 時間が経つにつれて、それらは新しいものに置き換えられます。

メモリキュー

また、このクラスにいくつかのオーバーロードされた演算子を追加して、メモリキューとクエリの間で直接比較を行い、「any」または「all」プロパティを比較して、メモリが上書きされたときに指定されたプロパティのみが上書きされるようにしました。 このため、ある場所に関連付けられたオブジェクトメモリを持つことができますが、この場所をもう一度見て、オブジェクトがない場合、この場所に対応するクエリを使用して、新しい塗りつぶしタイルを含むメモリで上書きすることでメモリを更新できます。

 void Bot::updateMemory(Memory &query, bool all, Memory &memory){ //Loop through all existing Memories //"memories" queue is a member of Bot for(unsigned int i = 0; i < memories.size(); i++){ //If all matches are required and we have all matches if(all && (memories[i] == query)){ //We have a memory that needs to be updated memories[i] = memory; continue; } //If not all matches are required and any query elements are contained else if(!all && (memories[i] || query)){ //When overwriting, only overwrite specified quantities memories[i] = memory; continue; } } } 

このシステムのコードを作成する過程で、多くのことを学びました。

タスクシステム

ゲームのループまたはレンダリングの性質は、すべてのメジャーで同じ機能が繰り返されることですが、ボットに非周期的な動作を実装したかったのです。

このセクションでは、この影響に対処するために設計されたタスクシステムの構造に関する2つのビューについて説明します。

ボトムアップ構造

私は下から上に移動して、ボットが実行する「プリミティブアクション」のセットを作成することにしました。 これらの各アクションは、1ビートのみ続きます。 プリミティブ関数の優れたライブラリを使用して、それらをいくつかのプリミティブ関数で構成される複雑なアクションに結合できます。

このようなプリミティブアクションの例：

 //Primitives bool wait(Garden &garden, Population &population, int (&arguments)[10]); bool look(Garden &garden, Population &population, int (&arguments)[10]); bool step(Garden &garden, Population &population, int (&arguments)[10]); bool swap(Garden &garden, Population &population, int (&arguments)[10]); bool store(Garden &garden, Population &population, int (&arguments)[10]); bool consume(Garden &garden, Population &population, int (&arguments)[10]); bool move(Garden &garden, Population &population, int (&arguments)[10]); //Continue with secondaries here... 

これらのアクションには、世界と人口の両方への参照が含まれており、それらを変更できることに注意してください。

• 待機すると、クリーチャーはこのループで何もしません。
• Lookは環境を解析し、新しいメモリをキューに入れます。
• スワップは、クリーチャーの手にあるオブジェクトを取り、地面に横たわっているオブジェクトに置き換えます。
• 消費すると、クリーチャーの手にあるアイテムが破壊されます。
• Stepは、現在の計算された宛先へのパスを取り、1つのステップを実行します（多数のエラーチェックを使用）。
• ...など。

すべてのタスク関数は、タスククラスのメンバーです。 厳しいテストの後、彼らは信頼性とより複雑なタスクに結合する能力を証明しました。

 //Secondaries bool walk(Garden &garden, Population &population, int (&arguments)[10]); bool idle(Garden &garden, Population &population, int (&arguments)[10]); bool search(Garden &garden, Population &population, int (&arguments)[10]); bool forage(Garden &garden, Population &population, int (&arguments)[10]); bool take(Garden &garden, Population &population, int (&arguments)[10]); //Species Masters bool Ant(Garden &garden, Population &population, int (&arguments)[10]); bool Bee(Garden &garden, Population &population, int (&arguments)[10]); }; 

これらの二次機能では、他のタスクを単純に連鎖させることで機能を構築します。

• walkタスクはほんの数ステップです（エラー処理あり）
• takeタスクは、ルックアンドスワップタスクです（antメモリ処理のために必要です。これについては後で説明します）
• アイドルタスクは、ランダムな場所を選択してそこに移動し（ウォークを使用）、数サイクル待機し（ウェイトを使用）、このサイクルを指定された回数繰り返す
• ...など

他のタスクはより複雑です。 検索タスクは、メモリクエリを実行して、「food」オブジェクト（このタイプのボットで使用可能）を含む場所のメモリを検索します。 彼女はこれらの思い出をダウンロードし、それらをすべて回って、食べ物を「探して」います（アリの場合、これは草です）。 食物の記憶がない場合、タスクはクリーチャーをランダムに世界を歩き回らせ、見回します。 （viewRadius = 1で「見る」ことにより、つまり、下のタイルのみを見る）観察し、研究することにより、クリーチャーは周囲の情報で記憶を更新し、食物を知的かつ意図的に検索することができます。

より一般化された飼料タスクは、食物を見つけること、食物を拾うこと、検査すること（近隣の記憶を更新し、食物を見つけること）、家に戻って食物を保存することから成ります。


蟻が蟻塚から出て、意図的に餌を探すことに気づくかもしれません。 初期化により、t = 0でのアリのメモリが空であるため、アリの初期パスはランダムポイントに向けられます。 それから、彼らは飼料タスクで食物を拾う命令を与えられます、そして、彼らはまた、もう食物がないことを確認して、見回します。 彼らは食べ物を見た場所を使い果たすので、時々さまよい始めます（不吉な近視）。

そして最後に、ボットには割り当てられたAIの種類を決定する「ビュー」があります。 各ビューは、そのすべての動作を定義する1つの制御タスクに関連付けられています。これは、一連のメモリキューとプリミティブタスクによって簡単に決定される、ますます小さくなるタスクのカスケードで構成されています。 これらは、AntやBeeのようなタスクです。

トップダウン構造

上から下に向かって見ると、システムは、マップ上の個々のボットの制御タスクとその実行を調整するタスクマスタークラスで構成されています。

Taskmasterには制御タスクのベクターがあり、各タスクはボットに関連付けられています。 各制御タスクには、サブタスクのキューがあり、関連付けられたタスク関数でタスクオブジェクトを最初に初期化するときに読み込まれます。

 class Task{ public: //Members std::stack<Task> queue; bool initFlag = true; int args[10]; bool (Task::*handle)(Garden&, Population&, int (&)[10]); int botID; std::string name; //Constructor Task(std::string taskName, int taskBotID, bool (Task::*taskHandle)(Garden&, Population&, int (&)[10])){ name = taskName; botID = taskBotID; handle = taskHandle; } //Launch a Task bool perform(Garden &garden, Population &population); //Continue with primitives here... 

キュー内の各タスクオブジェクトは引数の配列を格納し、関連する関数ハンドラーに渡します。 これらの引数は、可能な限り一般的に作成されたこれらのプリミティブタスクの動作を決定します。 引数は参照によって渡されるため、キュー内のタスクオブジェクトは引数を格納し、そのサブ関数を変更できるようにするため、特定のクロックサイクルを待機する反復や特定の数のアイテムを収集する要求などを実装できます。 サブ関数は、参照によって親関数の反復子（引数[n]）の値を変更し、その成功条件をその値に依存させます。

各メジャーで、タスクマスターは制御タスクのリストを調べて、performメソッドを呼び出して実行します。 次に、performメソッドは、タスク内のキューの一番上の要素を調べ、タスクからの引数を使用してそれを実行します。 これにより、タスクキューをカスケードして、常に最高のタスクを完了することができます。 次に、タスクの戻り値によってタスクの完了が決まります。

 //Execute Task Function bool Task::perform(Garden &garden, Population &population){ //Debug Message if(debug){std::cout<<"Bot with ID: "<<botID<<" performing task: "<<name<<std::endl;} //Change the Name and Execute the Task population.bots[botID].task = name; return (*this.*handle)(garden, population, args); } 

プリミティブタスクがtrueを返すとき、その安定点に達しているか、少なくとも繰り返されるべきではありません（たとえば、クリーチャーが終了点に達したときにstepがtrueを返します）。 つまり、その戻り条件が満たされ、キューから削除されるため、次のメジャーで次のタスクを完了できます。

タスクキューを含むタスクは、キューが空になった後にtrueを返します。 これにより、同じ関数が常に呼び出されるキューとサブキューの構造を持つ複雑なタスクを作成できますが、呼び出しごとにゲームの状態とタスクの状態が1ステップずつ繰り返されます。

最後に、制御タスクは単純な構造を使用します。各サイクルで呼び出され、空の場合にのみタスクをロードし、それ以外の場合はキューにロードされたタスクを実行します。

 //Species Functions bool Task::Ant(Garden &garden, Population &population, int (&arguments)[10]){ //Initial Condition if(initFlag){ Task forage("Search for Food", botID, &Task::forage); forage.args[0] = population.bots[botID].forage; //What are we looking for? queue.push(forage); initFlag = false; } //Queue Loop if(!queue.empty()){ //Get the Top Task Task newtask = queue.top(); queue.pop(); //If our new Task is not performed successfully if(!newtask.perform(garden, population)){ queue.push(newtask); return false; } //If it was successful, we leave it off return false; } //Return Case for Mastertask initFlag = true; return false; } 

キューループ（コードを参照）の助けを借りて、1つの関数を繰り返し実行し、そのキューの一番上の要素を実行するたびに、performメソッドを呼び出すとtrueが返されると要素をプッシュできます。

結果

これはすべてlibconfigにラップされているため、シミュレーションパラメータの変更は非常に簡単です。 多くの制御タスクを問題なくコーディングでき（アリとミツバチを作成しました）、libconfigを使用して新しい種を定義およびロードするのは驚くほど簡単です。

 //Anthill General Configuration File debug = true; //World Generation Parameters seed = 15; water = true; //Species that the simulation recognizes Species: { //Ant Species Ant: { masterTask = "Ant"; color = (0, 0, 0); viewDistance = 2; memorySize = 5; forage = 2; trail = true; fly = false; } Bee: { masterTask = "Bee"; color = (240, 210, 30); viewDistance = 4; memorySize = 30; forage = 4; trail = false; fly = true; } Worm: { masterTask = "Bee"; color = (255, 154, 171); viewDistance = 1; memorySize = 5; forage = 3; trail = true; fly = false; } } Population: ( {species = "Ant"; number = 40;}//, //{species = "Bee"; number = 12;}, //{species = "Worm"; number = 5;} ) 

これらはシミュレーションにエレガントにロードされました。 新しく改善されたパスの検索のおかげで、2次元の平面で食物を収集している多数のアクティブなボットをシミュレートできます。


同時に草を集める40匹のアリのシミュレーション。 それらが砂の中に作成する経路は、「手つかずの」土地に割り当てられた重量の増加によるものです。 これは、特徴的な「アリ高速道路」の作成につながります。 それらはフェロモンとして解釈することもできますが、アリが実際に記憶を交換した場合、それは真実のようになります。

このシステムのモジュール性により、単純な制御タスクによって動作が決定される新しい種の迅速な作成が保証されます。 上記のコードでは、ワームとAIミツバチの色、パス検索の制限（飛行できない）、可視範囲、メモリサイズを変更するだけで作成されていることがわかります。 同時に、これらのパラメーターはすべてプリミティブタスクの機能によって使用されるため、一般的な動作を変更しました。

Antメモリのデバッグ

複雑なタスクとメモリの構造により、予期せぬ困難と例外の処理が必要になりました。

サブシステムをやり直した3つの特に複雑なメモリバグを次に示します。

円で走っているアリ

私が直面しなければならなかった最初のバグの1つ：アリは裸地で草を探して広場に囲まれたパターンに沿って狂ったように走りました。 この問題は、その時点ではまだメモリの更新を実装していないために発生しました。 アリには食べ物の場所の記憶があり、草を拾って再び見回すとすぐに、新しい記憶が形成されました。

問題は、新しいメモリは同じポイントにあったが、古いメモリは保存されていたことでした。 つまり、食べ物を探す過程で、アリはもはや有効ではなくなった食べ物の場所を記憶し、保持していましたが、これらの古い記憶は保存され、新しいものに取って代わりました（彼らはこのおいしいハーブを覚えていました）。

私はそれを次のように修正しました：オブジェクトのデータは、同じ場所を見てオブジェクトが変更された場合、古いメモリに単純に上書きされます（たとえば、クリーチャーは草がもうないことを見るが、草があったことを覚えていない）。 おそらく将来的には、無効なプロパティを思い出に追加して、重要な古い情報をボットが思い出せるようにしますが、有効ではなくなった情報は「表示」されます（「ここでクマを見ましたが、今はありません」）。

アリは他のアリの下にあるオブジェクトを拾います

時々（特に多数のアリと高密度の草がある場合）、2つのアリが1つのメジャーで1つのタイルのタイルに乗って、それを拾おうとすることができます。 これは、最初のアリがタイルに入り、周りを見回し、3つのステップでアイテムを受け取ったことを意味しました。 次に、2番目のアリが同じことを行い、オブジェクトを持ち上げる直前にのみ、別のアリが鼻の下からそれをひったくりました。 彼は静かに仕事を続け、前の測定で他のアリと同じ環境を調べ、同様の方法で記憶行を処理しました（この段階で記憶は同一であるため）。 これにより、2番目のアリが最初のアリをコピーし、オブジェクトをピックアップせず、最初のアリに続いて、実際にすべての作業を行いました。 5匹のアリのシミュレーションでは、3匹しか見えなかったため、これに気付きました。 原因を見つけるのに長い時間がかかりました。

この問題を解決するには、スワップタスクプリミティブを作成し、テイクタスクを作成します。このタスクは、まず地面を見てオブジェクトがあるかどうかを確認します。 そうである場合、それは「スワップ」し、そうでない場合、2つの動きを「待機」して、他のアリが確実に去るようにします。 1つのケースでは、このアクションは2つのメジャーに対するものであり、もう1つは1つのメジャーに対するものです。

到達不能な場所

メモリの処理をやり直すことを余儀なくされた別の不愉快なバグは、アリが見ることができるいくつかの場所が彼にとって到達不可能だったということでした。 私の怠zyな「グラスクロス」の土地への配置が原因で発生しました。 これにより、ステップタスクを一般化できました。

食物探索のリクエストを送信するとき、アリはしばしば彼らが本当に到達することができない場所の記憶を持っていました（彼らは水の上に草を見たので、 めちゃくちゃそれを集めたかったです）。 メモリ内でマークされていない場合（たとえば、ブール変数「到達可能」）、このアクションが唯一になるまで、これを記憶し、キューに書き込み続けました。 これは、各メジャーでパス検索操作を常に実行し、そこに到達しようとして失敗したため、深刻な抑制を引き起こしました 。

解決策は、場所へのパスが見つからない場合にステップタスクでメモリを更新し、メモリ内で到達不能としてマークすることでした。 さらに、検索タスクは、到達可能な記憶のために食物のある場所のみを照会します。

システム全般

一般的に言いたいことです。はい、私は自分の人生の1週間をプログラミングマラソンに費やしたことを後悔しています。 私はいくつかのトリックをしなければならず、多くを学びました。

私が作成したシステムは100％信頼できるものではなく、まだいくつかのアーティファクトがあります。 たとえば、外観を解析する方向として、アクションは上下左右に使用されます。つまり、最後のメモリは右下隅にあります。 情報を呼び出してアイテムを検索するとき、これはクリーチャーが南東に移動する傾向があることを意味します。 これは、種に関係なく、草が急速に成長し、南東に向かってわずかに曲がる大規模なシミュレーションで特に顕著です。

機能強化

より複雑な生物のより複雑な記憶をシミュレートするには、大幅な改善が必要だと思います。

これには、メモリ処理機能の信頼性の向上、「思考」などの新しいプリミティブ、および「決定」や「夢」などの高レベルタスクの派生物の追加が含まれます。 「考える」は、メモリリクエストの原始的な動作です。 「夢」は、いくつかの「思考」呼び出しで構成できます。ランダムなメモリを選択し、ランダムなプロパティを取得し、それを繰り返して、共通のテーマや重要な関連性を強化します。

将来的には、3つの特定の追加を計画しています。

• 割り込み処理とタスクの優先順位付けを追加します
• エンティティ間の通信を追加する
• エンティティが互いに正式に識別できるように、グループ構造を追加します

エンティティ間のやり取りには、タスクの処理の中断と優先順位付けが必要になる場合があります。なぜなら、ボットが通信する（何らかの方法で「聞く」必要がある）か、攻撃される（「逃げる」または「戦う」） ）

エンティティ間の通信は、おそらく、メモリを交換したり、他のボットのメモリにリクエストを送信したりするための1つまたは2つの基本的なタスクで構成されます（「say」や「ask」など）。 このようにして、食料やその他のリソースの場所などの情報を送信できます。

これらのタスクを実装し、コミュニケーションの有無にかかわらず大規模なグループによるリソース蓄積率のグラフを作成したいと考えています。 人口はすでに各測定で収集された食物の量を追跡しています。 思い出の共有が効率に影響を与える可能性があることを示すのは興味深いでしょう。

未来

コミュニティシミュレーションの最も重要な機能は、グループ構造を追加し、これらのグループにマクロレベルのプロパティ、たとえば共通の「目標と責任」を与えることです。 これにより、一種の「シード」が得られ、そこからグループ構造の階層を下って委任された高レベルのタスクを取得して、世界に直接影響する「低」の高レベルのタスクを取得できます。 また、政治構造のフォームを作成することもできます。

このようなシステムは非常に自給自足であり、視覚化はその上に単純に重ねられます。 昆虫を人型生物に置き換えることは非常に簡単で、資源を集めてどこかに保管し、サイズを大きくします。たとえば、彼らの家の成長の性質は、ボットの行動に大きく依存するか、完全に独立しています。異なる種は、異なる特性と傾向を持つ異なる部族を持っているかもしれません。

さらに、このシステムを以前に作成したマップジェネレーター（世界クラスを拡張）と組み合わせて、世界をよりリアルにすることができます。

結論として

近い将来、クリーチャーを人に置き換え、最新の機能を実装する予定です。おそらく、システムの品質を改善するときに、完全なソースコードを公​​開します（コードはかなり混codeとしている場合もあります）。

次の記事を待ちます。それまでは、花の中で花粉を探しているミツバチのビデオがあります。それらは同じフレームワークを使用してエンコードされます。


出発点が小さな島にあるため、この種を選びました。しかし、ミツバチは巣箱に戻るようにプログラムされておらず、単に花粉を絶えず収集します。あなたは彼らの視界がより高く、時々彼らがちょうど見たばかりの花に非常に意図的に移動することに気付くかもしれません。

...そして、これがBee Taskメンバー関数です：

 bool Task::Bee(Garden &garden, Population &population, int (&arguments)[10]){ //Just Search for Flowers if(initFlag){ //Define our Tasks Task take("Take Food", botID, &Task::take); Task eat("Eat Food", botID, &Task::consume); Task search("Locate Food", botID, &Task::search); search.args[0] = population.bots[botID].forage; queue.push(eat); queue.push(take); queue.push(search); initFlag = false; } //Work off our allocated queue. if(!queue.empty()){ //Get the Top Task Task newtask = queue.top(); queue.pop(); //If our new Task is not performed successfully if(!newtask.perform(garden, population)){ //Put the Task back on queue.push(newtask); } //If it was successful, we leave it off return false; } initFlag = true; return true; }