新作アプリ「隣の田所さん」制作第16週目の作業予定です。

106日目：球形範囲での地形データロード/アンロードその1
107日目：球形範囲での地形データロード/アンロードその2
108日目：サーバへの地形データ送信その1
109日目：サーバへの地形データ送信その1
110日目：サーバでの地形データ受信その1
111日目：サーバでの地形データ受信その2
112日目：予備日(次の週の予定を立てる)

先週はクライアント側での地形データロード/アンロード時に60fpsが保てないという問題が発生したため、先ずそれを解決します。

その後、サーバへの地形データ送信作業に進みます。

とうとう100日をこえました。はやくアプリストア にリリースしたい・・・

今週は、クライアント側でのログインID生成/保持と、地形データの動的呼び出し処理を行いました。

保存した地形データをプレーヤーの位置に応じて動的にロード/アンロードする実装に時間がかかり、サーバ側まで手が回りませんでした。

7ブロック四方を”1区画”として、プレーヤーを中心とした5区画×5区画の合計25区画が常に表示されるようにしてみました。

が、これだとロード/アンロードのタイミングで少しfpsが下がってしまうようです。(常時60fpsにしたいのですが一瞬57fpsくらいに下がる)

来週はfpsが下がらないよう、ロード/アンロードの処理を調整したいと思います。

 
　　  　　…|￣ ￣ |＜新しいアプリはまだかね？ 
　　  　／:::|　___|　　　　 ∧  ∧　       ∧  ∧ 
　　    /::::＿|＿＿_|＿　　（ ｡_｡ ）   （  ｡_｡）  
　　||::::::（・∀・　） 　／<▽>　   ／<▽> 
　　|  |::／  <ヽ∞/> ＼　 |::::::;;;;::/   |::::::;;;;::/ 
　　||::|　　 <ヽ/>.-　|　|:と),__｣    |:と),__｣ 
＿..||::|　　 o　　o　…|_ ξ|:::::::::|  　.|::::::::| 
＼　　＼＿_(久)__／＿  ＼::::::|　     |:::::::| 
.||.i＼　　　　　  　､__ﾉﾌ  ＼|　        |:::::::| 
.||ヽ .i＼　_ __ ＿＿＿＿ __ _.＼　　 |::::::| 
.||　ﾞヽ i　　　 ﾊ i　ﾊ i　ﾊ i　ﾊ　|　し’_つ 
.||　　 ﾞ|i～^~^～^~^～^~^～|i~ 
 

今日の作業は「クライアントでのログインID生成」です。

今制作しているアプリは先ずiOSでリリースする予定です。iOSでは「IDFV」を取得します。ブラウザからの場合は「UUID」を生成します。

共に、ハイフンを除いて32バイトとなります。取得/生成方法についてはググれば腐る程出てくるので詳細は省きます。

JSでこの関数相当のものを実装して今日の作業は完了してしまいました。3秒で終わりました。

この記事書く方がよっぽど時間がかかりました。

新作アプリ「隣の田所さん」制作第15週目の作業予定です。

99日目：クライアントでのログインID生成
100日目：クライアントでのログインID保存
101日目：クライアントでの地形データ保存その1
102日目：クライアントでの地形データ保存その2
103日目：サーバへの地形データ送信その1
104日目：サーバへの地形データ送信その2
105日目：予備日(次の週の予定を立てる)

冬のボーナスが42円でした。

アプリ1個売れれば稼げる額でした。

みなさんアプリ買ってください。

今回はクライアントとサーバ間の通信内容を考えました。前回に引き続き、意味不明でしたらごめんなさい。

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

やり取りするデータは以下の３つです。

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

１.土地データ

入力
・区画位置

出力
・入力及び隣合う区画データ [10,125バイト]
(9+9+9=27区画、1区画375バイトなので 27*375=10,125)

２.設置アイテムデータ

入力
・区画位置

