現行のXOPSオンラインの改造パック(改造マップ集)は、改造マップを採用する際に、XOPSオンラインのdataフォルダの中身を入れ替えて実現している。(「map1」〜「map16」フォルダ)この実現方法だと以下のような問題がある。・最大でもマップが13個までしか入らない・マップ収録数が12個以下(極端な場合・2〜3個)の場合、色々と苦労する。・データを変更するには、クライアント(プレイヤー)に『バージョンアップ』という名目で、再DLを要求する。ネットワーク上にマップデータを置いておいて、1試合(1ゲーム)毎にマップデータをダウンロードするシステムを構築してはどうか?このシステムだと、以下のような利点が生まれる。・マップデータの変更・更新で、クライアントに再DLしてもらう必要がない。由来であり、厳密な意味ではクラウドコンピューティングとは異なる。今回は仕組みを簡単にするため、マップデータはXOPSサーバーと同一PC内に保存する。=サーバー内のマップデータを使うサーバーとクライアント(各プレイヤー)それぞれのXOPSのEXEファイル(実行ファイル)自体には殆ど手を加えずに、独自の外部ソフトウェア(EXE)を同時に実行させる方式を採用した。結論から言うと、ゲーム中にdataフォルダのマップデータを強引に書き換えてしまうというのが基本的な仕組み。下の図はその大まかな流れ。上がサーバー、下がクライアント(一般プレイヤー)。サーバー側はやや処理が複雑なので、処理手順で番号�@〜�Cを振った。実際は下のクライアントが(1.9なら)最大14人まで接続してくる。図で言う「データベース」に、オリジナルのマップデータを保存しておく。前の説明どおり、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氏の「プロセスメモリを操作するモジュール」を駆使している。