προφε 2020/12/12 19:00

きょだいむすめしみゅれーたver.2.0.1(コントローラー&カメラ機能テスト用)

どうもです。前回の記事から三ヶ月ほど経ってしまいましたがゲームの進捗状況を報告したいと思います。まずは動画をどうぞ。

https://youtu.be/QLP6iSefh10

Youtubeの動画でも述べましたが前回(ver.2.0.0)からの変更点は以下の通りとなっております。


①プレイヤーコントローラーの変更
②カメラコントローラーの変更
③アクションシステムの変更
④建物が破壊可能


後述しますが、この三ヶ月はマップの作成とシステム系の作成を行っていました。まぁ、見た目はあまり変わっていませんが、中身は多少変わっていると思います。未だに機能テスト段階ですが弄って頂けたら幸いです٩( ᐛ )و


↓↓ダウンロードはコチラから↓↓


きょだいむすめしみゅれーたー/Giantess Simulator(ver2.0.1)

GTS20201212.zip (206.98MB)

ダウンロード

ファイルを解凍後、中にある「Contoroller&Camera_test.exe」が起動アプリになります。注意としては名前が悪かったせいか高頻度でウイルス対策ソフトに引っかかるということですねw。(卑しいソフトかもしれませんが、怪しいソフトではないつもりです。)もちろん、数秒後には問題なしという報告が来ると思うのでご安心を。

なお、使用するキャラクターモデルによっては足音や落下検知など上手く機能しない場合がありますがご了承ください。


また今回は一応VRMモデルを持っていない人向けにモデルを一体同梱しておきました(いないとは思うけど)。カスタム少女から変換したキャラクターです。ちなみに著作権フリー(商用OK、描写制限なし、二次配布可)です。



さて、ここからは簡単ではありますが今回の変更点について説明をしたいと思います。まずは「①プレイヤーコントローラーの変更」について。


前回はVRMインポーターの機能テストがメインでしたのでゲームでは市販のコントローラーをそのまま貼り付けただけのものを使用していましたが、今回からは自分が欲しかった機能(ゲーム中にプレイヤーのサイズ変更を可能にする)をつけるべく新たに作成したコントローラーを使っております。


この「ゲーム中にプレイヤーのサイズ変更をする方法」は大きく分けて二つあります。一つはプレイヤーのスケールを変更する方法(直接的)で、もう一つは周囲のオブジェクトを変更する方法(相対的)です。それぞれメリットデメリットがあります。要約するとこんな感じ。


直接的
・メリット:キャラクターサイズをゲーム中に自由に変更できる。
・デメリット:コントローラーの制御が面倒。

相対的
・メリット:物理挙動やコントローラーの設定が簡単にできる。特定サイズに特化したイメージ。
・デメリット:相対的にサイズ変更する分負荷が高く、キャラクターサイズの変更は基本できない。


…といった感じになりますね。


今までは相対的な方法で行っていました。理由は物理挙動を扱いやすかったためです。‥嘘、ホントはめんどくさかったから(笑)。まぁ、ただやはりゲームプレイ中にサイズ変更させるには現実的に前者を取る方法しかないので、選択はあってないようなもの。ただそうなると既存のコントローラーは全部使えなくなるので結局一から作成することにしたわけです。ポチポチキーボードを押しながら作って行きました。


もっともコントローラーの製作は凝ったものを作らない限りはそれほど難しくはありません。移動量の制御などはrootモーションがあるアニメーションを使用すればほぼスクリプトを書かずに実現できます。幸い使っているアニメーションにはrootモーションがあったのでそのまま流用できました。しかしrootモーションがあるジャンプのアニメーションはTPSコントローラーとの相性があまりよくありません。というのも、rootモーションで移動を処理されてしまうためにジャンプの高さからジャンプ中の移動、ジャンプ後の移動が全て決まっているので自由に設定できないのが理由です。ある程度は自由に飛んだりできる方が都合はいいでしょう。そんなわけでジャンプだけはVector値を弄って制御することにしました。まぁ王道ですね。従って重力もVector値を弄って制御しています。そのためY軸の移動は総じて多少不自然に感じるかもしれません。なかなか難しい。


