この2日間はサーバ側データの保存形式を決めていました。

以下、私の開発用メモになってしまっている部分が多々あります。

意味不明でしたらごめんなさい。

　　　　 -ーー ,,_
　 　r'”　　 　　　`ヽ,__
　　 ＼ 　　 　　 ∩／￣￣ ヽつ
　 ノ￣＼ /”ヽ/ ” 　　ノ　　 ヽi
　|　 ＼＿)＼ .＼ 　　 ＞ 　＜ |＼ｽﾏｿ
　＼ ~ ) 　 　 ＼ .＼_　　( _●_)＼_つ
　　 ￣ 　　 　　 ＼＿つ

サーバ側で保存すべき主なデータは3つです。

１.土地データ
２.設置アイテムデータ
３.プレーヤーデータ

それぞれの詳細は以下の通りです。

１.土地データ

1つのブロックを1バイト(0〜255)で持つこととします。

1区画を、7×7×7と定め、この単位で各プレーヤーが”支配”可能です。1区画のデータ量は7×7×7=343バイトに加え、支配者識別IDの32バイトを加えて合計375バイトになります。

区画数は、縦方向(y軸)に10、横方向(x軸とz軸それぞれ)に4294967296(4バイト)あり、論理上の合計区画数は1.844674407370955e20個となります。

DBは読み書きが遅いので、データはバイナリファイルに保存します。区画の位置を元に、ファイル名はN-N-N.landとします。

世界の中心の区画を0-0-0区画として、0-0-0〜9-9-9区画(1000個の区画)のデータを”0-0″ディレクトリに格納します。0-10-0〜9-19-9区画のデータを”0-10″ディレクトリに格納します。10-0-0〜19-9-9区画のデータを”10-0″ディレクトリに格納します。10-10-0〜19-19-9区画のデータを”10-10″ディレクトリに格納します。マイナス10-マイナス10-0〜マイナス1-マイナス1-9区画のデータを”m10-m10″ディレクトリに格納します。

このような形で読み書きしたい区画データファイルをディレクトリで分類し、素早くアクセス可能にします。

尚、区画データ内の支配者IDは横方向(x軸とz軸)で一意に決まります。つまり縦方向(y軸)で支配者IDが変わることはありません。天井/地下方向とも戦うのは辛いですからね。東西南北4方向と戦います。

２.設置アイテムデータ

・アイテムID [2バイト]
・設置位置 [3バイト]
・設置状態[1バイト]

上記6バイト×設置数

区画の位置を元に、ファイル名はN-N-N.itemとします。保存ディレクトリは対象区画データと同じです。

３.プレーヤーデータ

・プレーヤー名 [64バイト]
・HP [2バイト]
・プレーヤー位置[1バイト+1バイト+1バイト=3バイト]
・所持アイテム [アイテムID2バイトを各最大数量255で最大64個所持=181バイト]

合計 [250バイト]

保存ファイル名は”ログインID.ply”です。保存ディレクトリはプレーヤーが存在する区画に基づきます。プレーヤー名が重複した場合は、○○区画の○○などと表示して区別します。

クライアント側にはログインID(GUID的なIDを自動生成)と区画位置、編集した区画データを保持します。

一意なIDでの重複チェックなどが必要ないデータ構造のため、区画毎に別サーバに分割可能で、サーバ数に応じてリニアに計算/通信性能向上可能です。

将来的に不足などが生じたら都度修正します。