最強クラスのゲームエンジン「アンリアル」でリスクを抑えてゲームを作る方法

「ゲームエンジン」とその重要性が様々な場所で語られるようになり、ついに大手の一角であるUnityが日本法人を設立。ますますゲームエンジンはその存在感を強めています。そんな中、1998年から発展を続け、今や世界で最も有名なゲームエンジンと言っても過言ではない「アンリアル・エンジン」を開発・ライセンス販売するエピック・ゲームズ・ジャパンが、アンリアル・エンジンでリスクを抑えてゲーム開発を行う方法について、CEDEC 2011で講演しました。

Unreal Technology
http://www.unrealengine.com/

エピック・ゲームズ・ジャパン 下田純也（以下、下田）：
エピック・ゲームズ・ジャパンでサポートマネージャーをしております。下田です。「今からアンリアル・エンジンで始めてリスクを最小限に進める為の心得 」と題して、リスクを抑えながらアンリアル・エンジンを使い始めていただくための方法をご紹介いたします。

下田：
今日の内容は、「なぜ今からアンリアル・エンジンなのか」、そして「プロトタイプを簡単に作成する」というもの。さらに「クオリティを高めるためのアプローチ」。そして「アンリアル・エンジンの導入とリスク」、さらに「ネットワークゲーム対応のリスク」。そして最後にまとめです。

下田：
始める前に、今のプロジェクトでどのような問題を抱えていますでしょうか？

よくある例としては、企画書はあるけれど、企画書だけでは企画が通らないということが、最近多いかと思います。書類だけでは企画が通らない。ではプロトタイプを作ろう、と言っても、検証できるレベルのプロトタイプができるまでに何ヶ月もかかってしまうので、その間に企画が流れてしまう。またプロジェクトの規模が見えない。どの程度の人員と制作期間をかければいいのか見当がつかない。

また、実際のクオリティやパフォーマンスをどこまで向上させられるのか分からない。例えばプロトタイプを作ってみたものの、製品としてのクオリティをどこまで高められるのか分からない。また、どのプラットフォームで出すべきなのか悩ましい、ということもあるかと思います。コンソール向けがいいのか、モバイル向けがいいのか、コンソール向けならどのプラットフォームがいいのか、いろいろ悩むところがあるかと思います。では一度、動作デモを見てみたいと思います。

下田：
これはサードパーソンビューのデモですが、これは「UDK(Unreal Development Kit)」で出来ています。UDKでどれくらいの時間がかかったかというと、実は一日かかっていません。数時間で出来ています。UDKを使うと、こうしたものを簡単に作ることができます。

下のムービーは、UDKを使ってゲーム制作を行っているところを視覚的に見ることができるプロモーション映像です。実際の会場で行われたデモとは異なるムービーですが、UDKの画面の動きやマテリアルを配置する様子など、会場で紹介されたデモに近い内容となっています。

Inside UDK: Fall 2011 - YouTube


下田：
「なぜ今アンリアル・エンジンなのか? 導入のメリット」について説明します。大規模プロジェクトにアンリアル・エンジンが向いているという話を聞いたことがあるかも知れません。確かにアンリアル・エンジンにとって大規模プロジェクトは得意な分野です。

例えば大規模プロジェクトを実現するための制作パイプラインやコンテンツ管理が充実しています。さらに、人数が増えてもライセンス料が変わらないという特徴もあります。制作環境やツールが充実しているので、これらを利用することで、効率的にゲームを制作することが可能になります。また、制作の初期にあたるプロトタイプ制作から、制作の最終段階にあたるDVDやブルーレイのデータにする段階などの制作工程に至るまで、トータルにサポートしています。これらを利用することで、開発者はクリエイティブな部分に注力することが可能になります。リードプログラマーがクリエイティブに参加することも可能になります。

下田：
次に、「なぜ今アンリアル・エンジンなのか? プロトタイピング」について。まずは少人数でプロトタイピングをすることをお勧めします。いきなり最初から大人数で開発を行うと、やはりリスクが高くなります。これについては、後ほど詳しく説明します。そして、アンリアル・エンジンを使っていシリーズ化を進めることで、さらに制作効率が上がります。こうした形での開発が行われているタイトルとして、「ギアーズ・オブ・ウォー」シリーズ、「マス・エフェクト」シリーズ、「バイオショック」シリーズ、「バットマン」シリーズなどが挙げられます。これらは、アンリアル・エンジンを使って複数のシリーズ作ることで、効率的な開発を行っています。

