FC2ブログ

ニートが頑張るブログ

ニートが現実逃避するために創作活動など色々とカオスに頑張ってみる
ニートが頑張るブログ TOP  >  自作ゲーム開発 >  アニマルメーカー改善中

アニマルメーカー改善中


随分久しぶりにUnity開発やった気がする。
なんでこんな久しぶりなのか。
まぁ今年の半分は、「生活費を稼ぐためのシステム」を構築するために潰した、ということにしよう。
上手く行ってるかはともかくとして。


で、やってみてまぁ色々進みました。




やったこと。

・エフェクト
・素手殴り
・足
・スローモーション
・注視
・ロックオン
・視界
・敵挙動
・地形に合わせて傾く
・・・

大体こんな感じ。



まあとにかくやってみれば
ラプトルがこっちについてきてくれます。
糞可愛い。

じゃれるラプトル

もうこれだけで全部どうでもいいです。



 

◆エフェクト

今までエフェクト出してなかったけど、
まぁようやくshurikenをちょっとだけ覚えてみた。


作ったのは

・足元から出る煙
・火花
・血


まだこんだけです。 しかもショボい



「煙」は非常にテキトー。
でもまぁ、今考えてみると、デモンズソウルでキャラの足元に出る煙、
あれもこれくらいテキトーなパーティクルだったのではないかと思う。

とにかく出しとけ感。


「火花」
trail機能のあるエフェクトですね。
バチコン火花

一応発光体のプレハブを撒き散らすというのはやっています。

今思えば、自分は自力でshurikenみたいなシステムを作ろうとしてたんだなぁ。
エフェクトメーカーとか、結構パーティクルシステムに似てる所あるぞ。

自分が最初にエフェクトメーカー作ろうとしたの、何年前だ?
shurikenより前じゃない?



「血」
これも今はまだ非常にヘボい。

でも一応、スクリプト付きで、
「衝突によってエフェクトを産むエフェクト」というのを作ってみたわけです。

まぁこれも、同じようなことはずーっと前からflashでやってたのですよね。
自力でtrailみたいなのやってたわけだよ。


んで、flash時代の血の方がまだよかったです。

昔の血の表現


血が地面に落ちたら広がる血を産む、というのは作ったけど、
血がにかかったら垂れる血を産む、というのはまだ出来てません。


◆素手殴り

武器を持ってないとき用の攻撃モーションというのを作ってみた。

で、人間の場合は「殴り」です。

恐竜の場合は「噛みつき」になります。
前の頭突きボタンは廃止して、これと統合しました。


でまだ素手攻撃の攻撃判定は出来てません。 いくら殴られても無害です。

壁殴りするミクさん

でも↑この「ボコン感」はなんか好きだ。

やるせない壁殴り感がある。 チクショウって感じがする。


殴りかかってくるミクさん

主人公を変えて、行動モードを攻撃に変えると、
ミクさんが物凄い勢いで殴りかかってきます。 結構怖い。


◆足の動き

前のバージョンでは、
恐竜の足の動きは良くなったけど、
まだまだ人間の足の動きがすっげー変でした。

なんか、「引きずってる感」が出てて、
ちゃんとのびのびあるけてない感じ?

3関節だと上手く行くけど、2関節だとダメな感じ?

人間の、二足歩行してて、足がまっすぐな感じが、
上手く作用できないのかもしれない。

今もまだ変だけどさ、
でも、まぁ前のと比べたらだいぶ人間の足の動きも良くなったのが分かってもらえると思う。


この辺、何をどう直したのか、に関しては、説明不可能。


「別の部分の話」はできる。

raycastにちゃんと足の長さを最初から入れることで条件文を減らすとか、
あと raycastにレイヤーマスクを入れたことと、
レイヤー構成を考えることで、「足から撃つrayは地形にしか刺さらないようにする」
みたいなこともちゃんとやるようにしました。

でもこれらは処理の軽さにつながるだけで、
根本のところのアニマルメーカーの足の動き自体が改善するわけではないのです。
よってそこは説明不可能。


◆スローモーション

Mキーを押すとスローモーションがかかる、みたいなことを
最初期からやってはいるのですが、
上手くいってなかったですよね。



でもこれは、「スローモーションはこのようなゲームでは重要だろう」という考えがあるからなんです。

フォールアウトのV.A.T.S.、
ベイグラントストーリーの時間止め、
メタルギアライジングの斬撃モード、
デッドスペースのステイシス
・・・

このように「部位破壊」「場所を選んで攻撃することが重要なゲーム」
には、必ずと言っていいほど、時間を止める要素や時間をゆっくりする要素があるわけです。

