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

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

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

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

消滅都市ご紹介

https://www.youtube.com/watch?v=2fB_Jm6S9Ck

• 現代を舞台にした
• おかげさまで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ゲームの成功体験
• 良いと思った事はすぐに実行して試した

× 市場調査、モデル、分析、KPI、が最重要だ！
○ ゲームの面白さ、新しい体験が最重要だ！

× 既にあるブランドのメリットを最大限活かすんだ！
○ 新しいブランドを立ち上げてNativeゲームとして
本当に、面白いゲームをお届けするんだ！

× 今まで使ってきた手法や技術をずっと利用すべきだ！
○ 要件に応じて最適な手法や技術を選択すべきだ！
SCRUM

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

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

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

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

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

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

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

• とにかく多くのコミュニケーション
• 積極的な行動、意見を絶対否定しない

• バーベキューで結束を！

結果、何が起きたか

• 結果１：プログラマーが良かれと思って
機能改善・追加

スマホは震えた方がいいんで、やっときました！

かっこいいんで電車走らせました！

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

• 結果２：QAから仕様の提案
ずっとQAやってて思ったんですが、
このステージこうした方が面白いと
思いました！
レベルデザイナーとしてジョインしてステージを作ることに！

• 結果３：公式Twitterを勝手にメンバーが運用
アカウントとりあえず作ったけど、
公式Twitterの運用は、
このマンパワーでは無理だ。
運用はじめちゃいました！
アイコンも作りました！
3ヶ月で約6,000ツイートいきました！

• 結果4
– 写真撮影の息もばっちり

• 結果5
– 5人リレーの難しいセッションも
時間ばっちり！

まとめ

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

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

(アート編)

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

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

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

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

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

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

何故か？

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

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

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

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

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

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

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

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

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

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

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

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

戦略を立てよう

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

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

夜のシーンから始まるの
で、キャラが沈まない様に
明るめの色を配色
髪の毛も思い切って
青く飛ばしてしまう

このままだと地味なので
差色に赤を追加する

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

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

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

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

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

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

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

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

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

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

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

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

高める
半年で
作るには
美味しい仕事を
独占しない！！

(ゲームデザイン/ シナリオ編)

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

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

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

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

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

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

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

ある日都市が消滅する

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

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

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

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

人と人との
繋がり

“信頼”を描きたい

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

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

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

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

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

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

ゲームデザインの
コアは
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.音楽がシナリオの半分を占める
テキストと
音楽のタイミングは
同時に決めていく

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

高める
半年で
作るには
コンセプトと感情に
フォーカスする

(クライアント開発編)

• 渡部晋司
自己紹介
– リードエンジニア
• 経歴
– 会津大学コンピュータ理工学部性能評価学講座
– 任天堂株式会社(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年）
• Webベースのソシャゲを
沢山作ってきた
– 踊り子クリノッペ（PG）
– ハコニワ（PG）
– ガンダムマスターズ（PL）
– 絶対防衛レヴィアタン（PD）
自己紹介

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

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

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

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

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

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

高める
半年で
新しいことにチャレ
ンジしてみる
作るには
個々の能力を
最大限引き出す

まとめ

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

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

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

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

More from gree_tech

More from gree_tech (20)