【Unite Tokyo 2019】「Unity Test Runnerを活用して内部品質を向上しよう」セッションレポート

2019年9月25~26日にグランドニッコー東京において、技術カンファレンスイベント「Unite Tokyo 2019」が開催されました。

本記事では、9月26日に実施されたセッション「Unity Test Runnerを活用して内部品質を向上しよう」の内容を一部抜粋して紹介します。

ゲーム開発でもテストは重要

本セッションでは、Unityにおいて、ユニットテストを実行する「Unity Test Runner」の仕組みを活用して開発者の手でテストコードを書き、ゲームの内部品質を向上するためのベストプラクティスやTipsなどが紹介されました。

登壇した株式会社ディー・エヌ・エー システム本部 品質統括部 品質管理部 SWETグループに所属する長谷川 孝二は、おもにUnity向けのテスト自動化支援に携わっています。

ディー・エヌ・エー システム本部 品質統括部 品質管理部 SWETグループ 長谷川孝二

なお、本セッションの前提知識として、2019年9月開催の「CEDEC 2019」において講演された「組織にテストを書く文化を根付かせる戦略と戦術」にて、タワーズ・クエスト株式会社の和田卓人氏から、開発者がテストコードを書く必要性や、開発効率を上げる根拠、取り掛かるべき指針が数字で公開されており、その点は本セッションでは割愛しているため、ぜひ参照してほしいと紹介されました。

SWETグループとは

DeNAのシステム本部に設立されている部署「SWET (Software Engineer in Test) 」グループは、他の横断的組織と連携して、テストの自動化のアドバイザリー、テストや検証ツールの作成、CI/CD、デバイスファームの利用、形式手法によって仕様書記述の品質を上げるといったR&Dの取り組みも担当しています。

テストに関する4つの誤解

ここからは、ゲーム開発におけるテストに関して、一般的に感じられているような「誤解」を解くための説明がなされました。

【誤解1】「テスト」==「デバッグ」

おもにゲーム業界の開発現場で使用されている「デバッグ」とは、バグの発見、原因箇所の特定、修正のことを指しますが、ソフトウェア開発全般で使われる「テスト」の目的は、バグの発見だけでなく、対象ソフトウェアの品質レベルが十分かの判断や、バグの作り込みを防ぐことを意味します。

その中でも「対象ソフトウェアの品質レベルのチェック」に関しては、正しく動作することを確認するとともに「クラッシュしないか」「ユーザーが実際に遊んで問題ないか」など品質を測る、という意味を持ちます。

また「バグの作り込みを防ぐ」ことに関しては、リグレッション(デグレ・エンバグ)をテストをすることにより、時間差なくバグを迅速に発見して修正することが可能とのことです。

【誤解2】ビルドしたゲームを、手動で操作するのがテスト

次の誤解ポイントとして、ビルドしたゲームを実機でテストすることだけがテストだと思われていることが挙げられました。

ゲームを遊べる形にビルドする以前に実施するテストでは、コンポーネントやメソッドのような小さな単位で早期に確実に検証できるのが、低レベルで可能なテスト(ユニットテスト・インテグレーションテスト)のメリットです。

もちろん、この段階では実機(手動)では操作できないので、必然的に自動テストが採用されます。

ユニットテストの利点は、素早く実行してバグを早期に発見できること、個々の部品の品質を上げておくことです。

また、再現の難しい条件を作り出しやすく、タイミング的に難しかったり、乱数的に低確率であったり、画面操作では指定できない値などに対してテストできることも、特にメリットになると長谷川は述べました。

【誤解3】テストを書けば品質が上がる

続いての誤解ポイントは、「テストを書けば品質が上がる」ことです。テストでは品質を測るだけで、実際は正しい設計やプログラミングで品質は上がります。

品質の低いプロダクトはテストが書きにくい事実もあるようです。「テスタビリティ」と呼ばれるテストのしやすさや、書きやすさについての品質特性を評価する観点のひとつがあります。

テストしやすいコードは、その時点でバグも少なく、可読性も高いく、すでに一定の品質を備えていると言えることがほとんどです。

この関係は「ルンバビリティ」という言葉に例えることができると長谷川は話しました。これはお掃除ロボットが自動で掃除するには、その部屋がある程度片付いていなければ、ロボット自体が動けずに、うまく掃除ができない、という意味で使われる言葉とのこと。

また、テスタビリティを含め、外部からのテストではわからないコード自体の品質のことを「内部品質」と呼び、保守性や可読性、移植性などがこれに含まれます。内部品質を高めていくには、ユニットテストを書き、プロダクトコードを見直すことが有効なようです。

