2010年8月31日~9月2日にかけて行われていたCEDEC2010で、ソーシャルゲーム関連をセッションをいくつか聴講しましたが、そのうち有益だったと思う3セッションについてのメモです。そのうち他のメディアで記事になったり、発表資料そのものが公開されるかもしれません。

下記3セッションについて取り上げます。

大規模ソーシャルゲームのつくりかた ～60分でわかるサーバサイド技術～

藤本 真樹 （グリー株式会社）　ほか1名

2000万人を魅了するソーシャルゲームの作り方

吉田 大成 （グリー株式会社）　ほか1名

怪盗ロワイヤルができるまで、できた後

大塚 剛司 （株式会社ディー・エヌ・エー）

まとめページとしては下記がよさげです。

CEDEC　2010 記事&感想まとめ ※追記更新します – 3dnchus jimdo page!

今のところ確認している、他メディアへの掲載。

【CEDEC2010】各社が公開、大規模オンラインゲームのバックエンドの秘密 – GAME Watch

CEDEC 2010：「ソーシャルゲームは生き物」　「怪盗ロワイヤル」大ヒットの裏側 (1/2) – ITmedia Gamez

————————————————————————————————————————
大規模ソーシャルゲームのつくりかた ～60分でわかるサーバサイド技術～
藤本 真樹 （グリー株式会社）　ほか1名
————————————————————————————————————————

GREEの紹介
SNS+ソーシャルゲーム＋プラットフォーム
2059万人
11億デイリーPV
数千台のサーバー
同時接続10000くらい
レスポンス200msくらいを目安

コンシューマ向けオンラインゲームとの違い
コンシューマ：専用クライアント→Proxy→フロントエンド→バックエンド
ソーシャル：ウェブブラウザ→LVS＋Proxy→ウェブ→DB
結論：そんなに変わらない

（コンシューマ）
同期
ステートフル
世界の境界がある
低レイテンシ
アクセスは夜から深夜
コアゲーマー

（ソーシャル）
非同期アクセス
ステートレス
世界の境界がない
朝や昼もユーザーがプレイ
普段ゲームをやらない人もプレイ
アーキテクチャ

（GREEのサービス自体が）メンテナンスをしないというのも特徴

釣りスタの紹介
2007年5月リリース
エンジニア3人
最大同時プレイ人数は25万人←同時の定義は？

【釣りスタをコンシューマで作るなら】
釣り場ごとにFrontend Serverが存在する
ログイン時にバックエンドサーバーからデータをロードし、フロントエンド上のメモリに置く
状態変化したら更新＋その変更を他のクライアントにも速やかに伝える
即時反映の必要がなければ後から更新

こうするとリアルタイムのメリットがあるが、サーバーをまたいだ処理が難しくなるため、スケールに限界がある
バックエンドサーバーもスケールするように作らなければならない

【GREEの構成だと】
すべてのウェブサーバーは等価。Proxyは一番負荷の低いウェブサーバーにリクエストを割り振るだけ。
そうするとデータベースがネックになる
master情報、user、item,図鑑、rankingなどで全て別のデータベースサーバーにしている

かなりシンプルであるが、MySQLをスケーラブルにしておけば全体がスケール可能
情報をとること自体にコストがかかることを意識する必要がある

最近のソーシャルゲームは5キーを押すとゲームが進行します

モンプラでは
冒険に出る
元気が減って
経験値が増える
達成率が増える
他のモンスターエンカウントする

ただ、これをMySQLでやろうとすると更新処理が多すぎて破綻する

・・・ここで藤本さんに交代

RDBMSのボトルネック
ほとんどはdisk/io
write 15krpm RAID10 で2m-3mbytes/secが目安　readはオンメモリが前提
日々ディスクIOを同さばくかとの戦い

ソーシャルゲームはとにかくwrite heavy
リリース直後のダウンはほぼこれが原因
一部機能はSQLが複雑になりがち
ex 最近ここで魚を釣った友達
ex このアイテムを持っているバトル相手一覧

解決策
１ Sharding
２ diskにかかない　オンメモリファイルシステム
３ diskにあまりかかない　キャッシュ(memcached)や中間データ（KVS）の利用

MySQLのレプリケーションの解説　数十台のスレーブの例もあり

垂直に割る方法
水平に割る方法　同一テーブルを範囲ごとに分割する　Range, Hash/Modular, Index
JOINは基本的に全くしていない

