ringoが書いたよ

きのう客先から帰るタクシーの中であるスタッフと話したこと。

彼は建築業界出身という、CEではめずらしい経歴をもつ。
住宅や学校などを手がけてきた。

彼は「建築のノウハウがソフトウェア開発にも活かせると思う」と言った。

ソフトウェア開発に建築のメタファーが通用する・しないという話は、
パタン・ランゲージのようなデザインの話から、
人月の神話のようなマネジメントの話までいろいろとよく出てくる。

最も重要な違いは何だろう？

建築に使う道具や資材、土地などの性能は、3年で4倍になったりしない。
彼は、もし鉄骨の耐震能力や防錆能力がこの速さで変化するなら、
確かに、いまの建築の技法は見直す必要があるという。
これは大きな違いだ。
実際、大規模なMMORPGの設計で、4年後のサーバ性能を見越して見積をするときは、
いまはまだ存在しないマシンを前提としてコスト計算をしていく。

もうひとつ違うのは、建築は地理的な場所に縛られているので、
3ヶ月ごとに2倍づつ利用者が増えたり、増えなかったりすることは稀だ、ということだ。
特にオンラインサービスの場合は、ニュースサイトにリンクが張られただけで
突然アクセスが数十倍になったりといったことが、想定できないタイミングで発生する。

「インターフェイスデザインは投機である」
という話を聞いたときには、この話を思い出した。
ソフトウェア開発は、建築よりも、上記のような点が異なるので、
きっと投機的側面が強いのだろう。

建築業界のマネジメント技法では対応しきれない部分もかなりあるに違いない。

だからどうしたら良いということはないけど。

去る金曜日（7月4日）にTomo's hotlineの西谷氏の コーディネートによる「オフィスツアー」を開催しました。

西谷氏のブログ
http://toremoro.tea-nifty.com/

オフィスツアーの案内
http://toremoro.tea-nifty.com/tomos_hotline/2008/06/74_ecad.html

ありがとうございました。＞参加された皆様

今回は総勢20名を招き、LiquidSyncのデモを携帯ゲー ム機での音声通信とPCでの映像配信を用いてデモをしました。通信業界やハードウェア業界、SI業界や研究者などさまざまな仕事をされている方から、なんと1時間にわたる質問責めを受けてかなり疲れました。。

1時間以上にわたり、的確かつ鋭い質問を受けたのですが、基本的には「ゲームの要求にあわせた割り切り」についての答えが中心となりました。答えにはほぼ納得いただけた様子でした。

質疑応答については現在、まとめ作業の最中です。まとめができ次第、ここにupしたいと思います。

今後1年～2年以内には、LiquidSyncが実績化しはじめます。「軽くて遅延の少ない Application Layer MulticastならLiquidSync」と呼ばれる状態を目指して改良を続けたいと思います。
LiquidSyncを試用してみたいという方は説明に伺いますので、ぜひご連絡ください。

(追記)
西谷氏による、キャリアグレードNAT仕様のインターネットドラフトが公開されています。
http://toremoro.tea-nifty.com/tomos_hotline/2008/07/nat_78a2.html

キャリアグレードNATは、ISPのネットワーク全体を1個のNATの下に入れるためのシステムで、既存のUPnPが使えなくなるほか、グローバルIPアドレスをもつ端末の数に大幅な減少が起こるかもしれないなど、P2Pシステム全般に影響がある重要な変化です。今後も刮目して見なければなりません。

（さらに追記）
参加された皆様の感想。ありがとうございました！

• http://www16.atwiki.jp/tokoroten/pages/856.html
• http://www.noritsuna.com/archives/2008/07/post_114.html
• http://d.hatena.ne.jp/effy/20080705/1215197010

2002年ごろ、すでに廃刊になっている「Linux Japan」
という雑誌において「インサイド・オンラインゲーム」の連載をしていた。
連載中に廃刊になってしまったのだが、
このたび出版社の株式会社五橋研究所の了解を得ることができたので、
ご厚意に感謝し、ここで掲載したい。

連載は第4回で中断しているが、第5回以降に予定していた話題としては、
ログ解析やシミュレータを使ってゲーム内容をできる限り自動生成したり
ユーザーが作れるようにすることによってゲームの延命をはかることや、
そのために必要な計算機システムのあり方についての考察などがあった。
ちょうどgumonjiの開発を進めていたころである。
現在であれば「アイテム課金」や「pay per minutes」、
Flash、ゲーム機におけるオンラインの話題などにも広がるかもしれない。

この記事への反響の中で最も印象的だったのは、検索エンジンのシステム全体を
開発しているエンジニアから、「MMOGのシステムは、検索エンジンとほとんど一緒だ。
SPAMを効果的に排除する仕組みを突き詰めたら検索エンジンと似たというのは、
とても面白いことだ。」という意見だった。
実際に2002年から6年が経過しているが、内容のほとんどはまだ陳腐化していない。
私は以前に増してサーバ型のオンラインゲーム開発に将来性を置いているし、
さまざまなゲームの開発に関わる中で、UGC(User-Generated Contents)
を追求するならばますますサーバ型が重要になってくるという確信を得ている。

今後、可能であれば第5回以降の記事を続けてみたいと思う。

PDF版はこちらからダウンロード。

はじめに

UNIX、そしてオープンソースソフトウェアが深く関わっている開発分野の 1つに、オンラインゲームシステム開発がある。 これらのシステムの開発/運営は、オンラインゲームというサービス業の最も重要な部分なのだが、 特にゲームというサービスは、人間の生活にとって必需品でないという事が、 オンラインゲームシステム開発に、 通常のシステム開発と異なった性格を帯びさせている。 つまり、すべての開発目標は、 「ゲームの面白さ」につながっていなければならないのである。 信頼性が高いこと、レスポンスが良いこと、メンテナンス性が良いこと、 使いやすい事、セキュリティが高いこと……。 これらはすべて、ゲームの面白さを実現するためには必要な項目なのだが、 それらだけを要件通り満たしても、ゲームは面白くならない。 そして、面白くないゲームは売れないのである。

オンラインゲームシステム開発の醍醐味は、 これら多様な変数を、ゲームの面白さという中核にうまく結びつける部分である。 この仕事を担当する者には、各種技術に精通しているばかりでなく、 ゲームというコンテンツの本質に対する確かな眼が要求されている。 特に、商用ゲームコンテンツの開発には、 通常のシステム開発とはかなり異なる特殊なノウハウやセンスが要求されている上、 「生活に必需でない」という理由で予算と時間の縛りも厳しい。 明らかに、全体の中でも難度の高いプロジェクトであると認識すべきである。

対象読者

本連載では、実用十分なネットワーク技術を修得したが、 数年後に自分がただの「IT作業員」 になり下がってしまうことを危惧しているエンジニアや、 もっと面白そうな分野を探しているエンジニアなどを対象に、 筆者のオンラインゲーム開発を通して得た経験や未解決の問題などを紹介し、 オンラインゲームシステム開発の面白さを伝えていこうと思う。 そして、 本記事がオンラインゲームの市場を熱くするようなクリエイター を増やす一助となるならば、これ以上の喜びはない。 (筆者は実は、この記事は、 オンラインゲームメーカーの新人教育マニュアルになるのではないか？ などと思っているのだが。)

コンピュータゲームの開発は本来日本が得意とする分野であったのだが、 金融機関の課金システムや常時接続回線などインフラ整備の遅れによって、 通信ゲーム分野では外国勢に押されっぱなしの状況となっている。 しかし、今後数年で急速にインフラ整備が進み、 日本でもネットワークを使う遊びは爆発的に普及しそうである。 今後数年間は、間違いなく日本におけるオンラインゲームの立ちあがり時期となる。 その時期にいろいろなことを試してみるのも、 UNIX エンジニアとしては面白いことだと思うが、いかがだろうか。

筆者の紹介

現在筆者はコミュニティーエンジン株式会社の代表として、 株式会社エニックス（現株式会社スクウェア・エニックス）の援助を得てオンラインゲーム開発の中でも 技術面のサポート/研究を専門に行なっている。 連載の中で出てくる固有名詞や数値などは、 (株)エニックスの了解を得て公開していることを明記しておく。 記事末のResource[1]、[2]、[3]に、関連WebページのURLを掲載する。

MPG開発の基本事項

インターネットを使ったゲーム開発プロジェクトには、 特有の考えかたや用語が多数登場する。 本連載でも、説明を簡潔にするために、これらの用語を多用することになるが、 これらの語を初めて目にする読者も多いだろう。 そこで、まず最初に専門用語の解説を一通り行い、 次に今後の連載で議論の対象となっていく 「スター型マルチプレーヤーゲーム」の紹介をする。 文中では、「コネクション」、「クライアント」、「サーバ」、 「IPアドレス」などといった TCP/IP の基本用語が頻出するが、 これらに関する説明はすでに理解されているものとして、今回は省略する。

MPG (マルチプレーヤーゲーム) とは?

現在、ネットワークを使ったゲームを表す用語として、 「オンライン・ゲーム」、「ネットワーク・ゲーム」の2つの用語が一般に 使われている。しかし、この2つの用語は、 商業的な理由から不自然なほど狭い意味で使われているので誤解を招きやすい。 従って、本連載では誤解を招かないように、 そのどちらでもない「マルチプレーヤー・ゲーム」という用語を定義し、使用する。

MPG (Multi Player Game) とは、 複数のゲームプレーヤーが同じゲームプレー空間に参加してゲームプレーを楽しめる ようなコンピュータゲームの事である。 この意味を広く捉えるならば、ポケモンも、「どこいつ」（どこでもいっしょ）も、 MPG であると言える。本連載では、その中でも特にインターネットを使用した MPG に限定するために、「IMPG(インターネットMPG)」という用語を使うことにする。

IMPGの品質保証

商用アプリケーションとして IMPG を運用する場合には、 サービスの品質をどう保証するかがテーマとなる。 サービスの品質には、クラッキング行為に対する対策や、 性能の保証、spam を防ぐシステム、同時接続ユーザー数など運用情報の管理、 個人情報などを守るパスワードの壁などなど、様々な項目がある。

IMPG の品質保証に関して最も大切なことは、 IMPG サービスを提供するためのコンピュータネットワークをうまく設計し、 品質保証ポリシーに沿って確実に運用していく事である。 品質保証は最終的にはゲームプレー空間のセキュリティをどう確保し、 どうメンテナンスするかに帰着される。 次節から、ゲームプレー空間とは何か、 そしてそのセキュリティとメンテナンスが、 IMPG を形成するコンピュータネットワークの基本構造と どう関わっているのかを説明していく。

ゲームプレー空間

コンピュータゲームに限らず、ゲームというものには、 かならず1セットのルール(ルールブック)と、 そのルールに基づいて厳正に管理されているゲームの状態がある。 ゲームの状態とは、例えば将棋の場合は、すべての駒の位置と、 2人の参加者の座っている位置、何手目か、などといった情報が含まれる。 サッカーの場合はもっと多くの情報、 例えば全選手とボールの位置、移動方向、能力、グラウンドの状態などがある。 ゲーム自体がアナログ的な情報によって左右されるため、 実際にははるかに多くの情報を管理する必要があるだろう。

コンピュータ上でこれらのゲームを実現する場合は、 ゲームプレーに必要な情報は、あるビット列ですべて表す必要があり、 これらのビット列をどのように操作するかを規定するのが ゲームのルールであると言える。 現在のコンピュータは、以上のような仕事をうまく処理できるので、 コンピュータを使ってゲームを管理するのは、非常にうまくいく。 このように、コンピュータによって管理されている ゲームの状態やルールに関するすべての情報をひっくるめて、 「ゲームプレー空間」と呼ぶ。 次の図は、サッカーというMPGにおける、ゲームプレー空間のイメージ図である。 この図に含まれるすべての変数は、 サッカーをコンピュータゲームとして実装するならば、 プログラム上でメモリのある領域に格納されたビット列として管理される。

+-- ゲームプレー空間 ------------------------------------------------+
|                                                                    |
|  +--- グラウンドの状態 --+  +-- プレーヤーの状態(22人+補欠分) -+   |
|  | 芝の状態              |  | 位置  体力    走る速さ           |   |
|  | 水たまりの位置        |  | 怪我  キック力                   |   |
|  | 客が投げた空き缶の位置|  | 好きな選手                       |   |
|  | ....                  |  | ....                             |   |
|  +-----------------------+  +----------------------------------+   |
|                                                                    |
|  +-- ボールの状態 --+  +-- 試合の状態---+                          |
|  | 移動方向         |  | あと何分あるか |                          |
|  | 位置  ....       |  | 何対何か       |                          |
|  +------------------+  | チーム名 ...   |                          |
|                        +----------------+                          |
+--------------------------------------------------------------------+

さて、ゲームをプレーするとは、この状態の一部をプレーヤーが見て(認知)、 それに対する意思決定を実行し、 ゲームの状態を自分の望む方向へ進めようとすること(操作)である。 つまり、自動車教習所で習ったような

    +-------+    +-----+    +------+
 +→|  認知 | → |判断 | → | 操作 | --+
 |  +-------+    +-----+    +------+   |
 +-------------------------------------+

というループを続ける事が、ゲームをプレーするという事なのである。 これを試しに ゲームプレー・ループと名付けてみる。 コンピュータゲームにおいては、 ゲームプレー・ループのうち認知と操作の段階において、 コンピュータ による最大限の支援が行なわれる。 以下に、将棋ゲームの場合を簡略化して、 ゲームプレー・ループを、図に表してみた。

