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フォルダのマップデータを強引に書き換えてしまうというのが基本的な仕組み。
下の図はその大まかな流れ。 上がサーバー、下がクライアント（一般プレイヤー）。
サーバー側はやや処理が複雑なので、処理手順で番号①～④を振った。
なお、分かりやすいようにサーバーに1人しか接続してないような図になっているが、実際は下のクライアントが（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氏の「プロセスメモリを操作するモジュール」を駆使している。
"どこの値をどう見るか"とかは独自に考案した。とりあえず現時点では非公開。
～あぁ怖い (ﾟДﾟ;)
サーバー用プログラムが既に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） ⇒公開終了