アニマルメーカーから作れるゲームは、
他のどのようなゲームよりも、「部位破壊」がリアルで重要なシステムになりうるはずなのです。
四肢切断をしたあとも、欠損した足の通りに敵が地面を蹴って這いずり回り続けるんだから。

普通のゲームじゃ四肢切断なんて無いし、
あったとしても、MGRの敵も、デドスペの敵も、
足を切断したらただの芋虫みたいな這いずるモードになるだけです。

片方だけ足をもいだ虫がどのような這い回り方をするか、をきちんとシミュレートなど出来てないわけです。


・・・まぁとにかく、
だからこそ、アニマルメーカーにはスローモーションをちゃんと表現できる状態に持っていかないとなぁ
とは思っているわけです。


で、なんで今まで
特にスローモーションが上手くいってなかったかというと
これは場所によって「デルタタイム」をちゃんと入れてなかったりしたからです。

そこんところを少しずつ直していってます。
つっても、そんな完全にすべてを直せてはいないのですよ。


例えば、
Mashf.Lerpを使って、フレームごとに
何かから何かに半分ずつ分数的に近づいていくパラメーターがあったとする。

位置でも、角度でも、ベクトルでも・・・
そういうのが自分のプログラムには山程ある。


A = Mathf.Lerp( A , B , 0.2);
と、テキトーに書いてあるのがあったとする。


これを
A = Mathf.Lerp( A , B , 0.2* デルタタイム*60 );

と書き直したら、それで上手く直せたと言えるのだろうか???


30fpsのときは、

AからBに 1/5 ずつ近づいていく動きである。
それが、1秒に30回

60fpsのときは、
AからBに 1/10 ずつ近づいていく動きになる。
それを1秒間に60回

これらは正確には、「同じ動き」にゃーならんはずですよ、本当は。


Aを、Bをだとすると
「0.8^30」
「0.9^60」の差
、みたいなことが出てくるはずなんだよ。

0.00179701029
0.00123794003

これくらいの差が出てくるのだよ。
どうすんだろうね。 (分かってない)


◆注視システム
チラっと見てからプイっとするカマキリ
このカマキリの頭の動きが可愛い。


前にも、主人公が注視歩きをしてるときは
中心を見ながら平行移動をする、
という程度には注視は出来ていたのですが、

それを色々増やしてみました。

近くのアイテムを見るラプトル
例えば、近くに落ちているアイテムをジロジロするシステム。

これを最初にやったゲームはサイレントヒル2なんじゃないかなぁ???
知らんけど。

これは最初に見たとき天才だと思ったもんですよ。

普通はアイテムを光らせるとかエフェクト出すとかだと思う。

(バイオ4辺りで、明滅させるというのが決定的になり、今ではどんなリアル系のアドベンチャーゲームでも)
(結局アイテム自体は明滅してる、なんてのが増えてしまったもんだ)

(その中でサイレントヒルは、キャラがそこをチラチラ見る、というのでプレイヤーにアイテムの位置、存在を教えてくれた)
(ホント天才)


で、問題はこれ。
近くの斧をジロジロ見るのはいいとして、
拾ったあとの斧までずーっと見てるのでした。


普通のゲームなら、アイテムだろうが武器だろうが、取得したらその場で消滅して
アイテムインベントリ行きになったりします。

そんで、メニューのUIを経て、武器装備をして、手の部分にアタッチしたりする訳ですが、
もうその時点では、最初に落ちていた武器モデルと、手にくっついている武器モデルは、「別モン」なわけですよ。

だからこそそこで自動的に視線は切れてくれると思うのですが、
(ontriggerexit的にはともかく)
(参照という意味でも切れるし)

でも、自分のこの表現の場合はそうはいかない。

ずっと、「落ちてたアイテムと同じオブジェクト」がその場でそそのまま手元にくっつくし、
その武器を振るうし、その武器を投げ、また拾うことが出来るのです。

だから、視線が切れない。

まぁ今はこれ直ってるんだけど。


◆ロックオン

前のやつではコントロールキーを押すと
画面中央に注視するだけでしたが、

今回からちゃんと、一番近くの敵(それも視界内にいる敵だけというリアル路線)
ロックオンする、という風にしました。

ロックオンカーソル

これも結局、
「自分の視界内にいる敵のリスト」というのをちゃんと作ってやるしかないのですよね。

この辺はさっきのアイテムジロジロとつながるところではあります。


でも、
どっちかというとこれは、
UI系の勉強でしたね。
画面上の位置に、UI画像を移動させる、という奴です。


で、結局ダークソウルのイカリングみたいなターゲットカーソルにしてしまっているじゃないか。