出力
・入力及び隣合う区画のアイテムデータ [6*アイテム*27バイト]
(各区画に10アイテムあるとして、6*10*27=1,620バイト)

３.プレーヤーデータ

入力
・区画位置
・ログインID

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

以上から、先ずログインすると10,125+1620+250=約12kバイトのデータ通信を行う必要があります。

1000万人のアクティブプレーヤー数で秒間データ平均通信量は、
10,000,000 * 12,000 / (24 * 60 * 60) = 1,388,888 ≒1.4Mバイト

うん、実現可能な範囲ですね。

アクティブプレーヤー数が1000万人という数値以外は。

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

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

この2日間でデータ保存用のWebサーバを構築しました。OSはCentOS、Webサーバはプログラミング言語を

RUST

で構築しました。RUSTはC/C++並に速いのに、近代的なプログラミングが出来る憎い奴です。

このページやこのページを参考に作成しました。

とりあえずURLを叩いてマルチスレッドでhttps通信が出来るところまで行きました。

フレームワークと呼ばれるものは使っていません。大部分はRUSTの標準ライブラリを使って作成しています。

なんでフレームワーク使ってないのかって？

だって、趣味でやってるんだから

自分が面白ければ良いんです。

1から作るって楽しいです。

(⋈◍＞◡＜◍)。✧♡

新作アプリ「隣の田所さん」制作第14週目の作業予定です。

92日目：Webサーバ構築 HTTP通信その1
93日目：Webサーバ構築 HTTP通信その2
94日目：Webサーバ データ保存形式検討その1
95日目：Webサーバ データ保存形式検討その2
96日目：Webサーバ/クライアント間IF検討その1
97日目：Webサーバ/クライアント間IF検討その2
98日目：予備日(次の週の予定を立てる)

ブロックや武器の種類不足は否めませんが、早めに地形データの保存を行うためサーバ側の実装を進めたいと思います。

新作アプリ「隣の田所さん」では、プレーヤー全員が共通の同じフィールドに降り立って多対多のご近所バトルをします。地形データはサーバで一元管理する必要があります。

一生懸命ブロックで何か作っても、テストデータとはいえ消えちゃうのはもったないですからね。

そのため今週はサーバ側の構築を進めていきます。

話は変わりますが、今期は私のお世話になっている会社の業績が下がり、冬のボーナスが5円くらいしか出そうにないです。え？知ったこっちゃない？ボーナスが出ないならいっそ会社辞めて短時間バイトしてアプリ作りに重点を置いて暮らしたいのですがダメですかね？いや、というかボーナスが出ようが出まいが会社辞めて短時間バイトしてアプリ作りに重点を置いて暮らしたいのですがダメですかね？

え？知ったこっちゃない？

そうですよねぇ・・・

　　　　　　　　*’“・* 。
　　　　　　　　|　　　　 `*。
　　　　 　　,｡∩　　　　 　* 
　　　　　　+　(´･ω･`)　*｡+ﾟ
　　　　　　`*｡ ヽ、　 つ *ﾟ*
　　　　　　　`・+｡*・’ ﾟ⊃ +ﾟ
　　　　　　　☆　　 ∪~ ｡*ﾟ
　 　　　　　　`・+｡*・ ﾟ 

先日の素晴らしいデザイン画に基づいて、侵入者自動撃退ロボをポリゴン化しました。まあ、デザイン画はほとんど無視したんですけど。というか、戦車になりました。

　
 　    ∧ ,, ∧
 　 (;`・ω・)　｡･ﾟ･⌒） チャーハン作るよ！！！
 　 /　　 ｏ━ヽニニフ))
 　しー-Ｊ

先ずは側面です。

・・・続いて正面です。

最後に上からです。

迷彩塗装を施しているため、草むらの中に入るとどこに戦車がいるのか判りません。

自分にしてはよく出来たと思います。自分にしては。

‹‹(´ω` )/››