ホーム > 技術資料 > (このページ)


XOPSオンラインクラウド(仮称)のシステム考案

 〜マップデータをネットワーク上に置く〜



■ 企画の原点

現行のXOPSオンラインの改造パック(改造マップ集)は、改造マップを採用する際に、
XOPSオンラインのdataフォルダの中身を入れ替えて実現している。
(「map1」〜「map16」フォルダ)

この実現方法だと以下のような問題がある。
 ・最大でもマップが13個までしか入らない
 ・マップ収録数が12個以下(極端な場合・2〜3個)の場合、色々と苦労する。
 ・データを変更するには、クライアント(プレイヤー)に『バージョンアップ』という
  名目で、再DLを要求する。


では、
ネットワーク上にマップデータを置いておいて、1試合(1ゲーム)毎にマップデータを
ダウンロードするシステム
を構築してはどうか?

このシステムだと、以下のような利点が生まれる。
 ・マップ総数が50個でも100個でも扱える
 ・2〜3個という少数マップ集の構築も容易
 ・マップデータの変更・更新で、クライアントに再DLしてもらう必要がない。
 ・サーバー側で毎回ランダムに成形したマップ とかも可能(プレイするたびに変わる迷路?


プロジェクト名の仮名称である「XOPSオンラインクラウド」の‘クラウド’とは、英語で「雲」を意味し、
最近噂の 「クラウドコンピューティング」 に由来している。
ただ、あくまで由来であり、厳密な意味ではクラウドコンピューティングとは異なる。


■ システムの概要

今回は仕組みを簡単にするため、マップデータはXOPSサーバーと同一PC内に保存する。
 =サーバー内のマップデータを使う

サーバーとクライアント(各プレイヤー)それぞれのXOPSのEXEファイル(実行ファイル)自体には
殆ど手を加えずに、独自の外部ソフトウェア(EXE)を同時に実行させる方式を採用した。

結論から言うと、ゲーム中にdataフォルダのマップデータを強引に書き換えてしまうという
のが基本的な仕組み。


下の図はその大まかな流れ。 上がサーバー、下がクライアント(一般プレイヤー)。
サーバー側はやや処理が複雑なので、処理手順で番号@〜Cを振った。

なお、分かりやすいようにサーバーに1人しか接続してないような図になっているが、
実際は下のクライアントが(1.9なら)最大14人まで接続してくる。


図1

図で言う「データベース」に、オリジナルのマップデータを保存しておく。
前の説明どおり、50個でも100個でも、サーバーのHDDが許す限り登録・保存できる。
また、クライアントには接続時あるいは試合中に毎度データを送信するので、マップデータの
書き換え・変更や追加も容易である。
(前文の説明通り、自らクライアントがDLし直す必要はない。)

下のクライアントは、サーバーから送られてくるファイル群を自動ダウンロードし、
サーバーの指示に従ってdataフォルダを書き換えるだけの非常に単純な物である。

一方、上のサーバー側のプログラムは大変。
サーバーモードで動いているXOPSを監視し、試合状況を見守る。試合のタイミングを見計らい、
マップを選択し、自分(XOPSサーバー)のdataフォルダに新マップをコピーした
後、全クライアントに(次の試合で使う)新しいマップデータを片っ端から送信していく。
無論、途中の入退出の管理や、突然姿を消す(通称・タイムアウト)クライアントも管理する。

単純に考えても、クライント側はXOPSオンラインに加えて、試合中という通信量が多い時に
裏でマップをダウンロードするので回線への負担が増す。
サーバー側は、回線負荷がさらに過激になる。XOPSオンラインの試合中の通信に加えて、
マップデータも接続人数分送信する必要が出てくる。


■ 細部仕様

【技術面をちょっと紹介。この項目は読まなくても良い。】

上記の説明通り、独自の外部ソフトウェア(制御プログラム)は「サーバー用」と「クライアント用」
の2種類分けて開発・作成する。

開発言語は、生産性と開発速度を重視しどちらも「HSP3.2」を採用した。
TCP/IPソケット通信にはHSP付属の「HSPSOCK」を使用する。
ただ、HSPSOCK自体が1対1の接続を前提に作られている簡易的な物なので、複数人と同時に通信する
必要があるサーバー側はプログラムが複雑化した。

通信プロトコル(アプリケーション層レベル?)は、基本的に独自設計。
手間と処理重視で最低限しか考えなかった。安定性と拡張性は犠牲になっている。
通信ポートもXOPSみたいに綺麗に1ポートには収まらず、広域(多ポート)を使用する。

サーバー側でXOPSの試合状況を監視する手段は、ka-navi氏の「プロセスメモリを操作するモジュール」
を駆使している。
どこをどう見るか とかは独自に考案した。とりあえず現時点では非公開。
 〜あぁ怖い (゚Д゚;)

サーバー用プログラムが既にHSPでの処理速度の限界に近づいているため、本格的な運用を行うには
(サーバー用は)Visual C++などで書き直す必要が出てくるかも。
でも技術評価および発想の実体化としては(HSPでも)十分だと思う。
後、おそらく通信プロトコル自体も見直しが必要。


■ システムの実用性と運用

概要での説明どおり、サーバー側の通信回線で いかに太い(速い)回線を用意できるかが、
実用化への分かれ道となる。


2011年4月8日に計34マップ収録した試作品を製作・開発し、5月19日から22日の4日間に掛けて
OTZさんのOTZ's鯖の協力の元、オープンで不特定多数にテストを依頼した。(公開サーバー化)
(OTZさんと、テストに協力してくださった方々に心から感謝する。)

下記は、その試験運用によって得られた今後の課題である。

■ 最重要事項  【可能な限り迅速に確実に行う必要がある】
・バージョンを変更する。
  >通常版1.9でのjoinを防ぐため
・ファイルを配信完了するまではサーバのautoフラグを切る。
  >ファイルが送信し終わるまで試合が開始されないという、非常に有力な対策。
・(サーバーから見て)各クライアントに対するマップの送信を、順次型から並列型(同時型)に。
  >これで低速回線のクライアントが居ても、全員を巻き込まない。 HTTP採用が濃厚。
・名前に「,」が入ると起動できない対策。
・通信の不具合による、マップやポイントデータに不具合が発生する対策。

■ 検討事項  【今後前向きに検討する】
・xopsolt19-クラウド.exeは直接実行できないような対策
  >拡張子変更案が有力
・システム終了時にマップが削除されない問題(見事なバグ)の修正
・マップの選択確率が明らかに片寄っている点
  >そんなはずは・・、でも明らかに同じマップばっか出てくるよなぁ。
・クライアント側、サーバー側問わずの不正アタック対策全般。
  >実験の枠を超えて、まともに活用するなら必須。

■ 保留事項  【今後の状況に応じて必要性が出てくるかもしれない】
・クライアント側(client.exe)の表示をGUI化してビジュアルに。
・1マップごとにZipなどで固めてしまう。
・起動前に、マップ以外にxファイル画像ファイル音声ファイルを強引に書き換える。
・全MAPを一括DLする方式の採用
・ハッシュ値の採用


「サーバー運用者向け」および「オンライン改造パック開発者向け」の、細部の技術資料の公開は未定。


■ ダウンロード

・サーバー版 (公開時期未定)
クライアント版(ver:20110520) (2011/05/20)


■ サポート先

XOPS OFFICE
 フォーラム・XOPSオンラインクラウド(仮) について

メールでも構いませんが、他の方(第三者)との情報交換の観点からも上記のフォーラムでの
お問い合わせをお勧めしています。




⇒ このページを「印刷」する

Copyright (C) 2006-2017 みかん箱. All rights reserved.                ◆ TOPへ 戻る