状態Aを表示(認知)

プレーヤーが考える(判断)

「前に進めば相手の歩を取れるので、 ここは歩を1コマすすめよう。」

実際に1歩すすめる(操作)

状態Bを表示(認知)

IMPG とは、以上のような手順を、 インターネットを使って複数のプレーヤーが同期的、 あるいは非同期的に行なうことで、 よりリアルで意外性と駆け引きに満ちたゲームプレー を作りだそうとする試みに他ならない。

ゲームとは本来 MPG的なものだったのだが、 実用上/商業上の制限からコンピュータゲームにおいては、 シングルプレーゲームに後退してしまっていたという事なのである。 今後すべてのゲームが面白さのために MPG(IMPG) 化していき、 孤高の芸術性をつきつめていくタイプのゲームだけが、 シングルプレーゲームとして残っていく構図となるだろう。

ゲームプレー空間のセキュリティ

すべての MPG には、ゲームプレー空間を正常に保つためのシステムが不可欠である。 これをゲームのセキュリティといい、 ゲームのセキュリティをどういう方法で確保するのかを決めることは、 ゲームデザインにおいてはルールを決めることと同じぐらい大切なことである。 セキュリティを欠くゲームプレー空間が根本的に面白さを欠いたものになるのは、 将棋板を途中でひっくり返された経験をもつ人ならば直観的に理解できるだろう (麻雀のイカサマやサッカーのフーリガンも面白いが、 それは当のゲームの面白さが保たれて初めて存在する面白さである)。

ゲームのセキュリティを確保するために、 多くのスポーツ競技では最も低コストな方法としてレフェリーが存在するか、 「フェアプレーの精神(自分の中のレフェリー)」が要求される。 特に、サッカーなど1つのゲームプレー空間に参加する人数が多ければ多いほど、 重要な事象の起こった順番や、ルール外の行為が管理されていない状態になりやすく、 そうなるとプレーヤーの権利主張が錯綜してしまう。

レフェリーはこのようなゲームの混乱を未然に防ぐために必要で、 ゲーム内の「spam」行為を厳正に排除できる能力を持ちあわせていなければならない。 たとえば、サッカーは 22 人同時プレーの MPG だが、 レフェリーは規定に違反する行為をした選手を、 レッドカードを用いて排除することが可能である。 もしレフェリーがいなかったら、試合はすぐに混沌とした状態になるだろう。 たとえば、サッカーでいつのまにか片方のチームが12人になっていたら、 誰が後から来たのか、そして誰が抜けるべきなのかを、誰も説明できない。

以上述べてきたことは、インターネットを使う IMPG でも同様である。インターネットを使う場合は、 インターネットの匿名性によってルール違反な行為が横行しやすく、 その影響も広範に伝播しやすいため、 人間による審判やフェアプレー精神に依存するよりも、 もっとシンプルで強力で自動的な機構が求められるのだ。 インターネットにおいては、 すべてのゲームプレーヤーが悪意を持っていると仮定し、 ゲームプレー空間にどの程度のセキュリティを与えたいのか、 またそのためにどの程度の開発コストがかけられるのかに応じて、 ネットワークの構造やプログラム手法を選択していくことになる。

ゲームプレー空間のメンテナンス

ゲームプレー空間のセキュリティと同じぐらい大切なのが、 ゲームプレー空間のメンテナンスである。 これは、IMPG 独特の概念で、インターネットに接続しないゲームの場合は、 ほとんど問題になることはない。 このメンテナンスの仕事が発生する事が、 IMPG がサービス業である所以である。

ゲームプレー空間のメンテナンスには、以下のような仕事がある。

• 運用状況の管理、システムの調整(ストレージ増強など)
• バグFix
• セキュリティポリシーの変更
• ゲームのルール内だが、ルールを濫用しているようなプレーヤーの取り締まり
• 新要素の導入や、あらかじめ仕込んでおいたイベントの起動
• Web を通した告知
• そのほか、ゲームプレーに変化を与えるような作業

IMPG をプレーするユーザは、正しくメンテナンスされた世界を求めている。 正しくメンテナンスされている世界は常に変化し、それがたとえバグ修正であっても、 変化している限りユーザは見放さない。 IMPG をよくプレーするユーザーは、「どれだけ世界が変化していっているか」、 「どれだけメンテナンスされているか」にこだわってゲームを選ぶ人が多い。 これは Web サイトにアクセスを集めるための定石である、 「常に更新し続けよ」の考え方と全く同じである。

IMPG のメンテナンス性にも、ネットワークの基本構造が大きく影響する。 一般に一極集中タイプがメンテナンスがしやすく、 IMPG サービスを長い目で見たときに、 ユーザーに高水準の満足を与えることができる。しかし反面、 アクセスを集中させるための設備投資が余分に必要となる。

IMPG ネットワークの基本構造

コンピュータネットワークにおいて、 どのコンピュータをどのように接続し、 何の仕事をさせるのかを規定する構造を、ネットワークの基本構造と言う。 ネットワークのトポロジーと言うこともある。 IMPG においては、ネットワークの構造によってゲームプレー空間のセキュリティと メンテナンス性がほぼ決まってしまうことから、基本構造の決定は非常に重要である。

どの IMPG も、コンピュータ同士の繋がりかたは同じだが、 どの種の「spam」をどの程度防ぎたいのかによって、 構造中の各ノードの役割と、通信内容/通信量が決定される。 MPG のトポロジを図にあらわすと、以下のようになる。

• pl : プレーヤーが所有する端末上の1プロセス
• ref : レフェリー(管理者)側が所有する端末上の1プロセス、通常はサーバプロセス
• p : pl 間の通信
• s : pl と ref 間の通信
• s と p の和はつねに 100

図の直線は、何らかの通信をすることを意味し、中央の =は、 その上下で行使できる機能(権力)に大きな差があることをあらわす。 pl 側のプレーヤーが、 ref だけが持つ権利にアクセスするためのパスワードを 知らないという意味で「パスワード境界」と言ってもよい。 この図で pl はゲームプレーヤーの持ち物なので、 pl のプログラムは簡単に変更(リバースエンジニアリングまたはクラック)できる。 また、pl のプログラムは、期待通りメンテナンスされているかは全く保証できない。 つまり、 pl は品質保証外となる。 プログラムが管理者の期待通り動くことが望めるのは、ref の端末のみである。 pl の端末で動作するプログラムは、完全にプレーヤーのコントロール下にある。

ゲームプレー空間に関する情報は、 pl にも ref にもどちらにも保管できる。 ここでのトレード・オフは、ゲームプレー空間のより多くを ref に保存するほうが 品質保証しやすいが、同時に ref の計算負荷も高くなるという事である。 ref の計算負荷が高まれば高まるほど、 管理者が用意しなければならないサーバマシンの台数は増え、 おそらく回線容量も増大し、トータルの設備投資量は増えていく。 この関係が、IMPG における基本的で最大のトレード・オフとなる。

p を増やして s を減らすことで、 ref の負荷を軽減することができるが、 ご想像の通り p のトラフィックは ref を経由しないため汚染されている (クラックされている)ので、セキュリティは低下する。 もちろん、 p のトラフィックの帯域や遅延は、まったく品質保証対象外となる。

以下、この p を s で割った比を p/s 比と呼び、 各種状況を理解するための助けとして、今後使うことにしよう。 もちろん、 p/s 比が小さいほど品質保証しやすいことになる。

p/s 比は多分に質的な情報を含んでいるため、 厳密な数値として求めることに意味はないが、 これから開発しようとしているゲームの品質が どういったものになるのかを考えるには役にたつ。 ネットワークの基本構造を決める作業は、まずこの p/s 比をどうするかを サービス品質とコストの両面から考える事から始まるのだ。

参考までに、既存のゲームの p/s 比を筆者なりに分析してみた。 読者も手元の IMPGの p/s比を分析してみて、 ゲーム内容と p/s 比の関係を考えてみると面白いだろう。

クラッキングと spam

IMPG サービスのセキュリティを根本的に脅かすプレーヤーの行為に、 ゲームプログラムやネットワークに対するクラッキング行為がある。 IMPG の p/s 比を決めるときに、 クラッキングとは何であるのかを理解しておくと、 システムデザインをするときに明確な意思決定ができるようになる。 私なりの解釈で恐縮だが、防ぐべきクラッキングとは、

「システムの機能を濫用して、安い投資で不当に多くの利益を得る事」 である。

これが本講座での spam 行為の定義なのだが、 クラッキング行為も実は全く同じなのだ。 spam も、クラッキングも、経済的行為なのである(以下 spam に統一)。 要するに、「時間を節約して強いキャラを持ちたい」、 「自分を有名にしたい」、「恨みを晴らす」といった欲求を、 相応のコストを支払わずに実現する事が spam なのである。 現実世界においては、spam を防ぐためにありとあらゆる法律が用意されているが、 IMPG においても、spam を防ぐために色々な工夫が必要だ、ということなのである。 現実世界の spam がそうであるように、 IMPG での spam もプログラムで100%防ぐことは不可能だが、 ゲームのルールを正しく実装することで、かなりの部分を防ぐことができる。

spam 行為を防ぐには、「コストあたりの利益」を小さくすればよい。 それには単純に考えると2通りの解決方法がある。 1つは、spam に必要なコストを高くすること、 もう1つは、得られる利益を小さくすることである。 ここで、この spam を減らせるかもしれない裏技(？)をすこし紹介しよう。 話のネタにでもして頂ければ幸いである。

家庭用ゲーム機における特殊な事情を利用する

家庭用ゲーム機(PlayStationシリーズや、任天堂の各種マシンなど)は、 pl 側で動作しているゲームのプログラムがクラックされることは少ない。 クラックされたプログラムをゲーム機上で動作させるためにユーザーが 支払わなければならないコストが、ほとんどのユーザにとって、 クラックによって得られるメリットを越えるからである。 ゲーム機用の IMPG はまだほとんどないに等しいが、 この性質によって、p のトラフィックを「汚染されていない」 として扱うことができる。 ただし、以下のいくつかの点により、 今後、この仮定は急速に崩れていくだろう。

エミュレータの高性能化

インターネット対応のゲーム機エミュレータにより、 クラックのためのコストが数百分の1に下がる。

ゲーム市場の拡大によるメリットの増加

ゲーム機上の IMPG 市場が拡大すると、 クラックによって得られるメリットが増大する。

ゲーム市場の拡大によるクラッカーの増加

中国と米国のユーザにより、クラッカーが増え、 クラックされる確率の分子が増大する。 中国人とアメリカ人は人数あたりクラッカーの人数が 日本人の数倍に達する上、彼らが作るクラックツールが、 全体のクラックのためのコストを大幅に下げる。

以上のようなことが現実に起きると、 クラックのコストあたりの利益が大きくなり、 ある点を越えると急激にクラックが増加することになると思われる。 コンシューマ機で IMPG を作ろうとしている人は注意が必要だ。

完全情報ゲームにする

将棋のように、ゲームプレー空間のすべての情報が、 全部の参加者に見えているようなゲームを完全情報ゲームという。 この場合、相手がクラックをした事がすぐに分かるので、 クラッキングしても得をすることがほとんどない。 これでクラッキングのメリットはほぼゼロとなる。 この方法の欠点は、もはや、 この世界で完全情報ゲームのネタは出つくしているかもしれない事である。

ゲームの蓄積をなくす

初期のインベーダーゲームのように、 ゲームの結果を蓄積することをなくせばよい。 つまり、ゲームの結果が次のゲームにまったく影響せず、 しかもランキングもなく、セーブもできないようにすればよい。 もちろん、1ゲームが数分以内に終わるようにしなければならない。 こうすると、蓄積が一切ないので、 クラッキングのメリットも限りなくゼロに近づく。 この方法の欠点は、最近のプレーヤーやゲームデザイナが好むような、 何かを時間をかけて育てるゲームが作れないことである。

独立ネットワーク専用とする

独立ネットワークとは、閇じられた数人でゲームプレー空間を作り、 そのゲームプレー空間に不特定多数の人間が入ってこないように することである。 ディアブロ1ではこのモードのみだったが、 ディアブロ2では独立でないモードが追加された。 プレーヤーが自分から出会いや発見を拒否するかわりに、 セキュリティを確保できる。 この方式の欠点は、 出会いや発見が他のプレーヤーからもたらされない点である。 同じゲームのエンジンを持って開かれたネットワークにしたら、 もっと面白くなるかもしれない。

匿名性を完全になくす

ゲームに参加するために、パスポートを取得するのと同じだけの個人情報 を登録させ、さらに面接をして入会確認をする。 そしてゲームプレー中は、いつでもその情報を参照できるようにし、 ゲームプレー中の姿をカメラで撮影し続ける。 この方法の欠点は･･････。

以上をまとめると、クラッキング行為は spam行為であり、 最新なゲームを作りたい IMPGクリエイターは、 ゲームプレーヤーの spam 行為を防ぐために、 ネットワークの基本構造を正しくデザインする必要があるという事である。 (そうでないとこの連載もあんまり面白くならないなぁ。助かった!?。) 次節では、「MPG(マルチプレーヤーゲームとは?)の節で少し触れた、「オンラインゲーム」、「ネットワークゲーム」 という用語について説明する。

オンラインゲーム、ネットワークゲーム

