[141004] cedec 2014 참관기 & 강연 리뷰 #1

2014.10.02
초중급 게임개발자 스터디
<데브루키>
알콜코더 박민근
CEDEC 2014
참관기 & 강연 리뷰

인벤의 CEDEC 관련 특별 취재 기사들도 있습니다.
http://www.inven.co.kr/webzine/special/gameshow.php?gs=cedec

CEDEC 2014 리뷰
• 전체적인 분위기는 KGC와 매우 흡사
• 일본 게임 개발 트렌드의 특징을 보여줌
• 콘솔게임 강국답게 콘솔게임의 그래픽스 기술력은 최강
• 온라인 네트워크 기술 관련 내용은 국내보다 미흡한 수준
• 유명한 게임 시리즈들(테일즈,FF,뿌요뿌요)을 가지고 있기
때문에, 프로그래밍보다는 관련 기획적 세션이 많음.
• 유니티 내용도 유니티 소개와 입문 수준의 강연이 많음.

CEDEC 2014 리뷰
• 다양한 미들웨어 회사들이 존재하기때문에, 미들웨어 홍보
세션이 많음
• 오큘러스 + LEAP등을 이용한 VR, AR관련 내용이 많음
• 사운드 관련 세션이 상당히 많음
• 전체적으로 그래픽과 사운드는 매우 우수하고, 반대로
네트워크 동기화나 온라인 시스템(ex. 패치)에 대한
수준은 국내보다 미흡

CEDEC 2014 리뷰
• DX11, PS4, GPGPU에 의한 처리 고속화에 대한 내용이
많음.
• 그래픽스는 물리 기반 렌더링이 대세. 거의 모든 그래픽스
기술의 주요 테마는 물리 기반 렌더링

CEDEC 2014 강연 정리
1. Deep Down(PS4)의 그래픽스 표현의 기술 해설 – 캡콤
2. 파이날판타지14(PS4, PC)의 파일시스템과 패치 시스템 – 스퀘어
에닉스
3. 해외의 대단한 크리에이터들이 중요시하는 단 한가지(일미 양국의
디렉션 경험을 통해서 배운 많은 힌트) – 스퀘어 에닉스
4. Tales of 시리즈에서의 자동 리깅과 워크플로우 – 반다이남코
5. 소멸도시 포스트모텀 – 반년만에 멋진 게임을 릴리즈하기 위해서는-
Gree
6. “하늘과 대지와 여신의 마법”의 멀티플레이 기술(스마트폰에서
리얼타임 멀티플레이라니 무모하죠 라고 이야기 들었다) – Gree

Deep Down의
그래픽스 표현의 기술해
설
CAPCOM

파이날판타지 14의
파일시스템과 패치 시스
템
스퀘어 에닉스

해외의 대단한
크리에이터들이 중요시하는
단 한 가지
-일미 양국의 디렉션 경험을
통해 얻었던 많은 힌트
스퀘어 에닉스

Talse of 시리즈에서의
자동 리깅과 워크플로우
山本佑平
Software Architect
BANDAI NAMCO Studios Inc.

Tales of シリーズにおける
自動リギングとワークフロー
山本佑平
Software Architect
BANDAI NAMCO Studios Inc.

AGENDA
• 開発内部でIKSystemと
呼ばれるものの説明
• 導入以前はどうだったのか
• 導入以後どう変化したか

ABOUT ME
2007 Namco Tales Studio
社内ライブラリ作成
R&D Programmer
2012 BANDAI NAMCO Studios
社内フレームワーク作成
Software Architect

関わった
タイトル
Tales of Vesperia(360/ps3)
Tales of Graces(wii/ps3)
Tales of Hearts(ds)
Tales of Abyss(3ds)
Tales of Xillia(ps3)
Tales of Xillia 2(ps3)
Pac-Man party(3ds)
Tales of Symphonia(ps3)
Tales of Zestiria(開発中)( ps3)

導入
タイトル
Tales of Vesperia(360/ps3)
Tales of Graces(wii/ps3)
Tales of Hearts(ds)
Tales of Abyss(3ds)
Tales of Xillia(ps3)
Tales of Xillia 2(ps3)
Pac-Man party(3ds)
Tales of Symphonia(ps3)
Tales of Zestiria(開発中)( ps3)

Tales of
シリーズって
?
アクションRPG

Tales of
シリーズの命題
多様な構造を持った
モンスターが存在
少ない人員
大量生産

人数（大体平均）
• キャラモデラー：3～4人
• モンスターモデラー：1～2人
• キャラアニメーター：4～5人
• モンスターアニメーター：1～2人

作る数（大体平均）
• キャラクタモデル：200
• モンスターモデル：220
• モーション：7000
• カットシーン：２時間半

