こんちわ。
前エントリで触れたとおり、作品の技術解説をします。
当然ですが、私はUE4をお世辞にも使いこなしているとは言えず、いわゆるUE4極本をひととおりやって、あとはネットでちょっと検索して継ぎ足したくらいの知識しかありません。（そもそもぷちコンってそういう人のためのイベントですし）
とはいえ、案外自分で常識だと思っていることを人が知らなかったりするものともよく言うので、習熟度が低くともある程度は発信していこうと思います。

（冒頭画像：ぷちコン応募時点の文字通りスパゲッティなブループリント）

レイキャスト

このゲームを作れると踏んだ最大の理由がレイキャスト系ノードの存在です。線分判定を行うやつですね。
こういう衝突処理は自前実装するとかなり面倒なんですが、ゲームエンジンには基本機能として入っているので実に敷居が低くて良いです。

具体的にはLineTraceForObjectsでWorldDynamicに対して判定を行っています。このノードにはTrace Complexというオプションがあり、これをオンにするとポリゴンに対して直接判定するようになるみたいです。（もちろん多少重いのでしょうが、この規模のゲームですからね）

モデルの形状と動作がそのままルールとして成り立つため、判定先との独自処理が必要なく、あとはレベルに動的メッシュを配置すれば勝手に障害物として機能します。これでスペースバーを押したときにクリアとミスに分岐すれば、この時点でもうゲームの骨子ができあがりです。ゲームルールの実装が簡単だったことが早く作れた最大の理由なのではないかと思います。

プレイヤーには自身の動作しか記述せず、判定後にイベントを呼び出すのみで、他の処理は全てパーシスタントレベルに任せてあります。こういう風に記述しておくと疎結合にできて便利ですね。
（本来はレベル移動時のために共通部の記述をGameMode等に移すべきですが、このゲームはレベルが1つで済んでいるため、ほぼ全ての記述がレベルブループリントに残りました）

レベルエディタを独自レベルエディタとして使う

このゲームはフロア間移動がシームレスなゲームで、数珠つなぎのステージが延々と存在します。これが全て画面外に配置されていると非常に無駄なわけです。しかもエンドレスゲームなので30面を越えたら1面が2度使用されます。
そこで、レベル上の配置はあくまでデータ層として扱い、起動時に解釈して配列に落とし込むようにしてあります。

上から見るとこんな感じです。4000x1100のグリッドを基準に配置し、障害物の基底クラスに合致するアクターを起動時に全走査してステージごとのローカル座標に変換します。走査したアクターの破棄は行わず、Tickと表示とコリジョンを抜いた状態で存在しています。あとはこれをゲームの進行に応じて継ぎ足していけばいいわけです。
（本来は破棄と生成でやったほうがいいのかもしれないですけど、そこまでやろうとすると根本的な構造化が必要なので、退避処理で妥協しています。ガベージ扱いにならないというメリットはあるかもしれません）

初期化処理はシミュレート状態で起動したときのみ実行を待機するように設定してあります。あまりお行儀のよい処理ではないですが、こうするとシミュレート時はステージが削除されず、配置されたデータはTickに任され、エディタで全ステージの動作を確認できて便利です。上動画で紹介しているのがその状態ですね。

これはタイトル画面を別アングルから見た状態。

進むごとにステージが直列に繋がれる。
リザルト時に表示されるので15フロア分残すようにした。

揺れものの扱い

ボーンの形状が人間ではないので当然モーションも手付けすることになります。幸いゲーム内容的にモーションはほとんど無くてよく、必要なのは待機モーションとミスモーションの2種のみでした。（その後ブラッシュアップ時にリザルト用モーションを追加しています）

ランタンや頭飾りが揺れていますが、この動きはモーションデータに直付けしてあります。物理アセットは一切使わず、キーフレームをずらして配置することでワンテンポ遅れた動きを実現しているわけです。（位相ずらしとかレイヤードアプローチとか呼ばれているらしい）

Flashの多関節アニメでもよく使われていた技法なんで、なんだか懐かしいですね。最後に多関節アニメ作ったの15年くらい前なんで、ここにきてその知識が役に立つか、という感じ。基本は同じなんですね。（DoGA-L3とかはここまでキーフレームが柔軟ではなかったような・・・）

さてこの手法、お手軽に揺れものができて良いんですけど、インポート時に問題があります。どうもUE4ではループ範囲外に含めたキーフレームもまるごとインポートしてしまうみたいなんですね。上のモーションだと、マイナス20フレームから80フレームまでを、100フレームのアニメーションとして読み込んでしまう。
そこで、インポート時にアニメーションの読み込み範囲を指定して、Blender編集時での0～60フレームに該当する20～80フレームのみを読み込んでいます。ただこの指定、FBXに含まれる全てのモーションに対して適用されてしまうため、別フォルダに読み込んで、特定のファイルを抜き出さなけれなりません。幸いスケルトンを指定しておけば既存のモデルと関連付けられるため、他は削除してOKということになります。（この辺、もうちょっとうまいやり方があったら教えてほしいところです）

インポート周りはいつ見ても粗雑ですよね。EpicはBlenderの支援者として推しているのだから、この辺りスッキリさせてくれれば自作モデルの導入が幾ばくか楽になるのですが。今後に期待といったところでしょうか。

動画というゲーム外の工夫

応募動画はPremiereで作ってます。とはいえカットとフェードとテロップくらいしか使ってないので、そんな仰々しいソフトを使わなくても・・・という感じ。

さて、いろんな人のぷちコン応募作品の動画を眺めていると、プレゼンテーションとして作られている動画と、プロモーションとして作られている動画があるということに気がつきませんか？
多くの動画は、プレゼンテーションとして作られているように思います。自らの実装リソースを全部見せて、自分が何を作ったのか？を相手に説明するための動画なんですね。課題の提出みたいな感じでしょうか。だから動画でラスボスまで行っちゃう。

いっぽう、ゲームのプロモーションというのはむしろ何を見せないかにかかっていて、チラ見せによってその外側にある体験の存在をほのめかすことでプレイ意欲を引き立てるわけです。私の動画は比較的こっち寄りのパターンですね。なので敢えてステージをクリアしなかったり、ちょっと見る側がモヤっとする動画になっています。

プロモーションとして動画を作るもう一つのメリットは、説明内容が少なくて済むので動画が短くていい、ということです。これも応募時間短縮に役立ちました。（あと、見る側にもやさしい）

「遊びたい」と言ってもらえたのは、この辺りの調整が功を奏しているのではないかなーと思っています。

解説するような部分は概ねこんな感じでしょうか。
またなにかあったら書きますね。