下田：
また、マルチプラットフォームに対応しているということも挙げられます。例えばプラットフォームを変えたい、というような場合にも、アンリアル・エンジンの場合なら、ビルドのターゲットを変えるだけで複数のプラットフォームに変えることが可能です。コンソールだけではなく「PS Vita」やiOS、Androidなど、マルチな展開をして、世界で販売することもできるようになっています。

今までコンソールのゲームを制作していた人にとっては、少しハードルのあるところとして、iOSやAndroidではObjective-Cを使わなくてはいけなかったり、Javaを使わなくてはいけなかったりします。アンリアル・エンジンの場合、Objective-CやJavaに関しては、気にする必要がありません。エンジン側でラッピングしているので、ゲームの制作自体にはC++や、アンリアル・エンジンの中のスクリプト言語「アンリアル・スプリクト」を使うことで、ゲームを全部作ってしまうことが可能です。

下田：
次に「なぜ、今アンリアル・エンジンなのか。ライセンス料」に関して。実はライセンス料を抑えることもできるようになっています。アンリアル・エンジンは、無償で評価使用することが可能です。無償でまずプロトタイプを作ることができます。また、評価使用として無償でプロトタイプを制作する期間であっても、サポートを無償で行っています。プロトタイプが形になるまで、ライセンス料は一切発生せず、さらにサポートも受けながら、ゲームを作ることが可能です。ただしプロトタイプが完成して、公式に発表したいという場合には、発表前に正式ライセンスを発行する必要があります。

作ってはみたものの、売り上げが伸びなかった場合のリスクというものも考えられます。ライセンス料が高いという話などもウワサで流れていることもあり、「ライセンス料を払ってしまって、売れなかった場合はどうするのか」というのは気になる点だと思います。しかし実は、初期のライセンス料を抑えて、売り上げに応じたロイヤリティーライセンスで支払う形の、ライセンスプログラムもあります。いきなり始めから売れるか売れないか分からないものにライセンス料を払うのではなく、初期のライセンス料は抑えて、あとは売れる数に応じてロイヤリティーで支払うという形も可能です。こうしたことを検討していただければ、十分リーズナブルに開発を行うことができると考えております。

下田：
では、先ほどのデモの制作過程をお見せします。アンリアル・エンジンは、新しくステージを制作しようすると、テンプレートが出るようになっています。例えば、午後のライティング、日中のライティング、朝のライティング、夜のライティング、まったく何もない状態、これらが簡単にできるようになっています。ナイトライティングを開いてみます。これを開くと各種設定が表示されるので、マップ設定を行ってみます。

下田：
歩いてみたいと思います。歩いてみると、このような形ですね。FPSというか、自分視点でただ歩けるだけのパターンになっています。テンプレートから開くだけで、歩き回ることが簡単にできるようになっています。

下田：
これだとゲームらしくないので、このステージのレベルに対して、いろいろなゲームのタイプを指定できるようになっています。ゲームタイプには、例えばデフォルトのゲームのタイプ、「UTgame」があります。UTgameは、アンリアル・トーナメントというゲームのタイプです。ここでUTgameを指定すると、アンリアル・トーナメントのプレイヤーの動きになります。銃を持って動き、撃つことができるようになります。このようにゲームのタイプを簡単に振り出せるようになっています。

下田：
今はFPSのアンリアル・トーナメントというゲームのタイプにしましたが、TPSのようなものも簡単に作ることができます。アンリアル・トーナメントやUDK向けに「カメラの行動スクリプト」を指定する機能があります。このカメラスクリプト自体で約30メソッドくらいあるのですが、その一部のメソッド、アンリアル・スクリプトでは、一部のメソッドを書き換えるだけでカメラの動きを変えることができます。

ソースや細かいところについては、今のセッションでは間に合わないので、実際に一部のメソッドだけを変えて、UTgameのTPSというタイトルで作ってみました。これを割り当てると、このような感じでサードパーソンビューで歩き回れるようなものがすぐにできます。サードパーソンビューのカメラにするためのドキュメントは、UDKのサイトや、ライセンシー向けのUDFというサイトに置かれていて、カメラの変更部分に関しては、数十行を追加するだけで、このようなTPS形式に変えることが可能です。