アニメーション作成時
こういうことありませんか？
① ツールをいくつもまたぐ
② 人型とそれ以外の作成方法が全く異なる
③ リギングスクリプトの高メンテナンスコスト

ツールをいくつもまたぐ
1モデリング：Maya
キャラクタアニメーション：Motion Builder
モンスターアニメーション：Maya
ツールをまたぐことによるデータ欠損
サポートコスト増
モデラーとアニメーターのやりとりが大変
問題

人型とそれ以外の
作成方法が全く異なる
2担当者（班）が別
世のソリューションの大半が人型特化
動かし方まで違う
ノウハウが分散
人員の行き来がしにくい
覚えることが多く教育コスト増
問題

リギングスクリプトの
高メンテナンスコスト
3キャラ・タイプ毎に用意
問題
構成変わる度にスクリプト作り直し
タイプ増える度にスクリプト追加

結果として
• バリエーション増やしづらい
• 人員が余るのに足りない
• サポートにしわ寄せ
• 統合されてないので
ワークフローが進化しない

IKSystemで解決を図る
• ツールを一つに
• 多種多様な構造に対応
• 共通の操作体系を提供
• リギングの自動化
• ノウハウをためていく

ツールをいくつもまたぐ
1ツールをまたぐことによるデータ欠損
サポートコスト増
モデラーとアニメーターのやりとりが大変
Maya上で構築し、サポートコスト軽減
Referenceを使用してデータの
やり取りを効率化
解決

人型とそれ以外の
作成方法が全く異なる
2ノウハウが分散
人員の行き来がしにくい
覚えることが多く教育コスト増
パーツ（モジュール）を組み合わせて
扱うことで多種多様な構造に対応
全て同様の操作体系でアニメーターを
統合（ノウハウをためる）
解決

リギングスクリプトの
高メンテナンスコスト
3構成変わる度にスクリプト作り直し
タイプ増える度にスクリプト追加
命名規則に合わせてリギングを自動化し
リガーの負担軽減
ジョイントの名前を考えるだけで様々な
構造が作成可能
解決

IKSystemまとめ
• パーツ（モジュール）を組み合わせて扱う
– 多種多様な構造に対応
• 命名規則に合わせてリギングを自動化
– リガーの負担軽減
• Maya上で構築
– ツールを一つに
• 共通の操作体系
– アニメーターの班分割をやめ、ノウハウをためる

Tales of
シリーズの命題を
解決する
ソリューションに！

1Bone
• 2ジョイントからなる構成
• 先端をTrans制御
• 始端をRotate制御
命名規則
• Spine1~連番
• Neck1~連番
• Neck?->Head?
• 複数頭の場合はNeck1_1/Neck1_2

2Bone
• 主に人間の腕などに使用
命名規則
• Arm/Forearm/Hand
• Upleg/Leg/Foot
• 複数はArm2/Forearm2/Hand2となっていく

3Bone
• 主に４足歩行系に使用
命名規則
• Arm/Forearm/Hand/Fingerbase
• Upleg/Leg/Foot/Toebase
• 複数は
Arm2/Forearm2/Hand2/Fingerbase2

Chain
• 1Boneの連鎖
• ジョイント個別制御も
可能なスプラインIK
• 尻尾や触手などに使用
• 命名規則
• Tail1~連番
• Tentacle1~連番

特殊用途
• Center
– 重心を表す必須要素
– 命名規則：Center_C
• Rotate
– 末端の回転のみを行う場合に使用
– 例えば手首
– 自動で必要な箇所に適用される

その他
• リグを入れない骨
– 命名規則から外れた名前を付ける
• もっと特殊なもの
– 基礎構成はこのリグにした上で、更に追加で手
動リグをかぶせる

機能的なもの
• ReachT/ReachR
• Pinning
• Animation Layer
• Retarget
• Take
• Mirror
• Etc.

ReachT/ReachR
• ReachT
– Translate補間を行うかどうか
– IK的な動作かどうか
• ReachR
– Rotateの座標系の扱い
– LocalかWorldか

Pinning
• 操作上の位置固定機能
• 体を動かしても手の位置は
動かさないとか

Animation Layer
• ベースとなるアニメーションに
アニメーションを加算
• Mayaの機能をほぼそのまま

Retarget
• 体格の違うキャラクタへ
アニメーションを適用
• パーツ単位で解析

Take
• 一つのmbデータで複数
アニメーションを管理可能に
• 管理コストが低減
• かなり好評

Mirror
• アニメーションデータの左右反転
• さすがにどんな構造でも
とはなっていない
• ある程度限定されている

導入した副次的効果
• 共通言語化
• モデラー/アニメーター間の
やり取りが増えた
– 良い意味で
• 会話の文脈が変わった
– 導入前：作りやすい・操作しやすいというhowの議論
– 導入後：こういう動きをさせたいというwhatの議論
– やりたいことの本質に近づいた会話に

