Java でエージェントベースのモデリング プログラムを作成しています。
エージェントをアニメーション化する最良の方法を決定しようとしています。グリッドを使用して、各エージェントが一度に 1 つのセルのみを占有できるようにする例をいくつか見てきました。
エージェントがウィンドウを横切ってあらゆる方向に「流れる」ことができる、よりスムーズなものを探しています。
助言がありますか？
ありがとう！
編集：
環境はシンプルで二次元になります。エージェントは 1 人から数百人まで存在します。
エージェントを、何らかの方向を示す小さな円として表現したいと思います (詳細は関係ありません。要点は、エージェントが回転する機能が必要であるということです)。
2番目の編集:
私は現在、このチュートリアルを読んでいます: http://www.giosoft.net/Development/Java-Asteroids-Tutorial.html
私が達成しようとしていることに役立つようです。
2000 年から 2006 年の間、マルチエージェント システムを専門とするオランダの会社、Tryllian で働いていました。会社は現在活動していません。
Tryllian での最初のアイデアは、エージェント ベースの検索アプライアンス (Gossip と呼ばれる) を構築することでした。これには、キュートな目をした鮮やかな色の円形のエージェントが多数表示されるグラフィカルなクライアント アプリがありました。各エージェントの背中には、「バックパック」を引きずることができる隙間がありました。バックパックには、検索クエリと多数の検索結果 (URL、ドキュメント、画像など) を含めることができます。検索を行うために、ユーザーは用意されたバックパックを持ったエージェントを「インターネットへのポータル」にドラッグする必要がありました。これは、SF 映画で見られるような星空を背景にした着陸ベイのドアのようなものでした。その後、エージェントはトリリアン サーバーに「テレポート」され、サーバー上に住む「バトラー エージェント」によって「トピック ルーム」に誘導されます。部屋では、他のエージェントと対話し、検索の関心と結果を交換できます。ここに。
その後、Tryllian は、Gossip のようなエージェント アプリケーションをより簡単に作成できるエージェント開発キット (ADK) を開発することを決定しました。エージェントの動作をプログラミングするためのタスクベースのモデルを提供しました。エージェントは多くのイベント (agentStarted など) を取得し、イベント ハンドラーでタスクを追加して、さらにイベント (taskStarted など) を取得し、より複雑な動作 (おそらくサブタスクの形式) をスケジュールすることができます。API は本当によくできていました。
私の意見では、ADK の重要な機能は、ADK が提供するコードの移動性でした。エージェントは、ローカルの ARE (Agent Runtime Environment) 上の仮想ルーム間を移動できるだけでなく、別のサーバーに移動することもできます。これには、クラスのシリアライゼーションと、当時非常に革新的なマルチクラスローダー ソリューションが含まれていました (私たちは考えるのが好きでした)。この機能により、データを渡す代わりにコードをデータに持ち込む設計が可能になりました (データのポンピングは、私が知っているほとんどのエンタープライズ システムの主な機能です)。たとえば、Tryllian は、監査会社のアナリストが監査ルールをエージェントにエンコードし、それをクライアントのサーバーに安全に送信してプロセスを監視できるようにするリモート監査アプリケーションを開発しました。
この回答が非常に長くなる前にやめます(-;
これはおそらく、あなたが今達成しようとしているものよりも少し多いでしょう。質問をもう少し具体的に定式化できる場合は、マルチエージェント システムの設定方法についてアドバイスできます (エージェント間のメッセージングをモデル化する方法も非常に興味深いトピックです - 申し訳ありませんが、やめると言いました. ..)。
マルチエージェント システムの目的は何ですか? エージェントは何をしますか？1 台のマシンで実行しますか、それとも分散しますか? エージェントは、その動作/ルールにおいてハードコード化、構成可能、または完全に動的ですか?
最後の提案: 単純なエージェントのモデル化について考えるための合理的な出発点は、通常ロボットに関連するセンス-プラン-アクトです。
編集：あなたのコメントへの応答
Tryllian エージェント モデルは、シミュレートされた物理環境との緊密な相互作用よりもメッセージングに重点を置いています。あなたが投稿したサンプル サイトを見ると、特にエージェントの数が増えると、パフォーマンスが非常に重要になるようです。Tryllian エージェントの強みであるコードの可動性、タスクベースのプログラミング、汎用性を活用することにはならないため、このようなシミュレーションには最適なツールではないと思います。
あなたは「グリッド」と「スムーズ」なアプローチについて言及しています。コンピュータ シミュレーションでは、エージェントのサイズ、座標、速度、および方向を、ある種の離散座標系で常に表す必要があると思います。したがって、常に何らかのグリッドが存在しますが、「セル」を小さくして、より滑らかに見せることができます。
ゲームの分野で役立つリソースがいくつかあるのではないでしょうか? (スプライト、衝突検出など)
頑張って楽しんでね！