【誤解4】テストコードは、プロダクトを開発した後から書く

最後に挙げられたのは、テストコードをプロダクト開発後に後付けで書けばいい、という誤解です。

やはりプロダクトを開発しながら、並行してテストコードも書き、常に実行していくことがベターだと長谷川は述べています。

ユニットテストは人間の手で作業するテストと違い、実行時間は短いので、書いたコードをリポジトリにコミットする流れの中で、テストコードを実行することを習慣化することが大事なようです。

長谷川の持論として「テストコードは建築における足場」だと話しました。実際の建築現場では建物が完成したら足場は撤去しますが、ソフトウェア開発ではリリースに含まれなければ良いので撤去する必要はなく、増改築でも引き続きその足場を利用する、という考え方です。

Unity Test Runnerを使ってみよう

「Unity Test Runner」とは、Unity標準のユニットテスト実行環境で、Unity2019.2からはPackage化され「Unity Test Framework(UTF)」となります。

実行環境としては、UnityエディタからEditMode/PlayMode/実機の各テストを実行できるだけでなく、コマンドラインでも実行可能です。またEdit Modeテストは、JetBrains Riderからも実行可能になっています。

Unity Test Runnerウィンドウは、Unityエディタのメニュー内、Window>General>Test Runnerで起動、EditModeもしくはPlayModeを選択してRun Allすると成否がカラーで表示されます。

2種類のテストモードがありますが、できる限りEditModeを使用することを推奨とのこと。EditModeではエディタ上で素早くテスト実行することができ、PlayModeはUnityエディタのプレイモードと同じ環境で実行することができます。

EditMode Tests

EditModeでは、テストコードの置き場所が2通り指定できます。従来はEditorフォルダの下に配置するしかなかったのですが、Unity 2018以降は任意のフォルダにAssembly Definition Fileを配置して、Editorアセンブリとして認識させることが可能です。

Assembly Definition Fileの設定内容は、テスト対象のアセンブリへの参照、Test AssembliesおよびPlatforms>EditorのチェックボックスをONにします。

テストクラスに制約はありませんが、テスト対象クラスと粒度を合わせることが慣例になっており、メソッドに[Test]アトリビュートをつけたものが、テストメソッドとして認識される仕様になっています。

セッションでは、テストメソッドなど、EditMode Testsのコード例も紹介されました。テストメソッドは、もっとも重要な検証(Verify)のコードから書き、下から上に、テスト対象の実行(Exercise)、環境設定(Setup)の順に書いていくのがおすすめとのことでした。

[UnityTest]アトリビュート

このアトリビュートは、複数のフレームにまたがるテストを記述できるもので、EditModeではEditor Application.updateコールバックループで実行されますが、yield returnにはnullしか指定できないなどの制約もあります。

PlayMode Tests

Edit Mode Testsとは別アセンブリを定義します。設定の違いは、Platforms > Editor をoffにするというところです。

注意事項として、テスト用の空のSceneファイルが生成・ロードされるため、テスト実行ごとにオーバーヘッドが必要となり、やや時間がかかります。またUnityエディタがクラッシュすると、Sceneファイルが残ってしまうことがあるとのことです。

また、一連のテスト実行の際には、生成されたSceneは使い回されるため、一個のテストメソッドを実行するたびに適切にクリーンナップしないと、後続のテストに影響します。

PlayMode Testsでは、Sceneベースのテストを書くことが大変なため、インテグレーションテストを書くのであれば、Poco、AltUnityTesterなどサードパーティのライブラリ導入を検討すべきと長谷川は述べました。

ゲーム開発向けユニットテストパターン

ここから本セッションの本題とも言える、ユニットテストのパターンや、ベストプラクティスの話題に入りました。

テストとはどう考えるべきか、テストの基本は「入力」と「出力」であり、観点によって入出力の捉え方が変わり、入出力はそのメソッドの何をテストするかによって定まります。

例えば実行速度が観点のときには、普通のパラメータを与えてレスポンスを見るのではなく、実行時間を図ったり、FPSを計測することが「出力」となります。

特に重要なのが、正しい入出力の見極めです。例えば出力として「セーブしました」というメッセージが出たため、テストはOKと判断してしまうと、実はメッセージは出したけど内部的に保存はされていなかった、もしくは保存データが壊れていた、というバグを見落とす恐れがあります。

価値の高いテストを書く

ショーストッパーと呼ばれる、基本的な操作ができなくなり、ほかのテストがすべて止まってしまうような部分、また、課金周りやクレームに直接繋がる部分はリスクが高く、価値の高いテストと言えます。