今後の改良点
• ラベル対応
– ノード名は別の用途に使ったりもする
– 既存データへの対応が困難
• UIの改良
– どの箇所のリグなのかをもう少し分かりやすく
• 命名規則をもっとシンプルに
– 作りながらつぎはいだ部分が多数

さいごに
• とにかく始めて継続していく
– 継続は力なり
– 改善していけば良い
– やる前からごちゃごちゃ言う人は相手にしない
• なるべくシンプルに
– 破綻しにくい
– 改善しやすい
• 仲間を作る
– １人じゃ大きなものは作れない
– 保守し続けられない

THANK YOU FOR LISTENING!
ご静聴ありがとうございました

소멸도시 포스트모텀
- 반년만에 멋진 게임을 릴리즈하기 위해서는 -
WRIGHT FLYER STUDIOS
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=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/
まとめ

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

スマホでリアルタイムマルチプレイ
なんて無謀でしょと言われた件
天と大地と女神の魔法のマルチプレイの技術

平岡大輔/ 永井雅人
自己紹介

天と大地と女神の魔法（てんめが）
今日の内容

マルチ協力プレイ

デモ
マルチプレイのデモ
やります！
にゃー
Special thanks to ソラナさん、松崎さんin 六本木

ここから
マルチバトルの技術内容をお話します
はじめます

Client Server
システム概要
Real-time Server
(独自実装, C++)
API Server
(Apache, PHP)
DB
IOS
Android
OSX
(Unity)
battle / lobby
building / others

マルチバトル
Client
Real-time
Client Server
Client
Client
最大4クライアント/ バトル

Client
マルチバトルをプラグイン
Client
Plugin Real-time
Server
Plugin
Plugin
Client
Plugin
Client
Plugin 最大5プラグイン/ バトル

ゲームのAI
プラグイン
- フィールドの管理
- キャラクターの動作
- キャラクター最大255 x 4 players + 防衛施設
マルチプラットフォーム
- C++
- OSX / IOS / Android / Debian(Server, Simulator)

クライアントのプラグイン
ユーザ入力
Plugin
Object
Buffer
Projectile
Buffer View
画面出力
バトル結果

サーバのプラグイン
バトル結果
Plugin
Object
Buffer
Projectile
Buffer
DB
ユーザ入力

プラグインAPI
- extern C
- 構造体のアライメントに注意
- 可変長配列を含む構造体は×
- C++からC#へコールバックも可
- 共用バッファはC# managed

プラグインAPIパフォーマンス
ユーザ入力（キャラクター配置やスキル発動）は問題なし
毎フレームアクセス
- 各種状態取得
ロード、施設、壁
- サウンドイベントのコールバック
アタックイベントなど
C++にして正解
にゃー

壁の接続

Real-time Server のプラグインの結果を保存
Client
Plugin Real-time
Server
Plugin
DB
Client
Plugin
Client
Plugin
Client
Plugin

実装するよ
開発中の苦労。。。

いろいろなコンパイラ
• LLVM 5.1
• android-ndk-r9
• gcc 4.4.5
マルチプラットフォーム

プラグイン実装でハマる
結果不一致...。

ある日のQA
100%クリア！やったーえッ！？98%？

結果不一致問題
実行順序に注意！
環境により変わるコードに注意！
外部環境に注意！
マルチスレッド実行に注意！

実行順序に注意
ポインターのsetをイテレートしない
// NG
typedef std::set<MapObjectBase*> MapObjects;
for (MapObjects::iterator i = map_objects_.begin(); i != map_objects_.end(); ++i)
{
// do something
}
// OK
typedef std::vector<MapObjectBase*> MapObjects;
実行するたびに結果が異なる

実行順序に注意
呼び出しパラメータ内で乱数を取得しない
// NG
Vector3f position(start_pos_.x + Rand(0, kRelaseSparse * 10.0f) / 10.0f,
start_pos_.y + Rand(0, kRelaseSparse * 10.0f) / 10.0f,
start_pos_.z);
// OK
const float offset_x = Rand(0, kRelaseSparse * 10.0f) / 10.0f;
const float offset_y = Rand(0, kRelaseSparse * 10.0f) / 10.0f;
Vector3f position(start_pos_.x + offset_x,
start_pos_.y + offset_y,
start_pos_.z);
実行環境により結果が異なる

環境により変わるコードに注意
実行環境によって乱数を取得しない
// NG
if (sound_callback_ != NULL && ShouldSound()) {
sound_callback_(kAttackSound);
}
bool ShouldSound() {
return Rand(0, 1) == 0; // 50%
}
サーバとクライアントで結果が異なる

