ゲームのアルゴリズムを教えて管sai
やっぱそんなもんか、俺もGEM2までしかもっていない よくわからないけど、画面表示の向きと、画面上の自機の向きをバラバラに考えて、上下左右移動時は時機の向きがそれぞれの方向に慣性付きで移動するようにして、その方向に弾がでるようにすればいいんじゃない? >>147
まず、一点に集中しちゃうのは平行線だけだぜ
よしんば自機の弾が平行にしか撃てないとしても、集中するのは無限遠点だ
ゲーム時間中に到達するのかい ゲーム画面中の10km先と無限の先は何ドットずれるんだい? crysisの四脚の敵とか
モンハンのシェンガオレンみたいのってどうやって作るんでしょう?
アニメーションさせれば平の地面を歩く程度はできると思うんですが
凹凸の地面を歩かせたりするにはプログラムからボーンを調整したりするんでしょうか?
いや、モンハンは分かりやすいかな?程度で出しただけなんで。
IKでやるのは理解してるんですが、
ボーンと地面の判定→先端ボーンの位置を指定→IKで根元までって感じなのでしょうか?
・・・今思うとDirectXの話な気がしなくもない。 自分が理解できない事は全てDirectXが解決してくれる病ですね モンハン並みのものを作れないおまえら雑魚すぎるwww 地面の高さに、モデル空間の座標を合わせるだけだと思うが
それとも、実行時にモデルアニメの計算をするのか
そんな事しないだろう
広大なマップを動き回るシミュレーションみたいなのを考えてて
とりあえずA*というアルゴリズムで2048x2048のマップで
1ドット単位で移動可能としてやってみたら遅くてとても実用的じゃないと判明した
もっと早い方法はあのかな?
マップを小さくしろってのは無しでお願いしますよ
考えてるゲームがマップの広さを利用したものなんで GameProgrammingGemsあたりにあったような気もする。
俺は買ってないけど。高くて。 調べてたらいろいろやり方はあるみたいだ
ちょっといいアイデアを思いついたんで今実験中 あれからいろいろ実験して完全オリジナルのアルゴリズムを考えてやってみた
2048x2048の1ドット単位移動マップで端から端あたりまでの検索の1秒も掛からなくなった
A*を継承してるんで検索漏れはないはず
なにげにすごい発明をしたのかも >>160
オライリーのAIの本のページにサンプルコードがあったはず、探してみな >>160
みつけてきたぞ
O'Reilly Japan - 実例で学ぶゲームAIプログラミング
http://www.oreilly.co.jp/books/9784873113395/
これの関連ファイルにソースコードとサンプルの実行ファイル入ってる ドカポンなどの双六式のゲームで、「おまかせ」というモードがありますよね?
でた目の数で丁度いけるマスを自動検索してくれるというものなんですが、
あれのアルゴリズム分かる方いますか?言語はなんでもかまいませんので
教えていただけないでしょうか。 マップが分岐なし一方通行なら一次元配列で出目を足せばいい。
分岐がたくさんあるなら、マップを二次元配列にするとして、
「ゲーム シミュレーション 移動範囲」を検索し応用。 >>168
SRPGの移動範囲みたいなのはわかるんですが、双六だと途中の経路にループがあったり、
飛ばせるマスがあったりしてそこを含めて出目に丁度合うように移動可能か判定するには
どうすればいいか、そこが今ひとつわからないんです。 それは簡単。印をつけてループしなくさせればいい
たしか移動歩数的なものを記録すればよかったんじゃない いや、ループはさせないとダメでしょ。
桃太郎電鉄でもリニアカードや新幹線カードを使うとサイコロをたくさん振れて
ループも含めて目的の駅に入りやすくなる。
単純に隣接マスを走査していけばいいと思う。
再帰でやれば楽だろう。 とりあえずマップを二次元スクエアとして、シティブロック距離を測定、移動可能距離が足りなかった場合はそこで打切り、
これを基本にして虱潰しにやるというのが一番いいですかね?
あとは直前のマスには戻れない、飛ばせるマスや通過点は移動距離に足して計測、とか細かい点が多いものの
当時のスーファミでも出来るくらいだからどのみち計算量は大したことないんですが リブルラブルやギャルパニ3みたいに「プレイヤーが引いて囲んだ線の内側」って
どうやって判定すればいいんでそ? 「線のどちらが内側か」という問題なら符号付き面積を求める方法があります。
もしくは、「確実に外側である適当な点から最初に線を横切った先は内側」
という判定方法もあります。
2Dアクションゲーム何ですけども、
キャラに引っ張られる様にスクロールさせるにはどうすれば良いでしょう。
常にキャラが中央に来るのではなく、中央から一定距離離れた所からキャラを追う といった感じです。 スクロール境界線を越えた分だけスクロールさせればよいでしょう。 >>176
有難うございます。正にその通りでした。 スーパーマリオブラザーズの様なゲームの場合、
ブロック等を全てスプライトで処理するのは やはり無理がありますよね あまり今のPCのマシンパワーを舐めないほうがいい
表示範囲外のところは勝手に無視してくれたりするんで
最適化とか効率はモノが動いてからでも十分間に合う
まずは思いついた方法、いちばん簡単にコーディングできそうな方法でやってみるが吉 >>179
有難うございます。
とりあえず組んでみる事にしました。 スクロールゲームでの、オフセット方式で座標を更新するとして、
画面のオフセット位置の更新ってどのタイミングでやるべきなのでしょう。
位置はプレイヤーに追従させるとして、プレイヤーの処理後だと プレイヤーの処理中にオフセット位置を用いる処理があればズレてしまうし、
結局どのタイミングでも、完全な同期は無理なのでしょうか。 2Dの無限マップってどうやってデータ保存しとけばいいんだろう
2次元リストだとプラス方向にしか伸ばせないし 簡単にお金が稼げる方法興味ある人だけ見てください。
グーグル検索⇒『来島のモノノリウエ』
FNI7DS9IDU >>184
基本的には動的に生成(プロシージャル)
乱数はパーリンノイズ
変化があったとこだけ差分を記録
見てないところでマジレスする快感
なお正しい方法かは知らん(俺だったらそうするってだけ) せっかくなので補足。
パーリンノイズは、「改良パーリンノイズ」のほう。
改良は、各頂点座標をシードにしたハッシュ値を乱数替わりにするので、
時間的にもメモリ的にもほぼノーコストで、各頂点のベクトルを再現できる。
(各頂点のベクトルを、メモリ等に保存しておく必要がない)
なので、無限マップの任意の座標の地形を、いつでも同じ形に再現できる。 昔のドラクエなどにあるメッセージ表示ってどうやるのでしょうか?
一文字づつ文字が表示されるみたいな。 2Dシューティングのホーミング弾が作れません
外積計算して正負で軸があってるか判断、
それを弾の個数分やるって事であってるんでしょうか もう見てないだろうが、
ホーミング弾の進行方向から見て、目標物が右側にあるのか左側にあるのか調べる。
(弾の移動ベクトルのatan2と、弾から物への方向ベクトルのatan2との比較)
右側にあるなら、ホーミング弾の移動ベクトルを右回転、左なら左回転。
ただし、回転角度には上限を設けないと、カクッと動くことになるw
最近のコンピュータって速いから、こんなもんで十分じゃないかな。。。と妄想w みてます!ありがとうございます
今はホーミング弾の目標が軸の左にあるか右にあるかを外積の正負で判断し、
弾一つ一つをループさせてみています
衝突判定に使う4分木の様な、効率的なアルゴリズムがあったりするのでしょうか 見られてたw
ホーミング弾って、距離離れてても追尾するイメージあるから、
四分木みたいな領域分轄はできないんじゃないかなぁ
処理速度の最適化は、一番重い処理を見極めて、
そこを高速化するのが効果的と思うけど、
ホーミング弾って、回転行列を使うから、
ホーミング角度θに応じたsinθとcosθを、あらかじめ計算しておくって手はあるかも。
(ホーミング角度θは、固定値なはずなので) わざと0.5秒とか一定間隔をあけてホーミングしたほうが
動きがカクカクしないしゲーム難易度的にもいいと思うぞ
(右回転なら右回転を0.5秒続ける) public int Sayu(Pos arg)
{
var buf = arg.posF - posF;
return Lib.GetSeiFu((vecF.X * buf.Y) - (vecF.Y * buf.X));
}
これを貼れと言われた気が。