データベースを分けるときに心得ていること　次の2点は担保しておく
・ユーザーの不利益にならないような順番でデータを更新する
・ログを必ず出すようにしておく

水平にShardingするとuser_id以外のconditionが制約になる
たとえばageなどで検索したい場合は？→（invert）転置インデックスを用いる　年齢をプライマリーにしたテーブルを別DBに作っておく
　
究極を言ってしまうと、tmpfsに全データを置いてしまうのが楽。 ioがネックになることはほぼなくなる
ただしサーバーダウンでデータロスト
もしやる場合、ラック単位はもちろんデータセンター単位で分散したりしている
適宜スナップショットをとる
トラフィック　12.5k x 1万qps = 1Gbps
Swap領域
データサイズ

GREEでは　I/OはKVSを用いる　Flare
RDBMSよりパフォーマンスがよい
運用コストが低い
Memcachedよりもデータ信頼性が高い
モンプラならレベルアップの段階でデータをFlushする

サーバーサイドのフロントエンドなポイント
構成の標準化が重要　（Real server or VM?）
たとえばJAVAのDAOに注意
GREEのDAO　DAO:table = 1:1
Shardingをサポートしたアプリプログラミング
SQLの実行時にシャードやテーブルを決定するインタフェース
コストの高い処理は非同期で
「〜さんが〜しました」等のお知らせにはQ4Mなどを使用

チート関連：手動ブルートフォース
モバイルユーザーのガッツは侮れない　場合によっては手分けして・・・
サーバー側トークン＋想定の1段〜2段上の厳しさでチェックしたほうがいい

CSRF対策
仲間を全て削除やステータスリセットへのリンク
主要な処理にはサーバートークンが必須
その他リロードや画面メモ対策など

slaveの切り離し・追加
・ウェブサーバー上のＤＢコネクション情報更新
・スタンドバイ機を利用
マスターが落ちたら
適宜自動化全スレーブでbinlogポジションが一致しているサーバーを用いる

無停止のために・・・
マスターの下にマスターを作ってそこでALTER TABLE　←　必要な場合、これは使える。ただ余分なサーバーが必要だが。

【チェック項目】
レプリケーション状態
遅延状態
テーブルデータサイズ
スローログ
スレーブへの直接書き込み
サーバートラフィック
時計がずれていないか？

質疑応答

ドリヅル　MySQLの簡単バージョン
これらしい
Drizzle (database server) – Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Drizzle_(database_server)

KVSの使用機会が増えている
tmpfsだとパフォーマンスは出るがアップデートログの書き込みすら追いつかなくてディスクへのフラッシュができない

————————————————————————————————————————
2000万人を魅了するソーシャルゲームの作り方
吉田 大成 （グリー株式会社）　ほか1名
————————————————————————————————————————

吉田さん
前職Yahoo
釣りスタ・ドリランド・モンプラのプロデュース

富田さん
前職スクエニ
モンプラのディレクター

6つの内製の中には1000万人を超えるサービスもある

１組織
２企画
３未来

### １組織 ###
垂直統合型スキルセットが必要。＋プロフェッショナルスキル
ゲーム業界は水平分業型。
少数精鋭のチーム体制
少人数によるスピード感
現場主義
プロフェッショナルチーム
同じものを再生産しない体制

・モンプラのケース
プロデューサー兼エンジニアｘ１
ウェブエンジニアx２
Flashエンジニアx１
ディレクターx２
インフラエンジニアx２
デザイナーx２

サービスと個人の成長を最大化する組織体制

データ駆動型アプローチ
1個人のセンスより数千万人のデータ
デザイン１つにもロジカルさを　
おもしろいと思うのはあなただけ
ゲーム開発者は自分がマイノリティであることを自覚すべき

PDCAサイクルの徹底
どの指標を改善するための企画なのか？
この企画により何％変化することを示す
実際にリリースしてみて何％変化したのか？
自分の企画精度を修正→それによってマジョリティ意識をもつ

データマイニングツール　GREE Analytics
登録日、登録経路、そのユーザーの利用状況→ＣＭの効果測定に利用
各イベントの参加率　プレイ率　消費率　アイテム別売上　ゲーム進捗状況　継続率などでゲームバランス調整

プロモーション効果を定量分析化

バナーやアイコンを何種類か試して一番よいものを採用

