UEFNで使えるプログラミング言語「Verse」のノウハウが集結。『UEFN.Tokyo 勉強会 03 Verse Night』レポート

「UEFN.Tokyo」は、Alche 代表 川 大揮氏が主導する「Unreal Editor For Fortnite（以下、UEFN）」の勉強会です。UEFNのクリエイターが集まり、LTや懇親会を通して知見を共有します。

3回目となる今回は、UEFNで使用できるプログラミング言語「Verse」にフォーカス。Verseの基本から、メジャーなクラス設計パターンであるMVP（※）をVerseに適用する方法まで、4つのセッションが行われました。
※　クラスをModel・View・Presenterに分割し、コアのロジックとUIのロジックを分離するクラス設計手法

ここからは、各セッションの様子を紹介します。

最初のセッションでは、川氏がUEFNにおけるVerseの基本を紹介しました。

フォートナイトがマルチプレイであるため、フォートナイトを基盤としているUEFNでも多くのマルチプレイゲームが作られています。UEFNでマルチプレイゲームを制作する際には、Verseコードもマルチプレイを意識した設計が必要となります。

そもそもUEFNにおけるVerseの役割は、プレイヤーや仕掛け（※）が送信するイベントに対してほかの仕掛けの起動やUIの表示などの操作を行うことにあります。
※　レベルに配置できる、「アイテムをスポーンさせる」などの機能を持ったオブジェクト

講演では、Verseを使って「ボタン」の仕掛けにアイテムのスポーンを紐づける例と、プレイヤーのしゃがみを検知してUIを表示する例が紹介されました。

ボタンへのインタラクトでアイテムをスポーンさせる仕組み

しゃがみを検知し、Verseで作成したUIを表示させる仕組み

プレイヤーのしゃがみを検知するには、ゲームの開始時に各プレイヤーのしゃがみイベントを取得し、UIを表示する関数を紐づけなければなりません。

各プレイヤークラスのインスタンスを取得する際は、全プレイヤーの情報などを格納する「playspace」クラスが起点になります。UEFNにおいて、プレイヤーに関係するクラスは下記画像のような関係になっていると川氏は言います。

UEFNにおける、プレイヤーに関係するクラスのイメージ図

また、プレイヤーやNPCのAIに対応する「agent」クラスと「player」クラス、キャラクターのクラスである「fort_character」は下記画像に示す関数を用いて相互に変換可能とのこと。

agentからfort_characterを、fort_characterからagentを取得する関数がそれぞれ用意されている

次に、川氏はVerseでマルチプレイゲームを作る上での注意点に触れました。

フォートナイトでは、Verseコードはクライアントでは実行されずサーバーでのみ実行される

例えば、6人のプレイヤーがプレイしている状態を考えます。先に紹介した、しゃがみ時にUIを表示するコードでは、特定のプレイヤーがしゃがむと、UIを表示させる関数が実行されるようになっています。しかし、関数内ではプレイヤー配列の先頭にあるプレイヤーにUIを表示させるようになっているため、しゃがんだプレイヤーとは別のプレイヤーにUIが表示されてしまいます。

このように、クライアント側での処理を記述できない都合上、プレイヤーごとに行う処理はプレイヤーの整合性がとれるよう実装しなければならない点は、Verseの特徴です。

ほかには、プレイヤーの途中参加に関する問題が挙げられました。 先に紹介した、しゃがみ時にUIを表示するコードでは、ゲーム開始時に全プレイヤーに対してしゃがみとUI表示をバインドする関数を紐づけるのみでした。

そのため、途中参加のプレイヤーに対してはバインド関数が呼ばれません。

そこで、プレイヤーが参加したときに発火するイベント「PlayerAddedEvent()」によってもバインド関数を実行させることで、途中参加にも対応できるようになります。

次に登壇したICE_N氏は、Verseを活用して島（※）の制作を効率化するテクニックについて解説しました。
※　UEFNやクリエイティブで制作したゲームのこと

同氏は6月からUEFNを使い始め、現時点で23の島を公開。総プレイ数は100万プレイ、同時接続数のピークは7,400人を記録しています。

