GameSeverDeveloper に参加した記録とメモ

簡単に捨てれる開発、検証環境(Happy Elements) twitter@aki017

開発環境の問題

• OSのバージョンがそれぞれ違う
• 複数のバージョンを並行して使う必要がある（互換性がない）
• 手順書が古くなる
  • 一つ一つのコマンドを入力していく形 →これでは別のバージョンが入る可能性がある。
  • 別のバージョンが必要なある場合がある →他の環境(Windows,Linux)ではできないことも…

問題を解決するには？

Docker（仮想環境を構築するもの）を使えばよい
Dockerなら

• 全員が同じ環境を使うことができる
• 1コマンドで環境が構築できる
• 一つの環境を更新すればその環境を全員が読み込むので手順書の更新がほぼ必要ない
• docker-compose を使うと複数のコンテナをまとめて便利

検証環境の問題

• 複数のステージングが必要になる
  • 環境による挙動を見るとき
  • 新たな要素を追加した挙動を見るとき
  • イベントの挙動を見るとき etc...

→Dockerを使うことで解決できる！！

まとめ

WindowsではDocker構成に苦労するけど、Docker使おう

ゲームエンジニアのためのデータベース設計(DeNA Games Osaka) @人西聖樹 twitter@sairoutine

ゲームのデータをどうやって保存する？

• RDBMS
• KVS
• etc...

RDBMSとは

• データを表で管理する
• 表同士を関係させることでデータを組み合わせる
• ACID特性

ゲームデータの特徴

• ユーザが主キー
• 期間限定データ・永続データなど種類がある
• マスタ（読み込み用）データが多い
• 状態更新が多い
• 可用性・整合性が大切
  • (課金ユーザ様すごく敏感)

データベース構築時に考えること

• Maste/Slave構成
• 垂直分割
• 並行分割

Master/Slaveとは

MasterDBで制御操作を行い、一方的に操作されるSlaveDBを作る

• Slaveを参照用に
• Slaveの複数作成は簡単
• しかし、更新はMasterに集中する →Master がボトルネックになりがち

Masterの分割

垂直分割

テーブルの種類によって複数のDBに分ける

• Join句使えない
• 均等な負荷を考えなければならない

水平分割

レコードごとに複数のDBに分ける

• auto_incrementを使えない

複数のDBへのトランザクションをどうするか？

• コミットタイミングはすべて同一が楽

アプリ開発時に気を付けること

• 適切なindex
  • 完全二分木にする
  • オプティマイザを走らせて計画する
• クエリ発行量を減らす
  • きれいに正規化しない
  • あえてカラムを分割する
  • 時限付きデータ（イベントデータ）は別テーブルに
  • IN句でSELECT
  • Bulk Insert（一括インサート）
  • 一つの構文でInsertもしくはUpdateを切り替える構文もある
• 行ロック
  • 同時操作を常に意識する
  • レコードロックを行う
  • ロック順番は統一して、デットロック発生に気を付ける
  • きちんと存在するレコードに対してロックする（存在しない場合、全てをロックしてしまう可能性があるため。）
• レプリケーション遅延対策
  • 大量コミットによってMasterの変更が遅れること
  • キャッシュにつめて、遷移先で使用する
  • 更新系はMasterを更新する

オプティマイザとは

SQLがどのindexを使ってどの順序でアクセスするのかを計画する
EXPLAIN構文…計画の実行結果を表示できる

MySQLはコストベースでオプティマイザする

• CPU使用量
• I/O量など

→(開発環境と変わる場合があるので)本番環境でオプティマイザを走らせるほうが良い

KVSとの併用

KVSとは

ハッシュ・連想配列を使ったDBのこと。SQLを使わなくて良くなるのでRDBに代わるデータ管理をできるようになるのではないかと期待されている。

• ゲームデータのキャッシュは難しい
• 更新が頻繁なので、キャッシュクリアが大変
• ReadOnlyのデータをキャッシュしよう

Amazon API Gateway を活用したゲームサーバー構築(AWS) @清水崇之 twitter@shimy_net

ゲームバックエンドの一般的なコンセプト

• APIとして考える
• HTTP + JSON
• フレンドリスト
• バイナリのアセットデータ
• 拡張性・可用性
  • 分散処理
  • ELB

