[CEDEC2014] 消滅都市のつくりかた半年で素敵なゲームをリリースするには -

Copyright © 2014 Wright Flyer Studios, Inc. All Right Reserved.
WRIGHT FLYER STUDIOS 消滅都市のつくりかた - 半年で素敵なゲームをリリースするには -

• 澤智明(33歳) – 消滅都市プロデューサー • 経歴 – 野村総合研究所に3年勤務(SE) – 2006年に社員20名くらいの頃にグリーJOIN • インターネットサービスのエンジニア, プロデューサー • ゲームプログラマー, ディレクター, プロデューサー自己紹介

• 消滅都市の事例をもとに半年で素敵なゲームを作るコツをお伝えします • 各セクション5名のリレー形式でお届けします本セッションについて

消滅都市ご紹介

消滅都市ご紹介 https://www.youtube.com/watch?v=tWY0mphZJUY

• 現代を舞台にした • おかげさまで1ヶ⽉で100万DL • まもなく新章追加, イベント追加消滅都市ご紹介

開発体制とスケジュール

開発体制プロデューサー 1名ディレクター 1名 PM 1名クライアントプログラマー 4名サーバープログラマー 3名アート 4名テクニカルアート 1名合計17名ゲームデザイナー 2名

スケジュール 2013年 10⽉ 2014年 11⽉ 12⽉ 1⽉ 2⽉ 3⽉ 4⽉ 5⽉プロト開発 α開発 - 主要機能完成 - β開発 - ひととおり完成 - 全社公開, 改善 QA G O A L 計7ヶ⽉アジャイルQA

消滅都市のつくり⽅ (組織・プロデューサー編) - 半年で素敵なゲームをリリースできた5の理由 -

消滅都市の作り方 (組織・プロデューサー編) 1. 良いと思った事は何でも実⾏する 2. チームワークを⾼める

1.良いと思った事は何でも実⾏する

1.良いと思った事は何でも実行する • 過去の⽅法を全て捨てる事から始めた – 脱Webゲームの成功体験 • 良いと思った事はすぐに実⾏して試した

1.良いと思った事は何でも実行する × 市場調査、モデル、分析、KPI、が最重要だ︕ ◦ ゲームの⾯⽩さ、新しい体験が最重要だ︕

1.良いと思った事は何でも実行する × 既にあるブランドのメリットを最⼤限活かすんだ︕ ◦ 新しいブランドを⽴ち上げてNativeゲームとして本当に、⾯⽩いゲームをお届けするんだ︕

1.良いと思った事は何でも実行する × 今まで使ってきた⼿法や技術をずっと利⽤すべきだ︕ ◦ 要件に応じて最適な⼿法や技術を選択すべきだ︕ SCRUM

• 過去や今までの制約にとらわれずに、良いと思った事は何でも実⾏してきました • 是⾮明⽇からもう⼀度、過去や制約をすべて忘れて他にもっと良い⽅法がないか考えてみてください 1.良いと思った事は何でも実行する

2.チームワークを⾼める

• チームビルディングを最重要視し、労⼒をいとわなかった – 良いゲームを作るために最重要な要素とずっと思って進めた 2.チームワークを高める

• 企画⽴案時にメンバー全員で納得するまで話し合って決めた – 企画だけでなく、プログラマーもアートも 2.チームワークを高める舞台が現代の作品は⾯⽩い簡単操作のアクションが好き謎と、ちょっとした恋があると熱中する

• 実は最初の案は王道RPGだった。。 – 流⾏ってるから。市場調査が主導の案 – プロト作るも、結果ボツに – 再度何を作りたいか皆で話し尽くした 2.チームワークを高める

• Vision/夢を語った、議論した – ちょっと照れくさかったけど。。 – 30枚の資料にまとめた – 2時間くらいひたすら語り合った 2.チームワークを高めるこういうゲームにしたい多くのお客様に遊んでいただきたい。家族に遊んでいただきたい。チームの全員が消滅都市を愛し、良くしたいと思うチームにしたい半年後こうなってたい