### ２企画 ###
企画三大モデル　集客・活性化・収益化　この3つが1つのサービスの中でしっかりカバーできているか
集客　ユーザーが集まり続ける仕組み
活性化　ユーザーが使い続ける仕組み
収益化　利益が上がり続ける仕組み
スーパーなどのビジネスのやり方とそう違わない

流入率ｘログイン率ｘ課金率ｘARPU

環境管理型アーキテクチャ＆ユーザーインタフェース
ルールや規制倫理ではなく、環境によって人間をコントロールされていると感じさせずにコントロールするシステム

ユーザーの迷いをなくし、選択と決断を連続的に行わせられるか

【集客モデル】
プロモーション（ゲームデザイン）ｘバイラル（ソーシャルデザイン）
誰もが知っているモチーフ＆誰もが理解できるゲームルール
釣り人口やペット人口や園芸人口などもリサーチしている

バイラルサイクル2種類
ゲームで遊ぶ→コインアイテムがほしくなる→友達を招待する
ゲームで遊ぶ→友達を一緒にあそびたい→友達を招待する

（参考）バイラル効果を可視化する
DAUx 招待率
招待送信UU x 一人あたり招待数
招待数 x 拡散率
招待受信UU x 承諾率
登録UU

【活性化モデル】
さまざまなゲームモデル
ユーザー間コミュニケーション
小さな達成感→→→大きな達成感というステップアップ
短期・中期・長期のゲームサイクルに欲求・達成感を配置

経験値ＵＰ　プレイ対価　レベルアップ　成長感　ロック解除　世界の拡大　コレクション欲求　コンプリート欲求

テキストより画像で履歴を表現　感情を画像で表現　←重要な気がする
あそばれた履歴を確認→ともだちの牧場を訪問→あそぶ→なつきがアップ→あそび履歴がもどる
運営者からのお知らせ　＜　友達からのお知らせ
コミュニケーション活性化は最大のリテンション効果

（参考）ユーザー間コミュニケーション効果を可視化する
DAU x あそび率
あそびUU x 一人あたりあそび回数
総あそび回数 x 拡散率
あそばれ率 ｘ 再ログイン率
再ログインUU

【収益化モデル】
納得のいく失敗　劇的な変化　ネットワーク効果　自己顕示欲の最大化

失敗→課金→劇的な変化
失敗に意味があること　失敗の画面が何より大事　効果が見た目で分からなければ二度と購入しない
細かいゲームバランスよりも課金機会の演出・効果の演出が重要
画像で表現　行動ポイントが無くなった→「おなかがすいた」→おなかがすいたキャラクターの表現　普通にテキストで出しても、行動ポイントが切れたことにユーザーは納得しない

協力型イベント　演出に凝る
競争型イベント
コミュニケーションを収益化　飴ちゃんetc

ユーザーの熱量を収益につなげる
ユーザーの成果を露出する面を増やす

ユーザー数が増えれば増えるほど収益力が上がる仕組み

### ３ソーシャルゲームの未来 ###
ソーシャルゲーム市場のとっても短い歴史
（１）多様なゲームモデル＆多様な世界観　プラットフォーム開放
（２）マルチデバイス対応　数年先を見据えた事業展開・サービス提供が求められる　2010年8月よりGREEiPhone版をベータリリース
（３）グローバル展開　2011年6月期中にアジアと北米拠点での業務開始予定

「ソーシャル化？」「新たな市場？」　→　ヒントは普段の生活に隠れている

——————————————————————————–
怪盗ロワイヤルができるまで、できた後
大塚 剛司 （株式会社ディー・エヌ・エー）
——————————————————————————–
２００９年６月からプロデューサー兼エンジニア
その他いくつかの内製ソーシャルゲームのマネジメント
今年の４月からはプラットフォーム事業担当

＜怪盗ロワイヤルの歴史＞
5月企画スタート
9/25ベータ
10/7正式リリース
12月mixi版開始
2010年4月チーム戦イベント開始
2010年5月戦国ロワイヤルリリース
2010年ヤフーモバゲーでもリリース予定

ソーシャルゲーム展開前は4半期の売上が90億円くらい

ソーシャルゲームプロジェクトにリソース投入
企画一週間　数多のソーシャルゲームを研究し、面白いと思うポイントを発掘
ラフ案2～30個　筋のよさそうなものを2，3個ピックアップ
設計　２，３週間　ゲーム構造を詰めていく　企画書の作成　パラメータの整理　ユーザービヘイビアの想定　バランスのシミュレーション