また、あまりプレイヤーが触らないような通らないルートや画面に関するテストも、見落としを防ぐ意味で価値のあるテストと言えます。

逆に価値に対してコストが高なってしまうものとして、副作用的なもの、目に見えるようなエフェクトやSEなどを挙げました。これらはあえてテストを書かないという選択もあるようです。

組み合わせ条件を減らす

テストの「入力」にあたる要素が多くなり組み合わせ条件が増えれば、テストもそれだけ複雑になります。例えば「弾がヒットして敵が破壊されたかどうか」の粒度でテストをすると、敵のHPや防御力などさまざまな要因が関係し、当然組み合わせの条件も増えてしまいます。

それを避けるため、プロダクトコード側の責務を適切に分割することで、個々のコンポーネントやメソッドが扱う要素が減り、組み合わせ数も減ります。

責務を分けたらコールスタックが増えて性能が出ないのでは?

実は本当にボトルネックになる部分は少ないと言われており、見極めはかなり重要になるようです。コンパイラの最適化を信じる、引数にrefをつけて参照渡しにするなど、対処方法は多数あると長谷川は述べました。

パフォーマンステスト

パフォーマンステストは、ユニットテストの段階から意識することが重要で、特にUpdateメソッドで動作する、呼ばれる頻度の高い部分を、できるだけ小さい規模のうちに意識することが大事だとのことです。

そのためには、メソッド単位に実行時間を測定して遅くなったら失敗するテストを書いたり、PlayModeでfpsを測定するなどの手段を使うと良いようです。

ただ、実行時間は環境に依存するため、実行時間のしきい値をピーキーに設定することはせず、自分以外の人がそのコードを修正したときに気をつけてもらうための「魔除けのお守り」程度の気持ちで考えると良いそうです。

また、メソッドの実行時間ではなく、AllocatingGCMemoryによって意図しないヒープメモリの確保が行われていないことを確認するテストも有効です。

他のオブジェクトへの依存

依存オブジェクトとは、テスト対象が内部で使用している他のオブジェクトのことです。例えば、乱数を内部に発生させている場合に、乱数の結果をテストコード側がコントロールできないと、テスト結果が正しいのかどうか判定できなくなってしまいます。

また、依存オブジェクトからの戻り値でテスト結果に影響するものを「間接入力」、依存オブジェクトに渡した引数のうちテスト結果として評価しなければならないものを「間接出力」と呼ぶそうです。

依存オブジェクトを持つメソッドをテストするための「テストダブル」といったパターンも存在します。これは映画のスタントや影武者のような役割を持っている手法になります。

テストダブルパターンは、あらかじめテスト側から依存オブジェクトのダブルを生成しておき、テスト対象は依存オブジェクトを内部で生成するのではなく外から受け取れるようにします。そうすることでテストダブルが間接入力を操作し、間接出力を検証します。

仕様変更のたびにテストが壊れる

よくある誤解としては「仕様変更があるからテストは書けない」のは間違いであり、「仕様変更があるからテストで保護しておく」という考え方に変えることが大事だとのこと。

将来の仕様変更を想定することで実装が複雑になり、品質も落ちてしまうったが仕様変更は起こらなかった、という経験はないでしょうか。テストがあることで仕様変更をしてもプロダクトが意図しない振る舞いになっていないか、すぐに気づくことができます。テストコードがあることによって「今必要でないことはしない」こと(YAGNIと言うそうです)を実行しやすくなるのです。

「なぜテストコードが壊れるか?」という話について、仕様ではなく実装のテストを書いてしまうことが要因とされます。ひとつの仕様に対して実装は何パターンも存在するため、実装が変わっただけで壊れやすいテストになってしまいます。

壊れにくいテストを実現するためには、副作用は検証しない、あえて定石から外れるといった選択肢もあります。

例えば「敵のHPゲージが5割を切ったら黄色にする」という仕様に対し、テストの定石としては50%と49%をテストするものですが、あえて80%と40%で色の変化にのみ着目するなど、境界値を攻めすぎず、十分役割を果たすテストにすることもできます。

また、メンテナンスが難しくなったテストコードは捨ててしまうこと、TDDではその過程で過剰にテストコードを書いてしまいがちなので、必要ないものは早めに取り除いても良いようです。またテストコードもプロダクトと同じように構造化することで、壊れにくいコードになります。

ここで長谷川は、Jon Reid氏の言葉「テストコードはガラスのような壊れやすいものではなく、竹のようにしなやかで柔軟性の高いものを目指すべき」と挙げ、アジア圏の建築現場で良く使われている竹の足場のように、安くて軽く、使わなくなったら捨てればいいようなコードと、思想は似ていると述べました。