下田：
これだけだとまだゲームらしくないので、敵を出してみたいと思います。先ほどの画面と大きく変わっていませんが、奥に行くと、マーカーがひとつだけ飛んでいます。ここで例えばCtrl+Kを押すと、「Unreal Kismet」というものが立ち上がります。今まではプログラマーがゲームを構築する場合、スクリプトや、C++、C#など、プログラミング言語でゲームの流れやロジックを組んできました。アンリアル・エンジンの場合は、こういったビジュアルなモノグラムを使って、ゲームのロジックを組むことできます。

下田：
この場合、レベルが読み込まれた時、「Actor Factory」という部分で、中で演技するものを設定して作り出すという仕組みをしています。これで動かしてみると、敵が出てきます。中にマーカーを置いて、この「Kismet」で、自由にロジックを組みます。それだけで敵が動き始めたりします。

下田：
まだ寂しいので、敵を増やしてみます。マーカーを3つに増やしました。増やしたマーカーから、敵を作って下さいという指示に変えます。これで敵が増えます。人数をもっと増やすこともできます。このように、簡単に敵を出して、増やして、戦うことができるようになっています。

下田：
平らな地面なので、これをもう少しリッチな表現にしたいと思います。マテリアルをドラッグ&ドロップするだけで、簡単に変えることができます。

下田：
アーティストが細かく作り込んだモデルを貼り付けることも簡単にできます。これで作っておいたドラッカーを配置したり、マテリアルを複製したりできます。

下田：
岩のようなものを一緒に配置したり、影のボタンを押して一緒に配置したりできます。

下田：
このように未来風にすることも可能です。

下田：
アンリアル・エンジンでは、このようなゲームを簡単に作り出すことができます。こうしたゲームを作っていく中で、別のプラットフォームにすることも簡単にできます。このデータをiPhoneに転送したものがあります。こちらと同じ画面になりました。このように、すぐにプラットフォームを変えることができます。

下田：
これらのドキュメントなどは、UDKのサイトなどに置いてあります。カメラを変えたり、敵をAIとして動かしたり、サードパーソンビューにしたりということが簡単にできるようになっています。

下田：
ここまでで、実際にアンリアル・スクリプトを使って、TPSのようなものを作ったり、Kismetを使ってGUIでロジックを組んだり、簡単にプロトタイプが制作する過程を見てきました。

下田：
今作ったようなものを、本番で作り直さなければいけないのか、という疑問が出てきますが、実はそんなことはありません。アンリアル・スクリプトで作ったプロトタイプのコードも、正式ライセンスの場合は、スクリプトのメソッド単位で簡単にC++化することができるようになっています。プロトタイプで作ったコードをそのまま利用しつつ、速度を上げたいところだけ、パフォーマンスを上げるためにC++化して、本制作に入ることができます。

さらに、先ほど地面が平らなスペースでやりましたが、そのような下地も、本番でそのまま生かすことができます。先ほど、マテリアルをドラッグ&ドロップで張っていましたが、単純に地面にマテリアルを張るだけで、本番で使えるレベルの地面を作ることができます。

下田：
本番になると、さらにクオリティを高めていく必要があるかと思います。クオリティを高めていくためのアプローチとして、レベルエディター上ではプロトタイプにマテリアルを張って、その上にさらにライティングを行います。ただ置いただけだと見栄えが悪くなってしまいますから、いろいろなライティングを行います。

ライティングに伴って、シャドーイングも使います。それらを利用して、「Grobal Illumination計算」、ライトの照り返しなどの計算をしっかりして、リアルな表現をすることがアンリアル・エンジンのアンリアル・エディター上で行うことができます。そしてそれを焼き付けることができます。

このほかにも、アンリアル・エンジンでは、さまざまなツール群と制作環境を提供しています。

下田：
ゲームプレイのプロファイリングを行う「GameProfiler」というものがあります。ゲームの進行に従って、どのくらいパフォーマンスが落ちたのかを見たり、ステージ上にいたキャラクターたちの処理時間、物理時間が何秒だったのか、コリジョンのチェックなどを簡単に見ることができます。このようなものを利用することで、パフォーマンスを上げることもできます。

エディターの中でシェーダーの複雑度なども、簡単に見ることができます。これだけではなく、様々なプロトタイピング機能や、スタッツ機能と呼ばれるものがあります。例えばステージ上にあるハッシュ、オブジェクトたち、モデルたちに、リソースが何キロくらいかかっているかなどを見ることができます。