• SCRUMベースの開発で毎週結束を⾼めた – 担当チームによる⾒積もり – 毎週の振り返り • 建設的なだめ出しをする事も – 朝会、週次のセレモニー • プロデューサーからQAまで全員参加 • 密な情報共有 2.チームワークを高める

• とにかく多くのコミュニケーション • 積極的な⾏動、意⾒を絶対否定しない 2.チームワークを高める

2.チームワークを高める • バーベキューで結束を︕

結果、何が起きたか

• 結果１︓プログラマーが良かれと思って機能改善・追加 2.チームワークを高める

2.チームワークを高めるスマホは震えた⽅がいいんで、やっときました︕

2.チームワークを高めるかっこいいんで電⾞⾛らせました︕

2.チームワークを高める多くのお客様に快適に遊んでいただきたいので、コードを抜本的に変えて改善しました︕ Androidの⼀部端末で性能が出ないけど、コードフリーズ直前だし、このままかな。リスクを犯したくないはずのプログラマー⾃ら提案︕

• 結果２︓QAから仕様の提案 2.チームワークを高めるずっとQAやってて思ったんですが、このステージこうした⽅が⾯⽩いと思いました︕ レベルデザイナーとしてジョインしてステージを作ることに︕

• 結果３︓公式Twitterを勝⼿にメンバーが運⽤ 2.チームワークを高めるアカウントとりあえず作ったけど、公式Twitterの運⽤は、このマンパワーでは無理だ。運⽤はじめちゃいました︕ アイコンも作りました︕ 3ヶ⽉で約6,000ツイートいきました︕

• 結果4 – 写真撮影の息もばっちり 2.チームワークを高める

• 結果5 – 5⼈リレーの難しいセッションも時間ばっちり︕ 2.チームワークを高める

まとめ

• チームワークを⾼める︕ – 良いゲームは良いチームでないと産み出せない – とにかく労⼒をいとわない。何でもやる。 – 結果、全員が⾃律的に動く、良い・早いチームに • プログラマーが⾃ら仕様を改善、 QAが仕様を提案するくらいに

半年で素敵なゲームを作るにはチームワークを⾼める

消滅都市のつくり⽅ (アート編) - 半年で素敵なゲームをリリースできた5の理由 -

• 濱坂真一郎(43歳) – リードデザイナー – 株式会社スクウェア・エニックス（２～３回程就職⇔退職） • ＦＦ６ • クロノトリガー • ＦＦ１０ • フロントミッションシリーズ • ファイナルファンタジー零式 • ……etc – 2011年7月にグリー株式会社に転職 • ……etc • 絶対防衛レヴィアタン • 消滅都市自己紹介

• アートディレクション – アートスタッフ（２～７名）の進捗とタスク管理 – アセット管理 – 内製・外製各種素材のクオリティ管理 • ＵＩデザイン – 詳細は渡部晋司パートにて • キャラクターデザイン – 詳細は後述消滅都市での業務内容

本日は時間も非常に少ないので【キャラクターデザイン業務】に絞ってお話します

半年で作る為にリードデザイナーとして考えていた事

自分はキャラデザイナーが嫌い

正確に言えば画力が微妙なのにキャラデザインしかしない自称キャラデザイナーが大嫌い

何故か？

キャラデザインはぶっちゃけ楽しい！

描いていて楽しい本当に楽しい

だから、そういう楽しい部分を独占するリードデザイナーが大嫌い

「大嫌いなリード」と半年でゲームを作るのは辛い

自身がそうならない様に気をつける事は大事

消滅都市の主要キャラクターは(ほぼ) コンペティションを経て作成されている

参加機会を不健全な形で閉じない事はとても大事

それとは別に自身のキャラデザインを通す時に、デザイナーとして考えていた事

（描きたくない物がもし採用されたら辛い、詰む）描きたい物が描きたい・・・（本音）

とはいえ、自分の大好きな

書き殴っただけでは説得力が薄い

そもそも自分はキャラデザイナーとしては画力が半端すぎる・・・・・・

戦略を立てよう

ゲームから求められる機能からデザインを起す