「オンラインゲーム」と「ネットワークゲーム」。この2つの用語は、 先に述べたように、不自然なほど狭い意味で使われている。 この節ではこの2つの用語に加えて、 「ハイブリッドネットワークゲーム」についても言及する。

オンラインゲーム

別名、MMO (Massive Multiplayer Online game)。 オンラインゲームとは、「ネットワークの基本構造」で述べた p トラフィックが ゼロ、つまり pl 間での通信を一切行なわない構造をもっているものである。 ゲームプレー空間は ref に一極集中され、 pl は単なるブラウザとして使われる。 ゲームプレーヤーの入力はすべて一旦 ref に送られ、 サーバのプログラムによって spam チェックされ、 許可されたものだけが、ゲームプレー空間に対して送り込まれる。 すべてのトラフィックが品質保証されている上、 ゲームプレーにとって重要なすべてのロジックが管理者所有となっているので、 ゲームの品質は最高水準となる。

このタイプの場合、 ref が pl からみてインターネットの向こうにあるので インターネット接続が「online」のときしかゲームを遊べない。 この性質によって「Online Game」という名前になったと思われる。 本連載では、このタイプを誤解のないように「スター型 IMPG」と呼ぶ。

スター型の利点として見逃せないのが、 サービスを完全に終わらせる事が可能である点だ。 これは企業にとっては重要で、 ユーザーを新作に誘導したりするのが簡単なので、商業上の利点が大きい。

ネットワークゲーム

別名、P2P (Peer To Peer network game)。 ネットワークゲームとは、スター型 IMPG とは反対に、 ゲームプレー空間のほぼすべての部分を pl 側に持ち、 ref との通信を 限りなくゼロに近付けようとするような構造をもつものである。 pl から別の pl にメッセージを送るために必要なインターネットルータの ホップ数が スター型 IMPG よりも小さくなるので、 レスポンスは少し良くなる。 またゲームプレー空間が pl 側にあるので、 オフラインのときも1人で遊ぶことができる。 このため商業的に有利となっている。 また p のトラフィックは、 IPv4 独自の問題(IPアドレス枯渇による IP masqueradeの利用など) の影響をうけるため接続性に障害が起こることがある。 本連載では、このタイプを「p2p型 IMPG」と呼ぶ。

ご想像のとおり、p2p型は、 ネットワークの各部に品質保証できないところが多く、 IMPG サービスの品質保証は難しくなる。 一般に、p2p型で有料課金ができるほどの品質を保つことは難しい。

p2p 型のゲームは、不特定多数のプレーヤーと出会うのがそのままでは 非常に困難であるため、ゲーム内容とは一切関係のない汎用の 「マッチングサーバ」というものを提供し、 プレーヤー同士の出会いを可能にしていることが多い。 マッチングサーバはいわゆるWebの掲示板と同じで、 「私のIPアドレスはこれです。誰か一緒にゲームしましょう。」 という書きこみを各プレーヤーが行ない、 それを別のプレーヤーが検索することによってプレーヤー端末(pl)同士の直接 接続を可能にする。このような単純なマッチングサーバは、 ゲームプレー空間のセキュリティをまったく提供しない。

ハイブリッドP2P

Hybrid Peer To Peer network game。 「p2p型 IMPG」 のゲームプレー空間のうち、 永続化される本当に重要な部分だけを ref に移し、 spam メリットの小さい画面エフェクトやチャット、 音声などだけを p のトラフィックを使って送受信しようとするものをさす。 p2p 型 IMPG におけるマッチングサーバに、 ref のゲームプレー空間管理機能を持たせる場合も多い。 その結果 spam 低減効果は期待できるが、管理者側の設備投資は、 p2p 型よりも大きくなってしまう。 そして、プレーヤー端末(pl)同士が p のトラフィックを使って通信する以上、 p2p型 IMPG がもつすべての技術的障害が発生することになる。

ハイブリッド型を採用することで p2p 型より品質を向上させることはできるが、 有料課金ができるところまで持っていくことができたメーカーは 少ないようだ。

以上をまとめると、 オンラインゲームとは完全に ref に依存する構造をもつゲームであり、 ネットワークゲームとは ref が存在しないゲーム、 ハイブリッドはその中間だということになる。 業界ではこれら、いささか強引な用語を使ってゲームを分類しているが、 これらの分類は意外と状況をわかりやすく説明していると思う。

現在発売される IMPGは、90%以上が p2p型となっている。 その最大の理由は、p2p型以外の、何らかの ref の機能を提供するための コストが高すぎるため、IMPG の開発会社がゲームの品質と コストをはかりにかけたときに、品質を捨てざるを得ないということである。 現在のコスト水準では、 大ヒットが確実であるようなタイトル以外、 スター型やハイブリッド型の IMPG をリリースできないのである。

このコストバランスを今後崩していくためには、 「ゲームの品質を上げると、どういう良い点があるのか」 ということを、企業において予算を握る人物でも納得できる形で表現したり、 同じ品質を得るために必要なコストをもっと下げたりする努力が必要だ。 特に筆者は技術者なので、後者のアプローチを得意とするが、 前者の「品質を上げるとどれぐらい面白くなって、何本多く売れるの？」 という問いに答える必要があることもまた、事実である。 この問いには明確な答えは出せそうにないが、おそらく唯一効果がある方法は、 1個でも多くのスター型ゲームが発売され、市場で成功をおさめることだ。 そのために私ができることは少ないが、 次に開発する予定のゲームをスター型で実装したくなるような、 いくつかのポイントを紹介しようと思う。

スター型にしたら、こう面白くなる

コンピュータゲームの面白さは自己実現と 自己顕示欲から生まれてくるが、 さらにネットワークを使うことによって これらの欲望を高レベルで満足させられる。 特に、スター型を採用することで、p2p 型よりもさらにネットワーク効果が高まる。

以下の意見は、筆者のまわりのゲーム・プロデューサーや、 エンジニア、会社経営者などに聞いてまわった、スター型ゲームの利点である。

コミュニケーションの増進

スター型では特に操作をしなくても、プレーヤー同士が出会うことができる (自己顕示をする相手が多い)。 特に、「チャットをする場面」が「ゲームする場面」と分かれていないのが、 コミュニケーションを増進する。

アイテムコレクターの増加

ゲーム内に、限られた資源(絶対に1個しかないアイテム)を積極的に導入できる (自己顕示の原料)。p2p 型だと、そのような資源はセキュリティ上実現できない。

ゲーム世界の存在感の醸造

プレーヤーがログインしていない間も世界が進行していることが、 世界の存在感を醸しだす。特にRPGでは有効。 ゲーム世界に感情移入させることができる。

プレーヤーランキング

厳正なランキングが可能。(自己顕示の場)

「生の声」に迅速に対応可能

ゲームに対するプレーヤーの評価を、 直接かつリアルタイムに把握でき、意見を反映できる。

遊び手、作り手双方の感情移入

ゲームがどう変化していくか、見るのが楽しい。

高品質と課金

接続に対して毎月有料課金ができるほどに高品質にできる。

リピーターの存在

スター型はほかのプレーヤーとコミュニケーションが密になるので、 高確率でリピートプレーされる。これは商業的に有利。

次回作への誘導

ゲームサービスを終わらせて次回作をリリースしやすい。 p2p 型だと、終わらせることが原理的にできない。

将来の IMPG

現在は、商業的、経済的な理由で p2p 型が多く選択されているが、 今後は社会のネットワークインフラが整備されていくため、 各種障害はどんどん小さくなる。 そして、 IMPG 業界では大作指向、高品質指向が強まっていく。 それは丁度、家庭用ゲーム機の性能が上がって起こったのと同じである。 つまり1作あたりの開発費用が高騰し、 数億円をかけた巨大な作品でないと儲からなくなって いったのと同じような循環が IMPG でも発生するということだ。 そうなっていく理由の1つには、 家庭用ゲーム機で IMPG がリリースされ始めることが挙げられる。 PC 用IMPGの規模や品質も、底上げされざるを得ないだろう。

ひとたび大作を作るとなれば、 ゲームの品質向上のためにはスター型やハイブリッド型など、 ref を使用する実装を選択すべきで、 そのようなゲームが占める割合は家庭用 IMPG の影響もあり、上がっていく。 ゲーム業界を眺めてみると、特に海外では、 すでにその動きは始まっているようである。 本連載では、 IMPG の実装においてスター型やハイブリッド型、 つまり ref を使った実装が中心になっていくという認識のもとに、 各要素技術を重要な順に説明していく。

スター型IMPG サーバの役割と要求事項

要求される絶対性能

スター型やハイブリッド型など、ゲームプレー空間の品質を 高めた IMPG が主流となっていくという考えはこれまでにも述べたが、 このタイプのサービスにおいて最重要となる部分は、 ゲームプレー空間の大部分が格納されるゲームサーバ本体である。 ゲームサーバの役割はゲームプレー空間をクリーンに保つことなので、 プレーヤーの操作のうちゲームプレー空間に影響を与えるものは、 それがたとえコマをひとつ動かすだけの処理であっても、 すべてサーバによってチェックされなければならない。 結果として、ユーザが1クリックするたびに、また数回キーボードを押すたびに、 ほぼ1つの何らかのクエリーがサーバに送信されることになる。

無料プログラムとして配布される草の根ゲームならばともかく、 商業的に成功をすることを見込むゲームでは、 数千人～数万人以上の同時参加者を前提として設計される必要があり、 これだけの数のユーザから送信されてくる総クエリー数は、 恐ろしい数にのぼる。 ゲームのプレーアビリティ(プレーしやすさ)を損なわないためには、 これらのクエリーを常にオンタイムで処理し続けることができる能力が サーバプログラムに求められる。 本節では以降の説明を、簡単のためにスター型に絞って行なう。

上の図は、エニックスのディプスファンタジアの場合のサービス全体の接続図 である。右端にプレーヤーの端末があり、真中にゲームロジックサーバ、 左端にバックエンドという構成である。 見てのとおり、サーバの構成は、現在流行(？)のクラスタリング構成となっている。

このサービスの場合、5000人～1万人のプレーヤーが同時にゲームをプレーし、 さらに各ユーザが数秒に1回何かの操作をする状態が発生する。 たとえば5秒に1回の操作だったとすると、 ゲームのロジックサーバに送られてくるクエリーの合計は 最大5万クエリー/sec という水準となる。 HTTP よりも無駄の少ない専用のプロトコルを使っているとはいえ、 1台のPCでこれだけのクエリーを処理することは、 暗号化など付加的な処理もあるため、まったく不可能である。 (Web サーバでCGIを使う動的なコンテンツの場合は、 PCサーバマシンで 1000クエリー/sec を出すのも一苦労である、 というかとてもつらい事であるのは、経験者ならわかるはず。)

もちろん、 refの負荷を少しでも軽減する方法として、 ref に対して送信されるクエリを少なくするような アルゴリズムを実装する余地もある。 以下に、ふたつの指針を紹介する。

ゲームプレー空間をキャッシュする

ゲームプレー空間の一部を pl にキャッシュし、 ref の判定を代行するという簡単な方法がある。 もちろん、そうすることでセキュリティは下がる。 ここでのトレードオフは、 キャッシュすればするほどセキュリティは下がるが ref への送信は 節約できるという事である。 また、キャッシュは一般に書き込み的な処理にはあまり使えない。

ゲームの操作を抽象的にする

ゲームの操作の粒度を上げる。抽象的な操作をさせるという事である。 例えば、「右に1歩移動してモンスターを殴って、左に一歩退く」 という操作をプレーヤーに直接行わせると3クエリ必要だが、 「ヒットアンドアウェイで攻撃する」という風な操作にすれば、 1クエリでよい。この手の最適化はゲーム内容に大きく影響する。 最もクエリが少ないのは、最初にキャラクターの性格を決めて、 あとは見ているだけという境地である (市場がこれを求めているかどうかは知らない)。 ここでのトレードオフは、 操作を抽象的にすればするほど、 ref の CPU が考えることが多くなり、 計算負荷が上がる事である。 このトレードオフに対する答えをサーバのプログラマが持っているならば、 採用を一考すべきアプローチである。

一般に、十分に使いやすいインターフェイスをもつゲームに対する入力は、 ディプスファンタジアと同じような、数秒に1回から1秒に5回以下の水準になるだろう。 そして、商業的な成功を勝ちとるためには、 数千人以上の同時参加プレーヤー数をこなす必要がある。 これらだけを考えても、 強力な CPU 資源を入手するために何らかのソフトウェア上の工夫が必要 である事は明らかである。 次節以降では、ディプスファンタジアほか、スター型IMPG において、 なぜ図のようなクラスタリング構成になっているのかを、明らかにしていく。

クラスタリングの必然

高水準の処理能力を手に入れる方法には、 全部のクエリを1台で処理できるスーパーマシンを買ってきて かっこいいマルチスレッドプログラムを書くか、 安いマシンをたくさん買ってきて Ethernetみたいなものでつないで、 かっこいい通信プログラムを書くか、どちらかの選択肢がある。 最近では、ネットワークの帯域とマシン内の帯域との差が小さくなってきたことと、 高速な通信プログラミングのためのツールが充実してきたこともあって (ここで宣伝：コミュニティーエンジンの VCE とか) 後者を採用する場合が増えているようだ。 ゲームサーバ独特の条件としては、 プログラムの内容的にマルチスレッドの効果を得にくいという特徴もある。 一般に、ゲームプログラムは、データ同士の独立性が低いため、 プログラム中が排他制御だらけになるからである。 そのため現在私は、 サーバプログラム内で自前の効率のいいマルチタスク管理をする プログラミングモデルを推奨している。 このモデルは、通信を多用するクラスタリングプログラムと相性がいい。