AWSを使えば高い可用性と拡張性

EC2で構築するのはしんどい

ならばAmazon API Gateway

• キャッシュができる
• クラウドウォッチでモニタリングなどを使える
• 簡単にすぐ作ることができる

DynamoDB

AWS上に存在するDBアプリ

Lambda

AWS上にデータの処理を記述する部分

API Gateway

AWSのインタフェース。HTTPレスポンスの設定や動かす処理の振り分けなどを行える

• メソッドの設定…入力値などの検査
• 処理の設定…使用するファンクションの設定

※ MOCKがテスト用に便利

• レスポンスの設定… HEADERの設定
• APIの設定…コール数の設定など
  

ゆるドラ運営記(Clover lab)@松本亮太 twitter@matumo0627

ゆるドラって？…北欧神話をもとに作られるたゲーム
http://yurudora.com/

ゆるどらの構成

• PHP
• C++
• JS

通常のハイブリットとの違い

Web画面を表示するものとNativeアプリを7:3で両立させたアプリ

なぜハイブリッド？

• ノウハウ・資産をいかすため
• 小規模チーム
• 短期開発

疑似パーティション

一つのデータ群を複数のテーブルで分割管理すること
例）一つのテーブルにID下一桁が1のユーザデータがまとめられる

• テーブルの負荷を軽減するため
• 普段から使用するデータ
• データが増えることが予想できる
• 不要なデータと必要なデータが混ざっている
• 不要なデータも必要になる可能性がある

メリット

データ参照・更新の負荷分散

デメリット

集計が大変

バッチ実行してたら途中で止まる件

冪等性を考慮しよう
冪等性（冪等性）…ある操作を一度でも複数回でも行った場合でも同じ効果を得られること

• ミス対策
• 予期せぬエラーに備える

詫び石の配布中などにエラーが起きた場合など

どうする？

• トランザクションを小分けにする
• どこまで行ったかを保存しておく

プレゼント配布に4時間かかる問題

全ユーザーにプレゼントを配布するバッチ処理に時間がかかる
→ログイン時に付与を行う

できるようになったこと

• OS別に
• アイテムはどんなものでも配布可能に
• 配布された時刻の指定可能に
• 指定ユーザーのみに
• etc...

メンテンパル現象

メンテ（中に）テンパる現象
→メンテナンス手順書を作成する

• 確認程度の設定
• 追加・変更点記載
• どのコマンドを使うのか

まとめ

• 泥臭く失敗だらけでも作ることができる
• あきらめずに作れば何とかなる

アプリ開発・運用で後々楽をするために知っておくべきUnityのサービス(ユニティ・テクノロジーズ・ジャパン) @鎌田泰行

複雑化開発・多様化する運用

→必要なのは楽をすること

開発フェーズ

Asset Store

資料・素材をマーケットプレイスで買える機能

Unity Maltiplayer

ネットワークゲームを簡単に作れる
フレキシブルにゲームを作ることができる。（多様なゲームを作りやすい）

Unity Cloud Build

ゲームのビルドを自動化・高速化できる機能
リポジトリを登録して自動でビルド・デプロイされる

Unity Collaborate

プロジェクトをチーム制作しやすくする機能

運用フェーズ

Unity Analytics

ゲームユーザの解析・表示を行ってくれる機能
+ 生データのエクスポート
+ ヒートマップ（ユーザのクリックポイントなどを解析できる）

Unity Ads

フリーゲームの広告などを行える機能

Unityから見たPhoton Cloud(クラウドクリエイティブスタジオ)@安藤健二,武藤辰矢

PUN(Photon Unity Networking)

マッチングサーバの用意などを吸収するフレームワーク

Photonのサーバ構成

• NameServerへのアクセス
• ↓
• MasterServerへのアクセス（ロビーやマッチング）
• ↓
• ゲームアプリサーバへのアクセス

クライアントからのアクセス状態は?

接続が完了するとPhotonNetwork.connectedAndReadyプロパティがtrueになる

マッチメイキング

Photon.joinOrCreate()メソッドを呼び出すだけでよい

まとめ

