3Dゲーム製作記録 2020/05/25 追いかけっこ2


 追跡プログラムを修正した。
 動画では前回との違いがわからないけど、だいぶよくなってるんだよ……。
 ノードに向かう時、目標座標をランダムに少しずらそうと思ってたけど、やらなくてもそこそこ自然に見えそうなのでそのままにした。
 ノード到達の判定が半径6メートルなので、無理にずらさなくても自動的にある程度のランダム性が出るわけですよ。

 動画中で敵の群れが大回りすることがあるように見えるのは、経路の更新が数秒おきになっているため。
 自機に近い群れは遠回りしがちになる。
 距離によって更新頻度を変えると良さそうだけどとりあえずはこのまま。

.
●今回の動作

 自機を視認したあと追跡状態になる。

 自分とターゲットの最寄りのノード(緑色の玉)を検索し、最短経路を調べて移動予定のノードリストを作る。

 追跡状態には、
・自機を追うモード
・1個先のノードを追うモード
・3個先のノードを追うモード
 の三種類がある。

 最初は3個先モードで、壁に接触すると数秒間1個先モードになる。
 射程範囲かつ自機に視線が通ったら自機を追うモードになる。

 自機を追うモードでは、もう少し接近しつつ左右にフラフラ動く。
 今はテスト用なのでかなり接近するようになってるけど実際はもっと遠くから攻撃してくる。

.
 はじめは2個先を追うようにした。しかしまだジグザグ移動感が強かったので3個先にしてみた。

 あと説明しづらい問題にかなり悩んだ……。
 がんばって説明してみると、再検索や目標地点に到達した時の処理が意外にややこしいという問題なんですよ……。
 最終ノードに到達したときに自機の位置を再検索するんだけど、中途半端に近いといろいろ問題が起こる。(自機までのノード数が0~2くらいのとき)
 また、検索直後は直近か1個先のノードを目指したほうが都合がいいものの、自機が広いエリアを逃げているときなどは直近や1個先ノードを目指すと変なところでカクっと曲がったりする。
 このあたりは完全にプログラム技術&ロジック構築能力の問題である……。(その場しのぎの処理を積み重ねたため効率のよい流れになっていない)

 こういうのがいろいろあって、「基本は3個先のノードを目指し、障害物にn回(とりあえず20フレームごとにチェックして3回以上)触れたら数秒間1個先ノードを目指す。まだ障害物に触れるようなら直近ノードを目指す」という形にした。

 あと、障害物以外にも崖や落とし穴を回避する処理も入れる必要がある。
 キャラ前方1メートルの位置を基準に、下方1メートルにレイを飛ばして判定する感じでいいのかな……。

.
 1作目に入れるかはわからないけど、泳ぎに関してもいろいろ考えている。
 泳ぎモードの判定は、キャラの中心から上方100メートルくらいにレイを飛ばして水面との接触を見れば良さそう。
 しかし……これだと地底湖のさらに下に空気のある洞窟を作る場合に困ることになる……。
 他にも水中に沈んだ船とか。プールのあるビルとか。
 いろいろ考えた結果、水底判定用の板ポリを張ればなんとかなりそう。
 真上にレイを飛ばして、先に水底ポリゴンに当たっていたら陸上移動モードになる。

 あと泳ぎ時の視点も悩む。
 泳ぎのあるTPSで、カメラが水面から出たり入ったりすると思いのほか画面が見づらくなったりするわけですよ。
 泳ぎモードでは常に主観視点が良さそうに思える。
 しかし浅瀬だと泳ぎと歩きが頻繁に切り替わったりして鬱陶しくなりそう。

 なので、