島を早く開発・リリースする必要性に関して、ICE_N氏は次の見解を持っているとのこと。

• 手ごたえがあっても伸びるかどうかは出してみないと分からないため、どんどんリリースするほうがよい
• 構想からリリースまでのプロセスを何度も経験することで、島の見られ方まで意識できるようになっていく
• モチベーションを維持するのは難しい
• 時間をかけすぎると、飽きるか愛着がわいて客観視できなくなっていく
• 早く出さないと、同じアイデアの島がリリースされ二番煎じになってしまう

そのため、同氏はひとつの島を平均6日でリリースしているそうです。

続いて、平均6日という早さで開発を終わらせるために心がけているポイントが紹介されました。

まず取り上げたのは、開発環境について。ICE_N氏は、AIを用いたコーディング支援ツール「GitHub Copilot」を勧めました。特にコードのサジェスト機能が便利であるそうです。

Verseに対する補完精度は高くないが、文法の間違いなどはエラーとして示されるため修正は容易とのこと。

また、VerseコードはGitHub、レベル上のアクターはUnreal Revision Controlでバージョン管理を行っているそうです。

命名規則に関しては、公式のルールを踏襲すると分かりやすいとのこと。

そして、Verseで最も効率化の効果が出やすいポイントが「再利用性」だとICE_N氏は言います。同氏は「ペットの追従」や「変身」、「マルチプレイ対応」などよく使用する機能は汎用化しプロジェクト間で使いまわせるようにしているそうです。

また、Verseで使用できるUEFNの機能「タグ」を活用し、レベルとVerseの紐づけを解消するテクニックも紹介されました。Verse上で定義したタグを仕掛けに適用することで、タグが適用された仕掛けを一括で取得できます。

テスト用タグも定義しておくとテストを高速化できるそう

続いて紹介されたのは、座標の指定にcreative_prop（小道具）を使用するテクニックです。座標をプロパティに直接打ち込む方法をとる場合、打ち込んだ座標はレベル上で確認できないため細かい調整は困難です。そこで、配置したcreative_propの座標を使うことで、位置が可視化され効率的に調整できるようになります。

また、とにかくVerseコードを書くことも、ゲームに対する思考の幅を広げるのに大きく役立ったそうです。

これらのポイントのうち、どれが最も大事ということはなく、すべてが同じくらい大事であると同氏は語ります。

次に、ICE_N氏は開発の効率化を考慮してVerseを活用した、いくつかの事例を紹介しました。

ひとつは、仕掛けなどを使わずに極力Verseを使って開発した『WHERE’S PET ?』（島コード：6058-3793-7518）です。

フォートナイトのマップを公開しました

WHERE'S PET ?
MAP：6058-3793-7518

プレイ人数：８名
🐈迷子のペットを探そう
🐈ペットの大好物を持って近づくと迷子のペットが寄ってくるよ
🐈飼い主の元に迷子のペットを連れて行こう
🐈ライトを持って近づくと鳴き声が聞こえるよ

是非遊んでみてください pic.twitter.com/M8KwfuTE9s

— ICE_N(アイス) (@ice_n_game) January 28, 2024

特に、ペットがプレイヤーに追従し、ダッシュや静止などに応じてアニメーションを自然に遷移させる部分に注力したそうです。また、フェニックスに変身するシステムで使われている、オブジェクトの滑らかな移動はVerseでしか実現できない表現とのこと。

距離の判定もミューテーターゾーンを使わずVerseを用いている

そのほか、巨大ロボを使った『THE BATTLE ROBOT』（島コード：9884-3371-8076）や、恐竜に騎乗できる『THE DINOSAURS』（島コード：3890-4970-8669）の事例も紹介されました。

Eisuke氏は、もともとUnityでの開発で使用していたMVPパターンをVerseでのクラス設計に適用する方法について解説を行いました。

Verseでクラス設計を行うことについては、機能を追加しやすくなるなどの利点がある反面、コードが複雑になりやすいほか、チーム開発では設計方針を共有するのが難しい欠点もあります。

MVPパターンとは、機能をModel・View・Presenterの役割に分割して実装するデザインパターンです。

