unoh.github.com

FarmVilleの開発 - FacebookのNo.1ゲームを5週間で作りあげスケールさせた手法

Mon Dec 06 06:26:48 -0800 2010

こんにちは、五十川です。

2010年12月1日に、ウノウがジンガジャパンとなってから初めてのタイトルとなるファームビレッジがリリースされました。ファームビレッジはFacebookで永らくNo.1の座にあるFarmVilleの日本語版ですが、先月そのFarmVille開発のリーダーで、現在はZyngaの共有テクノロジーをリードしているAmitt Mahajanが来日していました。

今回ご紹介するのは、そのAmittが2010年3月のGame Developers Conference(GDC)で行った、Rapidly Developing FarmVille - How we built and scaled a #1 Facebook game in 5 weeksと題したプレゼンテーションです。今回Amittの許可を得てそのときのスライドの日本語版を作成しましたので、それに解説を加えてご紹介したいと思います。

なお、スライドのオリジナルはGDC Vaultからダウンロード可能で、Rapidly Developing FarmVille Presentation - Amitt's Spaceに掲載されているリンクから直接ダウンロードできます。スライドの言葉は簡潔なものが選ばれる傾向にあり、そのまま訳しても意味が伝わらない場合が往々にしてありますので、日本語版の作成にあたって意図的に言葉を変えている点が多々あります。もし翻訳について疑問に思われる箇所がありましたら、オリジナルを参照ください。

FarmVilleの開発 - FacebookのNo.1ゲームを5週間で作りあげスケールさせた手法

スライド5までは特に解説は必要ないと思われますので割愛します。なお、ここに登場する数字はいずれもこのプレゼンテーションの作成時点、つまり2010年3月の時点のものである点にご注意ください。

スライド6-9 開発の効率化

ここではデベロッパーの作業が遅延する要因とその対処が述べられています。

まず「他のデベロッパーとの協業」ですが、一般的にPC向けのソーシャルゲームでは、クライアントはFlash、サーバは、Zyngaの場合はPHPと、異なるスキルが必要になります。もしデベロッパーがいずれか一方の知識しかない場合は、もう一方のデベロッパーとの協業が必要となり、これが往々にして作業を遅延させる要因になり得ますが、FarmVilleのデベロッパーはいずれもこれら両方のスキルを持っており、こうした問題が回避できたということです。実際この両方のスキルは、現在のZyngaのすべてのデベロッパーに求められるものになっています。