例えば、モバイル版であればやはり容量が気になります。コネクターテクスチャースタッツでは、このテクスチャが、このステージ上でテストプレイをしたときに何秒ぐらい見られていたかを確認し、一度も画面上に現れていないのに解像度が高いというような部分をリストアップして、モバイル向けにブラッシュアップしたりすることができます。

下田：
また、クオリティ向上のためのアプローチのひとつとして、プロトタイプを作りながら、アーティストに高クオリティのメッシュやモデルを作ってもらい、それを共有して配置することで、ステージも簡単に作れるようになっています。見栄えのクオリティは高く保ちつつ、制作工数は抑制するということが可能になります。

下田：
次に、「アンリアル・エンジンを導入する際のリスク」に関して。アンリアル・エンジンでプロトタイピングする場合、プロトタイピング自体にネガティブな要素やリスクは特にありません。ただし、大人数で始めるのはリスクが高いかと思います。アンリアル・エンジンが大人数での開発に向いていると言っても、いきなり大人数で始めてしまって、ちゃぶ台返しのように仕様を大きく変える必要が出たり、最悪の場合として、プロジェクトがキャンセルになってしまったりすることを考えると、大人数で始めるとダメージが極めて大きなものになってしまいます。

まずは少人数でプロトタイピングを行い、そしてパイプライン検証や構築をするという形をお勧めしています。もしやり直すのであれば、なるべく早い段階で判断できたほうがいい。そういう点ではアンリアル・エンジンなどを使って、プロトタイピングを迅速に行うことが、大きなメリットになると思います。

下田：
アンリアル・エンジンを実際に導入すること自体に関して言えば、「使いこなすのが大変ではないのか」という疑問があると思います。これについては、エピック・ゲームズで講習会も実施しています。導入する開発会社さんに伺って、開発者の皆さんの前で、「こういう風に作っていただくと早くプロトタイプができます」とか、「こういう風に作っていただくとさまざまなタイプのゲームが作りやすいです」とか、「レベルを制作するにあたってこのようなエディットキットがあります」というような説明を行います。最初は「大変かも」と思うかも知れませんが、サポートでその負担はかなり軽減できるものと考えています。

下田：
「エンジンの根幹に関わるような技術レベルが人や会社に残らないのではないか」という心配もあるかと思います。これは、「会社にとって何が大事か」ということになるかと思います。会社の目的は技術を溜めることが目的でしょうか？ 面白いゲームをどんどん生み出して、ユーザーに喜んでもらって、そこから利益を得るということが目的なのだとしたら、社内エンジンにこだわる必要もそれほど無いのではと思います。

本質的には、ゲーム制作のノウハウや、ゲームも面白さを構築することへのノウハウというものが重要なのかも知れません。そうであるなら、アンリアル・エンジンを使うことのメリットも十分あると思います。アンリアル・エンジンを使えば、ゲームの面白さを簡単に試すことができます。まずは少人数で試してみて、ゲームの面白さがこれで簡単に作れるというところを見てもらえればと思います。それでもやはり難しいというところがあれば、講習会も行います。

下田：
コンソールやモバイルでネットワーク対応ゲームを作りたいという要望もあると思います。ネットワークゲームに関しては、スタンドアローンのゲームには無いようなリスクも存在しています。例えば、ネットワークゲームのためには、様々な同期機能が必要になります。ステージへ出ているキャラクターたちを、複数のPC、複数のコンソール、あるいは複数のモバイルで、同期させることが必要になります。

またネットワークゲームの場合、たびたび接続が切れてしまったり、エラーが起こったり、パケットが相手のところに届くまでに遅延が起こったりします。このようなところを考慮した上で、プロトタイプをフルスクラッチで作る場合、どのくらいかかるでしょうか？

アンリアル・エンジンの場合はプレイヤー付近の、同期させる機能やパケットのリンク機能などが、エンジン自体に入っているし、先ほどのアンリアル・スクリプトにも備わっています。アンリアル・スクリプトには、同期のための機能、キャラクターを他のところで復元するための機能なども備わっています。

これをフルスクラッチして作ろうとすると数ヶ月、もしくは一年を超えるレベルでプロトタイプ制作に時間がかかってしまう可能性があります。アンリアル・エンジンには同期に関する機能が入ってはいるのですが、それでも同期のテストは必須になります。もともと同期の機能は入っているのですが、初めにそれを考慮をしないでゲームを作り始めてしまうと、あとからネットワーク対応にするのはかなり大変になります。同期のテストをしながら、作り上げていくことが必要になります。

