ソーシャルゲーム開発における運用とそのツール
Upcoming SlideShare
Loading in...5
×
 

ソーシャルゲーム開発における運用とそのツール

on

  • 2,420 views

Frontrend-Nagoya 発表資料

Frontrend-Nagoya 発表資料

Statistics

Views

Total Views
2,420
Views on SlideShare
1,676
Embed Views
744

Actions

Likes
14
Downloads
13
Comments
0

8 Embeds 744

http://nantokaworks.com 359
http://frontrend.github.io 151
http://blog.wnotes.net 138
https://twitter.com 69
http://localhost 11
http://feedly.com 9
http://s.deeeki.com 5
http://www.slideee.com 2
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

ソーシャルゲーム開発における運用とそのツール ソーシャルゲーム開発における運用とそのツール Presentation Transcript

  • ソーシャルゲーム開発における 運用とそのツール 2014/06/21 Frontrend in Nagoya @ysugimoto
  • Introduction •Yoshiaki Sugimoto •Frontend Developer •HTML / CSS •JavaScript / Node.js •PHP •Linux https://github.com/ysugimoto
  • Loving♡
  • Career 名古屋でWebシステム開発に従事 • フロントエンド特化したい • 株式会社サイバーエージェント • 東京こわい
  • Working... JavaScript SDK Perfomance Any ServiceMaintainability Pure JavaScript
  • Agenda •ソーシャルゲームとチーム開発 •技術的負債とどう付き合っていくか •運用フェーズの取り組み •まとめ
  • ソーシャルゲームと チーム開発
  • TODO : 天クロの画像貰えたらもらう
  • 天下統一クロニクル •ご当地名物を題材にしたソーシャルゲーム •2012/09 サービス開始 •会員数約250万人+ (2014/06/18現在)
  • •約30人くらいのチーム  (プランナー・エンジニア・デザイナ含)  うち、ディベロッパー6人 •週に一度くらいのリリースサイクル 天下統一クロニクル
  • レイドバトル ギルドバトル マラソン ゲームループと イベント メインループ +
  • プレイヤーグループ(ギルド) 同士のバトル ギルドバトル
  • プレイヤー同士が共闘するイベント レイドバトル
  • プレイヤー個人で目標を達成し、 順位を競う マラソン
  • アプリケーションの特徴 •(Semi)SPAの形式 •非同期リクエスト+DOM書き換え多数 •JSよりもCSSが複雑 •アニメーション多数
  • Frontend-technology •Pure JavaScript Core Framework •Sass(SCSS) •JsRender (Template Engine) •Grunt •CreateJS (Toolkit for CreateJS)
  • 2012/09 2014/06
  • 2012/09 2014/06
  • Technology Architecture Tool
  • フロントエンドの2年は 変化というよりも変革
  • 新しいツールの登場 → 便利そう! 新しいアーキテクチャの登場  →シンプルに書けそう! 新しい技術の登場  → 夢がある!
  • 理想と現実
  • 新しいツールの登場 学習コストに見合うかな・・・ 新しいアーキテクチャの登場  コアからのリプレイスは無理・・・ 新しい技術の登場  端末サポートが・・・
  • 数年先を見越した取捨選択、 現時点でのベストエフォート
  • 技術的な負債と どう付き合っていくか
  • コードと技術の 賞味期限
  • 導入ライブラリの最新版が取り込めない APIが大幅に変わって追従できない 重要なSecurity FIXが取り込めない 古い端末のサポートのためのPolyfill 影響範囲が大きすぎて改修しづらい APIのレガシー化
  • フロントエンドにおける ライフサイクルは短い
  • 増えるコードとステップ数 そしてファイルサイズ
  • このメソッドって使ってる所ある? ここの処理って通過する? if文ネストしすぎじゃ? コードカバレッジの低下
  • レスポンスタイムへの影響 実行速度への影響 メンテナンス性への影響 画像・CSS パフォーマンス 担保領域の拡大
  • フロントエンドエンジニアは やることが多い
  • ここの文言修正 してほしいんだけど この要素間は もう少しマージンが 欲しいです APIレスポンス、 フォーマット 変わったんで Android2.3で この機能 動いてないので 調査して
  • コードの属人化
  • 特定の人が永続的に メンテする可能性 途中から別の人が コードに触れる可能性 特定処理・ コードの属人化
  • このライブラリ 便利だし入れよう ライブラリの属人化 その人しか 使えなくない?
  • "この人しか分からない" は危険信号
  • Case:アニメーション タイムラインアニメーションを スクリプティングするのは難しい (素のCreateJS) 作った人以外は 動作がイメージしづらい
  • Toolkit for CreateJSの採用 Case:アニメーション
  • Flash IDE上で アニメーションが作成可能 Flashがわかる人なら修正が可能 プレビューしながら修正が可能 Case:アニメーション
  • ヒューマンリソース の限界
  • 切迫した状態でのコードは負債を大きくしやすい →場当たり的なコードの生産 →コアFWから乖離したコード 精神衛生上良くない 残業して解決するのは本質ではない
  • 技術的負債解消への 取り組み
  • 古いコードの見極め ツールで共通化・自動化
  • 運用・改善フェーズ
  • ミクロな視点と マクロな視点
  • マクロな視点 「この画像減色されていませんね」 「CSSは共通化できるんじゃないですか」 「ここはスプライト化してください」 「ページのパフォーマンスが落ちています」
  • アプリケーション動作の 側面からの観測
  • •トータルパフォーマンスは? •ユーザの体感速度は? •画像サイズは? •CSSサイズは?
  • •重複・冗長処理の削減・共通化 •新旧端末で発覚する不具合 •レガシーコードのリライト •属人化の低減 ミクロな視点
  • コードベースの観測
  • •今よりもっと良い方法はないか? •効率が上げられるポイントは? •ツールで補えないか? •このコード書いたの誰?
  • •API・ドキュメントの整備 •全体/細部のリファクタリング •端末問題の検証と対策 •大きな変更は加えず、影響を最小限に •テストを繰り返す Defensive
  • 安定稼働は最優先事項
  • 新機能開発フェーズ
  • •現時点での流行・便利そうな技術への取り組み •既存FWと著しく乖離しないポイントの見極め •数年先も生きる/基礎となるようなものの選択 •温故知新 Offensive
  • 新しい実装によるメンテナンス性は? 新しく書かれたコードはどこ? 既存コードへのリプレイスは?
  • 20% offence 80% defence
  • 運用での取り組みとツール
  • Webサーバ・DBの設定 サーバーサイドとの連携
  • フロントエンドが手を掛けるべき ポイントではない
  • 社内では「AeroMock」という Javaプロジェクト向けツールを 導入しています •軽量な起動 •APIレスポンスモック •Tomcatの起動・再起動が不要
  • 共通知としての ライブラリ・ツール
  • このライブラリ 便利だし入れよう ライブラリの属人化 その人しか 使えなくない?
  • とはいうものの
  • オンライン上に存在するドキュメント 特定APIの設計・実装の時短 技術・知識レベルの平坦化 ライブラリ導入による 恩恵は大きい
  • みんなが使えるものを使う 必ず吟味する 必要であれば勉強会を開く
  • 仕様ドキュメント を起こす
  • ドキュメンテーションはあって当たり前 実装引き継ぎの際のロスを低減させる スタイルガイドを作ってデザイナーと共有
  • ソースコードレビュー の文化
  • Enterprise
  • 属人化するコードの低減 コードベースで議論する なるべく偏らないレビュー指名 気軽に機能追加・改善を試せる土壌
  • SVNからGHEに移行して、 他のメンバーのコードを読むことが 増えました(32歳 男性)
  • テストを書く 実行する
  • リファクタリングの副次効果 →メソッドの分割  →引数・戻り値の型の意識 →メンテナンス性の向上 精神衛生上良い
  • DOM周りのテストはやりづらい DOMに癒着しすぎているメソッド ロジック分離の意識 モデル・コンポーネント化
  • 自動化する
  • 特にマンパワーが必要な(面倒な)部分 •CSSスプライト生成 •画像減色 / チャンク削除 •PixelRatioイメージ自動生成 •JS結合とminify •Sassコンパイル •自動テスト •etc...
  • 統計情報に基づく改善
  • コードに関する統計情報を出し、 改善の指針にする
  • platoの出力例
  • まとめ
  • チーム開発のいいところ
  • スタープレイヤー フルスタックエンジニア(?) 技術的な相談ができる 多様なチームメンバー
  • ゲームディベロップ に必要なスキル
  • ProjectA ProjectB ProjectC
  • 適応力
  • 流行りに流されない 普遍的な技術
  • キャラ付け
  • 1行の重み 1行の喜び
  • 自分のコードで 数百万人が楽しんでくれる
  • 自分のコードで 数百万人が遊べなくなる
  • コードに対する 責任感
  • 最終的に遊ぶユーザの気持ちで考える ・UI ・パフォーマンス 自ずと改善すべきポイントは見えてくる
  • パフォーマンスに 対する責任感
  • 目に見える・ 感じる部分が フロントエンドの 担保領域
  • 攻める部分と守る部分を明確に メンバーの入れ替わりは結構頻繁にある 明日いなくなっても大丈夫なように コミュニケーション力大事  一人よがりのコードを書かない  積極的にノウハウを共有していく
  • Thank you!! https://flic.kr/p/d9K1Bc https://flic.kr/p/bZw1ym https://flic.kr/p/fYtrdY https://flic.kr/p/njeKMd https://flic.kr/p/5TEDDA Any questions?