uka.appleコメントするminnano.appに新しいアプリが増えました!多分5年以上ぶりに増えました!WebGLを利用した、ブラウザ上で超高速に動くConwayのLifegameだよ!え?Lifegameを知らない?そんな不届き者はこのリンクを見やがってください。LIGHTNING」を選んで見てね。ブラウザから、いつでもどこでもスマホからでもPCからでもタブレットからでも動きます!FireFoxやChromeやSafariで動きます。IE、てめーは駄目だ。゚∀゚)右下の矢印アイコンからUIを表示して、「SIZE」を最小の1に、「SPEED」を最大の240にして「TOUCH」を”LASER”にするのがオススメです。さあ、その状態で黒い画面をなぞってみましょう!!超細かいライフが超高速に動きます!!よければiOSアプリ版も買ってね。uka.appleコメントする今日の作業は「クライアントでのログインID生成」です。今制作しているアプリは先ずiOSでリリースする予定です。iOSでは「IDFV」を取得します。ブラウザからの場合は「UUID」を生成します。共に、ハイフンを除いて32バイトとなります。取得/生成方法についてはググれば腐る程出てくるので詳細は省きます。JSでこの関数相当のものを実装して今日の作業は完了してしまいました。この記事書く方がよっぽど時間がかかりました。uka.appleコメントする新作アプリ「隣の田所さん」制作第15週目の作業予定です。99日目:クライアントでのログインID生成100日目:クライアントでのログインID保存101日目:クライアントでの地形データ保存その1102日目:クライアントでの地形データ保存その2103日目:サーバへの地形データ送信その1104日目:サーバへの地形データ送信その2105日目:予備日(次の週の予定を立てる)冬のボーナスが42円でした。アプリ1個売れれば稼げる額でした。みなさんアプリ買ってください。uka.appleコメントする今回はクライアントとサーバ間の通信内容を考えました。前回に引き続き、意味不明でしたらごめんなさい。\_つやり取りするデータは以下の3つです。[250バイト]以上から、先ずログインすると10,125+1620+250=約12kバイトのデータ通信を行う必要があります。≒1.4Mバイトうん、実現可能な範囲ですね。アクティブプレーヤー数が1000万人という数値以外は。uka.appleコメントするこの2日間はサーバ側データの保存形式を決めていました。以下、私の開発用メモになってしまっている部分が多々あります。意味不明でしたらごめんなさい。\_つサーバ側で保存すべき主なデータは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方向と戦います。区画の位置を元に、ファイル名はN-N-N.itemとします。保存ディレクトリは対象区画データと同じです。[250バイト]保存ファイル名は”ログインID.ply”です。保存ディレクトリはプレーヤーが存在する区画に基づきます。プレーヤー名が重複した場合は、○○区画の○○などと表示して区別します。クライアント側にはログインID(GUID的なIDを自動生成)と区画位置、編集した区画データを保持します。一意なIDでの重複チェックなどが必要ないデータ構造のため、区画毎に別サーバに分割可能で、サーバ数に応じてリニアに計算/通信性能向上可能です。将来的に不足などが生じたら都度修正します。uka.appleコメントするこの2日間でデータ保存用のWebサーバを構築しました。OSはCentOS、Webサーバはプログラミング言語をRUSTで構築しました。RUSTはC/C++並に速いのに、近代的なプログラミングが出来る憎い奴です。このページやこのページを参考に作成しました。URLを叩いてマルチスレッドでhttps通信が出来るところまで行きました。フレームワークと呼ばれるものは使っていません。大部分はRUSTの標準ライブラリを使って作成しています。なんでフレームワーク使ってないのかって?だって、趣味でやってるんだから自分が面白ければ良いんです。1から作るって楽しいです。