また、MOやSNSとの連携の部分も制作を始めています。例えばFacebookとの連動機能もiOS版で実装を始めています。

下田：
まとめると、「導入のコストが抑えられる」、「高速なラビットプロトタイピングに使える」、そして「そのまま本制作にも移行できる」ということになります。そして「実績のあるハイエンド環境」があります。「ギアーズ・オブ・ウォー」や「マス・エフェクト」などが、実際にアンリアル・エンジンを使って、複数のバージョン、複数のシリーズを作ることに成功しています。また「マルチプラットフォームに対応」しています。最近ではiOSやAndroid、PS Vitaなど、対応すべきプラットフォームも増えて来ましたが、これらにも迅速に対応していきます。

◆質疑応答

Q：
プロファイラーがあるということでしたが、ターゲットのプラットフォームでプロファイルが取れるということでしょうか？

下田：
スクリプトに関しては、PC上で動かすことになるかと思います。PC上で動くものを作っていただければ、Xbox 360や、さまざまなプラットフォームで動きますので、スクリプトをPCの方で見ていただいて、各プラットフォームのプロファイラーと併用していただきながら使っていただければと思います。

Q：
AndroidやiOSでプロファイルを取れるというわけではない、ということですね。

下田：
そうですね。今、対応を始めているものとしては、iOSのプロファイル機能を一部作り始めています。同じようなものが動き始めていまして、Androidはまだもう少しかかるかと思います。ただ、Androidもやりたくないわけではなく、まずはiOSの方から今、始めていきたいと思っております。

Q：
では、できることを楽しみにしております。

下田：
ありがとうございます。

Q：
大規模なプロジェクトになると、1つのステージマップの制作を行う場合、背景だけでも複数人が作業をすることになると思います。アンリアルにおいては、作ったスタックイメージをマップ上に配置したり、ライティングをしたりする時、そのときの作業の方向としてレベルデータをいじる人というのは基本的に1人なのでしょうか？

下田：
1人でももちろん可能なのですがアンリアル・エンジンの場合、レベルストリーミングという機能がありまして、もともとは大きなステージを作る際に、分割していって、どんどん同じプレイの流れで読み替えていくようなシステムです。レベルストリーミングは場所で切れていなくてはいけないわけではなく、同じ場所に対して複数のレベルを置くということが可能です。それを使っていただいて、例えば見栄え系のレベルと、ゲームのロジック系のレベルというものを複数重ねていただいて、ゲーム寄りのレベルデザイナーさんはロジックの方を使っていただいて、アートよりのレベルデザイナーさんはアート寄りのレベルを使っていただくなどの作業分けは可能です。

Q：
例えばスタティックミッションを配置する人と、ライティングをする人を別々にして、でも作業を同時にするといったようなことはできたりするのでしょうか？

下田：
一応、ライトは別のところに置いたものも反映できたかと思いますが、配置と同時にやはりライトも設定もしたいかと思いますので、同じ人がやったほうが扱いやすいかとは思います。

Q：
今回のセッションの表題が「アンリアル・エンジンで始めて、リスクを最小限に進める為の心得」ということで、このリスクという部分について質問します。「アンリアル・エンジンを使うことで克服できるリスク」という捉え方と、「アンリアル・エンジンを使うことで発生するリスク」という二種類の捉え方があるかと思います。使うことで発生するリスクとして、いきなり大人数で始めてしまうとリスキーであるというお話しでしたが、他にもアンリアル・エンジンを使うことで発生する失敗事例などが、もしあるようでしたらお聞かせ下さい。

下田：
過去に一度、エピック・ゲームズ・ジャパンができる前に、いくつかの日本の大きなゲーム開発会社さんにアンリアル・エンジンをご利用いただいて、制作まではこぎ着けたものの、大変だったという事例がいくつかあります。

アンリアル・エンジンの標準的な制作スタイルは、先ほどのレベルを作っていく流れや、コンテンツを共有してそれを配置するという作り方です。会社さんにもよりますが、今までのゲーム会社さんの場合、ステージデータは1つの大きなステージを作って、それをインポートしてゲームで使うというスタイルがあると思います。そういうスタイルをとった場合、ちょっとアンリアルのメリットは出しにくいです。

Q：
今後のロードマップ的な、プラットフォームなどが追加されるようなお話しがありましたら聞かせてください。

