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…ロードバランサのプレウォーミングをする
+ 攻撃性能が足りていない場合