さて、サーバ用のマシンを選ぼうと思ってパラパラとカタログをめくると、 2倍の処理能力を単体マシンで得るためには、 4倍～5倍ぐらいの価格になるようだ。 たとえばディプスファンタジアのサーバの場合、 1GHz のマシンで最大5000クエリ/sec 程度のクエリを1台で処理できるような ゲーム内容だが、 5万クエリ/sec を得るためには、その10倍の性能が欲しい。 PentiumⅢ 1GHz の10倍の性能を単体で持つマシンとなると、 100倍ぐらい高価で、1台でも5000万円以上の投資が必要になってしまう。 この予算で、1GHz の普通のマシンだと100台も買えてしまう。 ゲーム開発の予算全体からみても、 この金額は出せない。するとやっぱりクラスタリングで何とかできないの？ ということになる。

最近の超高速多プロセッサマシンは結局、 物理学的には、光速限界（何物も光速度を超えられない）の法則が存在するおかげで、全部のプロセッサを最高速のバスで つなぐことができない。 そのため高速なプロセッサ群を中速のネットワークでつないだような構造に なっている。こういうマシンでプログラムをするときは、 クラスタリングシステムを作るときに使うような何らかの通信ぽい プログラミングが必要になってくるのだ。 たとえば次の図のような論理構造をもつ多プロセッサマシンを考えてみる。

この図のマシンの場合、CPU-A と CPU-B は高速なバスで接続されているので、通常のスレッドプログラミングを することで性能向上が可能だ。しかし、 CPU-A と CPU-C では、間に遅いバスが挟まっているため、 適当にスレッドプログラミングをするとその遅いバスがボトルネックになってしまう。 そのため、CPU-A が属しているグループに用意されているメモリ(図の RAM) に、CPU-C へのデータをバッファリングして、 低速バスを効率的に使うために いわゆる帯域遅延積に応じたバッファが必要なのだ。 この工夫はまさに通信プログラミングで必要とされる工夫と全く同じである。 このボトルネックをハードウェアの仕組みでできるだけ回避しようと、 CMPとかハイパーキューブとか、いろんな方式が提案されているが、 それらを使ったマシンとなると、億がつく値段になっていく。

そしてまた、このようなスーパーマシンは、 全体の信頼性を上げるためのパーツ(多重化ほげほげ、ホットなになに)が満載である。 ゲームサービスの場合、システムの全体が同じ信頼性を持っている必要はないので、 安いマシンを使ってクラスタリングして、どうしても落ちてほしくない 大事なところだけ、信頼性を上げるためのパーツを付ける方法がよいのだ。

また、会社経営者としての筆者の立場からみても、 ゲームのクライアントとサーバをつなぐための通信プログラムのノウハウが そのままクラスタリングプログラミングにも適用でき、 特殊なマルチプロセッサプログラミングのツールを覚えなくていいので、 社員の新ツール習得にかかるコストが低くてすむというメリットがある。 筆者の経験では、マルチスレッドプログラムのバグ取りは、 TCP/IP のプログラミングより3倍は難しい(3倍時間がかかる)。

もうひとつ、クラスタのノードとなっている各マシンは いらなくなったら他のこと(他のゲームへの支援とか会社に持って帰ったり) に使えるというメリットがある。 これが実は、浮き沈みの激しいゲーム業にはピッタリなのである (もちろんスーパーマシンの中には、このあたりのことを考えて、 1個のマシンの中にバーチャルマシンが複数あるようにできるものもあるのだが、 さすがに一部のパーツを別のデータセンターに持っていったりはできない)。

結論としては、「ゲームプロジェクトは予算がなくて 超強力なマシンが買えないし、 クラスタリングを使っていろいろ工夫できそうな余地があるから、 それでがんばってみよう」という感じなのである。 現在までの筆者の経験では、まだ解決していない問題は残っているものの、 クラスタリング方式でかなりうまくいっている。

並行処理可能性

並行処理可能性というと、1つの学問になってしまうほど、 奥が深くてオモシロイのだが、ここでは深く立ち入らずに、 ゲームサーバの機能別に見てみる。ゲームサーバの各機能が、 どれぐらい並行処理しやすいのかを調べることで、 どの部分を並行化すべきなのかを考えていく。 もちろん、並行化しやすいほど、クラスタリング処理に向いているという事になる。

結論から言うと、後述する「排他」「永続化」以外の処理はすべて、 ちょっとした工夫で並行化できる。このちょっとした工夫というのは、 たとえば、スーパーマリオならば1～2面、3～4面、5～6面、7～8面という風に 世界をいくつかの部分(ゾーン)にわけて、 各部分ごとにクラスタノードが処理を担当するようにする。 クラスタノードとは、クラスタを構成する1個のマシン(プロセッサ)の事である。

この方法が効果的である理由は、どこかで習ったはずの 「最後にアクセスした情報は、次にアクセスされる確率がすごく高い」 という、メモリキャッシュの理論と同じである。つまり、 ゲームプレーヤーの、ゲームプレー空間に対するアクセスが、 極めて局所的かつバースト的であるからである。この性質はとても重要だ。

家庭用ゲーム端末では、 ランダムアクセスがとても遅いCD-ROMドライブとメモリーカードを ゲームプレー空間を保存するために使っている。 これらのデバイスにアクセスするのは、 ゾーンの区切りを越えるときに限定していることが多い。 これを先ほどの論理で説明するならば、 「次のプレーヤーの操作対象となるゾーンは、 前の操作と同じゾーンに対してである確率がとても高い」 ことを利用していることになる。 同じように、クラスタにおける並行処理について考えると、 「あるプレーヤーからの次のクエリの操作対象は、 前のクエリと同じゾーンに対してである確率がとても高い」となる。

ほとんどすべての既存のゲーム・モデルにおいて、 ゲームプレー空間へのアクセスがバースト的である事を利用した最適化が 効果的であることは、疑いの余地がないだろう。 安価なマシンによるクラスタリングによる効率化が最適であることは、 ここでも裏付けられたことになる。 最後に、ゾーンごとに分けることで並行化しやすい処理の例を挙げておく。

当たり判定

当たり判定は、空間的に極めて局所的な処理なので、並行化しやすい。 特にアクション性のあるゲームでは、 ほとんどの処理が当たり判定と関係しているため、並行化の恩恵は大きい。

チャット

2次元空間の距離を演出として利用して、聞こえるか聞こえないかを判定するような チャットをする場合、空間的に局所的な処理なので、並行化しやすい。

マップデータ送信

次に表示されるマップは、現在のマップに近いことが多い。 従って、差分を求めたりといった最適化がしやすい。

ゾーン分けによる並行処理

前節において、 IMPG においては、 クラスタノードごとのゾーン分けによる並行処理が有効であることを説明したが、 さらに IMPG においては、 同じゲームプレー空間の部分(ゾーン)に 参加しているプレーヤーを、同じクラスタノードに集めておくのが、 最も効率のよい並行処理の方法だといえる。 そして、その部分(ゾーン)を移動したいときだけ、 接続しているクラスタノードを切りかえればよいのである。（図） またまた宣伝になるが、VCE ライブラリではこの機能を標準で持っていて、 クライアントがいちいち暗号鍵を交換したりすることなく、 サーバ側ネットワークだけを使ってこの切り替えを実現することができる。

実際の商用ゲームでは各ゾーンごとにプレーヤーが均等に分布しているとは 限らないため、 ゲーム内容に応じて「パラレル式」、「分割式」の2系統の方式から選択することが多い。

パラレル式

この方式では、同じように見える世界を複数持つ。 つまり、ゲームプレー空間を複数持ち、 各クラスタがゲームプレー空間を1つずつ担当する。 パラレル式は、 一見すると「ゾーンに分けていないのでは？」 と錯覚してしまうが、 まったく中身が同じように見えるだけの別のゾーンであると考えるとよい。 この錯覚はゲームプレーヤーにも起こり得る。 つまり、サーバ1にログインしているユーザーAと、 サーバ2にログインしているユーザーBは、同じように見えるゾーンにいるが、 実際には違う世界にいるため、同じ画面に登場したりできないのだ。

プレーヤーにとってみれば、 この状態だと友達と一緒にボスと戦えないなど都合が悪い。 例えば図では、プレーヤーAとプレーヤーBは、 「星の右上の手のところで」というふうに待ち合わせをしても、 実際には違う世界にいるため、コミュニケーションできない。 この不便を解消するために、 ゲームを始めるときにどのクラスタノードに行きたいのかを選択させるための ユーザーインターフェイスが必要になるだろう。

パラレル式は、ゲームサイトの規模を、 スケール(規模拡大/縮小)させやすいという特徴をもつ。 参考までに、 エニックスのディプスファンタジアでは、以下のような画面を表示している。

分割式

分割式では、1個のゲームプレー空間を、 文字通り複数のクラスタノードが部分ごとに分けて処理する。 この方式の利点は、ゲームプレーヤーから見て、 ゲームプレー空間が1つしかないように見えることである。 たとえば「星の右上の手」という表現をしたときには、 世界には、そのような地形の場所は、1ヵ所しかないため、 コミュニケーションがスムーズに行える。 こうすることで、「世界はひとつ!」感を出すことができ、 ゲームの世界観の構築に役立つ。 ただし、ゲーム内容をいくら工夫しても プレーヤーが集まるところが数ヶ所に集中することが どうしても避けられない(スキー場でいうとゴンドラやリフトのあるところ、 スーパーマリオだと無限増植できる場所)ため、 スケールさせにくいという欠点をもつ。 ウルティマオンラインは、当初はこの方式を採用していたが、 しばらくしてハイブリッド式に移行した。

ハイブリッド式

ハイブリッド式は、分割式のクラスタを複数持つ方式である。 分割式があまりにスケールさせにくいので、 この方式が使われるようになった。 ただし、「世界はひとつ」 感を出したいという目標は達成されなくなってしまう。 ちょうど分割式とパラレル式の中間の方法だが、 1台のマシンに1個の世界が納まりきらないほど巨大な世界を表現したい 場合などは、この方法を取るしかない場合もある。

以上のように、ゲームのサーバを並行化する方法もいろいろあるが、 以下の条件を満たせるならば、 メンテナンスコストの点から考えて迷わずパラレル式を採用すべきである。

• ひとつのクラスタに数百人～1000人以上がログインできる程度の性能を 出せる
• ゲームプレー空間の全体が、1個のクラスタに十分納まる(数百Mbytes)

パラレル式を選ぶ理由は3つある。1つは、数百人という数は、 「その世界にたくさんの人がいる感」を出すには十分であること。2つ目は、 ゲーム世界が1とつであるかどうかを実はプレーヤーは重視していないこと。最後が、 1個のクラスタノードが落ちても他が埋めてくれるので 信頼性が高くなるということである。

プレーヤーは、友達と同じ世界に存在できて、 そこにある程度の数の他人がちゃんといて、 いつでも行きたいところに行けたら満足なのである。 ごく一般的なゲームデザインにおいては、以上の2つの条件は、満たされるはずである。 もちろん、ゲーム企画的に、 たとえば参加者全員によるバトルロイヤルをテーマとするなど、 どうしても世界が1個でないといけないようなことがしたいならば、 分割式を採用せざるを得ない。しかし、 現在の技術水準ではかなり危険な賭けになるだろう。

並行処理できない「排他」と「永続化」

ゲームのサーバの仕事としてこれら2つは代表的な処理だが、 もっと一般的に言えば、「ゲームプレー空間のうち、 空間的に切りわけることができない部分」である。 空間的バースト性をつかって並行化する以上、当然の成りゆきである。 このようなゲームプレー空間の部分には、どういうものがあるだろうか？

例： ファイヤーマリオは、同時には世界中に10人しか存在できない。

このルールはゲームプレー空間の大切な一部をなすが、 クラスタ中のすべてのノードが、何らかの情報交換をしない限り、 実現不可能なことは、直観的に理解可能だと思う。 典型的には、「ファイヤーマリオの数を数えるサーバ」という別のプロセスを 走らせ、それが10を最大値とする多値セマフォのようなサービスを提供する。 もうお分かりだと思うが、このサービスこそが「排他」であり、 しばしばゲームの面白さの本質にさえなる重要な部分である。 他の例でいうならば、たとえば最速タイム・ランキングであり、 世界に1つしかないまぼろしの剣であり･･････、枚挙にいとまがない。 では次の例はどうだろうか？

例： 8面にある箱を開けるためには、3面で出る鍵が必要である。

問題は、8面と3面が、別のクラスタノードによって分担されているときに発生する。 この場合、8面を担当しているクラスタノードは、 3面でそのキャラクターが鍵を取っているかどうかを知りたい。しかし、 そのプレーヤーが 他のクラスタノードが管理している3面で鍵を取っている（かもしれない）ために、 何らかの通信が必要になるのだ。

問題の根源は、「3面と8面が、実は分かれていなかった」事にある。 ゲーム内容を完全に空間で分離することは不可能な場合が多いのだ。 ゲーム内容を伏線に富んだものにすると、自然とそうなっていく。 これは、分割式の場合に固有の問題ではない。 それを家庭用ゲーム機の例を挙げて説明しよう。

