パソナテックエンジニアカフェ Lord of Knights の裏側見せます! ~Unity + PHP + MySQL で作るスマートフォンゲーム開発~

【エンジニアカフェEvent】エンジニアカフェ×Aiming (#aimingstudy 出張所)#2
Lord of Knights の裏側見せます!
~Unity + PHP + MySQL で作るスマートフォンゲーム開発~
Lord of Knightsのクライアント開発事例紹介

日時:2012/04/10(火) 19:00~
場所:パソナグループ 本部 8F

Lord of Knights
http://lordofknights.jp/
iPhone向けストラテジーRPG

発表資料

クライアントサイド(iPhoneアプリ:Unity)

開発プロセスの前提

  • チームみんなで楽しく開発
  • 工夫や改善を頑張る
  • なにがあっても楽しくあわてず

チーム規模

クライアント側:3〜8人
サーバ側:5人
企画:3人
デザイナー:3人

8.5ヶ月で作成

開発プロセスでの問題と対策

認識のすれちがい、部署の区切りによるコミュニケーション不足

対策:

席をまとめる
リーダのそばにセクションリーダー、運営を配置
新人はセクションリーダのそばに

結果:
必要な人にすぐ判断を仰げる
関連する話題が自然に耳に入る
新人が放置されにくい

他のメンバーが何をしているのがわからない

対策:
朝会を行う

結果:
全体の動きの把握
問題をチームで共有できた

朝会で言ったことを忘れる、報告遅れ、残業多い

対策:
夕会を行う
その日のことを忘れないうちに報告・共有
残業の必要性を判断

結果:
朝会の時短につながる

協力企業とのやりとりがチャットとメールだけだと進みが見えず、問題発見が遅れる

対策:
ビデオチャット会議を行う
30分程度
進捗報告。問題共有
雑談を交えつつ

結果:
合意が作りやすい
見えていない問題がぽろっとでたりする
仲良くなれる

どの実装を優先すべきか、仕様抜け

対策:
UXを Googleドキュメントにリスト化
ユーザーストーリーをリストアップ
それをマイルストーンごとにまとめる

結果:
次にやることが明確に
リスト化の段階で抜けに気づける

ただし、フローを工夫しないと管理が大変

スケジュールどおりに終わらない

対策:
タスクの増加・消化を可視化(グラフ)

結果:
遅れがすぐに分かる
終了予測がわかるように
遅れた理由が分かる

まとめ

アジャイル開発になっていった

現在の問題点

リリース後の割り込みが多く優先度がころころかわる
中長期スケジュールが立ちにくい

対策を試行錯誤中

大事なこと

  • 早期発見と改善が大事
  • チームみんなで作るという意識
  • 何でも言えるチーム
  • 何があっても楽しくあわてず

開発技術

UnityとHTMLのハイブリッド

UnityだけではUIが大変…40画面以上
→リスト系など動きが少ない画面はHTMLの方が作りやすい

メリット
  • UIとしては自然に実装できる
  • リリース後のUPDATEがしやすい。審査なしで可
  • 自由文字入力(chat,bbs)ができる
    フォントに使えるテクスチャサイズに制限がある(EZ GUI)
デメリット
  • ローディングが長い
  • 反応遅い
  • メモリー消費
    連携部分はエディタのみでは確認できない
Unity・HTML 連携

HTML側からUnityの関数を呼び出す

つかっているところ
  • クエストの達成判定
  • サーバとUnity内のデータ同期
  • Unityの画面遷移やUI操作
実装方法

native pluginとして実装。UIWebViewを利用

ブラウザが操作不能になるバグがある
→Unity側が自動生成する描画フラグを変更

C#の非同期通信

通信の実装を気にしたくない

通信実装コードの自動生成するようにした
→定義ファイルからコードを自動生成

処理を直感的に書きたい

メソッドチェインで書けるようにした

呼び出し().成功時callback().成功時callbackが完了した際のcallback().それが完了した際のcallback()

エラーをあまり気にしたくない

すべての非同期処理を共通化。根っこでtry〜catch。個別エラー処理も可能に
エラーはすべてキューに入れてあとで処理できるように
結果VIewは正常系のみの記述ですむ

サーバの実装に依存したくない

Mockを使う
ソースの変更なしで、本実装との切り替えを可能にする

簡単にViewに反映させたい

モデルからのイベントをVIEWでListenするようにした

VIEW作成時のモデル変更イベントをListen
VIEW破棄でListen解除

Q&A

  • Unitテストは?
    →クライアントは今回はやっていない
    今後は、ロジック部において、Unityエンジンのネームスペースを使わずにしてテストできるようにする予定
  • チート対策
    →クライアントで重要な処理はせず、VIEWのみ、サーバへはリクエストのみ
    リクエストの可否はサーバが判定
  • 通信切断からの復元
    →クライアントのデータの再同期メソッドをつくっておき、それを呼び出すようにしている
  • HTMLのチェック
    →コミットしたらパック化してすぐ実機確認できるようにした

サーバサイド

  • サーバはクラウドを利用、負荷に合わせてサーバの追加が容易
  • WEBサーバはApache+PHP5.3系 各ワールド共通
  • PHP
    • アプリのリクエストを受けJSONを返すAPI
    • アプリのリクエストを受けHTML返すAPI
    • 内部処理のバッチ処理
  • DB(MySQL5.5)
    • 各ワールドごとにMaster1台、スレーブ2台
    • バージョン5.5により、デッドロックが以前の版より減った感じ
    • MySQL MHAを利用した自動フェイルオーバー
  • ログはrsyslogで集約
  • デプロイは専用自作スクリプト(rsync)

対負荷設計で気にかけるところ

  • ソーシャル要素が強いのでユーザ間での関わりが強い
    • ユーザ単位の水平分割は難しい
    • ワールドでサーバを分ける(今回はゲーム仕様上可能だった)
      →1ワールドあたりの人数制限がかけやすい

MyDNSで名前解決

使い方

  • デプロイ先サーバの決定。サーバの追加に対応
  • 2台あるスレーブの参照率を変更できる(クラウドのインスタンスにむらがあるため、必ずしも同じ性能を示すとは限らないため)
  • DBバックアップ時にスレーブの参照を0にしてダンプ終わったら戻すという運用ができる

運用

監視

  • 死活
  • アプリレベル(ログイン数、同接数) ← 重要
  • アプリログ

問題があればMLにメール、携帯へ
ガラケーの電話帳機能でfrom判定 着信音を鳴らす
アラート専用PCを設置。メールの振り分け機能とPlaySound機能でアラートを鳴らす。
再起動レベルの簡単なインフラ障害の一時対応は24時間監視のサービス会社に委託

ソーシャルアプリのサーバサイドと既存案件との違い

  • サーバサイドはWEBアプリケーションそのもの
  • 設計や共通部は知識と経験が必要
  • API応答が主で地味な作業
  • VIEWがクライアントに移ったと言っても工数は減らず
    →調整などでむしろ増える
  • 分業作業(設計を受けて開発)をすることでWFモデルに近くなった
  • Appleの審査が大変(専用環境の用意やクライアントアプリとのタイミング)

ポイント

  • ソーシャルゲームは難しい
  • 規模が大きくなりがち
  • コーディングルールや教育スキーム 枠組みが大事
  • 自動化できるところは自動化
  • ノウハウの共有と短サイクルの改善
  • DBの深い知識
    • 設計
    • インデックス
    • ロック
  • 高負荷に耐える
    →仕様どおりつくっても負荷に耐えられるとは限らない
  • 負荷対策
    • リクエスト数が多い、SQL複雑
    • 急激な負荷
      →サーバのスケールアウトで負荷を軽減できるように

DBサーバの負荷対策

  • よく行われる参照はKVSへ
    →ただし、更新が多いデータはクリア忘れのバグにつながりやすい

負荷試験と性能試験

  • 各APIの実行速度と利用回数を記録
  • 実際のAPI利用率を社内テストから割り出し、試験シナリオを作成
  • 実際のレコード数を再現する
  • APIの呼び出し回数を減らす検討をする
    →処理速度UPと合わせてウォーズマン理論を形成
  • たいていはインデックスとSQLチューニングで改善

開発チーム

  • PHPエンジニア4
  •  DBエンジニア1
  • テスター1
  • インフラエンジニア1(他案件と兼務)
  • 見習い1

チームに見習いを入れることで、仕事を覚えていく。

開発プロセス

  • 進行はSkypeチャット
  • 朝会
  • 週一のふりかえり
  • 週一のクライアントとのビデオ会議
  • とかく楽しむ
  • 基本を大事に

Q&A

  • バッチによるDB負荷対策は?
    →ひたすらにインデックス、SQLチューニング

関連資料

第3回渋谷Unity技術勉強会

 

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中