テストを書く文化を根付かせる試み

最後に、SWETグループが採用したアプローチに関して、社内で横断的に共通的フレームワークのリファレンス実装に対して、テストコードのサンプルを書いて新種のバグを摘出し、タイミング良く、他の部署への引き合いに繋がったことが明かされました。

また、ゲーム領域でボトムアップでテストを書くことを始めるのは難しいため、いつでもチャンスが来たら、テストを普及できるような体制を整えておくことが大事とのことです。

長谷川は「米沿岸警備隊の格言 ”Senper Paratus(常に備えよ)”に表されるような心構えを大切にしながら、本活動に興味があればぜひ声をかけてほしい、そしてスライドには本セッションで紹介できなかったUnity Test RunnerのTipsを記載しているので、ぜひ参考にしてください」とのコメントでセッションを締め括りました。

取材・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

VRゲーム『VoxEl』開発メンバーが語る技術的な試行錯誤

『VoxEl(ボクセル)』開発メンバーにインタビュー

DeNAのR&Dの一環として開発が始まり、まだプロトタイプながら国内外の展示会で話題となった、『VoxEl(ボクセル)』。本作は少女「エル」に託された不思議なワンド(杖)を駆使して、仮想世界のギミックを解いていくVR専用の謎解きアドベンチャーゲームです。

今回、開発パートナーのあまた社を迎えて、開発中の苦労話や技術的なエピソードを交えながら、両社にお話を伺いました。