ブラボみたいな光点でいいんだとか言ってた筈なのに、
まずは結局こういうのを作りたくなっちゃうもんなんだよ。


◆視界


敵の挙動を作るために、
まずやったことが「視界」の用意でした。

これがもう、flash時代には絶対に出来ないことでしたね。

内部的には2Dのゲームで、ホント無理やりいろんなことやろうとしてましたが、
「視界内に敵がいるかどうか」てのはまじでやれなかった。


で、ここでUnityって円錐や四角錐をプリミティブとして配置出来ないことに気づく。
なんでやねん。
四角錐は絶対いるでしょ。

視界用メッシュ

で、結局こんな感じのメッシュをつくりました。
四角錐じゃ多分だめだ。 (でもソレにしたって半円柱があればそれでもよかった)

んでこれを、「頭」の位置、角度に合わせて動かすようにした。
これをメッシュコライダーとして、
近くにいる敵のリストというのをもたせるようにしています。


これで、主人公はロックオンすべき敵を見れるし、
敵は主人公の探索が出来るようになりました。


・・・この辺ちゃんと作れば、ステルスゲームも作れるようになるなぁ。

勿論いまはまだ凄いテキトーです。
「メッシュコライダーの中に敵や主人公がいるかどうか」でしか判断してないですからね。

ここで、もう一段階、rayを主人公に向かって撃って、「それが地形に阻まれずに突き刺さるかどうか」
を見ることで、
ようやく「正確に」主人公を見つけることが出来るようになるのだと思う。


こういうやり方でいいんだよね?

最初から光線的な処理をするわけにはいかんと思う。
太さを持ったrayは出せるけど、視界のような広がりをもたせようとするのは無理だろうし、
そんなものをやたらめったら撃つわけにもいかない。

だから、「箱的な判定」と「光線的な判定」の組み合わせによって、敵は主人公を見てる。
そしてその順番はこう。  「箱」から「ビーム」

(それとも「ビーム」から「箱」というのもあるのだろうか?)


・・・まぁそんな感じで、普通のゲームが内部的にどういうことをやっているのか
勝手にエスパーしているところですが、
アニマルメーカーならアニマルメーカーならではの
独特のことがこれから出来るようになるはず。


例えば、首チョンパしたら頭がゴロゴロ転がるワケですが、
それに合わせて視界も転がるようになっているのですよ!

だから、首を飛ばせばちゃんと敵の視界がおかしくなる、というのも今の段階では出来ているのです。
(たまたま落ちた首の視界内に入っていれば、バレるということが出来てる)


首が飛んでるんだから視界ごと消えろよという感じではあるけど、
まぁこれはこれで面白い。 消すのは簡単だし。


あとちゃんと首の動きと視界の動きをあわせているから、
もしこれから敵にも「近くのアイテムをジロジロする」みたいな機能をつけたなら、
敵の足元にアイテムや武器を投げることで、敵の視界を誘導して、ステルス的に進めるようになる、
みたいな要素とか、まぁそういう謎解きゲームも作れるようになると思う。

音に反応して振り向く、とかでもいいけどね。
メタルギアじゃよくある話。

てか忍び団子


◆敵挙動

で、敵挙動です。

今の段階で、いきなり始めて、ラプトルがこっちを振り向いて主人公を見つけたら、
ダッシュで近づいてきてくれると思います。
めっちゃ可愛い。


もっと可愛くしたかったら、
Bキー押して巨大化したら、 本当にずっと走ってついてくるようになる。

ダッシュでついてくるラプトルがめっちゃ可愛い
これで見上げ気味になるので、やはり可愛い。


こういう追従システムとして結構重要なのが、
主人公がサイドを取ろうとしたときですね。
てか、敵が突っ込んでくると自然とそういう位置関係になったりする。


そういう時にどういう風に動くか?


今回は、
主人公が右に回り込もうとすると、左にステップ移動、
主人公が左に回り込もうとすると、右にステップ移動する、

みたいな風にしました。


すると、まぁぐるぐる回るような感じではあります。
(これを逆にすると、「とうせんぼ」するような動きですね)


まぁ当たり前っちゃ当たり前の動きです。



じゃあこれをどう実装するのか?


普通に考えると、
敵と主人公のベクトルを見る。
方向=atan2 (主人公x - 敵x , 主人公z - 敵z)
敵の視界との角度差を見る。
deltaangle(方向 , 敵の視界の角度)
この角度差がある程度より右なら、左。
この角度差がある程度より左なら、右。
というのが普通だと思う。

つまり使うのは、Atan2とか、デルタアングルだとか・・・


そうではないのですよ。


