もんしょの巣穴blog

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

[UE4] Characterアクター

この記事ではUE4に実装されているCharacterアクターについて調べたこと、わかったことを随時書いていこうと思います。
かなりの数の機能、パラメータが実装されており、すべてを網羅するには少々時間がかかりそうなので。
追記した場合はTwitterでつぶやきますので、気になる人はそちらをチェックしていただければと。

まず、Characterアクターについて簡単に解説します。
このアクターは主に人間(もしくはそれに近い生物、ロボットなど)を取り扱うために実装された基本的なアクターです。
基本的な、と言ってもかなりの機能が実装されており、簡単なアクションゲームを作る上ではほぼ困らない程度の実装が存在します。
ただし、コントローラによる操作やアニメーションの設定はユーザが行う必要があります。
通常はこのアクターを継承したアクターをC++、もしくはBPで作成し、そちらで操作関係を実装したり、アニメーションについてはアニメーションBPを利用したりします。

基本的なコンポーネントは4つです。

CharacterMovementキャラクタの移動など、動きに関する処理を行うコンポーネントです
Characterアクターと密接に結びついているため、他のアクターで利用することはできないようです
CapsuleComponentカプセル状のコリジョン判定を持たせるコンポーネントです
ArrowComponent主にエディタ上で前方方向をわかりやすくするためのコンポーネントのようです
MeshSkeletalMeshです
StaticMeshを使いたい場合は継承先で追加しなければなりません

Characterアクターを理解するうえで重要なコンポーネントはやはりCharacterMovementです。
C++のクラス名はUCharacterMovementComponentで、OwnerとしてACharacter、すなわちCharacterアクターを持つため、Characterアクター、もしくはその継承先アクター以外で使用することはほぼありえません。

また、Characterアクターの継承元であるPawnアクターも重要です。
FPSテンプレートなどでCharacterアクターを継承したMyCharacterが存在しますが、ここで移動や回転を行うために使用しているAddMovementInputやAddControllerYawInputはPawnアクターのメンバです。

続きからは各種機能と関連パラメータについて順次書いていきます。

[[UE4] Characterアクター]の続きを読む
スポンサーサイト
  1. 2014/10/26(日) 12:30:09|
  2. UE4
  3. | トラックバック:0
  4. | コメント:0

[UE4] フェードイン・アウトを実装したHUDの作成

今回はフェードイン・アウトを実装したHUDをプラグインとして作成してみた話です。

UE4にはMatineeを用いたフェードイン・アウト機能がありますが(こちらの記事参照)、これは黒フェードのみです。
ゲームを作る上では黒以外のフェードも必要になることがあります。
The Loomでは強い光を表現するために白フェードを使っていますし、ホラーゲームなどであれば血を表現した赤フェードも使われるでしょう。
これらを実装する方法はいくつかありますが、今回はSlateを用いてみました。

さて、UE4はソースコードが公開されているのでエンジン側のコードを修正することでこのような問題に対応することも可能です。
しかしながら、現状ではあまりお勧めできません。
UE4の更新速度は非常に速く、サブスクリプションを始めてから8か月程度で大規模なバージョンアップを5回も行っています。
もしもエンジン側のコードを修正してしまうとこれらのバージョンアップの恩恵を受けられないか、恩恵を受けようと思うと大規模なマージ作業が発生します。
UE4のような大きなゲームエンジンをマージしようとするとかなりのコストがかかります。
しかもマージに成功したとしても潜在的な不具合が残る可能性を無視できません。
既にアップデートが一段落しているのであればバージョンアップを無視するのもありですが、現状では無視できる更新頻度ではないです。

しかしUE4ではプラグインによって機能を追加することが可能です。
機能追加はあくまでも限定的ではありますが、それでもかなり広い範囲で追加できます。
エディタに対する機能追加では自分たちのタイトルを開発するうえで特殊なUIが必要でも対応できますし、ActorやObjectを追加すればランタイムで使える機能も追加できます。
今回追加しているのはHUDアクターである"AHUD"を継承した"AFaderHUD"です。
フェードイン・アウトは色とα値を指定することができ、また、他のUIの奥と手前の2カ所でフェードをかけられるようにしています。