ステージで使用されるチップキャラの要件から考える速度を表現する為に風にはためく要素を大きめにデザイン

ステージで使用されるチップキャラの要件から考える夜のシーンから始まるので、キャラが沈まない様に明るめの色を配色髪の毛も思い切って青く飛ばしてしまう

ステージで使用されるチップキャラの要件から考えるこのままだと地味なので差色に赤を追加する

採用されるようにハッタリを効かせる事

絵が下手なのであれば・・・別の部分で勝負してみる

まず、バイクを描くそっけない表情のヒロインそれに軽くイライラしている主人公キャラコンペ時の提出作品

会話や口調が見えてきそう・・・な、気がする・・・

これと良く似た事例として

プラモデルを使ったジオラマの制作 1/35 ドイツIII号戦車L型ロンメル野戦指揮セット（人形6体付き）画像は株式会社タミヤの公式サイトから引用

些か唐突だったのできちんと説明します……

地図を⾒ながら物思いにふける指揮官遠くを指⽰し、意⾒を具申する下⼠官全員が同じ⽅向を向く事で、ドラマの焦点が画⾯外にある事が判る

ストーリーを想像するのはとても楽しい

画力以外で見る人を楽しませる事ができれば…… 採用の可能性が高まるかも…… しれない？

最後に（多くは語れないけど・・・）運も大事

まとめ

• しんどいリードデザイナーにならない – 美味しい仕事を不健全に独占しない • コンペには戦略を⽴てて挑む – 採⽤されるコツは適度なハッタリ︖

半年で素敵なゲームを作るには美味しい仕事を独占しない︕︕ チームワークを⾼める

消滅都市のつくり⽅ (ゲームデザイン / シナリオ編) - 半年で素敵なゲームをリリースできた5の理由 -

• 下⽥翔⼤(31歳) – ディレクター – 株式会社スクウェア・エニックスに9年勤務 • AI • レベルデザイン • シナリオテキスト – その後グリー株式会社に転職 • 消滅都市においてディレクターを務める WHO ARE YOU?

• ディレクション • ゲームデザイン • レベルデザイン – 初期設計 – ステージデータ作成 – エネミーデータ作成 (攻撃パターンなど) • シナリオ – シナリオテキスト – 演出消滅都市での業務内容は?

半年でゲームを完成させるには︖

絶対にブレない “コンセプト”を設定する

コンセプト ↓ ゲームデザインとディレクション ↓ レベルデザインとシナリオプロット ↓ データ

コンセプト ↓ ゲームデザインとディレクション ↓ レベルデザインとシナリオプロット ↓ データものづくりの初期衝動を⾔語化するコンセプトを体現する “感情”を明確にする “感情”の流れを作る

コンセプトにたどり着くまで

ある⽇都市が消滅する

消滅は現実にも起こりうる

あたりまえだと思っていたものも突然消えさる

“確かなもの”ってなんだろう

⽬を閉じて想像してみましょう

⼈と⼈との繋がり

“信頼”を描きたい

消滅都市は ”信頼”の物語他⼈だったふたりが信頼関係を築いていく

ゲームデザインとディレクション

“信頼”というテーマをゲームデザインに落としこむ

“信頼”をテーマに据えたゲームデザインスクーターに乗った男を操作しつつ⼥の⼦のために⾛りつづける

最も”信頼”を感じる瞬間はなんだろう

共にピンチを乗り切ったとき

ゲームデザインのコアは HPが減って ”ヤバイ”という感情

全てのゲームシステムはこの”感情”のためにある

• ピンチをきっちり認識させる仕組み – 敵の攻撃時はアクションを⽌める • ピンチをたくさん⽤意する – ”HPをギリギリまで削って⽣かす”バランス設計 “なんとかしなきゃ！” という切迫感を最大化

• 10chain刻みのフィーバーで全回復 • なんとかできるアクションステージ – 腕に応じたステージが提供される仕組みなんとかしたときの”気持ちよさ”を最大化

コアの”感情”が明確であれば仕様書は最低限でよい

