Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発&運営技法

52,221 views

Published on

Published in: Technology
  • Be the first to comment

【CEDEC2013】20対20リアルタイム通信対戦オンラインゲームのサーバ開発&運営技法

  1. 1. 20対20リアルタイム通信対戦オンラインゲームの サーバ開発&運用技法   代表取締役 本城 嘉太郎 取締役CTO 仁木 拓磨 運営開発部 西山 高志 株式会社
  2. 2. 本講演の趣旨 13-8-26 2 ■本講演の趣旨    20対20のリアルタイム通信対戦をブラウザで実現したオンラインゲーム   「クリスタル◆コンクエスト」(c)スクウェアエニックス2012    今回は、40人対戦を実現するためのサーバ開発と運用に焦点を当てて、 負荷分散、サーバ間通信、プロセス管理、データベース運用など、オンラインゲームの   サーバ開発や運用全般的に応用できる技術的なトピックを解説します。     ■本講演の対象者   ・オンラインゲームのサーバ開発を担当されている、もしくはその予定のあるエンジニアの方。     ■タイムテーブル ・開始〜5分  講師紹介、タイトル紹介 ・5分〜25分  <設計編>   ・25分〜45分  <開発編>   ・45分〜60分  <運営編>  
  3. 3. 講師紹介 13-8-26 3 株式会社モノビット <事業内容> 1,ネットワークゲームの開発と運営(コンシューマ、スマホ、ブラウザ) 2,通信ミドルウェア(モノビットエンジン)の研究開発 → 3階中央にブースも出しています 昭和53年生まれ。神戸出身。 19歳の時に出会ったUltimaOnline、Diabloに衝撃を受け、将来オンラインゲームを作ると決意。システムエンジニア、コ ンシューマゲームプログラマを経て、2005年にオンラインゲーム制作会社を創業。オンラインゲームエンジンを自社開発し つつ、2009年にはソーシャルゲームにも自社タイトルで参入。20タイトル以上のオンライン・ソーシャルゲームの開発と運営 を手がける。オンラインゲーム開発に専念するため、SAP事業を譲渡し、2013年1月に株式会社モノビットを設立し現職。 代表取締役社長 本城 嘉太郎 1980年生まれ。大阪出身。 代表の本城とともにオンラインゲーム開発会社を起業。 主にオンラインゲーム・ソーシャルゲームのためのサーバ、ネットワーク、データベースの設計と構築に携わる。 自社開発オンラインゲームエンジンのプログラム基盤も担当。 取締役CTO/ネットワーク技術部 部長 仁木 拓磨 1971年生まれ。島根出身。 アーケードゲームとコンシューマゲームのプログラミングを長年手がけ、5年前に本城が代表を務める会社へ入社。 MOタイプのオンラインゲームを複数本開発し、クリスタル◆コンクエストの開発、運用を担当。 現在は通信ミドルウェア&総合サーバパッケージ「モノビットエンジン」の研究開発に従事。 運営開発事業部 副部長 西山 高志
  4. 4. 対象タイトル紹介   13-8-26 4 「クリスタル◆コンクエスト」は、 チーム対戦型横スクロールアクションバトルゲームです。 プレイヤーは最大20人vs20人、4つのクラスで役割分担し、 多彩なスキルを使ったり、強力な召喚獣を配下として操ったりしながら、 敵軍の本拠地を陥落させることで自国を勝利へと導きます。 強力なマッチング機能により、 ひとりで気軽に短時間のバトルに参加したり、 より強さを求めて仲間とパーティを組み、 さまざまな連携や戦略を駆使した協力プレイで、 定石のない白熱したバトルを楽しむことが可能です。(wikipediaより) クリスタル・コンクエスト©2012  SQUARE  ENIX  CO.,  LTD.
  5. 5. 対象タイトル紹介 13-8-26 5 ■クリスタルコンクエストの特徴 ・最大40人対戦のリアルタイム通信アクションゲーム ・ロビーでマッチング→バトルへ遷移    →いわゆる一般的なMOタイトルです! ■技術的な特徴 ・ワンワールド設計 ・クライアントはFlashPlayer ・サーバはLinuxベース ・通信エンジンは自社開発のミドルウェアを使用  (モノビットエンジンのプロトタイプ) ■本講演でお話すること ・サーバ周りを中心にお話しします。 ・2年前に設計されたサーバとなるので、 どう作ったかだけでなく、反省点と良かった点、 実際やってみて気づいた点などもお話しします。 クリスタル・コンクエスト©2012  SQUARE  ENIX  CO.,  LTD.
  6. 6. 【設計編】  
 1. データベース構成 2. ゲームサーバ構成 3. 可用性、安定性の向上 4. 負荷分散 13-8-26 6 【設計編】 目次
  7. 7. 1.データベース構成
 マシン構成   性能向上施策など 13-8-26 7
  8. 8. 【設計編】1,データベース構成
 ■まずデータの保存方法の選択 •  データベース •  ファイル •  KVS   •  etc...   →  迷わずデータベース すべてのデータをレコード単位で保存 13-8-26 8
  9. 9. 【設計編】1,データベース構成
 何故データベースか – アイテム一つに至るまでトレースしたい – SQLで集計、調査したい – データ構成を変更できる – どこからでもアクセスできる 何故KVSではないか – 集計ができない 13-8-26 9
  10. 10. 【設計編】1,データベース構成
 ■全体構成 •  MySQL  5.5  + InnoDB  (+InnoDB  Plugin) •  レプリケーション(マスター/スレーブ構成) •  ゲームデータ、ログ、管理、KPI   13-8-26 10 ゲームデータ ログ 管理 KPI
  11. 11. 【設計編】1,データベース構成
 ■スレーブによる参照性能の確保   •  バッチ処理   – ランキング集計、KPI集計   •  調査   •  バックアップ   – Full  dumpなどの長時間の読み出し       参照性能はスレーブ増設で拡張   13-8-26 11
  12. 12. 【設計編】1,データベース構成
 ■テーブルパーティショニング   データベースの性能を「下げない」ための手段。   ※データベースは運用期間が長くなるほど性能が低下する 13-8-26 12 record すべてが 検索対象 index record 必要なレコー ドだけ読み 込み でも:インデックス   全体は検索対象 数千万、数億レコードになるとインデック スだけでもメモリを圧迫
  13. 13. 【設計編】1,データベース構成
 ■テーブルパーティショニング   データベースの性能を「下げない」ための手段。   ※データベースは運用期間が長くなるほど性能が低下する 13-8-26 13 index record パーティションのインデックス 、レコードだけが対象
  14. 14. 【設計編】1,データベース構成 ■パーティションの種類   Range、Hash、List、etc…     •  基本的には日付ベースの Range   –  ログなどの時系列データに効果が高い   –  一般的によく使われる方法     •  時間と関係無いデータは?   –  ログではないゲームデータとか   –  仕様に合わせて選びましょう   –  メモリに乗せる量が絞られるように   13-8-26 14 index record 2013年8月21日 2013年8月22日 2013年8月23日
  15. 15. 【設計編】1,データベース構成
 ■テーブル圧縮   データベースの性能が「下がりすぎない」ための手段。   13-8-26 15 容量大きい 容量小さい (10分の1くらい) アクセス量多い アクセス量少ない メモリ上のデータ 量は変わらない 圧縮・解凍に CPUを使う
  16. 16. 【設計編】1,データベース構成
 ■どんなときに圧縮?   •  ディスクIO性能が低い(アクセスが遅い)   •  ディスクの容量単価が高く、容量を増やしにくい   •  マシン構成上、ディスク容量を増やしにくい    →IaaSクラウド、置き換えしづらい物理マシン     クラウドでも   –  ディスクが早い   –  容量単価が安い   –  ディスクの増設、拡張がしやすい   というサービスなら逆効果の場合も 13-8-26 16
  17. 17. 2.ゲームサーバ構成
 マシン構成、ネットワーク構成など   13-8-26 17
  18. 18. 【設計編】2,ゲームサーバ構成
 ■システムの前提条件   •  クラウドで運用   – 仮想マシンなので比較的性能が低い   – 突然落ちる、通信が途絶える   – IPアドレスがころころ変わる   •  グローバルIPアドレスはできるだけ節約   •  いつでもサーバを増やせるように 13-8-26 18
  19. 19. 【設計編】2,ゲームサーバ構成
 13-8-26 19 バトル バトル バトル ・・・ リレー リレー リレー ・・・ GSv1 ・・・ GSv2 ・・・ GSv3 ・・・ GSv4 ・・・ DB DB ・・・ データ データ ・・・ データベース バックエンド ゲームサーバ フロントエンド 1台ずつ固定I Pアドレスを 持つ
  20. 20. 3.可用性、安定性の向上
 
 サーバ構成の仮想化について   13-8-26 20
  21. 21. 【設計編】3,可用性、安定性の向上
 ■「サーバは落ちてもサービスは落ちない」   •  サーバが落ちてもすぐに復帰できるように   •  落ちたサーバだけに影響を限定して、サービス全体に波及 しないように   •  クラウドなので「マシンは落ちる」前提で        ↓    サーバの処理単位をプロセス内で分離、    仮想プロセス的なIDを持たせるようにした   13-8-26 21
  22. 22. 13-8-26 22 バトル ・・・ バトル ・・・ リレー リレー リレー ・・・ GSv1 ・・・ GSv1 ・・・ GSv2 ・・・ GSv2 ・・・ DB DB ・・・ データ ・・・ データベース バックエンド ゲームサーバ フロントエンド データ ・・・ プロセス 仮想プロセス 【設計編】3,可用性、安定性の向上

  23. 23. ■効果1   •  IDで通信できる    →物理的なサーバの場所を気にしなくてよくなった   •  仮想プロセスはいつでも作ったり消したり出来る    →特定の仮想プロセスに依存しなくなるので、同じ種類   のサーバの増減が容易になった    →どんなタイミングでもシステムに参加できるので、再起   動が容易になった    →MOゲームの特性に合わせて、接続ユーザ数に応じた   ルームを起動・終了可能になった   13-8-26 23 【設計編】3,可用性、安定性の向上

  24. 24. ■効果2   •  システム全体が仮想プロセスの消失を前提にしている    →落ちたマシン、プロセスだけに影響を限定できる   •  クライアントはリレーを介してIDで通信している    →ルーム移動やバトル前後で、接続し直さなくてもIDの   変更だけで通信するサーバを切り替えられる   13-8-26 24 リレー GameSv GameSv 【設計編】3,可用性、安定性の向上

  25. 25. ■ユーザデータの保全   •  ユーザデータはすべて「データサーバ」で保持   •  DBへのユーザデータ保存・更新もすべてデータサーバ   •  他のゲームサーバは、データサーバのコピーを扱う      ↓   データサーバが落ちたらユーザデータを失う?    →複雑なことをしないので落ちたことがありません   13-8-26 25 【設計編】3,可用性、安定性の向上

  26. 26. 4.負荷分散
 
 
 仮想サーバ構成の活用   13-8-26 26
  27. 27. 【設計編】4,負荷分散
 ■クラウドであることの利点   スケールアウト(増設)、スケールアップ(スペック増強)が容易    ↓   Webサーバと同じように「増やせば良い」と考える    ↓   仮想プロセス構成を活用し、サーバ種別ごとに負荷に応じて 台数を増減   13-8-26 27
  28. 28. 【設計編】4,負荷分散
 •  リレーサーバ   –  多数のクライアントが接続してくる   –  複数台のリレーサーバをクライアントに選択させる   –  自然分散に期待する   •  ゲームサーバ、バトルサーバ、データサーバ   –  最も負荷の軽いサーバを選択(データ量、ユーザ数少ないなど)   –  ラウンドロビン   –  足りなさそうだったらプロセスを増やす   仮想プロセス構成により負荷分散は自然と達成できた。   いくらでも増減できるので、コストバランスも最適化できる。   13-8-26 28 設計編は以上です!
  29. 29. 【開発編】 13-8-26 29 1. プロセス管理 2. データ同期システム 3. パケットの暗号化, 圧縮, 分割 4. 通信データ削減技法 5. サーバのデバッグ 6. 大人数同時接続テストの実際 【開発編】 目次
  30. 30. ClientClient Battle MySQL Login Communication Area Battle Relay Client Battle Linuxのプロセス MySQL ClientDataData Login Area Communication Battle Battle Relay Battle 子プロセス 2 【開発編】  1.プロセス管理 同種のプロセスは全て複数起動 ・負荷の分散 ・プロセスが落ちても  サービスを継続可 ・追加起動もできる バトルは 直接クライアントと接続
  31. 31. ロビー/ギルド ルーム ロビー/ギルド ルーム 31 ProcessUnit Areaサーバの例 Process Unit ユーザデータの管理理 他のエリアサーバ との調停 外部Webサーバとの やり取り ロビー/ギルド ルーム ・各PUはユニークなIDを持つ。 ・そのIDを宛先として、PU間で  メッセージを送れる。 ・1PUを1スレッドとして並列実行する。    (シングルスレッドモードでのビルドも可能)  ・SQLのクエリ実行リクエスト  ・外部Webサーバへのリクエスト PUの他にスレッド生成する物 【開発編】  1.プロセス管理 PUを派生
  32. 32. 32 データ同期システム 簡単に言えば、サーバ  -  サーバ間や、サーバ  -  クライアント間で 自動的に構造体の同期を取ることができるシステム。 Data Communication Area Battle ・どこに誰のユーザデータがあるかの  管理が容易 ・ユーザデータ移動の手順を  簡略化できる ・フロントエンドサーバが落ちても  DBへのデータ保存を保証する Master Slave 【開発編】  2.データ同期システム ここで 書き換えたら… …マスターと 他のスレーヴで同期 利点
  33. 33. 33 パケットの暗号化/圧縮/分割 ・攻撃やチート行為を防ぐ為には、暗号化が必要 ・圧縮と分割もやっている パケット ⽣生成 分割 圧縮(lz4など) 暗号化 暗号化 通信 結合 解凍 復復号化 サーバ クライアント 【開発編】  3.パケットの暗号化,  圧縮,  分割 ※  クライアントからサーバへの通信も同様。サーバ間では暗号化せず。 ゲームの 受信処理理
  34. 34. 34 通信量の削減 実測値で8Mbpsの回線速度で遊べるように パケットを圧縮しても、サーバからクライアントへの送信量が多い 特別な解決法は無い。最適化をこつこつと メイン画面はルーム内の 情報だけあればよいが、 ミニマップは全体が必要 視覚的に荒い情報なので、 300ミリ秒間隔で更新 例1  ミニマップ 【開発編】  4.通信データ削減技法 (解凍や復号化といった処理も重いし…)
  35. 35. 35 例2  移動 サーバ上で移動経路を 算出 方向転換した座標の リストを送る クライアントで曲線補間 【開発編】  4.通信データ削減技法
  36. 36. 36 例3  チャット 極端に多いと、リレーサーバが処理しきれない でも、誰もそんなに発言しないでしょ? 非常に低い確率で起きる  →  確実に起きる おは よろ おつ 1 FIFOキュー 6秒後 すぐに送信 10ミリ秒後に送信 1秒後 キューの上限を超えた  →  発言者へエラーを返す 同一市内の 全員へ送る 2 120 バルス 【開発編】  4.通信データ削減技法 バルス バルス
  37. 37. 37 Windows ローカル環境 VMware  +  CentOS shell(gcc,  gdb等の操作) Webブラウザ(クライアント実行) 【開発編】  5.サーバのデバッグ エディタ(Visual  Studio,  Eclipse等) FlashDevelop, Adobe  Flash 1台のWindows  PCで完結
  38. 38. 38 サーバのデバッグ ・フロントエンド  →  良い物が無かった ・gdbtui(テキストユーザインタフェース) ・stl-views  で  list  や  map  の中身を表示 ・.gdbinit  での設定  “set  print  elements  0”  など ・不正なメモリアクセスやメモリリークを調査 ・しかし、とても重い! ・独自実装のロガーでログファイルへ出力 gdbを使い易く Valgrind printf  デバッグ 【開発編】  5.サーバのデバッグ
  39. 39. 39 大人数同時接続テスト n  サーバ1台に3千人では一晩テストしても発生しない問題が、 10台に3万人では10分で発生する n  接続数を2倍にすると、負荷が2倍どころか それ以上に増える事がある (接続数が少ないうちは、接続数に比例しているように見える) n  非常にシビアなタイミングでのみ発生する現象の 発生確率を高める n  高負荷時でも、レスポンス良く快適に遊べるか そもそも何故やるのか 【開発編】  6.大人数同時接続テストの実際 重要!
  40. 40. 40 ・ローカル環境で各サーバプロセスを1~3つ起動 ・200接続 ・テストサーバ ・4千接続 ・topコマンドで負荷を監視 ・本番サーバ ・複数個所からの3万接続 ・muninで負荷を監視 小規模 中規模 大規模 【開発編】  6.大人数同時接続テストの実際
  41. 41. 41 ダミークライアント ・通常のゲームクライアントのような画面描画を持たない ・クライアントのインスタンスを多数生成 ・指示した行動を全インスタンスが一斉に実行 ・エージングテスト用の自動行動 Windows  PC ダミー クライアント ダミー クライアント サーバ 1PCで1000接続 PC PC PC ダミー クライアント ダミー クライアント PC PC PCPCPC 【開発編】  6.大人数同時接続テストの実際 異なる場所からも 同時に接続
  42. 42. 42 テスト手順 ・事前に7万人分のデータをDBへ投入 ・タイムテーブルに沿って操作 ログイン ロビー間移動 ロビー内での移動、チャット 探索の実行(Luaスクリプトの検証) マッチング バトル バトルを終えてロビーへ帰還 ログアウト  ~  別のアカウントでログイン 【開発編】  6.大人数同時接続テストの実際
  43. 43. 43 何を直したか ・バトルサーバのメモリを増設 ・ログ保存用にDBを分離 ・チャット量に上限を設ける ・マッチングが集中したら、バトルの成立時間を分散させる ・ロビー入室やバトル参加の条件変更    (様々な要因により、1分くらい待たされてしまう事があった) 負荷テストの結果、サーバが落ちるといったバグの修正のみでなく、 サーバの増強やゲーム処理の調整も行った。 等々。 【開発編】  6.大人数同時接続テストの実際 開発編は以上です!
  44. 44. 【運用編】   1. 運用監視 2. 負荷最適化 3. 運営中DB設計変更の実際 13-8-26 44 【運用編】 もくじ
  45. 45. 1.運用監視
 
 
 13-8-26 45
  46. 46. 【運用編】1,運用監視
 ■監視体制   •  24h365dで監視サーバからのアラートに対応   •  手動停止や再起動などの一次対応はリモート操作   •  データの更新、メンテナンスなどはチームが出社して   ■再起動“しない”という対応   柔軟なサーバ構成のため再起動は簡単だが、万が一のこと を考えて次のメンテナンスまでそのままのこともある。    →1台居ない程度では(負荷以外は)問題ないので    →運用体制の簡素化に貢献   13-8-26 46
  47. 47. 【運用編】1,運用監視
 ■監視方法   •  統合監視ツールZabbix   インストールも簡単のオールインワンパッケージ   –  多数の監視項目が最初から用意されている   –  柔軟に追加項目を設定できる   –  簡単にグラフ化   –  閾値によるアラート   –  マシンのヘルスチェック   –  負荷状況監視   –  リソース使用状況監視   13-8-26 47
  48. 48. 【運用編】1,運用監視
 •  ゲームサーバプロセス監視   Linuxの標準的な Service  スクリプトを利用   –  Pidファイルチェック   pidファイルにプロセスIDを記述。プロセスが実行されているか確認   –  プロセス名チェック   サーバ実行ファイル名のプロセスが実行されているか確認   –  ポート監視   フロントエンドサーバの外向けポートが開いていて、且つ応答があ るかどうかを確認     これらを1分に1回チェック   13-8-26 48
  49. 49. 【運用編】1,運用監視
 ■目視の重要性   各監視項目のグラフを定期的に目視でチェック     <何故?>   数値情報による機械的なアラートでは障害と判断できないことがあるため    例)一時的にあるマシンのトラフィックが極端に下がった    例)CPU使用率が閾値内ギリギリに上昇してしばらく下がらない   クラウドでは希によくあります。      ↓   毎日チェックしていれば変化を見つけることが出来る   人間の眼で見て「予兆」を捉えることは大切   13-8-26 49
  50. 50. 2.負荷最適化 13-8-26 50
  51. 51. 【運用編】2,負荷最適化
 ■サービスイン後の負荷   サービス開始してから判明する負荷もある    クリコンでは:DB書込みが予想以上に多く参照が少ない     原因   –  特定条件によるユーザデータの保存回数が予想より多かった   –  インベントリテーブル構造の問題で、無駄な書込みが発生していた      ↓   無駄な更新の多発によりスレーブが追いつかず、レプリケ ーション遅延が発生。   13-8-26 51
  52. 52. 【運用編】2,負荷最適化
 ■実例:インベントリテーブルの大幅な変更                   13-8-26 52 所持アイテムとインベント リ情報が一体だったのを… アイテム、インベントリステータス、インベン トリ利用状況の3つに分割 1億レコード、10GBのテーブルを分割するのに6時間 データ容量も2倍以上に増加
  53. 53. 【運用編】2,負荷最適化
 ■その他やっていること   –  各テーブルのレコード数増加傾向をウォッチ   –  テーブルパーティショニング、圧縮の適用(漏れているテーブルに)   –  パーティション単位で古いデータを削除     13-8-26 53
  54. 54. 【運用編】2,負荷最適化
 ■最適化タイミングを計る   「いつの時点でどのようにヤバイのか」を計るには   事前に指標を用意しておくことが大切   例:DBの場合   –  ディスク使用量   –  秒間更新/参照クエリ回数   –  各テーブルの一定期間のレコード増加数     CPU使用率などはいつでもヤバさが分かる。   多いのか少ないのか、長いのか短いのか。   相対的に論ずるべきものの指標を用意しよう   13-8-26 54
  55. 55. 【運用編】2,負荷最適化
 ■「いつ頃どれくらい」は出せるか?   問)サービス開始後1ヶ月でのDBデータ容量を出して欲しい   答)アクティブユーザ数と同時接続数と基本的なユーザの     プレイサイクルが分からないと。。。   ではダメ。     変動するパラメータはきちんと想定し、その上で    「このアクセス想定だったら」「いつ頃までに」    「少なくともこれくらいで」「どんなに多くてもこれくらいに」    「収まるはずだ」   と語れるようにしよう   13-8-26 55
  56. 56. 【運用編】2,負荷最適化
 ■指標を持つ意味   •  事前設計段階では  :目標となる   •  運営開始後は    :対応の判断材料になる     質の高い予測なんてできそうにないです。。。    →できるわけないです。     やっているうちに慣れて、段々と精度が上がります。     数をこなしましよう。   13-8-26 56
  57. 57. 3.運営中DB設計変更の実際 13-8-26 57
  58. 58. 【運用編】3,運営中DB設計変更
 ■メンテ無しでできるDB改修   データベースが止まらないので、サービスに影響を与えない     あんまり無いです。   –  不要なインデックスの削除   –  Enumカラムに要素を追加   –  新規テーブルの追加   –  新規Rangeパーティションの追加(ただし条件付き)   13-8-26 58
  59. 59. 【運用編】3,運営中DB設計変更
 ■メンテが必要なDB改修   データベースが停止するため、サービスが影響を受ける。   処理に長時間かかったり、DBの再起動が必要だったり。     やりたいとよく思うことは大抵当てはまります。   –  カラムを追加、変更   –  インデックスを追加   –  Enumカラムの要素順序変更   –  パーティション分割、条件を満たさない新規追加   –  テーブル圧縮   –  その他ほとんどのテーブル、カラム変更操作   13-8-26 59
  60. 60. 【運用編】3,運営中DB設計変更
 ■DB改修でメンテをしないためには   •  仕様に沿った設計にしすぎない   –  企画や仕様で見られるデータ構造をそのまま適用しない   –  ゲームサーバ上で使うデータ構造もそのまま適用しない   •  データの抽象化とテーブルの正規化   –  カラムを追加せずにデータを拡張できるように   –  正規化しすぎるのもよくない(性能を犠牲にする)   •  極力テーブル追加をしない   –  テーブル単位の対処が漏れやすい   –  クエリ負荷やテーブルのデータ量を見積もりづらい   –  追加しないとか、実際には難しいです     13-8-26 60
  61. 61. 【運用編】3,運営中DB設計変更
 ■DB改修でメンテをしないためには(続き)   •  先を見越してインデックスを付ける   –  一見不要でも、データの定義に応じて必要そうなら付けておく   –  でも増やしすぎると性能低下を招く。見極め大事   •  更新対象を最小限で抑えるようにする   –  ゲームサーバ上で更新された箇所だけを書き換える   –  DBへの保存はセーブデータではないと心得る     13-8-26 61
  62. 62. おわり •  ご静聴ありがとうございました! 13-8-26 62 ・ゲームサーバの設計、構築、運用のご相談を承ります。 ・3階中央にブースを出展していますので、ご質問などありましたらお越し下さい。

×