前回に引き続きですが 進捗の２です。

 

今回の動画はAI部分だけを分離して実際にコースを走らせてみるチェックです。 フィジックスの設定が少しおかしくなっているので コースの路面コリジョンの状態によって時々AIカーがポップしていますが、 これは問題ないですね。 ちょっと突っ込みどころを残したほうが、あえてテストっぽさが出るしいいかな？という判断です。 誰が見てもおかしいところは開発者はだいたい把握してますって（笑

シーンレベルのモデルは流用ですが、一応スプラインベンドに対応して背景オブジェとコリジョンが追従するプロシージャルなコンストラクタを作成して これで道具が一通り揃ったので これから背景作成を始められるかなという段階ですね。

Unityでもできなくはないんですけども 全体に描画が重たい...ので 学習も兼ねて今回はUE4で作ってます。 別にUnityをやらないとかUnrealべったりというわけではなく並行していろいろ進めていますけど なんというかこれは頼まれもので、しかもこちらの都合で数年経っているという。 時間のあるときに詰めてしまわないとまた仕事が忙しくなるとテンションが下がってしまうため 今は少しこちらに比重をおいている感じです。

今どきの自動車のメッシュモデルはノーマルマップで見せかけを良くすると言ったごまかしが効かないので （あまりきれいなハイライトが入らない）、ポリゴン数が結構食うんですよね。 最適化しなくても数万ポリゴンのモデルが処理落ちしない これは開発効率いいです。 シーンの容量はでかいですけど許容範囲じゃないかな。

いろいろと触ってみると 作業に対して見え方が変わって効率が上がったりするので、急がば回れです

 

簡単にAI実装のおはなしをしますね

AIは基本スプライン上をclosedポイント（最も近い場所ね）を探索しながら 車体のローテーションを決定してアクセルのボリュームを上げます。

障害物がある場合は左右どちらかにステアリングを切るavoid処理（障害物を避ける）を実行します。進めない場合は一旦バックギアに入れて戻す。

おおまかにはそのようなシーケンスですが、 それだけでは人間の操作ぽさが出にくいので走行スプラインは複数を配列に登録して、ゲームの進行に合わせてそれらスプラインを選択しながら走行します。 ここらへんは人間の思考と同様に状況に応じて複数パターンのラインを使い分けるということです。

そして走行データをすべて記録しておくレコードシステムを実装します。 最速ラップが出るたびにこの記録をもとにスプライン上のウェイポイントを書き換えてデータとして保持します。 ゲーム開発はあまりスケジュールに余裕がないケースが多いため、開発の序盤にレコードシステムを実装してレベルデザインができ次第テストを行いAIを強化していくことになります。 このシステムを流用したものがゴーストカーと呼ばれるもので、開発中のテストモードをそのままオプションに流用しているというか 基本開発はスケジュールがきついのでオプション系は開発に使用したコードの流用など まかないみたいなものが多かった気がします。

ゲームセンターの筐体の場合は電源を落としても基盤内部にランキングなど簡単なデータを残せるバックアップメモリが搭載されていて、この部分だけ電池が入っています。 家庭用のゲームソフトも電池のバックアップが搭載されていたので理解しやすいかと思います。 サーバーに接続していなかった時代はリリース後も筐体内部のメモリーにデータを蓄え続けて、AIが強化され続けるという仕組みになっていました ※ものによります。 ゲームはリアル世界とはどんなに近づけても法則が異なるため プレイヤーが裏技を発見して突然想定外な記録が出る場合がありますが、 そうした場合でもロム交換のようなコストの掛かる方法は回避することができるため 効率が良い実装だったようです。 もちろんメーカーによって差異があるのでどのゲームも同じではないですよ。 ただし筐体の中にデータを持つのでタイムアタックが加熱しているロケーションは敵AIも強めになりますが、過疎っているロケーションであまりプレイヤーがいないと己との戦いになってしまうという 弱点もあります。

ココらへんの昔話は またおいおいしていくとして

 

 

あとUnity感想的なもの

Unity2018からECSとJobSystemという機能がベータ版？として投入されました。 が まだ積極的に移行していないので見当違いの考えかもしれませんが 構造を理解している開発者には メモリ管理が手動でできるようになる スレッドプログラミングが比較的容易になる というのはメリットになるとは思うのですが、当初のゲームエンジンで開発のハードルを下げるという目的からは遠ざかっているような気もします。

開発の利便性を向上させる目的で、構造体に多くのアトリビュート情報を付加してあるのはエンジン側の設計の都合で それで処理の足を引っ張るようならば、そこら辺り考えずに今まで通りのコードの書き方をすれば、ECSやJobSystem使用時と同等の性能が発揮できるようにコンパイル時に最適化されるだけでよいだけでは という気がしなくもないです。 さらなる調整オプションとして使用できる分には良いのですが、 今ひとつ方向性が見えにくくなってきました。 うまく伝わるかわかりませんが、動作が不安定なアプリケーションの改善点が、「新機能のオートセーブがつきました ！!」だったような なんとなくですが

今さらですがゲームエンジンもだいぶ市民権を得てきたようで 当初は「ゲームエンジンだけでプログラムの基礎を学ばなければ、ゲームエンジンがなくなったらどうするんだ 」という意見も散見されましたが （長く開発を続けている職人さんね） もうさすがに急になくなるとかは無いでしょう。 スクラッチでゲームエンジンと同等の質と開発スピードに対抗できるならば分かりませんが。 寿司職人さんが、「回転寿司が急になくなったらどうするんですか」といっているようなもので、市場の需要を考えれば、まずないでしょう。

将来 現行ゲームエンジンにとって変わるものが出てきたとして使用するのは人間ですからインターフェースは大きなシェアを持っているツールに寄せてくるでしょうし 導入しやすい似たような環境になると思うので ビッグウェーブに乗っていけば大丈夫ではないでしょうか。

 

問題としてはゲームエンジンは進化が早いので必死に機能をマスターすることを重点にしてしまうとゲームを作れず終わる可能性はあります。しかも割と多いタイプな気がします。 ネットは大量の情報が参照できますけど ゲームはシステムや種類ごとに実装方法が異なるため情報化しにくく ネット上では制作物にぴったりと合った情報が見つけにくいか 見つからない そのため実装して制作ノウハウを蓄積していく必要があってその部分はネットの情報だけでは補強できないからです。

「クックパッドを毎日閲覧して料理の知識を身につけたら いつかはシェフになれるはず！」といった会話を小耳に挟んだとして ナンセンスなのでまずは実際に料理を作ってくださいというアドバイスをすると思いますがどうでしょう。 とりあえず実際に制作してゲーム制作ノウハウを身につけていけば 現行のゲームエンジンが廃れようがどんと来いなので、モノをどんどん作らないとですね。

 

 

ということで、 もうちょっと頑張っていきましょう

ではまた