実は、通常の家庭用ゲーム機でも同様の問題が発生しているのだ。 つとむ君の家のPlayStationで3面の鍵を取っても、 たかし君の家のPlayStationで続きをやって8面の扉が開くということが 実現したい場合を考えてみるとよい。 そのためにはメモリーカードにゲームプレーの状態を記録しておき、 ゲーム開始時にその状態をロードして、 途中の状態が再現できるようにユーザ端末のプログラムしておくのがよい。 この例の場合、「つとむ君の家のPlayStation」と、 「たかし君の家のPlayStation」の2台のPlayStationの関係は、 2台のパラレル式のクラスタノードの関係と、 事実上同じである。プレーヤーは、 以前にアクセスしたクラスタノードと同じクラスタノードに次にアクセスするとは、 限らないのである。

ところが、 IMPG で同じようにプレーヤー所有のメモリーカード(HD上のファイルでもいい) を使うとspam のコストが低いために、その温床となってしまい嬉しくない。 従って、 spam 対策上、管理者が所有しているメモリーカードにゲーム状態 を記録しておきたいのである。 そのために、クラスタノード間でゲーム状態を記録、取り出しする手段が必要となる。 これが「永続化」処理の代表である。 保存されたデータの寿命がプログラムの寿命よりもはるかに長いので、 このようにデータを記録することは永続化と呼ばれる。 永続化の事を、ネットワーク業界人は「ストレージ」ともいう。

ボトルネックの発生

これまでの説明で、ゲームプレーに必要な処理の多くは並行化できるが、 並行化できない大切な部分もあることが分かった。 そして、この並行化できない部分こそが、 IMPG システム全体のボトルネックとなっていくのである。 図に、ボトルネックになる場所を示す。

次回からは、並行化で性能を向上させにくい部分のうち特にストレージ(永続化)に 焦点をあてて、 どのようなツールや方法を使ってボトルネックと戦っていくのかを 紹介していこう。

Resource

コミュニティーエンジン株式会社のWebページ

http://www.ce-lab.net/

株式会社スクウェア・エニックスのWebページ

http://www.square-enix.com/

熱湯猿多（ネットエンタ）（※サービス終了）

http://saru.enix.co.jp/
エニックスのオンラインゲームサイト

韓国インターネット白書 2001

韓国電算院、韓国インターネット企業協会/1万円/ソフトバンクパブリッシング/ISBN 4-7973-1725-6

Korea Internet White Paper 2001

http://www.nca.or.kr/homepage/internet.nsf/_h68o30c8hmfh204dvmk8rjbghn7kh3f5d408rpf0hnb713e7h271fe_?OpenPage

日本MySQLユーザ会

http://www.mysql.gr.jp

MySQLリファレンスマニュアル

http://www.mysql.gr.jp/jpdoc/

UNIXという考え方

Mike Gancarz著/芳尾桂監訳/1600円/オーム社/ISBN 4-274-06406-9

初出：LinuxJapan 2002/3月号 「現場のUNIXエンジニアが明かす！　インサイド・オンラインゲーム」

PDF版はこちらからダウンロード

前回までのあらすじ

前回は、IMPG(インターネット対応マルチプレーゲーム) サービス全体を概説した。 特に IMPG サービスにとって根本的に重要な点として

• ゲームプレー空間のセキュリティを確保すること
• ゲームプレー空間のメンテナンスをしていくこと

以上の2点を挙げ、 これら2点を実現していくためには一極集中型のバックエンドサービスが必要 であることを示した。

概論は第１回で終わりにして、今回からは各論に入ろう。 各論のまず最初に、実際のゲームサービスで使われているバックエンドサービスの 考え方や実装例を紹介するとともに、 将来のさらなる性能向上を模索してみたい。

今回の議論では IMPG のバックエンドとして使用されている、 MySQL などデータベースエンジンの話題が中心となる。 そのために SQL やデータベース関連の基本的な用語を多数使うことになるが、 まだまだそれらに馴染みのない読者も多いかもしれない。

SQL やデータベース関連の知識を持っておく事は、 バックエンドの設計にはもちろん必須なのだが、 Web サイトの構築や一般的なプログラミングにおいても非常に有益である。 以下に、データベース関連の入門になりそうな Web サイトをふたつほど紹介する。筆者も時々アクセスするサイトである。 参考にしていただければ幸いである。

RDBMSやデータベースそのものについて

http://www.wakhok.ac.jp/DB/DB.html

SQLプログラミングについて

http://www.ann.hi-ho.ne.jp/hirok/sql/

IMPG バックエンドの仕事

IMPG のバックエンドがこなさなければならない仕事は、 ゲームプレー空間の状態を保存するストレージの仕事ばかりではない。 最新の IMPGサービスでは、 クラスタノードごとに完全に分離できないタイプの サービスは複数種類あるのが普通だ。 ここでは稼働中のゲームの実例として、 ディプスファンタジア(エニックス)の例を紹介する。 ディプスファンタジアのバックエンドでは、 以下のようなサーバ群が常時動作している。 現在でもかなりの種類があるが、 今後ゲーム内容の充実に伴ってますます増えていくことだろう。

以上のバックエンドには ディプスファンタジアに特有の部分(オークション、ランキング、ギルド、ログ) と汎用の部分(ストレージ、ロック、インスタントメッセージ、認証)とがある。 汎用の部分については、コミュニティーエンジンから提供している mm-suite という ミドルウェアパッケージに含まれているものが、そのまま使われている。 (よく考えるとログ収集も汎用の機能にしてよさそうだ)。

ディプスファンタジアでは、これら複数種類のサービスのそれぞれに対して 各ゲームサーバが常時 TCP のセッションを1本保持しておき、 再接続の負荷を軽減している。 この方法は、DBプロセスにアクセスする性能を向上させる 一般的な最適化と同様である。 また、 バックエンドへの接続に TCP を使うと、マシンの能力や資源が不足したときに、 すぐに別のマシンに載せかえができるという利点がある。 実際、ストレージサーバだけは高性能が要求されているので、 専用のマシン上で単体動作させている。 以下に、プロセスと TCP セッションの観点からみた接続図を示す。

図の右側が「フロントエンド世界」であり、 ゲームのロジックを実際に実装している部分、図の左側が、 ストレージなどの仕事を担当する「バックエンド世界」である。 フロントエンド世界とバックエンド世界の間は、Ethernet などの物理 ネットワークで接続されている。 この図では、非常に大量のセッションが多数のプロセス間で 同時に使われていることが見た通り分かる。 セッション数やプロセス数が多いことは そのままメンテナンスの手間にはね返ってくるため、 この複雑さを、性能を保ったままどういうふうに解消するのがよいのか、 現在模索中である(筆者としては、現在のところ 分散オブジェクトの考え方をうまく応用すれば、 性能をそのままにメンテナンス性を良くすることができそうな予感がしている)。

また、これらのバックエンドプログラム群のうち多くは、 データを保持しておくために、さらに下層のプログラムとして MySQL を使っている。 MySQL にアクセスするための libmysqlclient というC言語用のライブラリを用いて、 直接 MySQL にアクセスしている。 MySQL のような DBMS に対して C言語のような低レベルの言語を使って アクセスする例はあまり多くないと思うが、 なぜそのようなデザインになっているのかは、 次節から説明する「dumbなバックエンド」についての議論や、 メンテナンス性と拡張性に関する議論を経ることによって 理解できると思う。

dumb なバックエンド