企画書段階では社内的に全く受けなかった

・ねらい
2，3時間に1分ぐらいずつやればゲームを継続的に楽しめるもの
盗む　盗まれる感覚のハラハラ・ドキドキ感をゲームとして携帯のゲームに閉じ込めたい
ターゲット　一般向け　やや男性向け

ゲームコンセプトに即した世界観　スタイリッシュ　善良な市民には害なし　殺さないなど　を設定し、デザイナー選定　キャラクター設定　クリエイティブ作成

・設計
構造設計　すべてのアクションに明確な理由を持たせるように各機能の関係性を整理
パラメータ設定　シミュレーションをして問題をみつけ再設計を繰り返す。

初期開発　1ヶ月　企画書で伝わらないからといって企画書をいくらリバイズしても先に進まない。とにかく作ってみせる
作って見せたものの　さっぱり受けがよくない。「つまらない」にいちいちへこまない。
仲間や相手がいないのでソーシャル性が成り立っていないのか。単にパラメータのチューニングがおかしいだけか？　ゲームの根幹要素が崩れているのか？
「トライ＆エラー」ボス戦はミニアクションゲーム型、ＨＴＭＬ型、Flash型と作っては壊し作っては壊し作っては壊し。バトルロジック：各種課題　レベル差バトル　ドキドキ感の演出などを作りながら考える。

ユーザーがどこの何にひっかかっているかを見極める。

ベータリリース～本サービス開始　
チュートリアル作り込み　最初の5分でユーザーに何を伝えたいか
→世界観に入り込ませる？　基本操作を理解させる？　ゲームの本質的な楽しさをどう伝える？

チュートリアル　パラメータ　画面遷移　基本構造を徹底的に見直す。
→詰まるポイントはどこか？　スケラビリティは担保されているか？　インフラ面　ゲーム構造面

大事なのはデータ分析
１，ユーザーとしてプレイしている中で違和感を感じた箇所についてチェックする　ユーザーとしての感覚から出てくる仮説を大切にする
２．データマイニング的に取る数字を決めておいて、おかしくなった数値に対して対処を行う

ここで大事なのはエンジニア。企画専任をいちいち通すよりもエンジニア自身が仮説をもってどんどん進めていくのが理想。

開始後3週間で、各タイトル合計で3億円の売上、45億PV
その後、インフラの試練が始まる。

サービス急成長機
伸び続けるトラフィックへの対応
ＣＭ出稿でさらに加速　モバゲー全体のトラフィック　
9月170億ＰＶ→12月380億ＰＶ→7月740億ＰＶ
機動的なサーバーの増設　アプリサイドの修正

ユーザー対応の工数も等比級数的に増加
初期開発2名→バグ修正・ＣＳ、イベント企画準備、各種チューニング　予期せぬ突発的事象への対応

その後　細かなブラッシュアップ
KPI
100万人登録時に月間コイン売上1億円を売り上げるための目安
継続率　ユーザー登録後　7日後、30％～40％
14日後　25～35％
30日と　20～30％
課金率（MAUに対する有料ユーザー比率）5~10%
課金単価 1500円～3000円

上記はあくまで基本的な指標。もっと細かいチューニングが必要。
「ゲームの盛り上がり」「ユーザーの飽き」をはかる仕様
「課金効率が高い」を確かめる指標は？

ユーザーリテンションを上げるには

画面遷移毎の脱落状況をチェックして修正
ウェブサービスであれば当たり前
これで直らなかったら？
ソーシャル性が効いているか
単にメッセージが送りあえることがユーザーにとって楽しいのか？
繰り返す行為がcomfortableか
ツモ要素、何かが上手くっている感覚、要素

継続率はあくまで結果指標。どういった指標を先行指標として追うかはゲームの特性次第
何でも短いサイクルで追えばよいというものではない

課金効率をあげるには
・ユーザーがシンプルに効果を実感できるか
・失敗例：効果が直接的でなくて分かりにくい
目標感が適切か
あせらし要素があるか　今しかない　届きそうで届かない　そのへんをしっかり煽る
課金率やARPPUはあくまで結果指標。課金の鉄則が守られているかをwatchする
数値ベースでは必ずしもはかれないものも考える
考えて分からなければ、試して結果を見てみる

怪盗の初期企画書
God Hand

企画書にとらわれないものづくり
作りながら考えるのが、ソーシャルゲームづくり