また、通常デベロッパー以外が担当するもの、つまりゲームの仕様であったり、画面デザインなどのアートワークや、そこに表示するストーリーやメッセージなどのテキストといったものが、デベロッパーの作業を妨げる要因として挙げられています。これらが決まらないためにデベロッパーの作業が待ちになってしまうという事態は往々にしてあり得ることですが、まずこのうち仕様については、通常はゲームデザイナーのみがこれを担当しますが、FamVilleではデベロッパー自身もこれを担当できる裁量が与えられました。スライド中の「ゲームデザイナーがすべてを支配しない(Design DOESN'T rule all)」というのがこの箇所です。また、データ主導のゲームデザイン(Data Driven Design)という考え方のもと、ゲームデザイナーがデベロッパーの手を借りずに自らゲームの機能をコントロールできる仕組みが採用されています。これは例えば、ゲームデザイナーが容易に編集できるXMLファイル等にゲームのパラメーター等を分離しておくといった、ごく簡単な方法によって実現できるものです。これと同様に、ストーリーやメッセージといった文字列をプログラムから分離してことで、ゲームデザイナーがそれを容易に変更でき、デベロッパーにとってはその決定や変更に作業を妨げられることがなくなります。これが、スライド中で「文字列テーブル(String Table)」と呼ばれているものです。これはもちろん、国際化を前提としたプログラムにおいてはお馴染みの手法ですが、それ以外にも、特にFacebook向けのゲームの場合には大きな意味を持ちます。Facebookではゲームに対する規約が非常に細かく定められており、かつそれが突然変更され、限られた期限での対応を求められるということがしばしば起こるのですが、こうした手法を用いることで、このような対応が容易になるというわけです。

スライド10-12 抽象化されたネットワークレイヤー

ここではクライアントとサーバーの連携について述べられています。Zyngaのゲームアーキテクチャーにはクライアントとサーバーを効率的に連携させる、抽象化されたネットワークレイヤーが用意されており、デベロッパーはこれを利用することで、その実際の連携処理を意識する必要なしに、アプリケーションを容易に実装できるようになっています。

スライド13 ソーシャルネットワークラッパー

FacebookのAPIリクエストはソーシャルネットワークラッパーと呼ばれる仕組みの中に一元化されています。FacebookのAPIはその仕様が頻繁に変更されるため、こうして一元化しておくとその変更への対処が容易になります。また、Facebookに限らず、様々なソーシャルネットワークごとに異なるAPIの実装を、ここで共通のインタフェースでアクセスできるようにしておくことで、クロスプラットフォームへの対応が容易になります。

スライド14-15 QAプロセス

スライド全体の締めで言われているように、ソーシャルゲームはマラソンであり、常に改修を加え新しい機能を提供し続けていくことが重要ですが、これらを早期にかつトラブルがないようにリリースするためにはQAプロセスが重要になります。FarmVilleでは、Facebook上に用意したテスト用アプリに対して、ソースリポジトリーの最新版が自動テストを経てビルドされる仕組みを構築しており、そこでのスモークテスト、そしてステージング環境でのフルテストを経て本番環境にリリースされるというプロセスを採用しています。

スライド16-19 サーバーアーキテクチャー

スライド16にあるように、FarmVilleは20週連続で毎週100万ずつDAU(デイリーアクティブユーザー)が増加するという、驚くべき成長を遂げました。こうした急激なトラフィックの増加に対して、いかにきちんとスケールするサーバーアーキテクチャーを構築するかというのは、ソーシャルゲームの最も重要なポイントのひとつとなっています。スライド18に示されているFarmVilleのアーキテクチャーは、一見ごく常識的なものに見えますが、実際はかなり大胆で野心的なアーキテクチャーとなっています。残念ながらここではその具体的な詳細に触れることができませんので、もしご興味を持たれたかたは是非Zynga Japanの人材採用に応募いただき、その一員になっていただきたいと思います(笑)

スライド19で述べられているのは、Zyngaのゲームアーキテクチャーではアプリケーションレイヤー、つまりゲーム本来の部分の実装を除くすべてのコンポーネントが共通化されており、新しいゲームを開発する際にはアプリケーションレイヤーの実装だけに集中すればよいということです。デベロッパーはスケーラブルなバックエンドやネットワークレイヤー、ソーシャルネットワークラッパーなどがすべて用意された状態から新しいゲームの開発をスタートすることができるのです。

スライド20-23 ユーザーエクスペリエンスの向上

ここでは主にユーザーエクスペリエンスの向上について述べられています。ご存知の通りユーザーはゲームが自分の操作に素早く反応することを求めます。この障害になるもののひとつがFacebookのAPIリクエストです。外部へのリクエストは遅く信頼性にも乏しいため、FarmVilleではクライアントが直接APIリクエストを実行することを避け、サーバー側でリクエストを実行してその結果をキャッシュし、さらにそれをクライアント出力に埋め込むといった手法が採られています。同様にデータベースへのリクエストもキャッシュされ、またページプロファイラーと呼ばれる仕組みを使って、キャッシュされていないリクエストを監視することでそれを根絶するといった手法が採られています。

スライド24-26 障害への対処

それでもサーバーはダウンします。あるいはFacebookのAPIが利用できない場合というのもあり得ます。そのため、サーバーアーキテクチャーのすべてのレベルを冗長化し、それでも冗長化に限度があるデータベースや、そもそもコントロールが不可能なFacebookのAPIが機能しなくなってしまった場合など、あらゆる事態を想定して、最低限でも動き続けることを目指すというのがスライド24です。そのためFarmVilleでは、スライド25にあるように、すべての機能にON/OFFスイッチ(Kill Switch)を用意しています。そしてもちろん、こうした事態を早期に発見するためには、スライド25のようなサーバーの監視体制と、スライド26にあるようなユーザーの挙動についての仔細なトラッキングが重要になります。

スライド28 ソーシャルゲームは短距離走ではなくマラソン

ここで登場する「ソーシャルゲームは短距離走ではなくマラソン(Social games are a marathon not a sprint)」という言葉は、ソーシャルゲームを運用された経験をお持ちのすべてのかたが実感されていることでしょう。長い道のりを走り続けるためには、ローンチの前にはそれがきちんと動作することを確信し、(ちゃんと睡眠をとって!)余裕を持ってローンチすることが重要であるとして、このスライドは結ばれています。

The slide introduced in this article

Thank you Amitt for your kind permission of the translation!