・歩きモード
・水面泳ぎモード(カメラは常に水面より上)
・潜りモード(主観視点。酸素ゲージが減る)
 の三種類の移動形式にしてはどうだろうか。

 潜りモード移行にはボタン入力が必要になる。
 ボタンで潜りは面倒なんだけど、現実での潜りも特殊動作という感じがあるので、ワンクッション置くのはいいのではあるまいか。
 水面泳ぎの最中には水中がよく見えないのもゲーム的わくわく感に繋がる気がする。
 実は僕は池や川などの水中が怖いんですよ。何が潜んでいるかわからない。何かに足が絡まって浮かんでこれなくなる恐怖もある。
 泳げないわけではなくて、むしろ遠泳はけっこう得意と言えるかもしれない。しかし自然環境での水中は怖い。
 だからこそゲームでの水中シーンはわくわくする……。

 水流も悩んでいる。
 水面オブジェクト自体に「流れベクトル」のデータ(水流の方向と強さ)を持たせ、レイを飛ばして水中判定するときに流れベクトルも拾ってくればいいかな……。
 深さに応じて流され量が緩やかになったりするのもよさそう。
 激流の底を泳いで秘密の洞窟に入るとか。

 しかしこのやり方だと曲がりくねった川の時に困る。
 水面をたくさん置かねばならない……。
 判定用の水面とテクスチャを張る水面を別にすればいいのか。
 マップ作るのが面倒になりそうである。
 ますます専用のマップエディタが必要になる。

 法線の方向をいじってそれを「流れベクトル」に使えば、テクスチャ水面と判定水面の2枚ですみそうな気もする。
 しかしこれも法線の編集とかめんどくさそう。

.
 いよいよゲーム用マップの試作に取り掛かろう……と思ったものの、移動ブロック(スイッチ&移動足場)が作りかけなのに気付いた。
 作りかけのプログラムを見ていたところなんかすごくわかりにくくて、別の方法にしたほうが良さそうだと思った。

 とりあえず
・制御部分
・接触判定(スイッチの当たり判定)
・移動ブロックの実体
 の3つが必要になる。

 最初は制御部分を親、接触判定と移動ブロックを子、という形で全部3Dオブジェクトにするつもりだった。
 しかし制御部分は「マップ内イベント」として3Dオブジェクトとは切り離したほうがいいのかもしれない。

 制御部分は専用のクラスを作り、マップオブジェクトがイベント情報として持つわけです。
 セーブデータにも反映しやすい。

 接触判定は、設置位置(親に対する相対位置のベクトル)のほかにくっつき対象のポインタを持つ。
 対象がマップなら、自動ドアやエレベータの動作・呼び出しパネルになる。(マップ側にパネルの絵を描く)
 対象が移動ブロックなら、押すと引っ込むタイプのスイッチや乗ると動作するエレベータになる。

.
 現在想定しているスイッチ&足場

・乗るだけで移動、下りたら定位置に戻る簡易エレベータ
・呼び出し付きエレベータ
・スイッチ扉
・複数スイッチ扉(スイッチを全部押すと開く)
・動作後一定時間で定位置に戻る扉(時限開閉式)
・パネルを踏んでいる間動く足場(時計の針のように動く回転橋など)

.
 足場は目標位置を2つ以上持っていて、スイッチ信号を受信するたびに
・1つ先の目標に移動
・すべての目標を一巡
・押されている間次の目標を目指す
 の動作をする。
 次元扉などは一定時間後目標を切り替える。
 なんか複雑になってきたぞ……。

 スイッチも、待機、動作中(無効)、接触中は常に動作)などいろんな状態があってめんどくさい……。
 汎用性を高めようとするから難しくなるのかな……。
 一作目は必要なものをその都度作っていって、二作目から汎用性のあるシステムを作るのがいいのかもしれない。
 3Dなんてわからないことだらけだもんな……。最初からちゃんとやろうとすると完成せずに投げ出すことになるわけですよ。




0
≪ Previous Posts    
Share On Twitter



"坂葉" is creating "ゲーム"
ものすごくかっこいいシューティングゲーム「夜光蛾6」の製作
坂葉 is creating ゲーム

ものすごくかっこいいシューティングゲーム「夜光蛾6」の製作
If you support right now, You’ll immediately get access to as many as 163 patron-only posts!
>> <<