このアニマルメーカーには、
もうすでに敵の「頭の挙動制御用のスクリプト」がある。
そして、注視している時に頭の角度に制限をつけるプログラムが、すでに走っているのです。

これは、注視している敵が凄い横サイドに逃げた時に首がゴキっとならないための制限だったのです。

この首は
60度までしか曲がりません。
-60度までしか曲がりません。

そこでもう判定しているのだから、
その判定をそのまま流用すればいいのです。

敵の頭のスクリプトが、
注視モードになっているということは、
主人公を発見しているということだ。
そして、その注視モードで、首を60度以上、-60度以下の曲げを発生させているということは、
主人公がサイドに回り込もうとしたということだ。


そこでわざわざ視界を調べて角度判定をしなくていい。
その頭の角度制限判定を使って、直接、歩の運び方を指定すればいい。



・・・という感じで作ったのです。
で、上手く行った。


今回、
我ながら、
これは賢くやったんじゃないかなぁと思ってるのは、このポイントですね。


賢いし、理にかなっていると思った。


主人公を注視していたら、首が痛くなるほど曲がることが起きた。
それ即ち、主人公がサイドに回り込もうとしたということだ!
敵と主人公の位置関係の計算、デルタアングルとか計算する必要なかったんや!!


◆地形に合わせて傾く

地形に合わせて傾く体


これ、随分前にflash時代にもやろうとしていたことですね。

flash時代でやろうとしたらゲキムズだったり、
そもそも理論上は正しくても処理自体がクソ重くて色々諦めざるを得なかったり・・・。
そもそも内部的に2Dのゲームでこんなに回転を扱おうとしたら頭がおかしくなる。

そんな問題だったのですが、
まぁ比較的簡単に解決できるようになるもんですね。




まぁこんなのは、
・マイナスtransform.upの向きに、主人公からraycastを撃つ。

・それが地面に衝突したら、そのhit.normalを調べて、地面の法線ベクトルを得られる。

・次は、その法線ベクトルと、transform.upの角度の差を計算する。

・でてきた角度差を、主人公にかける。


ハイハイそれで終わり。



・・・
それだけのことでした。


(それだけのことをparaflaで自力でやろうとしていた馬鹿がいるらしい)



でも、それがそんだけで簡単に済むのは、
やはりキャラクターコントローラー系で、普通にゲーム作ってる人にとって、
なのですよね。


自分の場合はちょっと話が変わってくる。


なぜなら自分のアニマルメーカーのシステムでは、
キャラクターのtransformを、キャラの走り方に合わせて、さらに色々と傾けているからです。


x軸方向、y軸方向、z軸方向の揺れパラメーターというのがあります。
それプラス、「走っている方向への前のめり込み」というのがある。 
(これはflash版のアニマルメーカーにもあるパラメーター)



この「4つの揺れ」、軸回転を、
リアルタイムに計算して、キャラの全身を傾けているのです。



それなのに、マイナスtransform.upと、足元の地面の法線ベクトルとの角度差を、
キャラクターにかける
みたいなことをするとどうなるかというと、

相殺

こうなります。
せっかく表現していたキャラの揺れが全部相殺されて、消えるのですね。


キャラクターコントローラー系で、
決め打ちのアニメーションでキャクターを走らせてる人は、
こんなの困らないのですよ。

「キャラが走っている時に発生する体の傾き、揺れ」なんてものは、全部モーション自体の中に予め入っていて
transformの問題ではないから。 transform.upとは普通に上を向いているモノ。

(でも、だからこそ、そういうので動くキャラというのは動きが硬いんだよね)
(普通のゲームでキャラを旋回させたときの動きがリアルじゃないのもそういうことかもしれん)



で、
じゃあ自分の場合これをどうやって解決したらいいのか?


処理の順番を変える?
全身を地面の傾向きに回転させてから、キャラの走り用の全身揺らしを入れる?


それでは上手く行かなかったのです。

(もうこの時点で上手く説明出来ないが、まぁ上手くいかんのです)


相対的に変わる主人公のtransform.upのマイナスじゃなくて、
絶対的な、Vector3.downとか使えばいいんじゃないの?


そうじゃあない。 いやそれで今回は解決するかもしれないけど、
自分はもっとこう、キャラが全身ごと回転した上でのこととかも考えている。

(カマキリゲームで、重力方向が360度変化するような、土管のような地形の中を走り回るようなことまでやりたいと思っている)
(そのやり方では、重力方向が真下で固定のゲームとか、主人公が完全にダウンしたときとかに対応できない)




じゃあどうしたか?

真逆の傾き

これです。

「主人公の上体傾き」と「真逆の曲げ」を、この四角達に常にかけるようにした。


