おまえだれやねん
うつみ けいすけ
KLab (Osaka) Developer
刺青だらけのエンジニア
Golang,PHP,C#(Unity)
CrystalFantasiaのServerリーダー
PHPカンファレンス関西
関西ゲーム勉強会
Kansai Users' Group of Golang(KUG2)
Team Ku’s
Agenda
質問タイム
クリファンの紹介
使っている技術の紹介
ゲーム開発現場について
技術ではどうにもならなくてやってみたこと
サービスの新規開発で気をつけたいこと
質問タイム
実行端末
モバイル端末
据え置き機
実行端末
モバイル端末
据え置き機
ジャンル
スマホ
コンシューマ
ジャンル
スマホ
コンシューマ
収益型
コンテンツ課金型
広告収益型
収益型
コンテンツ課金型
広告収益型
CrystalFantasiaのご紹介
完全自社開発オリジナルタイトル
2014/11/12より配信開始
140万DL(2015/01時点
iOS/Androidにて提供
Unityを使った爽快アクションゲーム
2015/06/30 15:00
∼永眠∼
CrystalFantasiaのご紹介
よくあるHTTPベースのAPI+Unityのゲーム
開発チーム:20~30人
プランナー:4∼6人
クリエイティブ:6人∼10人
サウンドエンジニア:1人
クライアントエンジニア:8人
_人人人人人人人人人人人人人_
> サーバーエンジニア:1人 <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄
使っているた技術の紹介
Client情報管轄
CIツール
Webサーバー
使っているた技術の紹介
使っているた技術の紹介
PHPフレームワークは(ほぼ)自作
DietCakeをベースに構築
300行にも満たない超軽量フレームワーク
何もしてくれない。でもそれがいい
使っているた技術の紹介
バックエンドのスクリプトも基本PHPベースで実装
遅くても気にしない。
アプリの実装資産を使う方が安心・安全
python/golangの方が得意かも?って思っても気にしない
使っているた技術の紹介
効率的なキャッシュ利用
OPcache
オペレーションコードのキャッシュ
APCu
設定データの保持
memcache
リトライ制御用のレスポンスキャッシュ
redis
その他ゲーム内データキャッシュ
使っているた技術の紹介
インテグレーション(CI:チープなインテグレーション
jenkinsではビルドするだけ
リソースのパイプラインは自前実装
sed芸とかもありました
ChatWork通知もふんだんに活用
使っているた技術の紹介
サーバー
DSAS(自社運営のホスティングサービス)
KLabの誇る変態最高峰のインフラチーム
Blogもよろしくお願いします
パフォーマンス
Webサーバー6台
DB/memcached/redisサーバー(master/slave各1台)
処理能力:3500Request/Sec
平均レスポンス時間:28ms *ベンチマーク数値
と、その前に
技術っぽい出だしだけど
_人人人人人人人人人人_
> それも、ここまで <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄
高度な技術話は他の人に任せて
少人数(1人)でも立派にチームとして、
開発チーム全体と渡り合い、
回していくお話をしましょう。
ゲーム開発現場について
ゲーム開発の特徴
結局はサービスなのでそんなに変わらない
大きく違うところ
コンテンツ更新頻度が高い
利便性ではなく楽しさを提供する
ゲーム開発の特徴
コンテンツの更新頻度
ガチャのキャラ追加
イベントの追加(クリスマスとか
機能追加とは比べ物にならない頻度で更新されていく
ゲーム開発の特徴
利便性ではなく楽しさ
エンターテイメントサービスである
最大の敵は競合よりもユーザーの退屈/飽き
自社サービス提供で気をつけるポイント
デプロイするものはプログラムだけじゃない
設定データ
お知らせ
詫び石
クリエイティブ素材
サーバーアプリケーション
クライアントアプリケーション
設定データ
一番更新頻度が高い
週に2~3回なんてザラにある
開発環境で何度も修正してバランス調整
お知らせ/侘び石
サービス提供ではユーザー満足度を左右する大事なもの
メンテナンス予定
バージョンアップ予定
イベント告知
詫び石
ユーザー神の怒りを沈める供物
配りすぎると運営大打撃
クリエイティブ素材
サービスの中で一番収益性の高いコンテンツ
かっこいい!かわいい!つよい!欲しい!
ユーザーに刺さるのはコンテンツがメイン
でも制作コスト高め
ダウンロードが多いとユーザーストレスの原因に
日本では月末のジレンマがある
サーバーアプリケーション
PHPなのでデプロイは楽
キャッシュクリアのタイミングだけがシビア
できるだけ全サーバーで同時に切り替わる工夫
頻度はそんなに高くないので、できるだけ設定データでい
ろんなことができるように設計/構築することが楽するため
の第一歩
クライアントアプリケーション
一番更新頻度は低い
その分一番神経使う
Apple様審査コワイヨー
多少のことはサーバーで対処できるように設計するのも大事
容量問題(最近やっと両方100MBになったね
公開からの浸透待ち
サービス提供するエンジニアとして
提供サービスのコンテンツの収益モデルを意識する
各チームがどういうお仕事してるか知る
コンテンツ提供の品質を担保する
技術ではどうにもならなくて
やってみたこと
一人でも他チームと同じように動くために
いろんなサービス/ツールを「使わない」最低限にする
他のチームを正しく頼る/きちんと分業する
僕のクローンを量産する
コンテキストスイッチの削減
サービス/ツールを「使わない」最低限にする
ツールで解決できるかもね
今発生している課題に対して最適?
多機能過ぎて浮ついた使い方にならない?
結局中のコード読んでツールの障害対応、したことない?
最適なものはやはり自前実装に限る
他のチームを正しく頼る/きちんと分業する
正しく頼るためにはお互いの仕事を知る必要がある
依頼などの方針インターフェイスを予め決めておく
人に寄り添った対応ではリソースが膨大に消費される
クローンを量産
日々依頼されることは管理画面だけで完結できるようにする
細かいタスクほどクローン(ツール)化すれば成果が出やすい
一度依頼されたルーチンタスクはクローン(ツール)がやってく
れる
コンテキストスイッチの削減
一人なので、何をやるにしてもコンテキストスイッチが発生
頭切り替えのオーバーヘッド
切り替え=タバコ…本数増える…
それでも大量発生するので、そのタイミングで最大の成果を
出すためにフルコミットする
開発/運用ツールの充実
CMS(管理画面)の作り方
収益コンテンツ制作の高速化
イテレーションスピードアップツール
夢や理想なんて捨てちまえ
CMSの作り方
CMSはエンジニアも全員使うようにつくる
オペレーションが複雑/煩雑にならないように
フロントアプリと同じプロジェクトとして扱う
オペレーションが複雑/煩雑にならないように
やりたいこと1つに付き
1画面
1インプット
1クリック
オペレーション数が増えれば増えるほど操作ミスなどの問題発生す
る原因になる
利用者の自由をなくす
利用者に理解を求めない
フロントアプリと同じプロジェクトとして扱う
同じ言語で実装する
フロントで利用するモデルをCMS用に拡張して実装する
ゲーム内で起こらないことはCMSでも発生させない。
よくある
UPDATE player SET level = level + 10
WHERE player_id = 123;
Playerのレベル上げて
よくある
UPDATE player SET level = level + 10
WHERE player_id = 123;
Playerのレベル上げて
よくある
Playerのレベル上げて
$player = Player::getById(123);
$nowLevel = $player->getLevel();
$newLevel = $nowLevel + 10;
$addExp = Exp::getNeedExp($newLevel) - $player->exp;
$player->addExp($addExp);
イテレーションスピードアップツール
完全社内制作のクリエイティブ素材なので最適なツールなど
ない
クリエイティブ素材なのでエンジニアでは正当性確認できな
い
作ったものは自身でその場で一人で確認できる環境を
PCとスマホ実機では全く同じようにはいかない
夢や理想なんて捨てちまえ
必要最低限でいい。必要になったら追加しよう。
運用ツールはサービスとともに成長するもの
いきなり大掛かりなものを作り始めると後戻りできない
理想を語っていても使ってもらえない仕組みは無価値
小さなツールをたくさんつくろう
開発に2日以上かかるのは課題分解ミスってる可能性
責任分界点を明確に
担当範囲が曖昧だと、責任感も曖昧になる
作ったものには責任を
各チーム、ユーザーに届けるまで面倒を最後までみる
責任が持てる環境をつくる
責任が持てる環境をつくる
担当者が単一でユーザーへ正しいデータを提供できるように
エンジニアが寝ていても安心して更新作業ができる
メンバーが全員安心してユーザーに正しいデータを提供でき
る環境を整備するのもエンジニアの責任
あたりまえのことをあたりまえに
情報は必ず集約する
サービスの通知などは必ず一つに集約
サービスの性質で深夜の通知も気にしなければならない
CMSと情報ツールだけでおおよその状況がわからなければな
らない
エラーとか障害は絵文字や画像を使ってインパクト重視
分散すればするほど、誰も見なくなる
サービスの新規開発で
気をつけたいこと
フェーズを意識した開発を
プロトフェーズ
本実装/制作フェーズ
運用フェーズ
プロトフェーズ
捨てる前提でつくる
バッドノウハウを蓄積する期間
コード品質なんかよりイテレーション速度が重要
各チームがどんな作業発生するかを見ておく
収益コンテンツの特性と、コスト感を把握しておく
本実装/制作フェーズ
初期でイテレーションスピードアップツールをつくる
仕様と収益コンテンツを見て再度整理する
大きな仕様変更がプロト最後であった時は要注意
運用フェーズを意識した開発運用をするようにする
この時からすでに運用リハーサルだと思う
運用フェーズ
開発環境のミスやエラーには気を使う
開発環境で起きた問題はいつか本番でも必ず起こる
誰が何に困ってるかを調べる
属人化してる作業がないか?
障害が起こってしまったら
しゃーない
次を防ぐ
障害はチャンス
しゃーない
いくらデバッグしても出るものは出る
しゃーない。しゃーない。
責めない
きちんと包み隠さず報告できる空気をつくる
次を防ぐ
きっちりヒアリングして原因を探る
ダブルチェックします!は対策じゃない
なにかしらのツールや、通知系のチェッカーをつくる
障害はチャンス
月に3回起こる障害の一つを潰せたら…?
社内評価も上がって
月に1杯ビール飲む時間ができる
年で12杯もお得!!!!
やっぱり障害はないほうがいいに決まってる
最後に
最後に
サービス提供するなら、きちんと収益を見据えましょう
とは言ってもエンターテイメントなので収益だけじゃダメ
所属するチームのプランナーが考えた最高のゲームをそのま
まの温度感でユーザーに届けられるエンジニアになる
技術だけに頼らずにチームを大切に
一人はやっぱり寂しい
ご清聴
ありがとうございました。

CrystalFantasiaを支えきった技術と技術だけではどうにもならなかった話