• PUNが煩雑な処理を自動化してくれる
• プロトタイプの作成までは簡単
• Photon Cloudの概念把握のドキュメントが公式では不十分

パネルセッション(Klab)@牧内大輔,山本雅也

EMLancherとは？

自作のテストアプリ配信ツール（OSS）

なんで作ったの？

社内でアプリ共有をするために既存のものでは不足部分があったから。
既存システムがなくなるのでは？となったから。

他社製品・既存品じゃいけなかったの？

• なんで？とほぼ同様。
• 既存品が使いにくくなる予想から使われるようになった

なぜOSSに？

• 自己や会社の宣伝にもなる
• 事業にすることで保守する必要がでてしまうから

最近やっていることは？

• Photonの解析
• SQLiteの解析
• etc...

Packdropとは？

通信遅延やパケットロスを疑似的にシミュレートをする装置

なんで作ったの？

シミュレートを誰でも簡単にできるようにしたかったため

他社製品・既存品じゃいけなかったの？

• 作れそうだった
• 作りたかった
• 拡張性がつけやすいため

なぜOSSに？

• 自分の宣伝になる
• 作り手が増えて、触ることができる人が増えてほしいから
• 仲間が増えて更に活発になれば良いと思うから

最近やっていることは？

• CTOが過去に作ったOSSソフトを解析

リアルタイム通信ゲームの実装例(Aiming) @山藤智之

常時接続と非常時接続

非常時接続（単方向通信）

クライアントからの要求に対してレスポンスを返すのみ

常時接続（双方向通信）

サーバーからクライアントに対して要求することができる

通信形式

キーフレーム形式

フレームごとの入力を交換しあう形式。
格ゲーなどに使われる

• 通信量が少ない
• 処理が簡単なため、高速

メッセージ形式

手続きを呼び出すデータを通信し、必要なパラメータをやりとりする
MMOなどに有効

• 拡張しやすい
• 複雑なデータを扱いやすい

通信ライブラリの作成

RPC(Remote Procedure Call)

ネットワーク上の別マシンで動いている手続きをプログラム内から呼び出す機能

実現するためには？

• 呼び出す順番の保証
• バイトオーダーによってデータがおかしくなるのを防ぐ

バイトオーダーとは？

OSによってがパケット送受信時にデータの並び順が変わってしまう問題

• ビックエンディアン
• リトルエンディアン

これをうまく考えることで送信料削減ができる

RPCのパケット構造

• バージョン
• 関数のID
• 引数のリスト
• 制御用パケット番号

IDL(Interface Definition Language)

送信用・受信用などと複数送受信用関数を記述しなければならないのを簡易化するために使う言語

• 定義を書けば自動で選択した言語での関数が生成されるように
• 選択した言語のジェネレータを作成しやすいように
• XMLを元に

負荷試験をしよう！(Klab) @内海恵介

目標性能試験

目標の数値が達成できるかを見る（）

• Request Per Sec (rps)
• Request time
• アクセス想定を元に使う

どんな時？

• 広告ブーストをかけるとき
• 新機能追加時
• コラボ

限界性能試験

現在耐えられる負荷を知る（アプリの性能を知る）

なんのため？

• ボトルネックを知ることができる
• Webサーバ１台でのrpsを知れる

どうやるの？

現在の構成で一旦落とす
↓
落ちる直前のテストまでレベルを下げる

拡張限界性能試験

インフラ構成の限界を知る（札束で何とか出来る部分を知る）

なんのため？

• 簡単に追加することが出来る部分を知るため
• さらに分けることが出来る部分を知るため

なぜ負荷試験をするのか

• 負荷に怯えないため
• 修正案を提出しやすくするため
• アプリケーションの性能を誇示するため

負荷試験に使うツール

プロファイラ

ログなどを使って性能解析を行うツール

メトリクス

サーバの負荷などをグラフ化するツール

攻撃側クライアント

サーバに対して攻撃をするためのクライアントツール

• 負荷試験用ロジックはいれない
• プレイヤーと同じ画面遷移
• マスターデータと出来る限り同じデータ
• シナリオを複数用意して実行する

落とし穴

• ELBPreWarming…ロードバランサのプレウォーミングをする
• 攻撃性能が足りていない場合