これに参加してきた。ネットゲームの通信の話だいすきなのでとても楽しかった。
スクエア・エニックス社内の具体的な事例をベースにわかりやすく話してくれたし、無料でこんなに技術公開するのすごい！！って思った。
以下講演中にとった雑なメモ
モバイル大戦アクションの通信最適化てくにっく
ひとりぷれいや協力プレイなら人間側を有利にすれば文句でないんですけどね
でも対戦ゲームはお互い人間なので、、
完全コマンド同期方式のゲームにおいて・・
- どのくらいの頻度で送受信するべきか
- RUDPの恩恵と作り方
- サーバー運用コストの下げ方
まず結論
100ms~200msごとに受信しつづけて、必要なときに送信するのがおすすめ
寝ている無線を起こす LTEはしばらく送受信がないと short drx という省電力モードの入っちゃうので それを active にするのに 50ms〜かかる
パケット頻度とrttを計測してみると面白い結果になった
~200ms は安定して速い 300~500ms はなんか時々スパイクが起きる 600ms〜は遅いけど安定してる
300-500msでスパイクが起きるのなぜ？ shortdrx に移行中にパケットを処理すると開放処理でなんか遅くなるやつか
下限はどれくらいにすれば？ まぁ100msぐらいでしょう 0.1秒単位で画面更新されればまぁまぁ十分でしょう
rudp
なぜudpでtcp/ipの真似する必要があるんですか？ tcp/ipはそもそもアクションゲームには向いてない
rudp: パケロス対策 パケットに過去のパケットもくっつけて送る
端末のipがかわってしまう現象 tcpipだとipがかわると切断されちゃうので、rudp!! ただ, udpはシーケンス番号もチェックサムみたいなのもないので送ってきた本人を認証する必要があります
なぜtcpip負荷が高い？ recvシステムコールが遅いから！ でもrecvmmsgは速いです→なのでudpは低負荷
なんでrecvmmsg は速い? 1回のシステムコールで大量のパケットをうけとることができる
ゲームエンジンで大規模開発する場合でのリソース管理の落とし穴
最近のスマホ、スペック高いけど省電力のためなどでフルに使うのは難しい。。 他のアプリが裏で動いてるのもあるので、1つのアプリで使い切るのはできない メモリだけで言えばps3にちかいけど、やっぱ消費電力があれなのでps3並のgraphicsはむずかしいかも
最近のスマホゲームの開発費、めちゃ高い 昔は数撃ちゃ当たるでだったが、現在はちゃんと作らないといけない感じ
エンジンはフォトリアルな高画質をアピールしてるけど、開発環境を開発チームのワークフローに組み込めず難航してるのがよくある スクエニでも起きてるらしい
大規模開発で失敗しないために
アセットの依存関係はすごい便利だけど、依存してるものは全部自動でロードするってやると、一気に大量にロードされてしまい メモリが足りない…
統合開発環境は、機能はたくさん与えてくれるけど、ワークフローは与えてくれない
ワークフローはちゃんと開発チームで考えよう！
たとえば、
- よく使うので起動時にloadしておくもの
- それ以外etc...
といった「リソース設計」はしっかりしましょう！！
モバイルゲーム配信業務効率化＆運用体制
効率化の1つ、プッシュ通知基盤
プロジェクトによってpush通知の仕組みバラバラ fastlaneよさそうだったけど、機能が多すぎるのでpemの部分だけがほしかったので自作！python使いたかった
2つ、game center や google play game service への対応 実装は簡単、でも登録は面倒…
プロデューサーが夜なべして6時間登録作業をし続けるなんてことがあった
なのでその登録をするwebアプリを作った
アセットバンドル作る時間がタイトルに寄っては12時間！ python好きって最初の人いってたのに担当者変わったとたん元graniのひとでてきてC#(ASP.NET+.NET Core)でてきて笑った
ビルドのapk(ipa)署名のツール appleの xcode についてる署名コマンド、ドキュメントがない！！！おいおい・・ googleはちゃんとドキュメントある、さすが、見習って欲しいapple
チートを未然に防ぐ脆弱性診断
たとえばガチャの実行回数に負数をいれると無限にポイントが貰える これを「仕様書に書いてないから仕様書が悪い！」ってする？しないよね、暗黙の仕様というか、 そもそもプランナーは実行回数がsigned intとかそんなこと考えないし、現実的にありえない
じゃあ負数のチェック入れましょう これでOK？まだだめです たとえば実行回数 0.1 にするとどうなる？
1日1回無料とかは注意 パラメータチェックがちゃんとしてないと、1日1回の実行回数をいじられて、無料分で2回以上ひかれてしまうなどありえる
仕様と実装かみあってないのが原因 パラメータ検査と言うのは非常に大事 ここをfwにできるだけ任せたい apiはロジックに集中したい
あとほぼ同時にリクエスト来たら、、とか考えると→排他制御 redis等の場合、hasKey と insert がわかれてるとその間の僅かな隙間に・・とか dbはtransactionに入る前にselectしちゃってるとか,,,
オンラインゲーム開発に欲しいプログラマーとその理由
運用経験のある人のほうがほしい
スケールアウトされたサーバーのどれにつなぐかというアルゴリズム least connection, round robbin どちらがいい？ round robbin を推奨します
least connection は本当に上手く作らないと、偏りが出て障害が悪化することが多い ので、round robbin使いましょう
効果音と同時にゴールドの増減表示しなくなったことによってお問合わせが急増
運用中のタイトルでは妥当と思える対応が、問題になることがあります これは運用してみないとわからない 経験値が大事です
ドラゴンクエストxを支える技術 発売予定です
質疑応答
海外ならではのパケロスチューニングはある？ →海外ならではを考えた結果発表したrudpになった。おそらく先ほど発表した内容が、普通のプログラムでできる最高速度だとおもいます。北米でやるならtcpipじゃだめで、rudpじゃなきゃなって思います
rudpに関してnatごえとかはどうしてるのか？ そもそもnatごえを必要なくした。サーバー側で頑張れるようにつくったものなので
least connection によって起きた障害はリリース後2週間ぐらいのときです null と "" は 1.1
リソース管理について、スクエニでのアセット管理どういう風にしているか バージョン管理とかですね、それでいえばpower force を使っているところが多いですね、また subversion で管理してます ffの13のときは独自のアセット管理用のシステムをサーバー側に立ててやってるとこもある つまりその手のインフラをストレージをどういうものを置くかによってパフォーマンスかわってくるので 大きいチームだとその規模にあったストレージを構成して 外部でも開発する場合はどうしても社内に全サーバーがあるとだめなので、キャッシュサーバー的なものを外に置けるようにしている その都度都度で開発体制、規模にあわせて毎回インフラを作る感じになっています ドラクエXも大きいんですけど、subversionで管理してるけどpower forceのほうがぶっちゃけいいですね、気軽に前のバージョンに戻せるので 最初から設計してたらpower forceにしてたかもしれないですね。キャッシュの仕組みも含めてやっていますね もしsubversionつかうときでかい場合は履歴が残り続けるsvnだと遅くなってくるので、repoを結構分けます repoを一回捨てて、いっかい作り直すこともありますね、
OSSの脆弱性みつけたらどうしてる？ 社内情シスのほうでみてて、そこから最新版に更新してくださいってやってる オープンソース部分の開発については社内ではないので
静的解析ツールはプロジェクトごとに使ってるところと使ってないところがある 脆弱性の観点でいうと機会的に出せる部分と出せない部分があるのでどちらかというとQAの部分で静的解析ツールは有効 でも脆弱性診断は機械的に判断するのは難しいところもあるので、ちゃんと手動で見ている
作った社内ツールをoss化される予定がありますか それは・・・・したいですね。まぁ、弊社のものをoss化する取り組みに関しては大きいので 配布するとなるとどれぐらいの頻度でメンテをしていなかればならないのかという社内リソースのですね、、 企業なのでそのあたりのバランスとか検討をしていきたい 個人としてはしたいなという意思はあります
udpが通らない場合はtcpにフォールバックしますか？ いままではやってないです。基本モバイル用なので、モバイルでudpつまってるとこないだろって 大学とか企業とかでこっそりプレイしてる方はあれですけど、、 将来的に考えたりしたもんですけど、ちょうどgoogleのquicの論文見たらなんか似ててあれですけど〜 その論文でudp通らない環境どれくらいあるって調査でけっこうすくないので これからudp通らない環境は少なくなってくるんじゃないかなーっておもいます
100ms~200msで受信してると起こしやすい、そのtriggerになるのはrecvのシステムコールですか？ recvっていうのはosがためたバッファから取ってくるだけの関数なので、 モバイルの端末の無線機が実際に電波が飛んできたときに寝ている無線が起きるので recvは関係なくハード側でやっている感じですね recv呼ばないとしても電波がちゃんと飛んできているならば、
あ、あとrudpのoss化を... tcpip自体がオープンな規格なので同じように動くのをudpに差し替えればささっとつくれますよ
グラフィクスと比べて無線のバッテリー消費は無視できるようなものなのでしょうか？ 通信もけっこうバッテリー消費はげしいですね
