ゆらゆらゆれる。

アバター
ideyan
記事: 2
登録日時: 15年前
住所: 京都

ゆらゆらゆれる。

投稿記事 by ideyan » 14年前

ちょっと前にフロッキングの記事が出てたので便乗。

確かAIの本を読んでて、なんか気にいって作ってみたんだったような。
パラメータを弄ると色んな動きをして面白いです。
2色いるけど特に意味は無かったり。
今度時間のある時に機能を追加しつつ1から作り直しててみたいな。

造語が混ざってる上に単位微妙に間違ってるのが恥ずかしい><


気になる人はよろしければどうぞ。
http://www1.axfc.net/uploader/Sc/so/169 ... y=flocking
添付ファイル
test2.png
test2.png (47.17 KiB) 閲覧数: 41 回
test.png
test.png (46.4 KiB) 閲覧数: 56 回

アバター
あーる@Reputeless
記事: 84
登録日時: 15年前

Re: ゆらゆらゆれる。

投稿記事 by あーる@Reputeless » 14年前

矢印じゃなく、虫の画像だったら
リアルすぎて気絶してます (゚д゚

アバター
MNS
記事: 35
登録日時: 15年前

Re: ゆらゆらゆれる。

投稿記事 by MNS » 14年前

遊ばせていただきました[e]140[/e]
リアルな群れの動きで面白いなあ、と思ったのですが、
パラメータを見たところ、私が作っているフロッキングとは、
全然違う方法で、群れが作られているような印象を受けました。
これは、boidsでは無いのでしょうか?
コードも気になるところです[e]207[/e]

アバター
ideyan
記事: 2
登録日時: 15年前
住所: 京都

Re: ゆらゆらゆれる。

投稿記事 by ideyan » 14年前

どうも、遊んでくださってありがとうございます。

書いたときに参考にした本(ゲーム開発者の為のAI入門)を
引っ張り出して来て確認しましたが使ってるのはboidsで間違いないですね。

旋回速度
壁衝突時~
矢印の数
基本速度

のパラメータは群れ形成に直接関係は無いですが

視認距離
視野角
この2つを基に視野に入っているユニットを判定し
データを集めます。
その後
回避距離内にユニットがあれば:分離
自分の位置と視野内に入ったユニットの平均位置を比べ、
安定距離のパラメタによって:整列or結合
といった感じで行動を決定しています。

一気に作って満足してしまった物なので
コードが目茶目茶&コメント0で読めたもんではないので
コードのほうはご勘弁を^^;

アバター
MNS
記事: 35
登録日時: 15年前

Re: ゆらゆらゆれる。

投稿記事 by MNS » 14年前

なるほど、パラメータでの表記はないものの、
整列と結合行動はきちんと行われているんですね

なるほど、たしかに勢いで書いたコードは見せられませんよね[e]199[/e]
あまり覚えていらっしゃらないかもしれませんが、
このプログラムで言えば、視野に入っているユニットを判定する処理でしょうか、
判定回数を減らすなどの最適化をしているなら、
どのようなアプローチで行っているのかを教えていただきたいです[e]207[/e]

アバター
ideyan
記事: 2
登録日時: 15年前
住所: 京都

Re: ゆらゆらゆれる。

投稿記事 by ideyan » 14年前

長文注意~
判定処理ですか。
うろ覚えですが適当に書いていきます。

一応視野判定の基本の部分から書いていきます。
一度作ってらっしゃるようなので知っていらっしゃるでしょうが
元々どういう処理なのかを書かないとどう減らしたのか書きにくいのと、
他の人も今後見る可能性があるのでこういう形にしています。

ユニットは以下の情報を持っています
・位置情報
・向き(rad)
------------------------------------------------
(1).相手のユニットとの距離を調べる。(視認距離で判定)
これは2点間の距離ですぐですよね。

視認距離内の場合は
(2).自ユニットの向きの情報を2元ベクトルに変換(赤線)
(3).他ユニットへのまでの距離をベクトルに変換(青線)
(4).公式?を使って2ベクトル間の角度を算出(水色線)
この値が視野角に入っていれば
そのユニットは視野に入っているということになります。

上記を他のユニット全てに対してひたすら繰り返して
視野内に入ったユニットの数をカウントしながら
位置情報と向きをそれぞれ足し合わせていきます。
他の全てのユニットを確認し終えたら平均位置・平均向きを出して、
各種パラメータに応じて自分の向きと速度を調節します。
---------------------------------------------------
これを全ユニットに対して行い、それぞれの新しい移動量が決まったら
最後にループを回して移動処理・描画処理です。

さて、この方法ですと
全ユニットが他の全ユニットと判定を行う必要があります。
ユニット数をnとすると O(n^2) です。
うちの環境ですとn=300にすれば処理落ち確定です。

で、作った時の自分ではオーダーそのものを減らすのは
厳しかったので微妙な小細工をしました。
マップを80×80の大きさのエリアに分割しましす。
640×480なら8*6=48個のエリアになります。

で、移動処理を行った時に「そのエリアに存在するユニットのリスト」に追加します。
判定処理を行うときは自分のエリアと視認距離のデータから
「視野に入る可能性のあるエリアのリスト」を辿って判定します。
手順としては絶対に視野に入らないと言いきれるユニットに対してだけ
(1)をすっ飛ばせるようになるだけですが結構効果がありました。

やってるのはこれだけです。
視認距離を640まで増やしたり全ユニットが密集したりすると効果がなくなります^^;

他に考えられる削減方法があったら今後の参考にしたいと思いますので
是非聞いてみたいです。

アバター
ideyan
記事: 2
登録日時: 15年前
住所: 京都

Re: ゆらゆらゆれる。

投稿記事 by ideyan » 14年前

(2)~(4)の図を貼り忘れた……
添付ファイル
eye.PNG
eye.PNG (2.49 KiB) 閲覧数: 0 回

アバター
MNS
記事: 35
登録日時: 15年前

Re: ゆらゆらゆれる。

投稿記事 by MNS » 14年前

なるほど、私の作ったものは、視野はあっても、
視野角は360度なので参考になります[e]140[/e]

最適化の方法はだいたい同じみたいです。
フィールドのサイズが1920*1440なのですが、
これを計4800もの区画に分割しています。
それでも、登場させるエージェント数は、500、600がよいところで、
それ以上であると処理落ちしてしまいます。

もう少し増やしたいなと思い、最適化の方法を聞いた次第ですが、
やはりもう少し高度な探索方法を使わなければいけないのですかね・・・[e]197[/e]