…ところで、巨大娘作品ではたびたび議論(?)になる問題なのですが、スケールサイズと物理法則(重力)ってどう思いますか?「非現実なんだから何でもいいじゃん」とは思うのですが、ゲームを作っていると度々考えてしまいます。例えば、通常スケールのジャンプが50cmだとして、100倍スケールでジャンプすると難しい話は抜きにして単純計算で50mはジャンプすることになります。50cmの落下時間は0.3秒に対して50mの落下時間は3秒といったところでしょう。つまり動画でも述べましたが、「高く」飛べても「速く」は落ちない、ということです。巨大娘作品では経過時間ははっきりしませんが、高く飛んだら普通は降りてくるのに相当な時間がかかっているハズ。みんなが空を見上げてる時間は長そうですねw。というのはさておき、まぁゲームをやっていて思うのはどれだけでかくなろうともスケールサイズに比例した速度で落ちてくれた方がラクということは言えるでしょう(ただ今回のバージョンでは落下時間は現実寄りにしてあるため落下には時間がかかります)。このようにどこまで物理法則を取るのかは意外と難しい問題なのかもしれませんね。実は相対的方法をとっていたのはこういう物理制御の問題も理由としてありました。


とはいえ、落下速度の変更は計算すれば解決できる問題なので対処は可能です。物理制御関係で一番厄介なのはスケール変更後のボーンの問題だと思われます。Youtubeの動画でも述べましたが、VRMに付いているVRMSpringBoneのスクリプトは意図的に切るように設定しています。これは何かを揺らす機能で使われるものなのですが、スケールサイズを変更すると十中八九ボーンが暴れます。MMDとかでおそらく経験した人はいるでしょうが、スケールを大きくするとスカート部分が暴れ始めます。スクリプト内部の構造がわかっていないので正直お手上げです。まぁ揺らす機能を一から設計できればスケール変更後も機能するものができるかもしれませんが、言うまでもなく私には無理です(無念)。しかし、今回の目的はゲーム中にキャラクターサイズを変更することにあります。なので以前も書いたと思いますが、キャラ演出は多少オミットする方針になりますね。


演出、つまり「見せ方」は難しい問題です。実はよく考えてみればプレイヤーのサイズを変更していようがいまいが、ゲームプレイ中のカメラ映像には変化はありません(そうしてるからだけど)。だとすれば直接的方法をとっても、見てる側には相対的方法のように思えるならキャラ演出を凝る方がいいのでは?というジレンマに陥ってきそうですね( ・∇・)。まぁどちらにも一長一短はあるということでしょう。うん、絵を作ることって非常に難しいですね。


話が長くなってしまいましたが、次は「②カメラコントローラーの変更」についてです。もともとのキャラクターコントローラーはカメラコントローラーとセットで機能するものだったので変更せざるをえませんでした。まぁ大体のキャラクターコントローラーはこんな感じにカメラとセットになっている場合が多いですね。ということで、新規に作るならば機能が多い方がいいと思ったので今回はをUnityの「cinemachine camera」を使用することにしました。


cinemachine cameraはUnityで使えるカメラパッケージの一つで、簡単に説明すると面倒事を「丸投げ」できるカメラだと言えましょう(笑)。このcinemachine cameraにはカメラコライダー(カメラの壁めり込みを防ぐ機能)やシェイプ機能(演出機能)などが簡単に実装できる機能が揃っており、ここら辺のシステムを作る手間が省けます。ただ当然と言えばそうなのですが、普通のゲームは「プレイヤーのサイズを常時好きに変更させる」ことは想定されていないので、ここら辺の制御のみ自作する必要がありました。このcinemachine cameraで使用するバーチャルカメラはスケール変更しても対象との距離は変更できません。なので今回はバーチャルカメラの設定をオーバーライドする必要があります。そんなわけで、プレイヤーのサイズ変更時にはスクリプトからカメラとプレイヤーの距離を逐一変更することでサイズ変更に対応することにしました。しかし恐らくこれは重くなる要因になってしまうので少しでも処理が軽くなるよう現在も考察中です。


また他にも問題がないわけではありません。動画でも述べましたが現状cinemachine cameraの感度が上手く制御できていないのでプレイヤーの移動には癖があります。問題になっているのはカメラが向いている方向(プレイヤーのコンパス的な役割をしている)のLookAtPointに方向転換するとカメラも移動するワケですが、その時のカメラ移動時の方向をコントローラー側が拾ってしまうことが原因でしょう。なのでここを少し無効化できれば多少は改善すると思います。そんなわけでここも今後の課題ですね。カメラについては以上です。