[su_note note_color=”#ffffff”]

Profile
[su_row][su_column size=”1/5″ center=”no” class=””][/su_column] [su_column size=”4/5″ center=”no” class=””]

永田峰弘
株式会社ディー・エヌ・エー プロデューサー(兼ゲームデザイナー・サウンドクリエイター)[/su_column][/su_row]

[su_row][su_column size=”1/5″ center=”no” class=””][/su_column] [su_column size=”4/5″ center=”no” class=””]

髙橋宏典
あまた株式会社 代表取締役社長[/su_column][/su_row]

[su_row][su_column size=”1/5″ center=”no” class=””][/su_column] [su_column size=”4/5″ center=”no” class=””]

渡邉哲也
あまた株式会社 シニアプロデューサー兼ディレクター[/su_column][/su_row]

[/su_note]

研究開発目的で始まったVRゲームプロジェクト

――はじめに、『VoxEl(ボクセル)』の開発が始まったきっかけを教えてください。

永田:自分が前年度にVRタイトルを開発していて、その流れでVRゲームのR&D目的のプロジェクトが始まりました。あまたさんとは、『天華百剣 -斬-』の開発でもお付き合いがあり、別ラインでVRゲーム開発実績を持っていたことから、今回の取り組みがスタートしたのが経緯となります。

株式会社ディー・エヌ・エー プロデューサー(兼ゲームデザイナー・サウンドクリエイター)永田峰弘

――『VoxEl』にはあまた社で開発しているVRゲーム『ラストラビリンス』の技術的ノウハウが使われているのでしょうか?

髙橋:キャラクター表現ではノウハウが生きている箇所もあります。ですが、『ラストラビリンス』は閉鎖された空間からの脱出がテーマで、広い世界で旅するというコンセプトの『VoxEl』とはレベルデザイン的に方向性が真逆なため、描画負荷対策を含めて試行錯誤の連続でした。技術的には、ノウハウを活用しつつ大きく挑戦しています。

あまた株式会社 代表取締役社長 髙橋宏典氏

――開発に両社のスマホゲームのノウハウは生かされているのでしょうか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:正直あまり関係はなかったです。スマートフォンのゲームでは小さな画面の中でバトル、強化や育成など、いかにプレイヤーに楽しんでもらえるかというプレイサイクルを中心に考えて開発していますが、VRではその空間で没入できるコンテンツが重要視されるので、ほぼセロベースからの検討になったといえますね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:ただ、Unity開発なので、3D表示部分などはゲームのノウハウを使用しています。とはいえ、本作はモバイルではなくハイエンド向けタイトルなので、シェーダーや画作りなどはまったく違う工程になってます。[/su_column][/su_row]

――なるほど。では、挑戦した部分や開発中に試行錯誤した点を教えてください。

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:VR対応のアドベンチャーゲームは、本格的に作ろうとするとコストがかかるため、あまり市場に出ていません。そのため、毎日が挑戦の連続でした。また、今回の取り組みにおいても、リソースや開発期間、予算などは限られていますので、その中で最終計画を念頭に置きながら両社で話し合いながら進めていきました。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:試行錯誤した点と言えば、VRゲームでは強制的に視点を固定しにくいので、視線誘導で変化が起きた箇所を注視する仕組みを永田さんにチェックしてもらい、フィードバックを受けながら調整を重ねたことですね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:特に、VR空間内での「サイズによる見え方の違い」のチェックは大変でしたね。プレイヤーがターゲットできるオブジェクトの大きさ、動かせるサイズがどのくらいあれば認識可能なのか、その確認から入っていきます。

現実の空間で50cmくらいあれば認識できるものでも、VR空間にポツンと置くと意外と分かりにくいんですよ。同時にテーブル程の広さなのか、広大な世界にするのか、謎解きの舞台となる空間の規模感も悩みました。[/su_column][/su_row]

――実際にオブジェクトをVR空間内に配置して開発を進めていくんですか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:ええ、そうです。配置パターンを複数用意して、プレイ確認しながら進めます。オブジェクトの質感によって印象も変わるので、何度も調整しました。[/su_column][/su_row]

チームメンバーからの意見・要望を新アイデアに生かす

――両社のやりとりにはどんなものがありましたか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:例えばプロトタイプの段階で「超巨大な鉄球を25mプールのような場所で風で飛ばす」というデカいギミックが企画で上がってきましたが、実際に作ってみた結果ボツになったものもあります。個人的にはおもしろかったんですが。

他のVRゲームでは、比較的小さな空間でパズルやキャラクターとコミュニケーションを楽しむ作品が多かったため、『VoxEl』ではあえて広い空間を使うアドベンチャーに挑戦しました。

なので、永田さんからは広大なスペースを使ったギミックの提案が多かったように感じます。一方、髙橋はこじんまりとしたギミックが好きなようで……。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:こじんまりというか、広すぎると影響範囲がわかりにくくなって、エルが相対的に小さくなり存在感が薄くなっちゃうなって。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:いくつかギミックを試作した結果、広い空間を設定してしまうと、エルの存在感が薄くなり、彼女が単純なコミュニケーションキャラクターになってしまうのが課題でしたので、ステージの規模やギミックのサイズ感など改めて修正して開発にフィードバックしました。[/su_column][/su_row]

あまた株式会社 シニアプロデューサー兼ディレクター
渡邉哲也氏

――開発メンバーからどのような意見・要望が出ましたか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:開発現場では、アーティストやレベルデザイナーなどのいろんな職種がフラットに意見を出しながら、既存のVRゲームには実装されていないようなアイデアを盛り込んでいきました。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:Primitiveで作ったレベルデザイン周りも、一旦は社内全員にプレイしてもらって、意見を吸い上げた後に永田さんとさらに調整していく、というフローにしました。

企画内容プレビューについては、「ユーザー目線ならどんなことを言ってもOKルール」を採用したので、意外にみんなが好き放題感じたことを言っていたのを覚えています(笑)。[/su_column][/su_row]

VR機器に合わせた操作性の調整とボイスの有効性

――操作周りに関する質問です。本作のプレイはコントローラ1つのみでしょうか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:ですね。実は開発途中では2つ使って、片方はエルと手をつなぐ設定だったんですよ。ですが操作が複雑になってしまうため、現在の仕様になりました。[/su_column][/su_row]

VRコントローラをゲームの中で「ワンド」として使用。トリガーを押してエレメントを吸収します

――操作感に関する調整は大変でしたか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:異なった設定パターンを複数作り、微調整をしつつ全員で実際に操作して決めていきました。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:両社でプレイして悩みながら「操作していて気持ちいい」設定を探していきましたよね。[/su_column][/su_row]

――エレメント(※1)吸収中はずっとトリガーを押しっぱなし(※2)だと思っていました。

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:おっ!そっちの操作のほうが良かったかもしれませんね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:いや~、そこは迷ったんです……。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:開発の段階でその操作感は試したような気がします。なんでボツになったんでしたっけ?[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:(押しっぱなしだと)単純に指が疲れると思います。エレメントの吸収も、当初のアイデアだと他の属性も同時にワンドにストックできて、属性を選んで自由に使えるようにしてたので、その時の名残かも……。[/su_column][/su_row]

操作を含めたワンドのグラフィック案は、かなりのパターンが考えられたようです。
 

編集部注釈(※1)エレメントとはゲーム内の謎解きに使用する各属性のエネルギーで、点在する属性ブロックからワンド(杖)に吸収して発射することでギミックを作動できます。

編集部注釈(※2)本来はエレメント吸収後にトリガーを離しても大丈夫。もう一度押し込むと発射します。

――プレイ中の「疲れ」に関する調整はありますか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:そんなに疲れは気にせず、遊べるようになっています。ギミックが出現するタイミング、エルとの会話シーンなど、ゲームのテンポ感も考えています。チャプターを細分化してバランスを取れば、たくさんの謎を組み込むことができると思います。[/su_column][/su_row]

――エルのボイス実装で、UI/UXにおける影響はありましたか?

ゲーム中は彼女がナビゲートをしてくれます。たまに謎解きのヒントを話すことも
ゴシック&クールな雰囲気が漂う、エルの初期デザインアイデアの一部です。
 

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:VRではゲーム説明やルール解説を担う「チュートリアル」や「ガイド」の表現が難しく、いきなりメニューが表示されてしまうと、一気に興ざめする恐れがあります。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:突然宙に浮いてきた文字はなんなんだ、って。せっかく仮想空間で楽しんでいたのに、急に現実に引き戻されてしまう感覚です。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:そこで、エルにボイスを追加し、要所要所で会話をさせるナビゲート役にすることで、チュートリアルなどを組み込まなくても、基本的な操作などを学べるようにしました。

さらに、謎解きのヒントを語らせたり、単純にプレイヤーとコミュニケーションを取るなど、使い方のバリエーションも増えたので、UIの開発はほとんど必要なくなりましたね。[/su_column][/su_row]

Unityでは可能、しかしVRでは苦手な「水の表現」

――技術的にボツになったものはありますか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:VRでは、水の表現が難しいのです。VRは立体視なので、水の屈折を左右両目用に別々にレンダリングする必要がありますが、謎解きやギミックで広範囲に水が出てきたら確実にフレーム落ちします。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:ゲーム内に出てくるエレメントが火・風・土だけで「水」が出てこなかったのは、こういった理由でもあります。実は、火+水で水蒸気になる、火+火で爆発が大きくなる、みたいな夢が詰まったアイデアもたくさんあったんですよ![/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:正攻法で作るだけだと、かなり厳しいですね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:どうしても実装できずに外した機能はあります。ただ、現時点で限られた期間内で作るのは無理だと判断しただけで、今後グラフィックカードが進化したり、ゲームエンジンが発達すれば実装できる機能もあるはずです。[/su_column][/su_row]

――他にUnityでは可能で、VRでは表現しにくいものってあります?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:粉じんや霧などは難しいですね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:通常の3Dゲームでも炎や霧、煙など自然現象の複雑な動き、光の屈折などで処理は重くなるのですが、VRになるとそれを複数同時に描画しているので、さらに重くなる傾向があります。[/su_column][/su_row]

――ギミックの爆発やシールドの表現はダイナミックでしたよ!

 

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:爆発には、ちょっとしたテクニックを使っています。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:でも、燃えている炎など、VR空間でじっくり見ると怪しい箇所がわかるかもしれません。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:当初は「木を火で燃やす」などの複雑なギミックも考えていたんですが、残念ながら実装していません。[/su_column][/su_row]

――VRでの表現の限界を考えてギミックも変更していくんですね。

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:はい。もちろん開発期間もふまえて考えています。研究開発をもっと進められるようなら、今後最新技術も試してみたいですね。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

髙橋:ただ、表現の開発だけに注力するわけにもいかないので、全体の進捗バランスやトータルコストも考えています。[/su_column][/su_row]

イメージしたものをイメージ通りに作れた喜び

――開発が進むにつれて、仕様はどのように変化していきましたか?

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:VRで3D酔いしないようにするため、開発途中で、移動の仕様を変更したことがありました。一度VRで酔った経験をしてしまうと、次は絶対に遊ぶのがイヤになります。それは避けたくて、移動方式を根本から見直しました。また、移動関連の仕様の変更で、世界観の見せ方もだんだんと変わっていきました。[/su_column][/su_row]

――本作の開発を通して、これまでにない「得たもの」を教えてください。

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

永田:VRに関しては、資料で学んだり他のVRゲームをプレイしたときに得た推論の答え合わせができたことが、ひとつの成果だと感じています。

サウンドに関しては他のゲームを作る際とあまり大差なかったため、こだわったのは立体音響の部分くらいです。イメージしていたものが、イメージ通りに作れているのが何より嬉しいことです。[/su_column][/su_row]

[su_row][su_column size=”1/6″ center=”no” class=””][/su_column] [su_column size=”5/6″ center=”no” class=””]

渡邉:やはりVRではボイスの存在が大きいと感じました。ボイスがなかったときは、エルの存在が空気になってましたが、永田さんが書いたセリフをエルが場面ごとに話すようになってから、プレゼンスがグッと上がりましたね。[/su_column][/su_row]

――VRゲームの研究開発を続ける中で、技術的にも成長し、両社のこだわりが詰まった作品に昇華していったようですね。本日はありがとうございました。

 



R&Dを目的としてスタートしたVR『VoxEl(ボクセル)』プロジェクト。試行錯誤を繰り返しながら、技術的に数多くの「学び」を得たことを感じられるインタビューとなりました。本研究の成果がDeNAの他の事業にも生かされていく可能性があるかもしれませんね。

※本作はプロトタイプのため、今後の販売や配信などは一切未定となっています。

※本記事は2018年12月時点での情報です。

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitter アカウントやFacebookページにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

【イベントレポ】GDM エンジニア向け勉強会Vol.5~Unityのバージョンアップによって発生した問題への対処~【登壇資料つき】

毎回様々なゲストをお招きして、最新の技術や情報をシェアするDeNA主催のゲームクリエイター向け勉強会の【Game Developers Meeting】(以下、GDM)。

去る、2018年11月16日(金)に開催したGDMでは、前回のエンジニア向け勉強会でもご登壇されたエンジニアの黒河 優介さん(ユニティ・テクノロジーズ・ジャパン合同会社)にお越しいただきました。

第一部 セッション

今回は「Unityのバージョンアップによって発生した問題への対処」とテーマを掲げ、「バージョンアップでTextureの容量が膨らんだ」や「UIでUV2が正しくわたってこなかった」などの過去事例を出したり一般論を織り交ぜながら様々な知見をご紹介いただきました。

主に「Unityのバージョンアップでバグに悩まされた方」「バージョンアップを控えている方」に向けられた内容となっており、バージョンアップする際の留意点や、バグ発生時にUnity側ではどのようなフローで修正まで進められているのかなど裏話的な内容も伺いました。

▼当日の登壇資料はこちらでご覧いただけます。

第二部 懇親会

GDM恒例の懇親会も大変盛り上がっていました!

次回は、デザイナー向け勉強会

株式会社スクウェア・エニックスの長谷川 勇さんにお越しいただき、キャラクター制作のワークフローについてのお話を伺います。
[su_note note_color=”#ffffff”]
GDM デザイナー向け勉強会Vol.7
キャラクター制作のワークフロー紹介
〜 FINAL FANTASY XVを事例として課題と、課題に対する今後の改善について 〜

■日程: 2018年12月18日(火)
■時間: 20:00 ~22:00(受付開始 19:30)
■場所: 渋谷ヒカリエ21F 渋谷ヒカリエ21F DeNA Seminar Room
[/su_note]

▼お申し込みはコチラ

https://genom.dena.com/event/1218_gdm/

 

 

【イベントレポ】DeNA×サイバーエージェントのエンジニア合同勉強会に潜入!

初の試みとなった”若手エンジニアが主役の勉強会”

2018年10月29日、東京・グラスシティ渋谷にて、DeNAとサイバーエージェントの二社合同でゲーム開発・運用技術に関するクローズド勉強会&交流会が開催されました。

コンセプトは「若手のエンジニアが発表しやすい勉強会」。DeNAとサイバーエージェントのエンジニアが2名ずつ、それぞれ約15分ほどのプレゼンテーションを実施、40名を超える参加者の中には、若いエンジニアが多く見られました。

この勉強会は、5月7~9日に開催された「Unite Tokyo 2018」の懇親会の会場で両社のエンジニアが知り合い、その際に「一緒に勉強会したら面白そうだね!」といった話がきっかけで、実現されたとのことです。

ちなみに両社のエンジニアとも、普段から他社とのコミュニケーションを積極的に取っており、今後もさまざまな勉強会や、気軽に参加できるカジュアルな交流イベントなどを企画・予定しているようです。

まずはDeNAセッションからスタート

「3DアクションゲームにおけるUnity2018アップデート対応」

太田垣八雲氏

登壇者:ゲームエンジニア 太田垣八雲

機能開発・周辺環境整備を担うエンジニアの太田垣八雲から、現在サービス中の共闘型3Dアクションゲームを題材に、Unity2018のアップデート対応について発表されました。

ブラックボックスとされていた箇所に対して、拡張に開かれたAPI/構造に変更してオープン化することをテーマとし、それに伴う新機能やアップデート、バグ修正対応などに関しての詳細が紹介されています。

「開発基盤部のおしごと~開発を支える技術~」

関慎太郎氏

登壇者:開発基盤エンジニア 関慎太郎

ゲーム事業を横断的にサポートする、開発基盤エンジニアの関慎太郎より、ゲーム開発を支えるためにどんな取り組みをしているのか、共通コンポーネントの提供と、開発力・運営力を促進するための活動といった、2つのテーマで発表されました。

以前までの開発基盤部の体制や、関係性の遷移イメージ、実際の事例を使って原因と改善の方法などを詳しく紹介しています。

続いて、サイバーエージェントセッション

「バトルアクションをもっと見やすく!~ロックオンのカメラワーク研究~」

川辺兼嗣氏

登壇者:グレンジ プログラマー 川辺兼嗣氏

サイバーエージェントグループのグレンジが2019年に配信予定の新作『Kick-Flight』を題材に、プログラマーの川辺兼嗣氏がカメラについての研究結果を共有しました。

川辺氏は現在、バトルアクション・FPS&TPS、アスレチックアクションの3ジャンルのカメラを研究しており、プレイヤーがより遊びやすく、ロックオン中の敵が見やすい位置関係の微調整など、自身が生み出した理論を公開しました。

「『リンクスリングス』におけるZenjectの活用事例」

二宮章太氏

登壇者:サムザップ 二宮章太氏

同じくサイバーエージェントグループのサムザップが2019年に配信予定のスマホ向け新作タイトル『リンクスリングス』について、二宮章太氏がZenjectの活用事例を紹介しました。

Zenjectの概要から基本的な使用方法、「参照の受け渡しの楽さ」「開発用環境の構築の簡単さ」などさまざまな利用シーンでの対応法や、注意する点などを具体的に紹介しました。

※Zenjectとは、オープンソースのUnity向けDI(Dependency Injection)フレームワークのこと。

情報交換で盛り上がる交流会

プレゼンテーション後は、お寿司&ドリンクが用意された交流会が実施され、登壇者と参加者が親睦を深めました。

今回は、二社の関連社員のみ参加が可能なクローズド勉強会のため、残念ながら一般の参加はできませんでしたが、このような複数の企業を横断しての、若手メインとなる勉強会は定期的に開催予定とのことです。

 

Copyright(C)DeNA Co., Ltd. All rights reserved.
Copyright(C)CyberAgent, Inc.

※本記事は2018年10月時点での情報です。

 

【イベントレポ】GDM エンジニア向け勉強会Vol.4〜 Unity 2018からのハイパフォーマンスな機能紹介 〜【登壇資料付き】

去る2018年6月22日、Game Developers Meetingエンジニア向け勉強会〜 Unity 2018からのハイパフォーマンスな機能紹介 〜(以下、GDM) が開催されました。

本記事にて勉強会の資料を掲載していますので、是非ご覧ください!

今回のGDMは、Unityより黒河 優介さんと森嶋 大樹さんのお二人にお越しいただき、“ Unity2018 ”の新機能や開発にあたっての留意点など、最新情報をご紹介いただきました。

開始早々、なんとUnityさんからのプレゼント!
開場前、会場のいくつかの席のアンケートの下にUNIBOOK電子書籍版がダウンロードできるカードを仕込むというイキなお計らいが。

Unityに携わる技術・知識・ノウハウが詰まった“UNIBOOK”。
日本Androidの会Unity部が発行し、コミックマーケットでの頒布では1時間で完売したという超人気の一冊。技術書展での販売も。

エンジニアの黒河さんよりUnity2018で追加された、ハイパフォーマンスな機能の紹介がスタート。
主に以下の内容について、実機を使用しての実験結果を見せながらお話いただきました。

・Unityが抱えていたパフォーマンス上の問題点を新機能を使って解決する方法
・新機能を使うことでどのようにパフォーマンスが向上するか
・新機能を利用した実装方法について

 

Unity 2018からのハイパフォーマンスな機能紹介 from dena_genom

 

イベント後半は、森嶋さんよりUnity Analiticsを使用することでできる、ヒートマップを利用した分析についてなどのご紹介がありました。

勉強会終了後は、GDM恒例の懇親会タイム。
お寿司やピザをご用意しました。

次回のGDMはデザイナー向け勉強会を予定しております。

『アウトソーシング経験録「私はこうして90%ぐらいは乗り切った…!」 』をタイトルに、ゲーム製作において欠かせない「アウトソーシング」のやりとりの中で起きた出来事をパネルディスカッション形式でお送りします。

▼詳細はコチラ▼

Game Developers Meeting デザイナー向け座談会Vol.6
〜 アウトソーシング経験録「私はこうして90%ぐらいは乗り切った…!」 〜

デザイン制作物以外の「シナリオ」や「BGM」などにも共通する内容なので、様々な職能の方にご参加いただける内容となっております!

 


GDMは毎回様々なゲストをおよびし、カジュアルに参加・交流できる会をめざして運営しております。
お気軽にお越しくださいね!