で、この上の四角から下の四角へ、raycastを撃つ。

そのrayが地面に当たったときのhit.normal。 

そしてその法線ベクトルと、「この四角」との角度差を調べる。

その角度差を、今度こそ、「全身」にかける。


・・・
このやり方で解決しましたとさ。


まぁそんな感じでした。



「キャラを足元の地面に合わせて傾ける?」
「簡単簡単、そんなのよくあるよくある」
ある程度分かってる人なら、そう思うかも知れんけど、

それは普通のゲームの作り方ではそうかもしれんけど
自分のは普通じゃないので、もっと大変ですよ~という話でしたとさ。




で、前のバージョンでは、
カマキリが全然段差を登ることが出来なかったのが確認出来ると思いますが、
これでちょっとはカマキリが登れるようになりましたね。 めでたい。

壁に張り付こうとするカマキリ


球体にへばりつくカマキリ
むしろどこまで行くんだと。


(なんでこのアニマルメーカーのシステムでは)
(こんなにカマキリの登坂能力がないのかというと、)
(まぁ理由は色々考えられる)

(でも個別に調整すればファンデルワールス力みたいなのも表現出来るようになるはず)


まぁそんな感じでした。


「キャラの動き周り」の 根本的な部分が
だいぶ固まってきたのではないか、という感じですね。




こっからどこを目指していくのか。


やはり今の自分としては、
「バナナゲーのリメイク」が良いような気がしています。

関連記事
[ 2018/07/04 07:42 ] 自作ゲーム開発 | TB(0) | CM(2)
管理人のみ閲覧できます
このコメントは管理人のみ閲覧できます
[ 2018/07/27 00:16 ] [ 編集 ]
Re: 質問
> 通りすがり さん


> もしネットワークゲームでこの技術を使ったとして、サーバー側で適切な移動かを判定する事はできるんだろうか?
> もしできないなら、ネットワークゲームにすると、アニマルメーカー的移動処理では越えれないはずのところを越えてしまう移動チートを検出できないと思う。





今日はこれだけ返信します。スイマセン。

他のコメ返信は後日やるかも。



基本的にそのとおりだなぁと思います。



アニマルメーカーの移動計算は、
ほんとめんどくさいことを内部でやってます。

これをネットゲームでやったなら、
まぁ、もしできたなら、パフォーマンスはすごくよくなるはずですよね。

普通のネットゲームでは、協力してるプレイヤーの「足が地面を滑ってる」なんてことは、いつまで経っても日常茶飯事ですが、
そこが完全に改善されます。



でも、クソ重いはずです。

>アニマルメーカーの独特な段差処理とかをサーバーでもトレースして、正常な移動であるかをサーバー側で判定できるか?大勢の>キャラクターが接続するサーバーにおいて現実的な性能が出るか?

まさにこういう問題になりますね。




でもプレイヤー側からの入力は「次にどこを向くべきか」というスティック方向の命令順だけであるはずです。


これをサーバー側に送って、
サーバー側で「のみ」アニマルメーカーの処理を全キャラ分やる、

(各マシンで自キャラ分を計算して、サーバーとその整合性を調べる、とかではない)
(サーバーで一括してやることになります)
(結局そのサーバーが凄い性能なだけじゃねーかという感じではありますが)
(でも今のリモートプレイのゲームなんて、そういうことなんじゃないかなぁとか思ったりします)
(プレイヤー側からはコントローラー入力だけ送って、あとは全部サーバー側で計算する)


そして、各キャラの現在位置と、足の位置、姿勢なんかが出る。
そうやって戻ってきた情報をもとに、自キャラ、全キャラの姿勢を 各マシン側で描写する

・・・というふうなやり方であれば、
そのチーター問題は解決するような気はします。



一つの問題は遅延かなとは思います。



んで次は、送るべき移動の方向の命令になにかチート要素を入れて、異常な移動をすることができるかどうか、ということになってきますが
でもまぁ、 コントローラーから連続して送られるような方向の命令なんて、ある程度どのようなものかなんて決まってると思うのですよね。 それを逸脱するような命令を送ってきたやつがいたら、チーター扱いしていいのではないでしょうか?




ちなみに自分としては、オフラインの一人用のゲームを作るだけで手一杯なので、
アニマルメーカーのシステムでオンラインゲームを作るとかは考えることもできないってのが現実ですね。

[ 2018/07/27 12:20 ] [ 編集 ]
コメントの投稿












管理者にだけ表示を許可する
トラックバック
この記事のトラックバックURL

月別カレンダー
07 ≪│2018/08│≫ 09
- - - 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31 -