• 1. 画⾯レイアウト – 他社製品のパーツを組み合わせてつくる • 2. プレイヤーができること – シチュエーションを明確にする • 3. どうやってデータを作りたいか消滅都市の仕様書は以下のみ

• 例︓下スワイプで下の段に降りる – 操作受付時間や反応タイミングを語るより – この操作でどういうピンチを乗り切り、どういう感情の流れを⽣みたいかを伝える大切なのは ”感情”

レベルデザインとシナリオプロット

“機能”と“感情”の流れから全体を設計

プレイヤー体験（機能）を当てはめていくと… chapter1 仲間を集め chapter2 事件の核⼼へ chapter3 ロストを⽬指せ︕ チュートリアル BOSS BOSS BOSS 機能紹介強化合成進化合成ドラクエ３のプレイ感（感情）と照らしあわせると… アリアハンロマリアへ船を⼊⼿バラモス機能と感情の流れから全体を設計

シナリオはミッドポイント理論で構成救出仲間を集める少年の正体判明敵の存在が徐々に明らかにミッドポイント序破急+序破急少年を倒しロストへ少年と再戦謎の男⼥登場謎の⼥を倒す謎の男を倒す⽗の意識と対峙ラスボスとの戦い

ゲーム体験も全く同じカーブに乗せる初バトルチュートリアルユニット強化で乗り越える⼭ミッドポイント序破急+序破急さらに進化でHPを増やす進化とリーダースキルで越える⼭ DPSを⼀定以上に上げる

シナリオとゲーム体験を密接にリンクさせつつ

“感情の波”を⼀致させる

タマシイガチャ特別クエスト納期の関係で削減したシステム Twitter担当 @shoumetsutoshi 例：登場人物を”機能”に割りふる仲間を集めるというシナリオ体験と機能解放というゲーム体験をリンクさせる

プレイヤーに ”進化”が求められるフェーズでは敵も”進化”をしてくる例：プレイヤーと敵を”機能”でリンクさせる機能を理解すればシナリオを理解できる

おまけ - 消滅都市のシナリオを書く上での10のTIPS -

1.単純で理解しやすい⽬的をつくる究極的には“右に向かう話” 進捗をイメージしやすい

2.コンフリクトを起こして解消するコンフリクト解消の過程で⼈間性が描ける

3.⼀話にひとことで表現できるテーマを設定するひとことで⾔えないときは書きたいことが不明確

4.ふきだしひとつに平均20⽂字ひと⽬で読めるようにあえてページをわける

5.⼝で⾔いやすいセリフを書く書く前に⼝で喋ってみる

6.何回も何回も同じことを書く⽬的を何度も書かないとプレイヤーは忘れてしまう

7.細かい疑問を⽣んで細かく解消する常に次のウィンドウが気になるように意識する

8.プレイヤーの気持ちを代弁する主⼈公が “⾃分は分からない”とアピールすることで “まだ分からなくていいんだ”とプレイヤーは安⼼する

9.ノベルシーンだけがシナリオじゃない “話のタイトル”も “敵の攻撃名”も “ローディング”も全部シナリオの⼀部

10.⾳楽がシナリオの半分を占めるテキストと⾳楽のタイミングは同時に決めていく

まとめ

• コンセプトを明確にする – 迷いなく進むためにも初期衝動を深く⾒つめる • コアの感情にフォーカスしづつける – 感情にフォーカスしたディレクションが⼤事

半年で素敵なゲームを作るにはコンセプトと感情にフォーカスする美味しい仕事を独占しない︕︕ チームワークを⾼める

消滅都市のつくり⽅ (クライアント開発編) - 半年で素敵なゲームをリリースできた5の理由 -

• 渡部晋司 – リードエンジニア • 経歴 – 会津⼤学コンピュータ理⼯学部性能評価学講座 – 任天堂株式会社 (2007年〜) – グリー株式会社 (2012年〜) • GREE Platform事業 • 消滅都市自己紹介