「③アクションシステムの変更」について。今回はクイックアクション的なものを実装しました。前作ではコマンドが多すぎて自分もわからなくなることが多かったので、今回はマウスホイールと右クリックでアクション実行できるようにしております(キーボードからも直接入力はできます)。これならアクションを増やしてもラクにできそうです。また今後はキーボードだけではなくゲームコントローラーでもやりたいなと思っていますので改善していくかもしれません。こんな感じに快適にプレイできるようにしていきたいと思います。


「④建物が破壊可能」について。実は今回の更新に三ヶ月近くかかった理由の大半はコレになりますw。建物は全部で250種類ほどありました(まぁ使っているのは半分だけだろうけど)。自動化しろよって話ですが、結局確認作業は必要なのであまり変わらなかったりします。ちなみに1オブジェクトを作るのには早くても3分はかかりました。破壊可能なオブジェクトにするのに1オブジェクトあたり平均して5分は必要でした(メッシュ生成する時間)。休憩も入れれば1オブジェクトを作るのに合計10分かかるんじゃないですかね。後はお察しください٩( 'ω' )


ところで、完成したオブジェクトを見て感じたことはもう少しエフェクト(パーティクル)が欲しいなというところでした。「地球防衛軍」だったり「進撃の巨人(ゲーム)」を参考にするとやはり煙が重要ですね(いや一番はアニメーションで建物をキレイに崩壊させることなんだが…)。実は煙関係の良さそうなアセットがあったので予算と相談しながら買う時期を調整しています。


こんなところですかね。以上が今回のバージョンの主要な変更点になります。


さて、最後に今後の予定を少し書いておきましょう。実現するかは別として取り入れたい機能が二つほどあります。一つは「リプレイ(ゴースト)機能」です。自分が遊んだ軌跡を自由な視点から観察するにはこれがもってこいだと思います(上から眺めたり、下から眺めたりと)。ただどこの参考サイトでも上がっていますがゴーストを作ると位置補正が難しくなります。とりわけキャラクターのサイズを変更しなければならないこのゲームでやろうとするのはかなり致命的のように思えます(苦笑)。だって位置補正している時にビル壊しちゃいそうだしw。まぁ、できる限り頑張ります。


もう一つは「複数キャラを入れられるようにする」ことです。やるのは簡単だと思います…が、問題は「どう動かすの?」ってことになるでしょう。てっとりばやく「Navmesh」を入れてやるとしてもその先に何ができるのかがイメージが湧きません(DQ的に付いてくだけになりそうw)。つまり、こっちは何をしようか先が見えない状況ですね。


そんなわけで、今回書いた改善点を含めれば完成は来年以降でしょう。毎度のことですが気長にお待ちください。またバグ等がありましたらコメント欄に報告してくれると助かります。


それでは今回(今年?)はこの辺で。


PS

ゲーム内にはちょっとした隠し要素を入れてみました。包帯の娘の近くで右クリックをすると…?是非探してみてくださいw。

ヒント


(制服ちゃん。どこかの公園に潜んでいる。包帯ちゃんを見つけていくと…?)

(包帯ちゃん1。これはすぐ見つかるでしょう。)

(包帯2。少し難しい。橋付近のビルの中庭。)

(包帯3。包帯2の近く。2はこれを目印にしたほうがいい。)

(包帯4。ノーヒントだけど簡単だと思います。)

(包帯5。橋の反対側にいます。方向はビルの日光陰がヒント。)

(包帯6。ビル街の端。外周を走れば気づくかも。)

(包帯7。ちょっと難しい。ビルの隙間に潜んでます。)

(包帯8。無理ゲーw。どこかのビルの中に潜んでいます。見つけた人は暇人認定。)

(本体9。太陽の位置で特定しましょう。__って、どこかのスパイ機関かよ…。)

(包帯10。これは楽勝でしょうね。)

以上になります。なおイースターエッグなし版も一応あります。少しでも動作を軽くしたい場合は下の奴をどうぞ。

GTS20201206.zip (174.38MB)

ダウンロード

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

記事のタグから探す

月別アーカイブ

記事を検索