それぞれの役割は、以下の通りです。

講演では、「1秒ごとにスコアを1増加させ、UIのボタンを押すとカウントが1増加する」仕組みをMVPで実装する例が紹介されました。GitHubにて、実行可能なソースコードが公開されています。

全体のクラス図は下記画像の通り。PlayerManagerが各プレイヤーに対応するPresenterのインスタンスを生成・管理する設計になっています。

プレイヤーの参加時などに、新たなインスタンスの組が生成される

Modelは、実際に「1秒ごとにスコアを1増加させる」「カウントを1増加させる」ロジックを実行します。また、スコアやカウントが変化する際に対応するイベントを発火させ、値が変化したことを伝えます。

ViewはUIの生成・更新や、ボタンをクリックしたイベントの発行を行います。Viewにおけるスコアやカウントの更新メソッドは更新以外の役割を持たないことがポイントだとEisuke氏は言います。

Presenterは、ModelとViewを参照し、両者のイベントハンドリングを行います。また、ModelとViewの生成もこのクラスが担っています。

これらのクラスは、Verseで継承できる仕掛けのクラス「creative_device」を継承していません。そのため、生成や初期化はcreative_deviceを継承した「players_manager_device」クラスが担う設計になっています。

creative_deviceのOnBegin()がエントリーポイントとなる

UEFN.Tokyoでの登壇は2回目となるイワケン氏は、同氏が所属するサイバーエージェントが制作協力を行った『くまモン島』の制作事例を紹介しました。

イワケン氏は、Subscribeを使わずAwaitを使う設計を心がけているそう

同作は4人チームで制作され、イワケン氏はエンジニアと制作リーダーを務めました。同時接続数のピークは1830人、フォートナイト全体のランキングでは49位を記録しています。

くまモン島のベースとなったゲームジャンル「タイクーン」とは、経営シミュレーションに近いジャンルです。

ベースにタイクーンを選択した理由としては、PvPなど戦闘系以外のジャンルでフォートナイトプレイヤーに人気が高かった点、自治体の魅力を伝えるのに相性がよかった点が挙げられました。

イワケン氏は、フォートナイトで20種類ほどタイクーンの島をプレイし、いくつかのパターンに分類しました。

くまモン島は、タイクーンにおける多くのパターンを網羅しているそう。

くまモン島は緑と赤文字で書かれた部分をおさえている

講演では、その中でもVerseがなければ実装が難しい「独自ポイント」「シーケンサー演出」について解説が行われました。

同作で画面中央上に表示される独自ポイント「エネルギー」はVerse上で実装しているそう。

フォートナイトのリソースである「ゴールド」とは別のリソースとして扱われる
©2010熊本県 くまモン

「エネルギー」をVerseで実装する理由としては、独自アイテムのカウント表記が難しい点、エネルギーが全プレイヤー共通のリソースである点が挙げられました。Verseで実装したことで、所持上限を100万に設定するなどの柔軟な処理も行えているそうです。

ゴールドの付与は、仕掛け「アイテムグランター」を使用しています。しかし、アイテムグランターでは付与するアイテムの個数を動的に変更できません。そこで、1、10、100、1000ゴールドを付与するアイテムグランターを用意し、アイテムを付与する関数をそれぞれに適切な回数呼ぶことで、負荷を抑えつつ任意の個数のアイテムを付与できるようにしています。

ゴールドの所持数を表示するUIでは、フォートナイトの仕様でゴールドを地面にドロップできる都合上、プレイヤーが持つゴールドの動きをVerse上で監視できません。そのため、イベントではなく1秒ごとに所持数をチェックする実装で対応しています。

©2010熊本県 くまモン

また、開発時には、ゲームをより良くするために追加仕様の検討をするのが楽しくもあり、苦労したポイントだとイワケン氏は語りました。

貴重なUEFNの勉強会である本イベント。次回以降では、クリエイティブの仕掛けをテーマにした「Device Night」が予定されています。

講演の後には懇親会が行われた

神谷 優斗

コーヒーがゲームデザインと同じくらい好きです