ただし制限もあります。
HUDアクターはOpenLevelによってレベルが遷移すると一旦削除されます。
FaderHUDは削除されるとフェードに使用しているSlateが削除されます。
これはつまり、レベル遷移によってフェードアウトがキャンセルされるということです。
フェードアウトして画面が真っ暗になっている状態でOpenLevelによるレベル遷移が行われると、遷移先のレベルではフェードアウトがキャンセルされて画面が表示されてしまいます。
回避するには遷移先のレベルのBeginPlayイベントでフェードイン処理を書く必要があります。

もう1つの制限は、フェードレイヤーは2レイヤーありますが、これらはSlateのZOrderが0と255で設定しています。
奥側(ZOrder 0)にはかからないが手前側(ZOrder 255)にはかかるようなUIはZOrderを1~254で指定してください。
また、ReceiveDrawHUDイベントでテキストやテクスチャを描画すると、これはZOrder 0のSlateよりも奥に描画されます。
どうやらこれらの描画はSlateではなくCanvasで行われているようで、Slate描画よりも前に行われてしまいます。
ですので、どのレイヤーのフェードを利用してもフェードの影響を受けると考えてください。

ではプラグインを追加していきましょう。
プラグインの追加方法はヒストリアさんのブログが詳しいのでそちらを参照してください。

[UE4] プラグインによるエディタ拡張(1) 空のプラグインを追加する

こちらの記事では元になるプラグインをUE4ソースコードの"BlankPlugin"としていますが、今回はアクターを追加するので同じフォルダにある"UObjectPlugin"をコピーしましょう。
なお、プラグインの名前は"FaderHUDPlugin"としています。

ue210.jpg

続きからで実際のコードを見ていきましょう。

[[UE4] フェードイン・アウトを実装したHUDの作成]の続きを読む
  1. 2014/10/19(日) 22:49:51|
  2. UE4
  3. | トラックバック:0
  4. | コメント:0

[UE4] The Loomの話 その3(完結)

The Loomの話はこれで最後です。
今回はMatineeを使っている部分の解説と小ネタ集です。

まずオープニングは小ネタを2つ。
1つ目はDestructibleMeshです。
The Loomでは一部のオブジェクトをDestructibleMeshに変換して破壊を行っています。最終レベルの机や本棚、皿などがそれですね。
しかし、DestructibleMeshに問題があるため、女神像だけは使用していません。
この問題というのはデカールが有効にならないという点です。

DestructibleMeshは物理挙動が前提となっているためか、動かすことを前提としていないデカールが貼りつけられなくても仕方ないかとは思います。
今回のゲームでは破壊された女神像を動かす必要がないのでStaticMeshとして配置することにしました。
もちろんDestructibleMeshはStaticMeshではないので、そのままではStaticMeshとして配置できません。
そこで、一旦Exportして各部位を切り出して別のモデルに保存、これを再度ImportしてStaticMeshとして配置しました。

まずは分割数5のDestructibleMeshを女神像のメッシュから作成、ランダムシードはいい感じに分割してくれるものを選択しました。
これをFBXでExportすると女神像の全体メッシュ+各分割メッシュが1つになったメッシュと分割メッシュを動かすためのボーンになります。
ただ、Mayaならどういう感じで出力されてるかわかりやすかったのですが、Blenderではさっぱりわかりませんでした。
Blenderはやっぱりあれだなぁ…

小ネタその2はLevel06から配置されている赤い光源です。
当然動的ライトですが、動作自体は鎖の物理シミュレーションを用いています。
本来、この手のループ再生させるべきものはループモーションを作成させるべきなのですが、モーション作成する能力が自分にないので物理シミュレーションで動かすことにしました。
しかしまあ、当然と言えば当然なのですが、物理シミュレーションで動かすと摩擦の問題もありますのですぐに止まってしまいます。

