第1回ぷちコン作品は使用したアセットがスターターコンテンツだけだったのでプロジェクトごと公開しました。
今回作成した作品”The Loom”はEpicが提供している無料のアセットを利用しています。
ContentsExampleのアセットは公開しても問題ないのですが、その他のアセットは.uasset形式での配布が禁止されています。
そのため、今作についてはプロジェクトの公開ができません。
プレイできる形では動画の説明にも書きましたが、以下のリンクからDLできます。
PetiCon02.zip
とは言え私もUE4関連情報を発信している人間の端くれなので、折角なので赤の扉を…げふんげふん、開発時に行ったいろいろを解説したいと思います。
まずはオープニングとしてソースコントロールの話。
ソースコントロールというのはいわゆるバージョン管理です。
UE4ではデフォルトプラグインとしてSubversionとPerforceによるソースコントロールが可能になっています。
ソースコントロールは何らかの原因でアセットなどが壊れてしまったり、不具合調査などで過去のバージョンが必要になったりした際に非常に有効です。
UE4は、最近は発生していないのですが、初期の段階では不正なBPを作成した場合などにエディタを立ち上げた瞬間クラッシュして困る場面がいくらかありました。
現在発生していないとはいえ今後も発生しないとは限りませんし、そのために複雑なBPを1から作成し直さなければならないということになると心が折れます。
そういう場面に遭遇してしまった場合、過去の、まだ正常に動作していたころのバージョンに戻せればキズはいくらか小さくなります。
で、今回はそのような問題が発生しても大丈夫なようにソースコントロールを実施しました。
ちなみに、そのような問題は作成中に発生しなかったということだけお伝えしておきます。
さて、ソースコントロールの方法についてなのですが、alweiさんがすでにまとめておいてくれています。
ソースコントロールの使用方法としてはこちらをご覧になっていただくのがわかりやすいと思いますが、いくらか補足説明をしておこうと思います。
特にSubversionに慣れている方だとはまりそうな部分もありますので。
Subversionではプログラムソースコードなどを編集する場合、編集自体はいつでもローカルで可能になります。
しかし、これを管理サーバにコミット(つまりアップロード)する際に、他の人が編集していないかどうかをチェックします。
誰かが編集している場合、編集が衝突した状態になりマージという作業が必要になります。
両者の編集をうまくとりなして正常に動作させるのはユーザの責任なわけです。
UE4ではこの辺の動作がSubversionとは異なります。
最も近いバージョン管理ツールはMSのVisual Source Safeでしょう。
アセットを編集したい人はそのアセットを[Check Out]します。
すると、このアセットはチェックアウトしたユーザにロックされ、他の人はチェックアウトできなくなります。
Perforceでもチェックアウト作業は必須ですが、チェックアウト時の動作はロックしないのがデフォルト動作だったはずです(ロックすることもできるけど)。
VSSとの違いは、VSSでは管理されているファイルは書き込み禁止になっていて、チェックアウトせずに編集はできません。
しかし、UE4では編集自体はチェックアウトしなくても可能ですが、保存する際にチェックアウトしていないとチェックアウトするように要求されます。
チェックアウトする場合は[Check Out Selected]で選択したアセットをチェックアウトすることになります。
この際に誰かがチェックアウトしている場合はどうなるか?
当然、チェックアウトはできません。チェックアウトしている人がチェックインするまで待ちましょう。
チェックアウトされていないが、誰かが編集した後だった場合は?
実はこの時の動作が結構問題になります。
この状態でアセットを右クリック[Check Out]を選択するとチェックアウトに失敗しました的なメッセージが表示されます。
このメッセージが出た場合は衝突しているということになり、アセットに"!"マークが表示されます。
この場合の動作ですが、どうも怪しい感じです。
[Sync]を選択しても管理サーバの情報を持ってきてアセットを更新してくれるような感じではないですし、もしも編集してしまっている場合は[Sync]すらまともに動作しません。
自分が正常に動作させることに成功した事例では、[Sync]->[Check Out]->[Revert]で、これでサーバの情報、つまり最終コミットの状態に戻せました。
ただし、編集してしまっている場合は[Revert]すらまともに動作しませんでした。
現段階では、編集前に必ずチェックアウト!を徹底しないとまずそうです。
Perforceなら問題ないのかは不明ですが、編集前にチェックアウトをしなければならないのがPerforceの仕様なので、こちらは大丈夫かもしれませんね。
テキストレベルでマージすることもできるはずなので、これを手動でやれば問題ないかも。
また、.umapもソースコントロール可能ですが、チェックアウトするメニューが存在していないようです。
無理やりチェックアウトする方法としては、[Levels]ウィンドウを開き、編集していない状態で保存(フロッピーのアイコン)を押して[Check Out Selected]ボタンを押します。
これでチェックアウトができますし、チェックインする場合は[File]->[Submit to Source Control...]でチェックアウト済みのすべてのアセットをチェックインできるようになります。
これを利用して目当てのレベルだけチェックインすることが可能ですが、衝突した場合にどうなるかは考えたくないですね…[Revert]もないので元に戻せないですし。
最悪はソースコントロールを解除したりエディタを閉じたりしてエクスプローラ上で作業することですね。
正直、一人で開発するなら問題ないと思うのですが、複数人で開発する場合は現在の動作はちょっと困ると思います。
これが自分の使い方の問題なだけならいいんですが、どうなんでしょうね?
あと、UE4.4ではソースコントロールを有効にしてエディタを閉じるとクラッシュします。
エディタを閉じる際なので実害はクラッシュレポートのウインドウが出るくらいなものですが、UE4.5では修正されているようです。
また、日本語でコメントを書く場合、日本語入力を開始→変換を確定せずにすべての入力を削除とすると入力カーソルが行頭に移動してしまうようです。
コメントはできれば一気に書いちゃった方がいいんじゃないでしょうか。
と、長くなってしまいましたが、続きからはゲーム内容についての話を進めていきます。
まず解説するのはやはりMyCharacterでしょう。
ぷちコンのテーマが発表された段階でどういうゲーム内容にしようか考えたのですが、ちょうど某ゲームが会社で話題になっており、これだ!と安易に飛びついたわけです。
某ゲームが何かは言わなくてもわかるな?静岡体験版
ファーストパーソン視点のゲームを作るので、当然FPSテンプレートを利用しました。
FPSテンプレートのPlayerPawnである"MyCharacter"BPは基本的な動作を網羅しています。
しかし、ゲーム内容からジャンプや銃を撃つといったアクションは必要ないのでさっくり削除します。
銃を撃つというアクションはありませんが、その代わりに注視するというアクションが存在しています。
そのため、銃を撃つFireアクションで注視動作を入れました。
注視動作はFPSのAim動作と同じで、カメラの画角を変更しています。
上はFireアクション時の動作で、左クリック中はIsAimをONに、そうでない場合はOFFにします。
画角の変更は一瞬では行わないので、毎フレーム処理のTickイベントで"First Person Camera"コンポーネントのFOVを変更しています。
注視を解除した場合の方がFOVの変化量が多めにしてるのは遊んでみてそっちの方がしっくりきたからですね。
上の画像でIsInteractというフラグをチェックしていますが、これはインタラクト中を示すフラグです。
プレイヤーがゲーム中のオブジェクトにインタラクトして通常操作ができない状態をこのフラグで規定しています。
The Loomではゲーム開始時の目パチの際には移動ができないためこのフラグを立てていますし、他にもドアを開けて部屋に入る一連の動作中、およびエンディング時にこのフラグを立てています。
当然、移動や視点移動もこのフラグをチェックしています。
次にフラッシュライトですが、これは普通にカメラの横の方にコンポーネントとしてスポットライトを置いているだけです。
ただ、最初は本当にそのまま置いていただけだったのですが、この際に問題が出てきました。
それはフラッシュライトっぽくなかったという点です。
カメラの近くに配置してしまうと真っ暗な部屋と明るい部屋を画面に貼りつけたマスクテクスチャでくりぬいているようにしか見えなかったんですね。
この理由は、フラッシュライトによって伸びる影がカメラからわかりやすく見えないし、壁や床に斜めに当てたときの楕円になる光がカメラの画角との関係からかほとんど楕円に見えなかったからでしょう。
フラッシュライトの位置を横にしすぎると注視時に光が当てられた部分と注視している部分がずれるという問題がありましたし、少し回転を加えてもやはり同じ問題は発生しました。
そこで、毎フレーム、カメラ前方方向に衝突判定をとり、注視点を決定し、そこにフラッシュライトを向けるようにしました。
当然、一気にそこに向けるわけではなく、滑らかにそこに向けるようにしました。
とは言え遅すぎても不自然なので通常の人間の動作よりも少しゆっくり目程度を意識して調整しました。
通常の人間は手首を軽く動かす程度なのでかなり早く回転させることができますが、自動で調節されてしまうためかフレームスキップしているように見えてしまったのでゆっくり目で調整したわけです。
この処理も数フレームかけて行われる処理のため、Tickイベントで処理をしています。
衝突判定をとる直線は長さ500に制限していますが、この距離は注視時にオブジェクトにインタラクトできる距離とも一致させています。
RotateFlashLightマクロはこちらで作成したものです。
"RInterpTo"という命令を利用していますが、これはUE4にデフォルトで存在しています。
現在の回転を目標となる回転に毎秒決まった角度(このマクロでは5度)回転させるというものです。
引数は現在の回転、目標回転、DeltaTime、角速度となります。
似たような命令で浮動小数点を補間する"FInterpTo"、座標を補間する"VInterpTo"、トランスフォーム(位置と回転)を補間する"TInterpTo"が存在します。
プレイヤーをガン見し続けるNPCとか、プレイヤーの後を追ってくるオプションとかを作成する際には有効な命令です。
若干足りない部分もあるな、と思っているんですが、それについては後ほど。
この処理によってフラッシュライトの位置を割と大胆に変更することができるようになり、それによって影の伸び方などが見て取れるようになりました。
最終的なフラッシュライトの位置は以下のようになっています。
手で持っているというにはちょっと高い感じはしますが、カメラの横よりはそれっぽい位置になりました。
実はあまり実感しにくいのですが、注視した際にDOFがかかるように設定しています。
残念ながら周囲が暗くてその効果がほとんど出ていません。正直言ってミスったと思っています。
この方法はUEのWikiにもあるのですが、こちらで作成したBPも掲載しておきます。
注視アクションをすると画角の変更に合わせてDOFスケールが大きくなります。
焦点距離はフラッシュライトが向いている位置までの距離を入れています。
問題点としてはポストプロセスボリュームをどこから持ってくるかですが、これはゲーム開始時にMyCharacterに設定するようにしました。
削除されることはないのでこれで問題ないでしょう。削除されるようなら検索するようにした方がいいかと。
次にPostProcessSettings構造体の巨大なメンバ数ですが、4.3か4.4から構造体の一部のメンバだけ変更する"Set Members"命令が追加されていますのでそちらを利用しています。
これがない状態だと構造体をBreakして、再びMakeして、変更しないパラメータはピンをそのまま繋ぐということをしなければならないところでした。
Set Membersのおかげでまともにはなったのですが、残念なのはSet Membersではデフォルトですべてのピンが表示されてしまっている点です。
PostProcessSettingsのSet Membersはピンの数が201個あります。
実際に使用しているのは2個だけなので、199個のピンは無効にしなければならないのですが、現状ではこれは手作業で1つ1つOFFにしなければならないようです。
一気に全部OFFにする方法があるようでしたら誰か教えてください。
というか、デフォルトは全部OFFでもいいような気がするんですよね…
MyCharacter最後の解説は足音です。
本来足音のSEを鳴らすなどはモーションに合わせて行う方が楽なのですが(UE4にはモーションの特定フレームでSEを鳴らす機能が存在する)、今回はモーションを使っていないのでそういうわけにはいきません。
なのでTickイベントで連続移動時間をチェックし、一定時間以上連続で移動したらSEを鳴らすようにしました。
ひどい実装だな、とは思いますが、モーション作るよりは安上がりなのでこれでいいです。
というわけで、今回はThe LoomのMyCharacterの解説を行いました。
このBPは他にもいくつかの機能を作成しているのですが、これについては他の部分と合わせて解説した方がわかりやすいのでその際に解説します。
2回くらいあれば全部解説できるかな、とか思ってましたが、さすがにちょっと厳しそうです。
多分、3,4回くらいになるとは思いますが、興味がある方はお付き合いください。