新作アプリ「隣の田所さん」制作第15週目の作業予定です。
99日目:クライアントでのログインID生成
100日目:クライアントでのログインID保存
101日目:クライアントでの地形データ保存その1
102日目:クライアントでの地形データ保存その2
103日目:サーバへの地形データ送信その1
104日目:サーバへの地形データ送信その2
105日目:予備日(次の週の予定を立てる)
冬のボーナスが42円でした。
アプリ1個売れれば稼げる額でした。
みなさんアプリ買ってください。
新作アプリ「隣の田所さん」制作第15週目の作業予定です。
99日目:クライアントでのログインID生成
100日目:クライアントでのログインID保存
101日目:クライアントでの地形データ保存その1
102日目:クライアントでの地形データ保存その2
103日目:サーバへの地形データ送信その1
104日目:サーバへの地形データ送信その2
105日目:予備日(次の週の予定を立てる)
冬のボーナスが42円でした。
アプリ1個売れれば稼げる額でした。
みなさんアプリ買ってください。
今回はクライアントとサーバ間の通信内容を考えました。前回に引き続き、意味不明でしたらごめんなさい。
-ーー ,,_
r'” `ヽ,__
\ ∩/ ̄ ̄ ヽつ
ノ ̄\ /”ヽ/ ” ノ ヽi
| \_)\ .\ > < |\クマー
\ ~ ) \ .\_ ( _●_)\_つ
 ̄ \_つ
やり取りするデータは以下の3つです。
1.土地データ
2.設置アイテムデータ
3.プレーヤーデータ
1.土地データ
入力
・区画位置
出力
・入力及び隣合う区画データ [10,125バイト]
(9+9+9=27区画、1区画375バイトなので 27*375=10,125)
2.設置アイテムデータ
入力
・区画位置
出力
・入力及び隣合う区画のアイテムデータ [6*アイテム*27バイト]
(各区画に10アイテムあるとして、6*10*27=1,620バイト)
3.プレーヤーデータ
入力
・区画位置
・ログイン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.土地データ
2.設置アイテムデータ
3.プレーヤーデータ
それぞれの詳細は以下の通りです。
1.土地データ
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方向と戦います。
2.設置アイテムデータ
・アイテムID [2バイト]
・設置位置 [3バイト]
・設置状態[1バイト]
上記6バイト×設置数
区画の位置を元に、ファイル名はN-N-N.itemとします。保存ディレクトリは対象区画データと同じです。
3.プレーヤーデータ
・プレーヤー名 [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円くらいしか出そうにないです。え?知ったこっちゃない?ボーナスが出ないならいっそ会社辞めて短時間バイトしてアプリ作りに重点を置いて暮らしたいのですがダメですかね?いや、というかボーナスが出ようが出まいが会社辞めて短時間バイトしてアプリ作りに重点を置いて暮らしたいのですがダメですかね?
え?知ったこっちゃない?
そうですよねぇ・・・
*’“・* 。
| `*。
,。∩ *
+ (´・ω・`) *。+゚
`*。 ヽ、 つ *゚*
`・+。*・’ ゚⊃ +゚
☆ ∪~ 。*゚
`・+。*・ ゚
先日の素晴らしいデザイン画に基づいて、侵入者自動撃退ロボをポリゴン化しました。まあ、デザイン画はほとんど無視したんですけど。というか、戦車になりました。
∧ ,, ∧
(;`・ω・) 。・゚・⌒) チャーハン作るよ!!!
/ o━ヽニニフ))
しー-J
先ずは側面です。

・・・続いて正面です。

最後に上からです。

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



自分にしてはよく出来たと思います。自分にしては。
‹‹(´ω` )/››
今日は
侵入者自動撃退ロボデザイン
を行ないました。

・・・
・・
・
これが私の画力の限界ですが何か?
ポリゴン化出来るかな・・・
新作アプリ「隣の田所さん」制作第13週目の作業予定です。
あと一息で完成する・・・ような気がします。たぶん。
85日目:侵入者自動撃退ロボデザインその1
86日目:侵入者自動撃退ロボデザインその2
87日目:侵入者自動撃退ロボテクスチャ作成その1
88日目:侵入者自動撃退ロボテクスチャ作成その2
89日目:侵入者自動撃退ロボ動作その1
90日目:侵入者自動撃退ロボ動作その2
91日目:予備日(次の週の予定を立てる)
「隣の田所さん」はお隣さんと仲良くなったり戦ったりするゲームです。24時間365日、いつお隣さんにいつ侵入されても大丈夫なように、自宅を警備する侵入者撃退ロボが必要です。
今週はその撃退ロボを制作する予定です。
今週の作業により、プレーヤーが壁の裏等に移動してもカメラ距離が調整され常に視野を確保出来るようになりました。
またブロック削除時に、ブロックがプルプル震えるアニメーションを追加しました。
難しい作業と想定していましたが、意外と短時間で順調に作業を終えることが出来ました。
順調に作業が進んでいます。
100年以内にはアプリストア でリリースできると思います。
9割方負けるので、常に滅んでいる隊ということで不滅隊改め
常滅隊
に名前変えた方が良いんじゃないですかね?
え?何の話かって?
ff14のPvP、フロントラインの話です。
(´・ω・`)ショボーン
不滅隊に参加している人ってマゾなんですかね?指揮している人がいないと負けが濃厚なんで即抜けしますね。みんなごめんね・・・
指揮している人がいてもよく負けるけど。