下田：
まだアンリアルが対応していないようなプラットフォームで、アンリアルが動く可能性のあるプラットフォームというものについては、できれば対応していきたいと考えています。今、この場では申し上げにくいのですが、アンリアル・テクノロジーというサイトをご覧いただきますと、実は今まで対応していなかったはずのプラットフォームの名前が挙がっていたりします。そういうことはぜひ進めていきたいと思っております。

Q：
アンリアル・エンジンを使用するにあたって、一番苦手なゲームのジャンルとか、こういったゲームのスタイルには合わないというような「これをやると失敗しやすい」というようなことがありましたら、教えてください。

下田：
失敗しやすいジャンルですか……。

Q：
FPSとかTPSというのは非常に多くのサンプルを見かけますが、RPGスタイルとか音ゲーとか、そういったスタイルは見かけたりすることはないので、それは相性の問題があるのかな、と。

下田：
そうですね。実際にRPGに関しましてはエピック・ゲームズ・ジャパンができる前に、国内の大きなメーカーさん、2社が日本向けのRPGタイトルを二つを出しています。音ゲーに関しても、すでに韓国などでダンスゲームがあったり、ブラック・アイド・ピーズというグループのダンスゲーム的なものが発表されていたりします。苦手というものは特に無いかと思います。

ただ、追加のコードや、そのほか必要になるものに関して言えば、普通の通信対戦のFPS的な対戦ゲームは簡単にできるのですが、MMOのようなものに対応するとなりますと、もう少しMMO的なサーバーがあって、クライアントがあって、その通信ログをキャラクターたちに与えたりとか、通信したりとか、そういうものを書いていただく必要があるかと思います。ただそれができないわけではなく、特に韓国とかですと、ブレード&ソウルやテラのようなMMOタイプのアクションRPGが出てきたりしていますので、特に不得意な分野があるとは考えていません。

Q：
3点ほどお聞きしたいことがあります。有償版と無償版の差異はあるのでしょうか。あと、アセットは別売のものがあるのでしょうか？ あとから追加して購入するアセットがあるのかどうかということですね。あと、スマートフォン版に関しまして、恐らく出力はプロジェクト単位で出力されて、ビルドは別環境になるかと思うのですが、例えばiOS版の場合、最終的なフィルターはMacのXcode上でするのか、AndroidであればEclipseを用意する必要があるのか、そのあたりについてお聞かせください。

下田：
無償版のものと有償版のもののライセンスでの中身の違いについてですが、無償版のUDKと呼ばれているものに関しましては、C++のコードを使っていただくことができません。C++のコードを使って開発をする場合は有償版を使っていただく必要があります。有償版の方はエンジンのコード、エディターのコード自体もC++、もしくはアンリアル・スクリプト使ったものを既に公開させていただいています。

アセットに関しましてはUDKの場合、キャラクターモデル以外のものは使っていただくことが可能です。有償版のものは基本的にはアセットはイチから作っていただくようにお願いしております。

マルチプラットフォームの対応に関しましては、iOSの場合ですと、実はiOSをサーバーのように使っていただいて、一部、クライアントソフトを入れていただくのですが、それを入れていただくと、先ほど見ていただいたエディッターの画面などから、Visual Studioのビルドのターゲット、ソリューションがいっぱい出ているような画面のところから、ビルドをしていただきますと、その中で通信をしてMac側にコンパイルさせて、その結果をまた持ってくるということが可能です。ですので、特にデバックをXcodeの上でされないということであれば、Visual Studioですべて完結します。あとサーバーはAppleで完結できます。

Q：
先ほどお聞かせいただいた事例で、非常に大きなマップを読み込んで作ろうとしたときに苦労されたというお話しでした。もともとFPS、TPSベースだと思うので、あらかじめ非常に広大なマップの上でわーっと遊ぶようなゲームを作ろうとした時、考慮すべき事などありますか？

下田：
アンリアル・トーナメントというFPSタイプのレベルの場合ですと、1つのステージで、1つのレベルでできています。ギアーズ・オブ・ウォーのようなものの場合ですと、レベルがある程度分割されていまして、分散されたレベルをどのよう処理していくかということが、初期のアンリアル・エンジンの場合はあまり得意ではなかったので、その分割機能、ピアリスト機能などが充実してきました。MMOを作るような事例もありますので、それをサポートするためのものとしまして、広大な地面を作るためのランドスケープという機能があります。

Q：
ありがとうございました。