最初は普通に振り子の方程式で動かしてみたのですが、鎖がしならずにそれっぽい動きになりませんでした。
ですので、物理シミュレーションを用い、定期的にImpulseを与えてやる形で実装しました。
何度も言いますが、本来こんな実装はしません。普通に作成する場合は素直にモーションを作成しましょう。

実装のBPグラフは以下の通りです。

ue202.jpg

ユーザが設定するのは揺れる力と方向で、力を与えるべきソケットがアクターの基準位置より揺れる方向に存在した場合に1秒間だけその方向にImpulseを与えます。
Impulseを与え終えたら揺れる方向を逆方向に向けておけば物理的に動いた後で揺れる方向に少しでも傾いたところで再び1秒間のImpulseが与えられます。
イマイチわかりにくBPグラフかもしれませんが、やっていることは非常に単純です。

与える力はいろいろ調整して行っていますが、調整パラメータは変数としてBPに設定しています。
物理的な動作はレベルエディット中に確認できませんが、ゲームを実行して確認するのは面倒です。
そこで適当なレベルに配置し、Simulateを行って確認します。
Simulateはこのような、ちょっとした動作だけを確認したい場合にPlayより簡単に行えるのが便利ですね。

というわけで小ネタはこれで終了。
続きからはMatineeの話です。

[[UE4] The Loomの話 その3(完結)]の続きを読む
  1. 2014/10/12(日) 16:50:04|
  2. UE4
  3. | トラックバック:0
  4. | コメント:0

[UE4] The Loomの話 その2

第2回目の解説。
まず最初にレベル作成から。

今回のゲームはループもので1つの部屋を使いまわす形になります。
なので部屋を1つ作成すればOK。
いつも通りにBrushで部屋の構造を作成、そこからメッシュを作成しました。
部屋の構成はこんな感じです。

ue196.jpg

天井は非表示にしています。
右奥の部屋がエンディング部屋ですね。エンディング部屋はデフォルトでは壁が非表示ですが、表示しておくと扉から部屋に入った時に壁にぶつかってしまうためです。
ちなみに、この部屋はカットシーンでしか利用されないため、コリジョンはありません。
また、点光源がいくつか置いてありますが、これはエディタで作業中に暗いと困るから、という理由で置いてあります。

Persistent Levelは常に読み込まれているレベルなので、どのレベルでも共通して利用されるものはここで配置しています。
具体的には壁、床、天井、4枚の扉、通路にあるシーリングライトとスポットライトです。
実は奥の通路はゲームクリア時以外は使用されていないため、扉の色も違っていますしメッセージも置いてあります。

予定では奥の扉を開けると自動的に扉の外に出て、カットシーン終了時に最初の通路に飛ばしてループさせようとしました。
が、通路の寸法を微妙に間違えてしまったっぽくてワープさせると部屋が変わってるのがバレバレになってしまいました。
なので諦めてホワイトフェードを入れるようにしました。ホワイトフェードはポストプロセスで作成しています。

Persistent Levelに置かれていない配置オブジェクトはすべてStream Levelとして配置しています。
GameLevelXX.umapという名前で作成し、先に進むと自動的に次のレベルを読み込むようにBPで設定しています。

ue197.jpg

ゲーム内容的にあるゲームレベルは前回のゲームレベルから少しずつ変化させる形になります。
なので基本的には前回レベルの.umapをエクスプローラでコピー、ファイル名変更、既存のレベルを読み込みで追加、という流れで作成しました。
ただしこれだけだとどのオブジェクトがどのレベルに属しているのかわかりにくくなります。なんといってもアクター名が同一になってしまっていますから。

そこでGameLevel00.umapに登録されているアクターをすべてLevel00というフォルダに格納します。
次にGameLevel00.umapをコピーしたGameLevel01.umapを作成し、読み込みます。
この段階でLevel00フォルダに2重にアクターが格納されている状態になりますが、レベルウィンドウでGameLevel00を非表示にするとアウトライナーでもGameLevel00に配置されているアクターが非表示になります。
この状態でLevel00フォルダ内のすべての表示アクターを選択、Level01フォルダに格納します。
Level01フォルダはLevel00フォルダ直下になってしまうので、[Move To Root]でルートに置きます。
これからLevel01を編集し、同じ要領で02,03と作っていきます。