外部環境に注意
バッファサイズが異なる
弾を管理するバッファサイズが異なり、
遠距離攻撃ユニットの弾数がゼロ...。
マスターデータが異なる（リリース前日）
検証用にスピード10倍…。
サーバとクライアントで結果が異なる

マルチスレッド実行に注意
クライアント環境はシングルスレッド
サーバ環境ではバトルインスタンス毎にマルチスレッド
ローカルstatic 変数を使用しない
結果が異なる
void UnionUnit::Release() {
static bool released = false; // NG
if (!released) {
released = true;
...
}
}

プラグインまとめ
- マルチプラットフォーム
- サーバの結果を保存
- 実行結果が異なると大問題

てんめがの
リアルタイムマルチプレイバトル
を実現する技術。
ここからは

COMMANDS RESULTS
CLIENT
REAL-TIME
SERVER
Plugin
バトルの処理フロー。
DB
Plugin
RESULTS
COMMANDS
COMMANDS
(独自プロトコルon TCP)
RESULTS
VIEW
RESULTS

マルチプレイバトルの要件
要件1
すべてのクライアントの
バトル進行を同期する。

コマンドを同じフレームに入力する。
CLIENT A
REAL-TIME
SERVER
I PUT
CLIENT A PUT
Plugin
CLIENT B
Plugin
Plugin
OK!
FRAME 300
FRAME 300

要件2
クライアントの
バトル進行は止めない。
（リアルタイム）

コマンドが同期する間もバトルは進む。
(AIによる進行)
CLIENT A
REAL-TIME
SERVER
I PUT
CLIENT A PUT
Plugin
CLIENT B
Plugin
Plugin
OK!
FRAME 300
FRAME 310

マルチプレイバトルの問題
問題発生。

同期中にコマンドが過去のものとなる。
しかし、過去のコマンドは処理できない。
CLIENT A
REAL-TIME
SERVER
FRAME 300
I PUT
CLIENT A PUT
Plugin
CLIENT B
Plugin
Plugin
FRAME 310
TOO
LATE..
at FRAME 300

どうすればいいのか？

マルチプレイバトルのコマンド先延ばし処理
コマンドを未来に先延ばしする。
(その未来に到達するまでの遅延は許容)
CLIENT A
REAL-TIME
SERVER
FRAME 300
I PUT
CLIENT A PUT
Plugin
CLIENT B
Plugin
Plugin
FRAME 310
OK!
YOU PUT at FRAME 320
at FRAME 320
Hmmm.
320 will be
OK.
OK!

どのくらい未来にするか？
(値が大きい程、確実性が上がるが応答性が下がる)

最悪遅延時間を推定する。

推定最悪遅延(T) =
当該片道遅延(T1) +直近最悪片道遅延(T2)
T2 T
REAL-TIME
SERVER
CLIENT A
T1
CLIENT B

先延ばし時間を計算する。

先延ばし時間(T) =
推定最悪遅延(T1 + T2) + 許容変化量(T3)
T2 T
REAL-TIME
SERVER
CLIENT A
T1
CLIENT B
T3

許容変化量はさまざまな条件で変化量を
サンプリングして決定。

電車でもサンプリング。
(社内チャットから抜粋)

大事なこと。

開始時刻のずれは可能な限り抑える。
(バトル中常に遅延に加算される)
CLIENT
REAL-TIME
SERVER
CLIENT
TIME-LAG
Start
ASAP!
Start
ASAP!

開始時刻のずれは可能な限り抑える。
CLIENT
REAL-TIME
SERVER
CLIENT
I’m
ready!
I’m
ready!
Start
in 100 ms.
Start.
Get
ready.
Get
ready.

待ち時間を体感的に短くする。
(即時応答、演出)
半透明のユ
ニットを事
前配置。
時間になっ
たらユニッ
トを配置。

切断時に復帰できるようにする。
開発中の画面

てんめがの
リアルタイムマルチプレイバトル
を実現する技術でした。
以上

新しいことをやるのは楽しいです！
試行錯誤が楽しいです！
まとめ
一緒に楽しいゲームを作る仲間を
絶賛募集中です！
http://jobs.gree.net/jp/ja/

ご清聴ありがとうございます
TenMeGa !
50クリスタルがもらえます。
てんめがを遊んでください！
1103-CEDECTMG

용과 같이 유신 : 제작 사례
진화하는 이벤트 제작의
운용기법과 크로스플랫폼으로의
새로운 도전
SEGA

[141004] cedec 2014 참관기 & 강연 리뷰 #1

[141004] cedec 2014 참관기 & 강연 리뷰 #1

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie [141004] cedec 2014 참관기 & 강연 리뷰 #1

Ähnlich wie [141004] cedec 2014 참관기 & 강연 리뷰 #1 (20)

Mehr von MinGeun Park

Mehr von MinGeun Park (16)

[141004] cedec 2014 참관기 & 강연 리뷰 #1