• クライアントプログラマ 4名 – 増員要望実らず… – 終盤にサーバと掛け持ちで 1名追加 • 半年後のリリースが絶対 – ギャグだと思ったがマジだった消滅都市のクライアント開発

プロトタイプ開発 – 開発⼀ヶ⽉⽬ -

• ⼈数、期⽇的に3Dゲームは厳しそう – 2Dゲームの企画にしてもらうようにした • ゲーム基盤 – Cocos2d-x Ver3.0.0 α → Ver3.0.0 RC – LWF for Cocos2d-x • swf (Flash) を再⽣する – 開発⾔語 C++11 消滅都市のプロトタイプ開発

• がっちり決めないで開発開始 – ラフな仕様書 – 画⾯イメージ • プログラマで適当に作る – アクション部分 1名 / 裏の戦闘部分 1名 – プロトタイプ開始⼀週間後から結合実験 • プロトタイプはスタンドアロン – 本番ではサーバが持つべきデータも全部抱く消滅都市のプロトタイプ開発

• 実働ゲームを基に企画の練り込み – 仕様書が都度並⾏で作られた – 実働するゲームがすべてだった – ゲームシステム等もこれをベースに検討 • 週⼀回でプレイ会 – 全員⼿元で遊んでみる – 課題出し – 職種を超えてみんなで意⾒を出しあった消滅都市のプロトタイプ開発