他に試したことですが、ライトマップの焼き付けを試してみました。
ライトマップを焼き付けるためには専用のUVが必要になります。通常はUV Channel 1を利用することになるでしょう。
普通にメッシュを作成するとUVは0番のみになりますが、1番をUniqueUVとして生成する機能がUE4には存在します。
StaticMeshウィンドウを開き、メニューから[Window]->[Generate Unique UVs]を選択するとUV生成ウィンドウが表示されます。
生成するチャンネルをUV1にして適当なパラメータで[Apply]ボタンを押すと生成されます。
UV Channel 1を表示すれば以下のようにUVを確認できます。

ue201.jpg

微妙に斜めってるのがわかると思いますが、これがどうもライトマップには良くないようで、かなり高い解像度でライトマップを生成しても微妙に色々な場所が汚くなってしまいました。
通路だけでもライトマップを適用したかったんですが、結局あきらめました。
自動生成後に手で直すなりした方がいいかもしれませんね。

というわけでレベル作成はここまで。
続きはメッセージ表示とその関係の話です。

[[UE4] The Loomの話 その2]の続きを読む
  1. 2014/10/06(月) 09:14:23|
  2. UE4
  3. | トラックバック:0
  4. | コメント:0

[UE4] The Loomの話 その1

第1回ぷちコン作品は使用したアセットがスターターコンテンツだけだったのでプロジェクトごと公開しました。
今回作成した作品”The Loom”はEpicが提供している無料のアセットを利用しています。
ContentsExampleのアセットは公開しても問題ないのですが、その他のアセットは.uasset形式での配布が禁止されています。
そのため、今作についてはプロジェクトの公開ができません。
プレイできる形では動画の説明にも書きましたが、以下のリンクからDLできます。

http://1drv.ms/1EYLzjL
PetiCon02.zip

とは言え私もUE4関連情報を発信している人間の端くれなので、折角なので赤の扉を…げふんげふん、開発時に行ったいろいろを解説したいと思います。

まずはオープニングとしてソースコントロールの話。
ソースコントロールというのはいわゆるバージョン管理です。
UE4ではデフォルトプラグインとしてSubversionとPerforceによるソースコントロールが可能になっています。

ソースコントロールは何らかの原因でアセットなどが壊れてしまったり、不具合調査などで過去のバージョンが必要になったりした際に非常に有効です。
UE4は、最近は発生していないのですが、初期の段階では不正なBPを作成した場合などにエディタを立ち上げた瞬間クラッシュして困る場面がいくらかありました。
現在発生していないとはいえ今後も発生しないとは限りませんし、そのために複雑なBPを1から作成し直さなければならないということになると心が折れます。
そういう場面に遭遇してしまった場合、過去の、まだ正常に動作していたころのバージョンに戻せればキズはいくらか小さくなります。
で、今回はそのような問題が発生しても大丈夫なようにソースコントロールを実施しました。
ちなみに、そのような問題は作成中に発生しなかったということだけお伝えしておきます。

さて、ソースコントロールの方法についてなのですが、alweiさんがすでにまとめておいてくれています。

UE4 ソースコントロールを使ってアセット管理をする

ソースコントロールの使用方法としてはこちらをご覧になっていただくのがわかりやすいと思いますが、いくらか補足説明をしておこうと思います。
特にSubversionに慣れている方だとはまりそうな部分もありますので。

Subversionではプログラムソースコードなどを編集する場合、編集自体はいつでもローカルで可能になります。
しかし、これを管理サーバにコミット(つまりアップロード)する際に、他の人が編集していないかどうかをチェックします。
誰かが編集している場合、編集が衝突した状態になりマージという作業が必要になります。
両者の編集をうまくとりなして正常に動作させるのはユーザの責任なわけです。

