2012年4月11日水曜日

Unity + PHP + MySQLで作るスマートフォンゲーム開発勉強会にいってきた


こんばんはー、にゃまだんです。
私事ですが最近転職しました。
今はソーシャルゲームに関わるお仕事をしています。

さて、今日はLord of Knightsのうらっかわ勉強会に行ってきたのでその感想を書きますね。
メモみたいな感じになってますけどご容赦くださいm(__)m

~Unity + PHP + MySQL で作るスマートフォンゲーム開発~

Aiming細田さんのさんの発表

内容は「チームでの開発手法」と「クライアントサイドの技術」です(資料はこちら

大切なこと

  • 楽しく開発すること
  • 言いだしっぺが主導して頑張る
やっぱ作ってる側が楽しくないと楽しいゲームは作れないよね!

チームの話

  • チーム構成
    • クライアント3~8人
    • 企画3人
    • デザイン3人
    • サーバー約5人
  • 問題1
    • 企画とエンジニアのすれ違い
    • 部署ごとに部屋を区切られていてコミュニケーションが取りづらい
  • 解決
    • 開発メンバーの席近くにする
    • 近いので関連する話題が自然と耳に入る
    • 新人はリーダーの近くに配置し、放置を防ぐ
近いので関連する話題が自然と耳に入るってのはけっこー重要だと私も思います。
  • 問題2
    • 誰が何をやっているかわからない
    • 誰に相談したらいいかわからない
  • 解決
    • 朝会を行う
      • 難しい話しない、当日やること、わかってる懸念点を話す
      • 問題はチームで悩んでいく
  • 問題3
    • 朝会でやったことを忘れてしまう
    • 問題報告がおくれる
    • 残業が多い
  • 解決
    • 就業間近に夕会
    • 当日達成できたこと、出た問題点を話す
    • 朝会が短くなった
朝会の振り返りのフェーズね、なるほど。
  • 問題4
    • リモートで会社と仕事をしているとき
    • チャットやメールでは仕事の進みが見えず、問題発見が送れる
  • 解決
    • 週礼ビデオチャット会議、30分ぐらい行う
    • すれ違いが減る
    • 見えていなかった問題がぽろっとでてきたり
  • 問題5
    • 実装の優先順位がみえづらい
    • 仕様抜けがポロポロ出る
  • 解決
    • ユーザー体験のリスト化
    • いつどんな体験ができるか一覧できる
    • 優先順位はリーダーが決める
    • マスターストーリーリストというらしい。
  • 問題6
    • スケジュール通りに終わらない
  • 解決
    • バーンダウンチャート
    • 遅れ始めたらすぐわかるようになった
    • いつ頃終わるか予測が立つようになった
    • リリースバーンダウンチャートって言うらしい
    • タスク25からスタート、最高で70ぐらい
    • タスク消化の平均速度からリリース日を予測
やっぱアジャイルだねっ!
  • 大切なこと
    • リスクの早期発見
    • みんなでつくるという意識
    • 何があっても楽しく、あわてない
    • 何でも言えるチームの空気
      • すごい人にも「これグソゲーじゃね?」といえる空気。
これらが実現できれば手法はどうだっていいらしいです。

技術の話

Unity+HTML

  • UnityでUIつくるのは大変
  • リスト系など動きの少ない画面はHTMLのほうが作りやすい。
    • 実際パッと見区別がつかない
  • リリース後のアップデートがしやすい、
  • HTMLはサーバー側なので審査が不要
  • キャンペーンページなどの自由が効きやすい
  • 自由文字入力ができる
    • Unityだとフォントテクスチャのサイズが決まってる。
    • HTMLだとこのような制限はない。
  • HTMLのデメリット
    • ローディングが長い
    • レスポンスが悪い
    • メモリーを食う(ブラウザーとしてのメモリを食う)
    • Unityのエディタで確認できない
  • HTMLからUnityの機能を呼び出す仕組み
    • クエストの判定
    • サーバーとUnityの同期を取る
    • ユニティの画面遷移やUIの操作
    • Native Pluginとして実装

C#を活用した非同期通信アプリ

  • 通信の実装を気にしたくない
    • APIインタフェースがかわる
    • データのシリアライズ
    • バリデーション
  • 解決
    • 通信コードの自動生成
    • 定義ファイルからコードを生成
通信コードを自動生成とかかっけぇ。
  • 処理を直感的に書きたい
    • リクエストとレスポンスが分離されている
    • 非同期が連続するとカオスになる
  • 解決
    • メソッドチェインで解決ように
    • コルーチンを使っている
実はこの部分に一番ピンときた。
確かにリクエストを投げて処理を中断し、レスポンスが来た時点で処理を再開すれば非同期通信でもすっきり1つの関数で書くことができる。
  • エラーを気にしたくない
    • APIごとにエラー処理が分散している
    • 連続してエラーが起きた時に最後のエラーしかわからない
    • ERROR実装マジ面倒
  • 全ての非同期処理は共通化
    • エラーはキューに詰めておく
    • Viewはだいたい正常系だけかけばOK。
  • サーバー実装に依存したくない
    • Mockを使う(擬似サーバ)
    • クライアントだけで完結(擬似サーバがダミーの結果を返す)
    • ソースの変更なしでサーバーと切り分けられる
    • 異常系の確認も簡単
  • 簡単にVIEWに反映させたい
    • ポーリングしてデータチェックをして反映
      • チェック頻度が高いと負荷が高い
      • チェック頻度が低いと画面反映が遅れる
      • チェックコードを書きたくない
  • 解決
    • イベントドリブンでViewに反映
  • 通信の処理はUnityのWWWクラス
    • データフォーマットはJSON

質疑

  • ユニットテストとかでどんな工夫してた?
    • 今回は特に工夫はしていない
    • 次回からロジック部分はUnityとは分離したインターフェスを使って行いたい
  • チート対策とか
    • クライアントでは大切な処理はしない。

インフィニットループ松井さんの発表

  • 東京怖い
  • 会社はコーラ飲み放題
  • Vim検定をリリースwwww
  • 企画はやっていない、開発のみ
    • JSON API(RPC
    • HTMLを返すAPI
    • バッチ処理(PHP
  • 対負荷設計
    • ユーザー単位での水平分割は難しい
    • ワールドでサーバを分けられる仕様
      • ユーザー数で制限可能
  • インフラはGMOアプリクラウド
    • クラウドなのでサーバを追加しやすい
    • LBはGMOが用意しているものを使う
  • wwwサーバはApache+PHP5.3
    • 各ワールド共通で使っている
  • DBは1ワールドに1つ、バッチも1ワールドに1つ。
  • MYSQLは5.5系
    • 5.5系でデッドロックが劇的に減って、クエリも速い
  • rsyslogで監視
  • デプロイは専用自作シェルスクリプト
    • 中身はrsync
  • MySQL MHAを使用した自動フェイルオーバー(DeNAの中の人が作ったらしい
    • 1秒とか0.X秒で切り替わる
  • MyDNSが便利
    • 面倒なhosts管理から解放される
    • デプロイ先サーバーの決定、サーバの追加にも柔軟に対応
    • DBのバックアップ時に参照を外して、終わったら自動で戻す
  • 運用
    • プロセスやポートレベルの死活管理
    • アプリレベルでの監視
      • ログイン数や同時接続数(5分辺りのログイン数とか)
    • アプリログ監視
  • 対応
    • 問題があればMLにメール、担当の携帯へ
    • 電話帳機能でFrom判定し、けたたましい着信音を鳴らす
    • 社内にはアラート用PCを設置(ThunderbirdでPlaySound)
      • ゆっくりボイス
        「サーバがオチました、サーバがオチました、ゆっくりした結果がこれだよ」
      • ゆっくりサーバーと呼ばれているそうな
  • 既存案件との違い
    • PHP+MySQLWebアプリケーションそのもの、業務系の経験がそのまま生かせる
    • 設計や共通部分の制作には知識と経験が必要
    • クライアントは別でも工数は減らない、調整の必要があって増える傾向
    • ネイティブ実装にこだわらずHTML+JSで作っていったほうがいい
      • HTMLはなんだかんだで開発速度は速い
    • クライアントとサーバーに分業して作業することでウォーターフォールに近くなる
      • アジャイルとは相性が悪い部分もある
    • 規模が大きくなりがち
      • コーディング規約、教育スキームなど初期の枠組みが大事
      • コードレビューのしかけとか
    • データベースに関する深い知識が必要
      • 高い負荷に耐えられなければいけない
      • 仕様通りに動くものは割と簡単に作れるが運用に耐えられるかどうかが難しい
    • 負荷対策の難しさ
      • リクエストが多く、SQLも多い
      • ランキング入りで急増など
      • 負荷に対して柔軟に対応
      • 完全に負荷を読むことが難しい
        • サーバ台数を増やすことで負荷を調整できる設計に
  • ゲームの仕様を利用
    • ワールドで分かれるゲームなので利用上限を決定できる
  • スマホならではの特徴
    • 画面遷移ごとじゃなくて、要所要所のみでサーバアクセスできる
    • マスタデータはクライアントにキャッシュできる
  • PHPの処理を劇的に改善することは難しい
  • Webサーバーの負荷は台数増加で対応するしかないのかな
  • よく使われる参照はKVS(MEMCACHED)に回す
  • 負荷試験
    • 何処が遅いかをしっかり把握できるようにする
    • 遅くてよく呼ばれるのからじゅんばんに
    • 社内テストで実際のAPIの利用率を調べて試験シナリオを作成
    • 実際のレコード数をしっかり再現して実行する
    • ネックの箇所はAPIの利用回数を減らせないか検討
    • ウォーズマン理論wwwwwwwwwwwwwwwwwwwwww
  • 大抵の場合はインデックスとSQLチューニング
  • チーム運営について
    • Skypeチャットでコミュニケーション
    • 朝会をやっている
    • 楽しんで仕事をやることが何よりも大事

感想

特に興味を持ったのが非同期通信の仕組みです。ネットワークゲームなのでどうしてもリクエストとレスポンスがあります。レスポンスを待つのはいやだけど、サーバーの結果を待たないとゲームの進行に影響が出る。そこでコルーチンを使うのは賢いなーと思いました。
リクエストを送ったあとに関数を中断し、レスポンスが来ると同時に関数を再開すれば1つの関数でリクエストとレスポンスを記述できます。
ひょっとしたら発表者の意図とは違うのかもしれませんが、非同期通信では結構使えるテクじゃないかなと思っています。

サーバーサイドのお話は経験が浅いのもあり、「あるある」というよりも新鮮な感じがしました。
ランキング入りしてから負荷がどっと増えるというのはソーシャルゲームならではかもしれませんね。

0 件のコメント:

コメントを投稿