F-ZERO的なゲームを作りたいと思っていますが、私の場合、ネックはライバル車のAIでした。 今回、指定したポイントを指定した順番に通過するアルゴリズムを思いつきまして、原型を作ってみました。多分、この手のアルゴリズムには正式名称があるんだと思いますが、私は勝手に「パイロット・トレース・アルゴリズム」(Pilot Tracing Algorithm 略してPTA)と呼ばせていただいております。 キー【KE3X23K4】でダウンロードしたプロジェクトの中の「HNZPTA」を実行し、下画面タッチで、0～7の8点を指定してください。8点の指定が終わると、車がドリフトしながら8点を順に通過します。

車のドリフトの挙動は、少し前のИあっキー#ジャロさんの投稿を参考にさせていただいております。 今回は、ハンドルの舵角速度は一定、アクセルもベタ踏みの状態ですが、次は、ハンドル舵角やアクセル、ブレーキの微妙な制御の盛り込みに挑戦します。 更に、車同士の衝突時の挙動についても検討します。

F-ZEROのエディタ「風情」に仕組みが載ってます。 http://borokobo.web.fc2.com/neo/fuzee/index.html 参考になるかも知れません。

参考になるのは、この辺 http://borokobo.web.fc2.com/neo/fuzee/areakotu.html

そのようなページがあるとは存じませんでした。今拝見しましたが、これは結構詳しく書いてあって、参考になりますね。ご教示いただきましてありがとうございます。

くんくんくん。 ドリフトするAIの情報を嗅ぎ付けて やって来ました。(お知らせが来ただけ← DLしてみます。

As far as I can understand, this is an AI racing setup using numbers to direct the path of AI cars. Is that right?

＞Иあっキー#ジャロさん： 自分が描いた線の上をトレースするAIを考えているとおっしゃっていましたが、今回の私のプログラムも、その考え方に極めて近いです。トレース対象が連続的な線か、離散的な点かの違いだけですね。

@BeefJerkey: That's right! Now I'm studying automatic driving method for making new racing game like F-ZERO.

点の打ち方によってはぐるぐる回って たどり着かない事もあるみたいですね… ちなみに線の上を走行するというのは、 グラフィックに手書きで線を書いて、 GSPOIT()だけを頼りに(センサー的な) 走行するというものです。 高校見学で見たマイコンカーを プチコン内で再現してみたくなったので、 ついでにドリフトさせてみちゃいました。

今回のアルゴリズムは、ある目標点に舵を向けて進み、目標点と自分の距離が16ドット以内になったら、目標点を次に移す、という単純なものです。ところが、先述したとおり、舵角速度は一定で、アクセルベタ踏みのため、自分の進行方向と目標点が大きくずれている場合、目標点を中心に、延々とに回り続けることがあるんです。まぁPTAは開発に着手したばっかりなのでお許しを･･･ やはり連続舵角制御と加減速制御を早急に盛り込まないといけませんね。

F-ZEROって複雑なのね。 いつか完成する日を夢見るのよね。

ただし、あまり複雑なアルゴリズムにしてしまうと、今度は計算に時間が掛ってしまい、60fpsを維持するのが難しくなります。私の目標は、れいさんのF-ねこを超えるゲームを作ることですが、実際問題、F-ねこに勝る可能性のある要素は、唯一fpsだけなんですよね。 なので、単純かつ効果的なアルゴリズムを構築する必要があるわけですが、幸いなことに、ある程度の見通しはついてきている感じです。

You're doing very well! When your Mode 7 engine is perfected, you can simple apply this setup to it, making set positions on the track for the AI cars!

処理速度に一番影響するのは二軸回転の描画処理だと思います。 自分も二軸回転の処理作ってるので、気になって以前、F-ねこの描画処理読んでみましたが、 F-ねこは解像度を高めるためにインターレースで表示してますし、 描画ルーチンのループ処理の展開もしてあって、処理速度の点ではかなりやってる感じするので、FPSでF-ねこを超えるのは難しそうですね。 更なる高速化するとしたら、高度サウンドユニットの配列間の一括演算を使うとかかなぁ。 でもHanzoさんの場合、二軸回転使わない別の描画処理を作ってたの見かけました、あの描画方法で作るのですかね。 期待してます。

@BeefJerkey If we make Mode 7 algorithm on SmileBASIC, we have to choose either "processing speed" or "graphic resolution", and I will choose the former. Also I have to make simple and effective AI for rival cars in order to keep processing speed. Now I've made new AI. Could you try "HNZPTAB" in "93E8X5RX"?

＞ZEXさん： 画像処理方法として私が考えているのは、【93E8X5RX】の中の「HNZMD7F」で実施しているやり方です。 要は、2軸回転のうちの1軸（ヨー角）について、あらかじめグラフィック面に回転させた画像を作って置いておくことで、処理時間を稼ぎます。回転がカクカクするのが難点ですが、その代わり、60fpsで動作します。 F-ねこに勝てるかも知れないのは、まさにこの一点のみなので、ライバル車のAIをできるだけ軽く作って、何としても60fpsをキープする必要があると思っております。

I see what you mean about processing speed. Your Mode 7 tests always took a long time to load. That last one was good, though. I don't understand why SmileBASIC can't use more of the 3DS's processing power. The system itself can obviously handle a whole lot more than this.