UE4ではこの辺の動作がSubversionとは異なります。
最も近いバージョン管理ツールはMSのVisual Source Safeでしょう。
アセットを編集したい人はそのアセットを[Check Out]します。
すると、このアセットはチェックアウトしたユーザにロックされ、他の人はチェックアウトできなくなります。
Perforceでもチェックアウト作業は必須ですが、チェックアウト時の動作はロックしないのがデフォルト動作だったはずです(ロックすることもできるけど)。
VSSとの違いは、VSSでは管理されているファイルは書き込み禁止になっていて、チェックアウトせずに編集はできません。
しかし、UE4では編集自体はチェックアウトしなくても可能ですが、保存する際にチェックアウトしていないとチェックアウトするように要求されます。

ue186.jpg

チェックアウトする場合は[Check Out Selected]で選択したアセットをチェックアウトすることになります。
この際に誰かがチェックアウトしている場合はどうなるか?
当然、チェックアウトはできません。チェックアウトしている人がチェックインするまで待ちましょう。
チェックアウトされていないが、誰かが編集した後だった場合は?
実はこの時の動作が結構問題になります。

この状態でアセットを右クリック[Check Out]を選択するとチェックアウトに失敗しました的なメッセージが表示されます。

ue187.jpg

このメッセージが出た場合は衝突しているということになり、アセットに"!"マークが表示されます。

ue188.jpg

この場合の動作ですが、どうも怪しい感じです。
[Sync]を選択しても管理サーバの情報を持ってきてアセットを更新してくれるような感じではないですし、もしも編集してしまっている場合は[Sync]すらまともに動作しません。
自分が正常に動作させることに成功した事例では、[Sync]->[Check Out]->[Revert]で、これでサーバの情報、つまり最終コミットの状態に戻せました。
ただし、編集してしまっている場合は[Revert]すらまともに動作しませんでした。
現段階では、編集前に必ずチェックアウト!を徹底しないとまずそうです。
Perforceなら問題ないのかは不明ですが、編集前にチェックアウトをしなければならないのがPerforceの仕様なので、こちらは大丈夫かもしれませんね。
テキストレベルでマージすることもできるはずなので、これを手動でやれば問題ないかも。

また、.umapもソースコントロール可能ですが、チェックアウトするメニューが存在していないようです。
無理やりチェックアウトする方法としては、[Levels]ウィンドウを開き、編集していない状態で保存(フロッピーのアイコン)を押して[Check Out Selected]ボタンを押します。
これでチェックアウトができますし、チェックインする場合は[File]->[Submit to Source Control...]でチェックアウト済みのすべてのアセットをチェックインできるようになります。
これを利用して目当てのレベルだけチェックインすることが可能ですが、衝突した場合にどうなるかは考えたくないですね…[Revert]もないので元に戻せないですし。
最悪はソースコントロールを解除したりエディタを閉じたりしてエクスプローラ上で作業することですね。

正直、一人で開発するなら問題ないと思うのですが、複数人で開発する場合は現在の動作はちょっと困ると思います。
これが自分の使い方の問題なだけならいいんですが、どうなんでしょうね?

あと、UE4.4ではソースコントロールを有効にしてエディタを閉じるとクラッシュします。
エディタを閉じる際なので実害はクラッシュレポートのウインドウが出るくらいなものですが、UE4.5では修正されているようです。
また、日本語でコメントを書く場合、日本語入力を開始→変換を確定せずにすべての入力を削除とすると入力カーソルが行頭に移動してしまうようです。
コメントはできれば一気に書いちゃった方がいいんじゃないでしょうか。

と、長くなってしまいましたが、続きからはゲーム内容についての話を進めていきます。

[[UE4] The Loomの話 その1]の続きを読む
  1. 2014/10/05(日) 11:59:09|
  2. UE4
  3. | トラックバック:0
  4. | コメント:0

プロフィール

Author:monsho
ゲームプログラマ?

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

カテゴリー

ブロとも申請フォーム

この人とブロともになる

ブログ内検索

RSSフィード

リンク

このブログをリンクに追加する

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。