最近私は「テレコズム」([3]）という本を読んだのだが、 その中の「ネットワークは dumb であるべきであり、 インテリジェンスは末端に集中させるべきである。」 という記述に非常に共感できた。 この意味は、インフラはできるだけ単純で賢くないほうが使いやすく、 拡張しやすく、また堅牢になり、複雑なロジックは端末側に実装しておくと 変更しやすくなるという事である。 この論理は通信のコストが十分に低いことを前提としている。

この論理は各種のシステム設計においてかなり重要なアイデアのひとつ になっているようだ。 実際、既存のプロジェクトでも確実に採用されつつある。 たとえば IPv6 の設計においてはできるだけ IP層の動作を単純化しようとする努力がなされているし、 qmail などのインターネットサーバプログラムでも、 「dumbなインフラ」を目指して開発されていることが一目で分かる。

私はIMPGシステムの設計においても 「dumbなインフラ」論を適用することによって、 堅牢で拡張性の高いバックエンドを構築することが可能だろうと考えている。 つまり、複雑で随時バージョンアップしていくようなロジックはすべて フロントエンドのゲームサーバクラスタに置かれ、 バックエンドはあくまでも寡黙に、 データの保存と取り出しだけを行なうようにするのだ。 そうすることで、変更と機能拡張に強いシステムができあがるはずだ。 このデザイン指針の下では、ゲームのロジックのようなインテリジェントな 部分はすべてフロントエンド側に置かれ、 バックエンド側には一切実装されないことになる。

N=10000
array = []
(N+1).times { array.push(0) }
for i in 0..N
  for j in 0..N
    array[j]+=i
  end
end

$N=10000;
@array = ( 1 .. $N );
for($i=0;$i<$N;$i++){
    for($j=0;$j<$N;$j++){
        $array[$j]+=$i;
    }
}

public class a
{
    public static void main(String args[]) {
        int i,j;
        int N = 10000;
        int array[] = new int[N];
        for(i=0;i<N;i++){
            for(j=0;j<N;j++){
                array[j]+=i;
            }
        }
    }
}

#define N 10000
int main()
{
    int i,j;
    int array[N];

    for(i=0;i<N;i++){
        for(j=0;j<N;j++){
            array[j]+=i;
        }
    }
}

PDF版はこちらからダウンロード

オンラインゲーム、ようやく盛りあがってきたかな？

SCEがPlayStation BBを発表したり、 XBox が発売になるなど各社の オンラインゲーム合戦はいよいよ本格化している。 日本でこんなニュースが飛び交っている間も、 台湾や韓国をはじめアジア諸国では、 IMPG（インターネット対応マルチプレイゲーム） ユーザーの人口は増え続け、数百万人に達している。 筆者は2月中旬にコミュニティーエンジンの仕事の関係で台湾に出張に行って きたのだが、当地のオンラインゲーム、 そして PCゲームに対するニーズの強烈さには驚くばかりだった。

台湾出張の最中に、台北駅前にある PC房と呼ばれる PC ゲームセンターに行ってきた。 1時間で約90元(日本円にして400円弱)の利用料金がかかるのだが、 これはかなり高い。それなのに、 土曜の昼間でも学生服を着た中高生が200席のフロアを 半分ほど埋めていた。夕方になると満席になるという。 ひとりっ子政策で、中高生の男の子がたくさんお金を持っているのだろうか？

またPC房では、ほとんどの客が友達同士だということもあり、 P2P型ですぐに対戦が終わる少人数タイプのゲームを好んでプレイしていた。 Massive Multiplay 型のゲームをやっている客はほんのわずかだった。 このあたりがゲームセンターと家庭の違いなのだろう。

アジア地域でこのように PC のゲームが全盛なのは、 日本が誇るコンシューマゲーム機の市場がまったく育っていないことや、 安い娯楽が少ないこと、違法コピーがしやすいことなど、 いろんな原因があるのだろう。しかし、 そこには日本とは異なるゲーム社会があり、 凄い速度で変化していることだけは事実である。 アジア地域からは、ますます目が離せない。

前回までのおさらい

第1回では、IMPG サービスの品質保証の観点から、全体を概説した。 第2回では、IMPG の性能／サーバコストパフォーマンスの ボトルネックになりやすいバックエンドデータベースの実装を中心に 議論を展開し、MySQL サーバを使った実装で十分なコストパフォーマンスを 実現する方法を模索した。今回からは、フロントエンドのいわゆる 「ロジックサーバ」の実装に話を移していきたいと思う。 なお、本文中で使用されている統計データ類は、 すべて株式会社エニックス（現株式会社スクウェア・エニックス）の「ディプスファンタジア」から得られたものであり、 エニックスの許可を得て掲載していることを明記しておく。

次節以降、 ディプスファンタジアの実際の運用中に得られたデータを元に、 フロントエンドの実際を紹介していく。

IMPG サーバの基本構成(3階層モデル)

ディプスファンタジアの場合ばかりでなく、 IMPG サーバシステムの開発においては、 私はいつでも3階層構造を提案している。 ここでは IMPG サーバ実装の3階層モデルを図で示し、 3(多)階層モデルを採用している理由を説明する。

IMPG サーバの3階層モデル図

バックエンド部分

図で左端に位置するのがバックエンド部分であり、 永続化や排他処理など、並列化できない処理を担当する部分である。 データベースアクセスなどの処理は、この層に集中している。

フロントエンド部分

図の真中、インターネットの左に位置するのがフロントエンド部分であり、 並列化できる処理を担当する部分である。 今回はこの部分を議論の対象とする。

クライアント部分

一番右端、ユーザーと直接触れあうマンマシンインターフェイス の部分となるのがクライアント部分である。 この部分も高品質な IMPG を作る上では相当重要な位置を占めるので、 今後の号で、議論を展開していくことにする。

このように、「クライアント部」「フロントエンド部」 「バックエンド部」の3つに分けてアプリケーションの実装を考えるモデルは、 実は Web のアプリケーション実装における3階層モデルと、 まったく同じであることがわかる。 クライアントとフロントエンド部分をつなぐプロトコルが異なるだけで、 根本的にはまったく同じ構造になっているのだ。

実際にはこのような3つの階層構造以外にも、TCP/IP ネットワークの層、 Linux OS の層など、もっと多くの階層がからんでいるのだが、 ほとんどの開発プロジェクトにおいて それらの層に関しては安定で不変の(開発対象でない)ものとして扱われるため、 特にそれらの層を除外して「3階層」と呼んでいる。 したがって3階層という呼び名の「3」という数字には、 深い意味はない。「開発者の頭の中が3つに分かれている」と でも考えればよいだろう。

例えば、Javaを使ったWebアプリケーション開発では、 以下の図のような3階層モデルが多く採用される。 この図をもっと細かくみると「中間層」が2層にわかれているため、 「4段階モデル」だと言えるかもしれない。

Webアプリケーション開発における3階層の図

ここで大事なことは、プログラム(サービス)全体を複数の階層に分けて 実装することであり、3つに分けることではない。

しかし、そもそもなぜこのように複数の層に分けてアプリケーションを 実装するのが一般的になったのだろうか？ その理由は、アプリケーション(プログラム)というものが、 将来の激しい変化を許容していく必要があることを、 プログラムを開発する者が認識したということだ。 言い換えると、 システムを市場の変化に併せて低コストで変更していくための方法なのだ。

以下に、なぜ階層に分けた開発がコストダウンにつながるのかを、 リストアップしてみた。この項目はすべて、経験のあるエンジニアだったら、 当たり前だと感じることばかりだろう。

テスト・デバッグしやすい

システムが階層に分かれていると、 エクストリームプログラミングでいうところの 「ユニットテスト」に代表される、 部分(階層)ごとのテストやデバッグが簡単になる。 階層ごとの仕事が明確になっているからである。 この特性により、エンジニアの時間が劇的に節約でき、 直接のコストダウンになる。 ただし一般に、上(ユーザーに近い)階層になるほど、 プログラムの副作用がプログラムの目的になり、ユニットテストしにくくなる。 IMPG のサーバにおいては、バックエンドは完全にユニットテストでき るが、フロントエンドは一部の機能しかユニットテストできない。

性能をチューンしやすい

テストしやすいということとほぼ同義である。 テストをするということはほぼ同時に、 ベンチマークをするという事だ。 開発の各段階で常にベンチマークをすることは将来の問題を減らす。 また、階層ごとにAPIが絞られているので、 的を絞ったチューンが可能になる。 性能をチューンできれば、サーバに対する設備投資を減らすことができる。

アプリケーションの変更に対して強い

アプリケーションをレイヤーに分け、各レイヤーがあらかじめ決められた 外部インターフェイス(API)を実装することで、 APIを変更せずに内部の実装を変更できる。 プログラムに対する多くの変更がAPIの変更でなく、 実装の変更である場合は特に効果が高い。 うまくデザインすれば、ある層をまったくすげ替えることも可能。

分担しやすい

複数層に分けて各層ごとにスタッフを配分すると、 1人あたりの管理しなければならないソースやドキュメントの量が 軽減され、開発者同士のコミュニケーションが取りやすくなる。 開発者同士のコミュニケーションにかかるコストは見えないが とても巨大なものなのだ。

実際に、ディプスファンタジアの場合でも、 バックエンド側はほとんど変更されることはなく、 フロントエンド側とクライアント側が別々に変更されていて、 プログラミングの担当も別れている。 そしてゲームが成熟段階に入ると、 ほぼフロントエンドサーバのプログラムを変更するだけで済むようになる。

長い目でみると、アプリケーションが階層構造に分かれていることは、 根本的なコストダウンにつながるのである。

IMPG フロントエンドにおけるコスト意識

IMPG サービスを運営するには、毎月、確実に費用がかかる。 費用はおもにシステムを維持するためのコストと、 コンテンツを拡張、メンテナンスしていくためのコストに分けられる。 できることなら全ての予算をコンテンツのメンテナンスのために使いたいの だが、完全なP2P型以外のIMPGでは、 サーバシステムの運用費用が大きな負担となる。 次節以降では、 システムを維持するためのコストと、 コンテンツを拡張・メンテナンスしていくためのコストについて 別々に解説をしよう。

システムを維持するためのコスト

IMPG サービスを維持していくための、 サーバ周辺で必要なコストには、どのようなものがあるだろうか。

IMPG サービスでは、クラスタリングを採用してコストパフォーマンスを 向上させようとするアプローチが有効なことは第1回でも説明したが、 クラスタリング方式を使う場合に考えるべきいくつかの指標、 ここでは、「計算能力密度」「回線速度」「同時接続数密度」「クエリー頻度」 などといった指標について、説明をしよう。 これらはお互いに深く関係していて、 すべて、システム維持のためのコストに直結しているのだ。

計算能力密度

これを表すために汎用的に使われている単位を私は知らない。 適当に、 qps / U とでも命名しよう。 qps は "query per second"で1秒間に処理できる要求の数、 UはユニットのUだ。 Uとは、汎用的に使われているデータセンターのラック単位である。 Uは体積に比例した値であり、 高さ約 43ミリ×奥行き約550ミリ×幅430ミリの、 「ちょっと長いピザボックス」を1ユニットと呼ぶ。 サーバマシン屋から発売されている多くのマシンが 1U のユニットに ピタリと納まるようにできている。

以下の写真はぷらっとホーム社の1U製品である（記事末のResource[1]を参照）。

1Uサーバの写真

このマシンの場合は 1.4GHz の Pentium3 が2個と 6Gbytesのメモリが1Uに 入っているため、なかなか良い qps/U を実現できそうだ。 ちょっと乱暴に、1GHz あたり 1000 qps だと換算すると、 このマシンの場合は 2800 qps/U が限界だ。

最近では、Compaq のマシンで 3Uの匡体に20個の Pentium3 0.7GHz を内蔵 できるものが安価で発売された。この製品の場合は、 14000 qps/U が実現できることになり、 単純に計算すると実に5倍のコストパフォーマンスといえる。

qps/U は日本のようにデータセンターの賃貸料が高い場所では 特に重要だ。 最近ではラック容積あたりのコストが土地の値段によって決まる水準に 近づいてきて下げ止まったことと、 データセンターは開発者から近いところにあるべきだということから、 qps/U の重要性はますます高まるばかりだ。

回線速度

ラック容積あたりのコストが下げ止まっても、 帯域(bandwidth)の値下がりはとどまるところを知らない。 この現象はまさしく「テレコズム」（[2]）なのだろうか。 私の目から見ると、 帯域の値段は、 純粋に市場での競争によって値下がりを続けるように見える。 中国、日本、米国の順で帯域あたりコストが高いのも、 競争の激しさに完璧に対応している。

同時接続数密度

これも一般的に使われる単位が見つからないので、 "ncp/U" (Number of Concurrent Players / Unit ) と適当に命名しよう。 同時接続数密度(ncp/U)とは、 「1U 当たり、最大何人のユーザーが同時にゲームプレイができるか」 を表す値である。 計算能力密度と、回線速度が、 ある程度市場の状況によって選択肢が固定されるのに比べて、 この値はコンテンツごとのビジネスモデルや、 ゲーム内容に左右され得る。 ディプスファンタジアの場合はマシンの限界に対して大分マージン をとって 700 ncp/U に設定している。

クエリ頻度

一般には query per second (q/s、qps) と言われる。 1個のユニークユーザーが、1秒間にどれだけの数のクエリを サーバに対して送信するかをあらわす値である。 もうお分かりだと思うが、 要求される計算能力と、同時接続数、クエリ頻度の3つの間には、 単純な関係がある。

計算能力 = 同時接続数 × クエリー頻度

以上の関係が成立する。 例えば1000人のユーザーが 4個のクエリを毎秒送信すると、 4000 qps が必要なので、必要なサーバ投資量が浮かび上がってくる。

以上、システムを維持するためのコストのうち、 特に重要な変数を紹介した。 IMPG のサーバ開発においては 設備投資を最小限にしようという力が非常に強く働くため、 「プログラムの処理速度」が全体の開発目標の中でも最も高い優先度を持つ。 サーバサイドに負荷を集中させるというパラダイムが、 CPUの能力を浪費して開発効率を向上させるというベクトルと逆を向いている のが面白い。

「これからゲームを作ろうとするのに、やれコスト比較だ、 やれ数値化だ、と机上の数字をいじって喜んでいるのはいかがなものか」 と感じるクリエイターは多いのかもしれない。 しかし、 これらの「極めて社会的な制約」をうまくクリアしながら、 オリジナリティあふれるゲームを作っていくこと自体が、 極めてオンラインゲーム的で面白いことなのではないかと、 私は思うのである。

コンテンツを拡張、メンテナンスするためのコスト

システムを維持するために必要なコストよりも、 もっと重要なのが、ゲーム内容をユーザーにとって面白く保つための、 変更や保安にかかるコストである。 ゲームに対する変更にはいろいろあるが、 ユーザーの興味を維持するためには、 とにかく新しい情報を追加していかなけれならない。 新しい情報には追加画像や、ゲームのルールを変更したりといったことが含まれる。 また保安には、 違法行為を繰り返すプレイヤーを追放したりといった作業が含まれる。 これらの作業には、いったいどれぐらいのコストが必要になるのだろうか。 そしてまた、低コストでユーザーを満足させるには、 どうしたらいいのだろうか？

この問題について考えるには、ゲームデザイン論に深く立ちいる必要がある。

ゲームデザインに関して語ることは非常に危険だ。 下手をすると論者の主観的なメッセージだらけになってしまいがちだからだ。 しかし、思考対象を「IMPGプレイヤーを低コストで満足させるための仕組み作り」 と捉え直せば、かなり普遍的な議論に落とし込めると私は考えている。 特に、 「人間(プレイヤー)をコントロールするためのコスト」という考えかたは重要 だ。

次回以降、技術的な話題が一通りクリアされた後で、 私なりの「IMPGゲームデザイン論」を紹介しようと思う。 今回は、主な見出しだけを列挙しておく。 次回までの思考のネタにでもしていただければ幸いだ。

• コンテンツとは、何なのか
• 1円あたりのコンテンツ増加量
• 足し算ではなく、掛け算で増やせ
• ユーザーに仕事をさせろ
• 自動的に変化させよ
• 確率を使え
• 物理法則
• コミュニケーション性を最大化せよ
• データ量に依存するな
• 経済学

IMPG 開発におけるゲームデザインは、 実はこれまでの家庭用ゲーム機などにおける「普通の」ゲームでの デザインの延長上にある。「普通の」ゲームでも、オンラインゲームでも、 低コストでゲーム内容を奥深くするための方法は、共通のものがあるのだ。

筆者は特に、任天堂のゲーム作りは、 昔からオンラインゲーム向きのやりかたを踏襲していると感じる。 それはなぜなのか、ピクミンでもやりながら 考えてみるというのはいかがだろうか？

サーバトラフィック

IMPG サーバの負荷はクライアント端末から送信されてくるクエリ (トラフィック)の量だけで決まるわけではない。しかし、 サーバに対するトラフィックは、 サーバの性能を考える上で非常に重要な指標となる。 ここでは、ディプスファンタジアにおけるトラフィックのパターンを 紹介して、サーバトラフィックと負荷に関して、考えてみる。 ここで挙げていくデータは、ディプスファンタジアのフロントエンドサーバマシンで ピークアクセス時に、 tcpdump プログラムを使ってパケットをモニタリング して得た統計である。右軸がサイズで、上軸がパケット数である。

1台のフロントエンドに対して、毎秒1500程度のパケットが到着し、 ほぼ1パケットあたり1個のクエリ(操作要求)が含まれている。 ただし、フロントエンドからクライアントへの送信に関しては、 1個のパケットに複数のクエリが含まれている。 これはフロントエンドの実装に使用している VCE ライブラリによる パケット最適化が行なわれていることが原因である。

実際のアクセスにおいては、サーバが送信するパケットの数と、 受信するパケットの数はほぼ一致しているが、 この特徴は、TCPが「次のデータと一緒に、前のパケットに対するACKを送るよ うにする」という動作をすることが原因となっている。 参考までに、フロントエンドとバックエンドストレージとのパケットの 記録も掲載してみた。

フロントエンドがクライアントから受信するパケット数

クライアントからフロントエンドに送られてくるパケットの 分布は極端に小さいパケットに集中していることがわかる。 サイズを平均すると、44bytesとなる。 この小さなパケットの中身はキャラクターの移動で、 マウスクリックによって継続的に発生する。 それより大きなパケットはほとんどない。

フロントエンドがクライアントに対して送信するパケット数

フロントエンドが「キャラクターの移動」要求を受信したら、 ゲーム内の地理的に近い(画面内に納まる程度に近い)キャラクター に対して、移動要求を同報する。 通常、1回の移動要求に対して、複数のプレイヤーキャラクターに 移動を通知するため、 フロントエンドからクライアントへの送信のほうが、 クライアントからフロントエンドへの送信よりも数倍多くなる。 ディプスファンタジアでは、平均パケットサイズは 287bytesで、 受信の45bytesと比べると約7倍多くなっている。 単純計算で平均して約7人のユーザーが画面内に存在している ことになる。この比率は、サーバが混雑してくると大きくなる傾向がある。

フロントエンドがバックエンドストレージから受信するパケット数

フロントエンドはストレージに対してキャラクターの保存をするが、 ディプスファンタジアでは、キャラクターの読み込み1に対して 10以上の書き込みをする。また、1回のキャラクター保存は10Kbytes～20Kbytesの 範囲に入るため、1500bytesのMTU一杯のパケットが多量に発生する。 バックエンドから多数受信している小さなパケットは、 保存処理の結果パケットであり「保存できた」、「保存に失敗した」 という情報だけを返すパケットだ。

フロントエンドがバックエンドストレージに対して送信するパケット数

キャラクターの保存のためにデータを送るときのパケットである。 予想通り、1500bytesの MTU 一杯のデータパケットの比重が圧倒的に 高くなっている。

ディプスファンタジアのフロントエンドがクライアントから受信する パケットの分布パターンは、かなり一般的なものだ。 つまり、受信1に対して、7から8の送信を行ない、 小さなパケットがほとんどを占める。

ただし、ゲーム内容のうち、特に自動的に状態が変化していくような ゲーム内容がある場合は、クライアント端末から送られてくるクエリがなく ても、その変化をクライアントに伝えたい場合があるため、 送信パケット数もバイト数も増加することになる。

自動的に変化していく内容には、例えば ゲーム世界の中をモンスター(NPC)が常に徘徊していて、 生活を営んでいるといったことをしたい場合がある。 このような NPC の処理は、IMPG サーバの高負荷状態を招く代表的なものだが、 これによってゲームの世界観を構築できる面が多いので積極的に使われる。 うまく実装すれば、1プレイヤーの接続に必要な平均負荷の数十分の1程度の 負荷で、1体のNPCをコントロールすることができるが、 それによるトラフィックの増加が無視できない場合もある。

CPU 使用率

ここでは、 ディプスファンタジアのフロントエンドサーバが実際にどういった処理に CPU時間を費やしているのかを見るために、 プロファイリングして得られた結果から上位のいくつかを抜粋してみよう。

SSL暗号化

クライアントからフロントエンドへの通信はインターネットを経由して、 かつ重要なゲームデータやパスワードなどの個人情報が 含まれることから、完全暗号化されている必要がある。 このためにゲームサーバにおいて、暗号をデコードする必要が生じる。 ディプスファンタジアでは使用していないが、 VCE ライブラリを使ってこの部分の 負荷を外部のマシンに分離する方法もある。 VCE では、Diffie Hellman / Blowfish （[3]）を使っているが、 巨大な整数の計算などが必要なため、この部分の計算負荷はかなり高い。

キャラクターデータ圧縮(pack)処理

ディプスファンタジアのキャラクターデータは、 アイテムの性質から、1キャラクターあたり数百Kbytesというサイズになる。 このまま保存するとバックエンドのネットワーク資源や ディスクアクセスなど、 データベースの性能を圧迫するので、圧縮をした上で保存している。 キャラクターデータの中身はゼロビットが多いので 10Kbytes～30Kbytesに小さくでき、 バックエンドのパフォーマンス向上に寄与しているが、 その反面、フロントエンドに負荷をかけることになっている。 圧縮の処理をフロントエンドかバックエンドか、 どちらでやるべきかは、検討の余地がある。

ユーザー検索

各キャラクター(NPCも含む)が移動するなど 状況が変化したときには、 ゲーム世界の中で地理的に近いところにいるキャラクターに対して その状況変化を配信する必要がある。 各キャラクターは空間の中を自由に動きまわっているので、 地理的情報に関して、常に検索をし続けなければならない。 この処理は IMPG のサーバーにとって並列化しにくい代表格である。

NPC スクリプトインタプリタ

ゲームの進行を決定づけるのが、NPCによる会話や、 ゲームのフラグ操作である。 この部分は非常に頻繁に変更される上、 プログラマ以外のスクリプターと呼ばれる担当者によって 書かれることが多い。 そのため、通常このような「半データ、半プログラム」 のような部分は、動的に読みこんでプログラムから利用する という風に実装することがほとんどだ。 これは Web ページにおいて HTML を作成する担当者と PHP プログラムを書く担当者が分かれていることに似ている。 NPC のインタプリタも最適化の余地がたくさん残されている。

上に挙げた4項目のうち、並列化できない部分は、 ディプスファンタジアの場合は実はユーザー検索の部分しかない。 またゲーム内容に本質的に関係しているのは、 NPC スクリプトのインタプリタの部分だけだ。 IMPG のサーバにおいて、ゲーム内容以外の処理がいかに多く必要か という事がわかると思う。これらの一般化可能な部分を、 どんどん外部化して、 1個のCPUの時間をゲームのためにフルに活用できるようにしていくことが できる。

フロントエンドサーバの今後

今後、さまざまな機器の登場や技術の向上によって、 間違いなく 1U あたりの同時接続ユーザー数は向上する。 おそらく 3000 ncp/U とか 5000 ncp/U といった効率が 数年以内に実現できると考えられる。 その結果、設備投資の必要量が現在にくらべて数分の1に減少する。 この段階になると、もはやほとんどのゲームがネットワーク対応となり、 さらにそのほとんどが MMO（Massive Multiplayer Online game）型、もしくはハイブリッド型を採用することとなる。

こうした環境下では、 ゲームのクリエイターはより多くのCPU能力をゲーム本体の処理に使い、 リアルな物理法則や、動的な世界を実現 できるようになっていく。 ゲームを作る楽しみのひとつには、誰も 見たことがないような空間をサイバースペース内に作り、 そこでいかにプレーヤーを楽しませるかということがあるが、 サイバースペースの表現そのものがネットワークによって格段に 多様性に富んだものになっていくわけだ。ゲームを作る楽しみもまた、 格段に大きくなる。 今後数年間はゲームクリエイターにとって今まで以上に 興奮に満ちた期間になりそうだ。

第3回のまとめ

今回は IMPG サーバの実装に関して、 プログラミング手法以外の部分を簡単に説明した。 筆者が多忙のため執筆に多くの時間を割けないのが残念だったが、 プログラミングにおいても何が大切か、 今後何が大切になっていくかについて、 少しでもイメージを持っていただけただろうか。 次回連載では、 フロントエンドサーバの実装に関するさらなる詳細か、 ゲームデザインに関する議論のどちらかを取りあげる。 ゲームデザインに関しては、 実際に今後オンラインゲームを作ろうとしている日本や海外の クリエイターたちにも登場してもらうことにしよう。

Resource

ぷらっとホーム「Trus シリーズ」

http://www.plathome.co.jp/factory/tru/

テレコズム - ブロードバンド革命のビジョン

George Gilder著/葛西重夫訳/2800円(税別)/ISBN4797318392/ソフトバンクパブリッシング/2001年11月
原著は「TELECOSM:How Infinite Bandwidth will Revolutionize Our World」(ISBN-0684809303)

Blowfish

http://www.counterpane.com/

エクストリームプログラミング - 変化ヲ抱擁セヨ

http://objectclub.esm.co.jp/eXtreameProgramming/index.html

サーバサイドJava初心者のためのWebシステム入門

http://www.atmarkit.co.jp/fjava/rensai2/websys01/websys01.html

コンパックコンピュータ株式会社「Compaq ProLiant BL 10e サーバブレード」

http://www.compaq.co.jp/products/server/bl10e_sh.html

2002年5月 LinuxJapan初出
インサイド・オンラインゲーム　第1回　はこちら
インサイド・オンラインゲーム　第2回　はこちら

PDF版はこちらからダウンロード

前回予告した通り、今回は、各所で仕事をしているゲームクリエイター やゲームプレーヤーの意見も聞きながら、 オンラインゲームのゲームデザインに関して、 話を進めてみる。ゲームのデザインに関しては これまでにも何回か引用をしてきている「ゲームデザイナーズバイブル」 という本があるが、 そこでも触れられていないような考察をすることを目標にしよう。

ゲームデザインについて語る場合、たいていは大成功したゲームの プロデューサーや開発者が自分の体験に基いて語ることが多い。だが 筆者の場合は彼らとはかなり立場が異なり、 オンラインゲームタイトルを直接作るのではなく オンラインゲーム用の開発ツールやライブラリを作るという仕事に 携わっている。非常に多くのゲームクリエイターと接触して ゲームに関するアイデアを交換する機会があり、 そのようなやりとりの中でゲームのクリエイターや開発会社の 経営者、エンドユーザーなどあらゆる人達の意見を聞き、 成功したプロジェクトや失敗したプロジェクトの話を聞いて、 多くの事例を比較することができる。 本稿ではできるだけそういった各方面の事例を用いることにより、 「これがベストだ!」とか「こうすべきだ!」という結論を得る ことを避けるが、読者が自分で「ゲームデザイン」について考えるための材料を提供できればと考えている。

まず外側から

まず今回は、オンラインゲームのデザインを目指して、 社会的、経済的な側面、つまりゲームを取り巻く「外側から」 いろんなトピックを取りあげてみることにする。 もちろん、「これが最高」という単一の結論は得られるはずもないが、 オンラインゲームが満たしていなければならない条件や、 まだ試されていない分野などが発見できるかもしれない。 オンラインゲーム作りにどっぷりと漬かるのもいいが、 たまには外側から眺めてみることもよいだろう(と自分に言いきかせる)。

オンラインゲームに求めるもの

オンラインゲームのユーザーは、一体どんな動機によってゲームで 遊んでいるのだろうか？ また、これからオンラインゲームをやってみようという インターネットユーザーは、 オンラインゲームに対して何を 求めているのだろうか？

最高なオンラインゲームの像を見つけだすためには、 ゲームのユーザーが何を求めているのかを知る必要がある。 オンラインゲームとは芸術作品ではなく、 商業的な成功を願うサービス業。 ゲームのエンドユーザーがオンラインゲームについてどう感じ、どう接しているのかがとても重要で、 しかし直接意見を聞いてみないとエンドユーザーの気持ちはこちら側に伝わってこない。従って 今回はできるだけ多くのエンドユーザーの意見を聞いてみることにした。

コミュニケーション

筆者のようにオンラインゲーム開発に携わっていると、 自然と自分の周囲にはコアなオンラインゲーマーが多く集まり、偏った環境になりがちなので、 今回はできるだけ公平な意見を得るためにも、 現在オンラインゲームをやりこんでいる最中のユーザー、 用語は知っているがプレーしたことがないユーザー、 そもそもオンラインゲームという単語を知らないユーザーなど、 各種のユーザー層に取材してみることにした (ただし、オンラインゲームという単語を知らないネットユーザーはいなかった)。 そしてできるだけだが女性／男性と複数国(台湾、韓国、米国のIRCチャンネルなど) のネットユーザーを対象としての取材も試みた。

取材をしていく過程で特徴的だったのは、 オンラインゲームという単語を知っているがまだ プレーしたことがないユーザーも、 オンラインゲームを現在プレーしているユーザーも同様に 「オンラインゲームは、誰かとコミュニケーションをとるための場である」 という認識を持っていることだ。 また彼らに、「ゲーム内容が面白いことと コミュニケーション性とどちらが大事か」 という質問をしてみたところ、彼らは その質問に答えることは難しいと言いながらも、 コミュニケーション性が高いことのほうが重要であるというような答えを返してきたのだ。 もちろん、ゲームが面白いほうがコミュニケーションに対する モチベーションが上がりやすくなるはず、と分析するユーザーも多かった。

というわけで、 オンラインゲームに求める基本的なものの1つとしてコミュニケーション性の重要性があることは 間違いないといえるだろう。どうやらオンラインゲームのゲーム内容は、 コミュニケーション性を最大に生かせるような内容を 目指すのがよいようだ。 家庭でインターネットを使うユーザーが、 日々の生活を他人とのコミュニケーションをして楽しく過ごすための ツールととらえている傾向が強いことからも、 ごく自然な結論なのかもしれない。

なぜまだオンラインゲームで遊んでいないのか

インターネットを日常的に使っているネットユーザーのうち、 オンラインゲームで遊んでいるユーザーの占める割合は日本では 非常に小さい。 国によって様子は異なるが、韓国以外のほとんどの国では、 インターネットを使うユーザーのほとんどは、 オンラインゲームをしない。 その理由で一番多いのが、「ゲーム自体に興味がない」 というものだ。「ゲームよりも面白いことがある」、 「忙しい」といった理由もほぼ同じ割合であった。

近年ではコンシューマーゲーム機の家電化によって、 ゲーム自体に興味がない層をもゲームの世界に取りこむことを目指したゲーム 作品がいくつも登場している。例をあげると、映画のようなゲームや 「エデュテインメントソフトウェア」と言われるものだ。 オンラインゲームでも「コミュニケーションツールとして使える」、 「友達を作れる」といった、既存のコンピューターゲームにはない 特徴を利用したデザインとマーケティングを導入することによって、 オンラインゲームに興味がない層を取りこんで市場を拡大する ことができるかもしれない。 特に日本市場はゲーム以外の娯楽が豊富で、インターネット上にも 音楽や映像など各種メディアが進出し始めているので、 インターネットユーザーの目をオンラインゲームに向ける努力をしていくことが、今後この業界でも 必要であるように感じる。

遊ばない理由

オンラインゲームに興味はあるが遊んでいないというユーザーもまた、 非常に多い。これらの人々は以下のような理由を挙げている。

• インターネット接続自体に金がかかりすぎる。
• ゲーム代金を支払うのが面倒くさい。
• オンラインゲームは時間がかかりすぎる

これら3つの問題に関しては、それぞれたくさん考察できる余地がある ので、1つ1つ取り上げてみることにする。

接続コストの問題

オンラインゲームをプレーしたいのにできないという問題のうち、 最も基本的なのが、接続コストの問題だ。 幸い、最近の日本ではブロードバンド化がものすごい速さで進んでいるので、 数年以内には 日本でもインターネットへの接続代金は水道代やガス代と同じような 扱いになるだろうから、今後数年でこの問題は解消されるだろう。 特にIPv6の普及によって、料金の低下は仕上げの段階を迎えるはずだ。 現在の接続料金は、おなじ100MbpsでもIPアドレスのタイプによって、 9000円(ローカルIP)から12万円(グローバルIP 16個)まで幅があるが、数年後にはおそらく それがすべて最低のものと同程度の水準に落ちつくことになる。 高速な接続環境が安く手に入るようになってしまえば、 「遅い回線でもプレーできるように ゲームデザインを調整しなくてはならない」といった手間や必要性は今後さらに薄れていくだろう。

ゲーム代金を支払うのが面倒くさいという問題

現在、日本では小額のリアルタイム決済ができる環境が 全くといっていいほど整備されていない。 今のところISPなどの企業が独自で発行している 「ポイント」か、ごく限られた利用方法を強いられる「デビット サービス」などを使用してしかリアルタイムの小額決済はできないのである。 そして企業が発行している「ポイント」を使う場合、 日本円からポイントへの変換という手間が必要である。 ポイント以外にもクレジットカードや携帯電話の課金システムを 使うという方法もあるが、 クレジットカードを使う場合は、手数料が高いという問題があり、 携帯電話の課金システムはキャリアの問題や、公認サイトの認定問題がある。

とにかく課金まわりの整備は、法制度や政府の体質など、 様々な外部要因が整うことが必要だとなっているのだが、 日本では金融まわりの社会システムが他国に比べて悲しいほど遅れているので、 自動的にネット上での金融社会も遅れをとってしまっているのだと思う。

このような課金システムを使う手間は、ユーザーにとって オンラインゲームサービスを利用するための実質的なコストとして 見えてしまう。それらを金額に換算してみると、どれぐらいになるだろうか？ 認証の手間の経済効果については、客観的な調査をした例は見つからないので 筆者の印象で申し訳ないが、日本円からポイントへの変換のために 複雑なWebページを操作したり、個人情報を入力したり、 コンビニエンスストアにプリペイドカードを買いに行ったりするということで、 大学生以下の学生の場合で数百円、社会人の場合は数千円の 追加コストに値すると思う。 だとすると、面倒くささを受けいれるための心のコストのほうが、 ソフトの利用料金よりも高くなってしまう場合さえありうるのだ。

理想的には、サービスを利用開始した後で より良いサービスを受けたくなった場合には、 1クリックで課金され利用可能となるシステムが実現されればよいのだが、 これを実現するためにはMicrosoftの .NET や Sun の SunOne 、ベリサイン のような「シングルサインオン」が必要となってしまう。 日本では携帯電話における ハードウェアと接続方法と課金が一体となった形でのみ シングルサインオンがすでに可能だが、 この形態はすごく未熟なものであることは、言うまでもない。

ゲーム時間の問題

「オンラインゲームは時間がかかり過ぎる」という問題は、実は、ユーザーがゲームプレーに満足するまでに かなりの時間が費やされてしまうということである。ヒマなときにしかできないというような問題よりも、 もっと大きな問題を含んでいる。 その問題とは、オンラインゲームのゲームデザインが、 ゲーム業界の萎縮を引きおこしかねない、という問題である。

消化時間最大化デザイン

ネットワーク対応のゲームは、ほとんどの場合、 プレーヤーがすべてのコンテンツを消化するのにかかる時間が最も多く充てがわれるように ゲームデザインされている。 特に「ウルティマオンライン」に代表される、 MMOタイプのキャラクターが成長するタイプのゲームではその 傾向が顕著である。 まるで、「プレー時間＝キャラクターの成長」と言わんばかりである。

ゲームサービス提供者側が、ゲームプレー時間を最大化させたい理由。 それは、プレー時間というファクターを使って課金処理をしているからである。 オンラインゲームを提供する企業から見れば、 自社の売上げを大きなものとするためには、 ユーザーが接続してプレーする時間を最大にすればよいからだ。 そのため、「消化時間最大化ゲームデザイン」は、 至極当然なことなのである。 だが、筆者はこの「消化時間最大化デザイン」が オンラインゲーム市場を縮小／萎縮させてしまう のではないかと危惧している。

消化時間最大化デザインによる市場縮小が起こるしくみは簡単である。 まず、ゲームユーザーの持っている「可処分時間」は最大でも1日に1～3時間程度と、 非常に限られているわけである。1日2時間として単純に計算すれば、 ゲームプレーヤーは毎月 2時間×30日 = 60 時間 の時間をゲームに使うことができる。

ゲームをよく購入するユーザーならなんとなく気づかれているかも しれないが、１人で遊ぶ用のゲームは、どんな内容の濃い大作でも、 およそ百数十時間でコンテンツの内容をすべて消化できるようにデザインされている。 メガヒットするゲームでも、 短かいものだと10時間程度で、いわゆる「クリア」ができるようになっている。 ということは、ゲーム市場に対して各企業から1～2ヶ月に1本の 大作を投入しても、各ユーザーはすでに前作のゲームをクリアしているので、 発売となった新作品を購入するときには、 ユーザーは自分の財布の中身と相談するだけでよいことになる。 コンシューマーゲーム機市場のこのような動きを、 「消化時間の自粛」と命名してもいいかもしれない。

ところが、ウルティマオンラインに代表される 「消化時間最大化」デザインに基くゲームの類は、100時間どころか、1000時間でも 1万時間でも絶対に「クリア」できず、プレーヤーがゲーム自体に対して 興味が尽きるまでゲームをプレーすることができてしまう。 つまり、次の作品が出たときに、自分の財布の中身と相談するだけでなく、 まだクリアしていない前のゲームとも相談することになってしまうのだ。 単純に言えば、まだ前のゲームをクリアしていないユーザーに、 買い控えが発生してしまうのだ。 ゲーム業界全体としては、「消化時間最大化デザイン」 に基づくゲームが増えると、 単位時間あたりのユーザーが払う金額が低下して、 収益性が悪くなるという結果が付き付けられるのである。

この状況は極端な場合を挙げると分かりやすい。 クリアに30時間必要な6800円の値段がついた大作が毎月発売されるだけのゲーム市場と、 毎月一律1000円でプレーできるオンラインゲームしかないゲーム市場とでは、 1人のユーザーが1年間にゲーム業界に対して支払うことができる金額は、

前者の場合は 6800円 × 12ヶ月 = 8万1600円
後者の場合は 1000円 × 12ヶ月 = 1万2000円

となり、収益性に圧倒的な差が出てしまう。 オンラインゲームの開発は、そうでないゲームの開発よりも難易度が高く、 発売後もサービスの提供をし続けなければならないなど高コストの要因が 多いにも関わらず、収益性が既存のものよりも悪化してしまうのだ。

もしも「すべてのゲームをオンライン化する」というどこかの ゲーム機プラットフォーム会社の言う通りに すべてのゲームを何の工夫もなくオンライン化していくと、 ゲーム業界全体が萎縮してしまって、 より面白く内容の濃い、そしてサービスもいいオンラインゲームを ユーザーに対して提供できなくなってしまう可能性が高いのである。 オンラインゲーム業界に新規参入する企業が、もしも業界の将来性など に関して考えが及んでいないとしたら……。

今回取材したあるゲーム開発会社の経営者の意見では、 オンラインゲーム開発会社がやっていけるだけの収益性を保つには、 現在の3倍以上の価格水準(一律の場合)に変更することが必要とのことだ。 各社が安い料金でゲームサービスを提供している中で 1社だけでそのような値上げをするのは、無理があるだろう。

オンラインゲームの利用料金に関しては、 ウルティマオンラインを作ったリチャード・ギャリオットが言った 「私がした大きな失敗は、ウルティマオンラインの利用料金を、 月額一律の9ドルに設定したことだ。」というセリフが有名だ。 彼はウルティマオンラインをリリースした後で、その値段設定が、 将来の大きな問題を生むことを自覚したのかもしれない。

どうすればいい？

消化時間最大化デザインが引きおこす問題を解決するには、 どうしたらいいのだろうか？ 業界団体を作って自粛を呼びかけるなどといった単純な方法では、 アジア諸国のベンチャーが市場で重要な位置を占めている状況では ほとんど現実性に乏しいだろう。 より高度なゲームデザイン上の工夫と、 ビジネスのプランとの連携で自然に解決すべきであると筆者は考える。

本連載でこれまでにも繰り返し述べてきたが、 オンラインゲームの企画／デザイン／開発のすべての段階では 社会経済的な要因を常に考えあわせて仕様を検討すべきなのだ。 ところが現在市場に流通しているほとんどのオンラインゲームは、 ゲームデザインにおいてもマーケティング戦略においても、 在来の非オンラインゲーム開発のノウハウをベースに構築されており、 業界全体の市場の大きさや収益性については後回しにされているのが現状なのである。 これらの要素を後回しにしておくと、 数年後にかならず自社のゲームに対して悪影響が及ぶ。

市場の成熟

このようにオンラインゲーム市場はまだまだ未熟な点が多いので、 新しいゲームのアイデアとビジネスの方法を駆使して、 より競争力の強い作品を投入していかないと、 市場全体の成長の芽をつむことになってしまいかねない。

韓国や米国などオンラインゲーム市場が成熟して競争が激化している地域では、 すでに一律のサービス料金システムを廃止して、 ユーザーの満足度を課金の量に対応させる試みが進行している。 これらの試みはすべて、 ゲーム内容と課金方法をより密接に結びつけるものとなっている。 今後、日本でもオンラインゲーム市場に参入するときに参考になりそうな 方法を以下に紹介してみよう。

課金プランを複数種類にする

ゲームサービスの内容の濃さに応じて、 ノーマルプラン(月額1000円)とスペシャルプラン(月額3000円) のように複数のプランを設けて、コアなユーザーから納金ルートを確保する。

ゲーム内の権利を直接購入する

たとえば「やくそう」を8ゴールドで買うのではなく、 8ドルでゲーム提供企業から実際に購入する。 ゲームの内容に直接関係のあるアイテムなどをこの種の取り引きの 対象にすると、ゲーム内容やゲームデザインにあまりに深く響くので、 ゲームの進行に関係のない自己主張やメッセージング のためのオプションを購入するようにするとよいだろう。

接続は無料、パッケージを有料で売る

アジア地域では成立しにくいが、北米や日本で Diablo シリーズほか、多くのゲームが伝統的に採用している方式である。 サーバ投資が少なくてすむP2P接続タイプのゲームにおいて、 オンラインプレーのためのロビー利用を無料で提供し、 パッケージを5800円～8000円といった価格で販売するモデルである。 この方法はネットワーク対応ゲームの高セキュリティ化、つまり MMO化、ハイブリッド化の流れに沿って減る可能性は高いが、 PlayStationなどコンシューマーゲーム機や携帯端末など セキュリティ上有利な点を持っている環境では、 かなり先まで残ることになるだろう。

サービスを交換できる市場を作る

韓国では、ゲーム内と現実世界の財やサービスを交換できる仕組みの実現まで、あと1歩と接近しているようだ。 現在、ゲーム内の財やサービスの移動や集約に対しては、 国家からもゲーム提供企業からも課税されないので、 ゲーム内の市場はユーザー間で取り引きをするのに非常に都合がよい。 単純にゲーム内のゴールドを日本円に交換するのは法律が許さないが、 もしもゲーム内の100ゴールドを支払えば近所の温泉に1回 入れるとか、Webストレージの代金をゲーム内のゴールドで 支払うとか、ゲームの100ゴールドがヨドバシカメラの100ポイントになる というような機能が実現すれば、 そこには非課税の取り引き市場が発生することになる。 現在の日本ではポイント同士の交換は許されないが、最終的なターゲット市場である海外ではこの限りではない。 もちろん長い目で見ればこのようなシステムが放置されるはずはないので、 何らかの課税システムが導入されるだろうが……。 ゲーム内の財産に関しては面白い動きがある。 東京都でカジノが合法化されるのがいま話題になっているが、 もし日本でもゲーム内の財産を合法的にお金に変換できるようなことになれば、 ゲームのありかたが全く違ったものになる可能性もある。 例えば、パチンコ産業にお金を落としているユーザー層の一部が、 オンラインゲームに流れてくることになるかもしれない。

以上のように、オンラインゲームを取りまく環境は激変を続けていて、 それぞれの要素がゲームデザインにも深く影響を与えている。 今後オンラインゲームに携わるクリエイターは、 そのあたりの社会情勢にも常に注意を払っておく必要があるのだ。

ゲームデザインの重要性

エンドユーザーへのインタビューでも分かったことだが、 オンラインゲームにおいては、画像の美しさや有名なキャラクター などよりもコミュニケーション性が評価の基準となっている。 コミュニケーション性を高めるためには基本的なゲームデザインが 優れていることと、洗練されたユーザーサポート、 そして継続的なコンテンツの追加が必須となる。

オンラインゲームを商用運用していくためには、 ユーザーサポートやコンテンツ追加のコストをできるだけ低く抑える 必要があるが、そのために最も効果的なのは、 それらの低コストに対応したゲームデザインをする ことなのである。

次号では、よりオンラインゲームに向いたゲームデザインは どういったものになるのかについて、さまざまな例を挙げつつ紹介したいと思う。

2002年6月 LinuxJapan初出
インサイド・オンラインゲーム　第1回　はこちら
インサイド・オンラインゲーム　第2回　はこちら
インサイド・オンラインゲーム　第3回　はこちら