消滅都市のプロトタイプ開発開発中のビルドがすぐにダウンロードできるように (http://www.hockeyapp.net/より)

消滅都市のプロトタイプ開発アクションパート⽤キャラクタデザイン (旧) ※製品版相当

消滅都市のプロトタイプ開発プロトタイプゲーム画⾯

• 実機ベースによる議論は良かった – 各⼈の想像によって議論が進むことがない – 触り⼼地等が机上の空論では無い – 仕様書が無い / 少ない状態でも問題なかったポストモーテム • 環境を維持するのが⼤変だった – サーバとの開発進捗ずれ – 初期化シーケンスのバグで起動しない

• 常時動作できるように – クラッシュログは最優先対応 – サーバ開発は極⼒⼿元で⾏えるように • チーム内の周知 – 開発環境ダウンタイムの連絡 – 前もって連絡することで別作業をしてもらう • スゴイ仕組みを⽤意したわけではない – 機械的ではなく⼈間的な温もりポストモーテム

開発環境

• Cocos2d-xはツールを含まない • 開発環境のバランスが重要に – 全てのセクションでリソース不⾜ – 全体の⼯期が短い – 投資に⾒合ったリターンがないと厳しい • 各個⼈の能⼒が最⼤限活かせるように – 今までの経験 / バックグランド消滅都市の開発環境

• UI作成の環境整備 – ゲームの画⾯数が多い – UI制作スピードがプロジェクトの成否を左右 • Cocos2d-x向けのUIツール – Cocos Builder – Cocos Studio (旧称 : CocoStudio) – などなど消滅都市の開発環境

• 新しいツールを覚えるのは負担… – そもそも画⾯デザインはPhotoshopで作る – 作ったのをツール上で再配置︖するの︖え︖ • 最初からPhotoshopで作れればいい – JSXでレイヤー構造をエクスポートする消滅都市の開発環境

消滅都市の開発環境 PhotoshopによるUI制作

消滅都市の開発環境 psdファイルのレイヤー構造

消滅都市の開発環境 UI部分のプログラムを実装してゲーム画⾯に

• UI系アニメーション – Photoshopで全体的な画⾯構成は出来た – でもアニメーション付けは無理 • プログラマが適当につけた – 雰囲気で – ⻑さとか距離とかカーブとか適当に空気読んで – あまりにも酷い時はダメだししてもらう消滅都市の開発環境

• デザイナの反応は良好 – ⾒た⽬どおりに画⾯が作れた – 使い慣れてるツールで制作ができた • アニメーション適当でなんとかなった – デザイナさんにあまり怒られなかったポストモーテム • 実機と若⼲⾒た⽬が異なる – フォント周りの箇所 – (仕様ということに…)

• ゲームデータ制作 – ゲームバランスに直結 – データ制作者が⼊⼒しやすいように • Excelでデータ管理 – 機能の豊富さ – データ制作者が慣れていた消滅都市の開発環境

消滅都市の開発環境 Excelによるデータ⼊⼒

• ツールでExcelの内容を細かく検証 – 設定画像ファイルの存在しているか – ID重複していないか – 必須設定パラメータが設定されているか – クリア時報酬タマシイの最⼤レベル – などなど… • ミスを事前に検知して⽌める消滅都市の開発環境

消滅都市の開発環境 Excelデータの変換ツール

消滅都市の開発環境⼊稿ツールをJenkinsから実⾏出来るように

消滅都市の開発環境 Excelデータを基にビットマップフォントの作成

• データ検証機能の充実が良かった – データ制作者の安⼼につながる – データ起因の問題に時間を割かなかった – ⼈に怒られるよりも、機械に怒られたいポストモーテム • データ共有が難しい – Excelの共有ブック機能では使えない機能もある – 作業者ごとにExcelファイルを分けた

• ゲームステージを作りやすくする – アクションゲームの⾯⽩さに直結する • ステージエディタは独⾃開発 – ゲーム仕様はどう変わるか分からない – ツールの都合でゲームの仕様を落としたくない – 実は裏で壮⼤な計画があった (が、中⽌) 消滅都市の開発環境

消滅都市の開発環境ステージエディタ

• ゲーム仕様追加 / 変更に柔軟に対応 – ツール側も機能追加することで対処できた • 専⽤ツールなので分かりやすい – 新しく配属された⼈でもすぐ使える – QAチームとのデータ共有 • 機能追加の要望に対応しきれない – 細かいところまでやり切れていないポストモーテム

クライアントコード

• とにかく⼈数 / 時間が⾜りなかった • お互いを信じてとにかく並⾏作業 – 技術ドキュメント無し – コードレビュー無し – 他⼈の担当箇所も勝⼿に直す – 空気読んで適当に何とかするクライアント開発「修羅の国」と呼ばれる

クライアント開発⼀⾏ごとに書いた⼈間が違う

• 納期に間に合った (結果論) – かなり危険な綱渡りだった – 誰か⼀⼈でも交通事故にでも遭ったらアウト • コードがカオスに (お察し) – 運⽤する製品でこんなことしちゃダメだった – ⾟くなってきたので全体を整理中 (今現状) • 属⼈性が⾼すぎる – リリース後にジョブローテーションを実施 – ドキュメントの充実ポストモーテム

パフォーマンス関連

• スマホゲームの宿命 – いろんな端末がある – いろんなGPUがある – 60FPS出てても、さらに軽く (バッテリ) • 初期リリースギリギリまで調整 – 危険な変更も多かった – 結果論だけど、⼊れてよかったパフォーマンス関連

パフォーマンス関連無駄なドローコールがないか調査 (Xcode)

• 調べてみると残念な箇所が⾒つかった – ⾒えない透明レイヤーが描画されてる… – 頻繁に作成削除を繰り返してた… – 毎回オブジェクトのデシリアライズが… – ⾒えてないLWF(アニメーション)が動いてた… – ゲーム中にディスクアクセスしてた… パフォーマンス関連

• パーティクルの使⽤をやめた – Cocos2d-xのパーティクルはCPU負荷が結構⾼かった – LWFアニメーションで代⽤(表現の変更) • オーバードローを回避 – 不要なピクセルの上書きをしない • glClear呼ばない – Cocos2d-xを改造 – どうせ全画⾯が塗りつぶされるゲームパフォーマンス関連

• SpriteBatchNode結局速い – Ver3系から⾃動バッチレンダリング機能 – 分かっているものは事前にまとめておく • フラグメントシェーダを変更 – 無駄な乗算演算を削除 – ⼀部GPUで効果が⾼かった • iPhone等ではほぼ変化無しパフォーマンス関連

まとめ

• 個々の能⼒が最⼤限活かせる開発現場 – 開発環境の設計 – 開発⼿法 – そして、お互いを信じること • 役割の明確化 – ⼈にやってもらって嬉しい事は⼈に – 怒られるのは機械に

半年で素敵なゲームを作るにはコンセプトと感情にフォーカスする美味しい仕事を独占しない︕︕ チームワークを⾼める個々の能⼒を最⼤限引き出す

消滅都市のつくり⽅ (サーバ開発編) - 半年で素敵なゲームをリリースできた5の理由 -

名前︓吉川毅役割︓エンジニアマネージャ • グリーの古参です（5年） • Webベースのソシャゲを沢⼭作ってきた – 踊り⼦クリノッペ（PG） – ハコニワ（PG） – ガンダムマスターズ（PL） – 絶対防衛レヴィアタン（PD）自己紹介

• チャレンジとしてAWS採⽤ – 構成管理の⾃動化の実現 – オートスケール・オートヒーリング – Blue&Greenデプロイ • ピーク10万DAU想定で⾒積もり Ø外部コンサル会社を⼊れつつ、最新トレンドの編成を採⽤した消滅都市のサーバーインフラ

• 安い・早い・ウマい︕ – ⼈的リソースが少なくても運⽤可能 – サーバ費⽤のコントロールが容易 • 何が当たるか分からない市場に対してスモールスタートできる︕ • プロモーションで突発的に⼈が増えるという状況にも対応できる︕ Ø要件を叶えてくれる︕是⾮チャレンジしたいなぜAWS採用に至ったか

• オープン数⽇で想定ピークを突破 • 数々の想定外の問題発⽣ – 負荷検証時と⽐較して性能が出ない – デプロイ時の切り替えで障害 – ロードバランサーの挙動が不安定 – 無停⽌でスケールアウト／アップできない Ø対応⽅法わからず、とりあえずの停⽌メンテナンスを繰り返すことにリリースを迎えて

• 費⽤が爆増し、制御不可能、運⽤コストが極限まで⾼まった – 性能が出ないので、最終的に⼀番⾼いインスタンスに買い替えた – オートスケールは実現できず⼿運⽤ – デプロイが致命的に不安定でエンジニアが付ききり、施策運⽤が柔軟にできなかった Ø⾃社インフラ（オンプレミス）に全⾯移⾏することを決断した結局どうなったのか

• 前提としてAWS⾃体は良い製品だが、圧倒的な検証不⾜だった – ハードウェアの集合としての仮想化技術であることという当たり前の前提を常に疑うべきだった – 仮想化されたブラックボックスを扱うので、トラブル発⽣の際の運⽤リスクを重視すべきだった – 特性を理解したうえで最適なソリューション・ツールを取捨選択し、徹底検証するべきだった ØAWSに夢を⾒ず、⾃分の頭で考えて慎重に導⼊しましょう AWSをどう使えばよかったか

まとめ

• （⼿段を選ばなければ）新しいチャレンジは半年でもできる – ⼀応爆増するDAUに対応はできましたが • でもやっぱり新しいことをやるときは検証に時間を割かないと失敗します

半年で素敵なゲームを作るにはコンセプトと感情にフォーカスする美味しい仕事を独占しない︕︕ チームワークを⾼める個々の能⼒を最⼤限引き出す新しいことにチャレンジしてみる

まとめ

• 消滅都市は様々なメンバーの⼯夫と苦労と失敗から⽣まれました • これからもどんどん改善して多くのお客様に楽しんでいただけるゲームにしていきます︕ • ⼀緒に楽しいゲームを作る仲間を絶賛募集中です︕ http://jobs.gree.net/jp/ja/ まとめ

ご静聴ありがとうございました︕

[CEDEC2014] 消滅都市のつくりかた 半年で素敵なゲームをリリースするには -

[CEDEC2014] 消滅都市のつくりかた 半年で素敵なゲームをリリースするには -

More Decks by gree_tech

Other Decks in Technology

Featured

Transcript

[CEDEC2014] 消滅都市のつくりかた半年で素敵なゲームをリリースするには -

[CEDEC2014] 消滅都市のつくりかた半年で素敵なゲームをリリースするには -