- 761： 名前：枯れた名無しの水平思考 ：2011/12/04(日) 00:18:59.00 ID:Hj2CeJmq0(9)
- ジャンプ方向によってジャンプ距離が違うんだね。
アグリオスを仮想的にして研究していたのが間違いだった。
どの方向にジャンプしても対応できる予測射撃は不可能だったのか。
見ろ・・・これが予測射撃の魅力に溺れた者の末路だ・・・
人が未来を予測するなど・・・元より無理だったのだ・・・
>>760
0か1かを入れているカウンタのことをフラグと呼んでいた。
敵がジャンプしていればフラグに1を入れる。
敵がジャンプしていなくてフラグが1なら、敵が着地したということになる。
などというように判定に利用する。 - 763： 名前：枯れた名無しの水平思考 ：2011/12/04(日) 00:32:36.18 ID:Hj2CeJmq0(9)
- 敵の向きと敵の移動方向から、敵がどの方向のジャンプを使っているのかを見極めることは可能。
しかしそれぞれの方向のジャンプの移動距離を保存しておかなければならず、そのためにはカウンタが全8方向分必要になる。
どうやってもカウンタが足りない。
いやちょっとまて、左右のジャンプの移動距離はおそらく全ての機体で共通なはずだ。
だから実際に保存する必要があるのは4種類だけか。
いやいや、そもそも保存する必要があるか？
あらかじめ計測しておけばいいだけじゃないのか？
ん？ということは戦闘中に敵のジャンプの移動距離を取得するために使っていたカウンタは節約できるんじゃないのか？
重力が小さいあるいは大きい一部のステージではそもそも着地を取れない。
だからあらかじめ用意した機体ごとのジャンプ移動距離を使っても何ら問題はないはずだ。
まだ終わっていない。
俺がこのゲームをクソゲーに変えるんだ。 - 767： 名前：枯れた名無しの水平思考 ：2011/12/04(日) 00:59:48.73 ID:Hj2CeJmq0(9)
- 助言ありがとう。
滞空時間は計測しても利用できるのが近距離しかなく、
着弾を着地タイミングを合わせるために待つにしてもその間移動できないため、
あまり計測する意味がないようだ。
敵のジャンプ移動距離を求めるプログラムを流用して、
自機のそれを求めるOKEを作って、まず初級演習場の値を自分で計測してみるよ。
ルーチンの領域がすでに結構埋まっているし、処理速度の問題から、
普通にあらかじめ用意した機体毎のジャンプ距離の値を計算に用いるのには無理がある。
だから味方に「機体毎のジャンプ距離の値を教えてくれる機体」を用意することにした。
ルーチンが1個使えれば実装できるはずだ。
チャンネルを使って敵の機体番号とジャンプ方向を送信し、ジャンプ距離を返信してもらおう。
ジャンプ距離を検索している間に、予測計算をすれば実行時間を抑えられる。
今最高に胸が熱くなっている。 - 770： 名前：枯れた名無しの水平思考 ：2011/12/04(日) 01:24:13.52 ID:Hj2CeJmq0(9)
- みなありがとう。
ありがたく頂戴します。
手早く実装させたい。
ただ恐ろしき数�型�Cの定期試験が迫っているのでうまいこと回避ロジックを用意しないと。
卒業できんのかな。OKEの弾道より自分の未来見据えるべきなのかな。 - 774： 名前：枯れた名無しの水平思考 ：2011/12/04(日) 01:49:54.90 ID:Hj2CeJmq0(9)
- >>769
見て感動した。このカウンタ数やこのチップ数でここまでできるのか。
ジャンプ距離をあらかじめ用意すると、ジャンプ距離を記憶しておくカウンタも
着地を確認するためのフラグカウンタもいらなくなる。
味方にジャンプ距離などの検索をまかせれば、その値を取得する時間が実質ほとんどなくなる。
ジャンプ方向によって距離が違うことを含め、毎回ジャンプ距離を取得するのは利口ではなかったようだ。
なんで他にやらねばならないことがあるときの方が色々案が浮かぶのか。 - 781： 名前：枯れた名無しの水平思考 ：2011/12/04(日) 09:31:48.28 ID:Hj2CeJmq0(9)
- >>776
なるほど距離じゃなくて時間をかけるという方法があるのか。
自分は距離をかけて着地地点を求めるものしか作っていなかったけど、
求めた変化角が1fごとのものということが確定していれば、
任意のタイミングの経過フレームを利用すれば、ジャンプ中の座標も求められるのか。
無論あらかじめ着地にかかるフレームを調べておけば着地地点の座標も求まる。
私にはジャンプ中の平面移動がどうなってんのかよくわかんなかったから、
着地という結果だけについて考えていたが、思い出してみれば平面的にはこれただの等速運動なんだな。
座標変換がいらないだと…
そうか、「敵の座標予測→そこを攻撃する角度を求める」という流れで組んでいたがそれが短縮できるのか。
ああそうか座標に直さずに最初から自機の位置を減算してから相対的な角度をうんぬん。
つまり「座標→角度→座標→角度」ではなく「座標→角度」だけで実装できるのか。
無駄な作業が入ってるな。全面的にプログラムを見直すことにした。 - 784： 名前：枯れた名無しの水平思考 ：2011/12/04(日) 10:29:30.05 ID:Hj2CeJmq0(9)
- そもそも1フレームの移動距離を求めれば距離をあらかじめ用意しておく必要ないじゃん。
時間に注目すると大分プログラムが短く、どの距離にジャンプされても対応できるものなる。
なるほどそういうことか。予測射撃始まった。 - 785： 名前：枯れた名無しの水平思考 ：2011/12/04(日) 10:36:13.87 ID:Hj2CeJmq0(9)
- ×1フレームの移動距離を求めれば
○1フレームの移動角を求めれば
×どの距離にジャンプされても
○どの方向にジャンプされても
すんまそん - 794： 名前：枯れた名無しの水平思考 ：2011/12/04(日) 13:28:44.59 ID:Hj2CeJmq0(9)
- >>790
一応それでもできるんだろうけど、それだとジャンプ最高点に相手が到達するまで計算できない。
ジャンプ時間は機体にも夜がおよそ0.90秒つまり27フレーム。
この半分の13フレーム目に計算を開始したとて、計算に7フレームかかるとしよう。
残った7フレームでは射撃から着弾が間に合わないと思う。
これが間に合う距離だと予測射撃を行うより普通に撃った方が強いと思うんだ。
ジャンプ開始時の1fの差分から予測した方が早い。
>>792
気付いたらもはや目的は勝利ではなくなっていた。
■TOP■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- ツリー表示 dat