メール:g.tekuto@gmail.com
先週末までに、ModelとControllerを作り終えた。
＊
機能の切り分けは割と想定通りにできたと思う。
それで、今日はActivityにMVCの3要素を実装して実際に動く画面を作っていた。
が、その途中でControllerの想定漏れとViewの想定外の挙動が発覚した。
前者はさくっと修正できそうだが、後者は少々苦労しそうだ。
というのも、後者は処理の方法からして変更するので、それに合わせてテストを書き直すところからになるためだ。
まったく、意味分からん動きするのはやめてほしいものだ。
とは言え、あまりよくない処理の仕方をしていた自分も悪いのだが。
ゲーム画面のViewができた。
＊
次はModelかな。
大まかな機能はすでに出来ているが、現状ではControllerが利用することを考慮していない状態だ。
なので、その辺り考慮した構成に変更する必要がある。
Viewのテストはandroidのエミュレータか実機がなければ動かせないが、ModelとControllerのテストには必要ないはず。
テストの実行にあまり時間が取られないと思うので、テンポ良く進めて行きたい。
機能分割むずい。
＊
機能をMVCで分けるとして、ViewかControllerはActivityに書くかと考えていたが、どうも全部独立させた方がよさそうだな。
Activityに書いてしまうと、他の要素に依存してしまってテストがうまく書けなくなる。
ようやくたどり着いた結論としては、ModelとViewは完全に独立させてテストする。
Controllerは同じインターフェースを持ったダミーのModelとViewを参照させてテストする。
そこまではいいのだが、問題はViewのテストだ。
どうもテスト用のActivityやレイアウトファイルを作らないとうまくいかない感じがある。
テスト用の情報をAndroidManifest.xmlに書きたくないんだけど、これ別のファイルに分けられないのかな。
検証が必要だ。
全然書いてなかったな。
＊
サーバー側はさすがに完了してる。
で、今クライアント側のandroidアプリ作ってる。
javaとか、最新のは分からんけど、いや本当に知らないんだけど、使う気にならんのでkotlinとかいう言語で作ってる。
javaをより実用的にしたような感じでいい感じ。
大体の見た目は作ったのだけど、そこにUIパーツを組み合わせるのが少し難航していた。
今日ようやくやり方が見えた。
明日には手法を確立させて、見た目に機能を持たせて行きたい。
ようやくサーバー側を完了できそう。
＊
最後の1つの機能追加が、ちょっと手を加える程度だと思っていたが予想外につまずいている。
firestoreからデータを取る時に、複数のフィールドに不等号の条件付けるのが不可能とは知らなかった。
幸い、対象のフィールドは同じ型の似たようなデータなので、統合したフィールドをもう1つ用意することで対応できそう。
しかし、ちょっとした機能追加だと思っていたのにフィールドを追加するはめになるとは。
追加するフィールドについて、色々テストが必要になるな。
今週の頭には完了できるかと思っていたが、今週いっぱい使うことになりそうだ。
＊
これで、サーバー側のアルファ版が出来上がる。
次にクライアント側のアルファ版を作り、身内でテスト。
その次に様々な統計データを取れるようにしたベータ版を作り、無料で公開してテスト。
最後にいくつか機能を追加した正式版を作り、有料で公開。
こんな感じか？
年内に正式版まで行きたいが、クライアント側の開発環境構築からして難航しそうな予感がしている。
まだサーバー側も終わってない。
＊
ようやく当初予定していた基本機能の正常系は完了した感じか。
あとは機能1つの異常系処理を追加すれば終わり。
当初予定していたのはそれで終わりだけど、そこにもうちょい機能追加をする予定。
＊
モチベーションの低下がやばかった。
DBの扱いでまごついたのが大きかったように思う。
厳密にはDBではないのだが、トランザクションとかあるし似たようなもんだ。
DBの扱いは経験が少なかったため、どう記述をまとめたらいいのか戸惑ってしまったのだ。
サーバー側のマッチング処理はほぼできた。
＊
現状ではイレギュラー時のゴミが溜まってしまう状態なので、その除去が必要だがそのくらいだ。
GoはC++と同じようにはいかない部分も多く、戸惑ってしまうことも少なくない。
ここまで時間がかかったのは、暗号やレーティングなどの慣れない概念を扱ったこと以外に、その辺も関係してるんだろうな。
＊
今はゲームを構成するパーツを作っている。
今週中には作り終えて、ゲーム本体の処理作成に入りたい。
ゲーム本体部分には暗号化などのあまり複雑な概念は絡んでこないし、5月の頭ごろにはサーバー側の処理を作り終えられるだろうか。
公開鍵暗号で作成済みのキーペアを利用する方法も確認。
＊
しかし、RSAはともかくECCはキーペアを読み込むだけでも妙に時間がかかる。
RSAはおよそ100マイクロ秒、ECCはおよそ10ミリ秒、100倍程度の差がある。
別の方式の暗号だから、それだけで単純に比較することはできないが。
鍵長はそれぞれ、RSAの方は4096ビット、ECCは521ビット。
ちょっと調べて出てきた情報によれば、RSAの鍵長4096ビットはECCの鍵長313ビットと同等、とあった。
そこから考えても、今回ECCの方が時間かかっているというのは当然なのかも。
というか、ECCの方はとりあえずでかいのを試してみただけなので、実際にはこんな長いのいらない気がする。
どこかで見た情報では、ビットコインの電子署名は224ビットのECDSAを使っている、とかあった気がするし。
＊
さて、大体確認も済んだし、明日からまた進めて行こう。
まずは自動テストの確認をするために作った対戦待ち受け開始処理に、暗号の対応を追加するところからかな。
レーティングについてのデータ追加も必要だな。
というわけでGoをやっている。
＊
必要になる技術は大抵触ったと思う。
Goにおける自動テストに始まり、GAEで扱う予定なのでURLパラメータの受け取り方やJSON出力、firestore。
共通鍵暗号、公開鍵暗号、電子署名、レーティング。
大体こんなところだったか。
これらを活用して、対戦型ゲームのバックエンドを作ろうと思う。
androidアプリから接続して利用する感じ。
＊
暗号関係は、プログラム内で鍵を生成して利用する方法しか試していなかったな。
すでに存在する鍵を利用する方法も確認しておかないと。
バージョンは17日中に確定した。
＊
翌日には細かい修正をして、その次の日からは別件を進めようと調査したりなどしていた。
今日は別件のサーバーサイドの処理について仕様を固めた。
＊
fgについては、セーブデータ機能もとりあえずできたわけだしコントローラ制御周りを進めたいところなんだが。
大雑把なイメージしかないし、すぐはちょっと無理だなーという感じ。
なので、少しの間別件を進めようかと。
予定通り、セーブデータの削除機能追加完了。
＊
これでバージョンを確定するつもりだったけど、もうちょい変更を行う。
型名の変更と、ファイル読み書き処理の例外処理を修正する。
明日中にその2つを完了させて、バージョンを確定させたい。
昨日、セーブデータのセーブ、ロード機能ができた。
＊
で、今日その機能が実際に機能するかどうか確認が取れた。
前回の記事から察するに、1ヶ月以上かかってる。
なんでこんなにかかってるんだろう。
慣れない処理でテンション上がらなかった、というのは確かにあるんだけど。
コミットログを見たら、fg::GameStateとかに変えたのをfg::GameContextに戻したり、などもやってたようだ。
その踏ん切りがなかなかつかなかった、ってのもわずかに影響したか。
それに、割と影響範囲が大きかったから仕方なかったのだろうか。
＊
大きな変更だったが、自動テストがあるおかげで無事に完了できた感じがある。
自動テスト書いてなかったら、とても完了できていた気がしない。
＊
とはいえ、この機能はまだ不完全だ。
セーブファイルの配置はこれでいいのだが、内容が不完全すぎる。
内容の暗号化などをできるようにしたいが、どのように表現するかまだ考え中。
＊
そっちはともかく、セーブデータの削除機能はすぐ追加できそう。
それを追加したらバージョンを確定しようと思う。
セーブ機能の具体的な構成が大体決まった。
＊
前回大まかな構成を決めたと言ったが、構成と呼べるレベルでもなかったな。
大まかにどのような処理を使うか、といった感じか。
で、時間はかかったがどういう構成にするか決まった。
来週、実際にヘッダファイルを作ってインターフェースを決めよう。
＊
セーブファイルを出力する機能というのは今までろくに考えたことなかったので、そのせいで余計に時間がかかってしまった。
画面を出すセーブ機能はステートで、出さないセーブ機能はスレッドで処理することにした。
それらが処理した結果は、スレッドで呼び出し元に通知する。
＊
前回の記述見たら、コマンドライン引数でディレクトリを指定する機能はまだ追加していなかったか。
それは先週だったかに完了しておいた。
セーブ機能について、大まかな構成を決めた。
＊
セーブとロード用のステートをベースシステムに用意する。
それらのステートに遷移することで、専用の画面を作ることなくセーブとロードを行なえるようにする。
あとは画面を出さないセーブとロードなんだが、こっちはまだ考え中。
ゲーム用と考えるなら、fg::Stateにメンバ関数を追加して対応するべきかと思ったが、それだとfg::Stateが変に肥大化してしまうような。
それに、ベースシステム用のものが用意できなくなる。
そうなると、fg::GameStateとfg::BasesystemStateにそれぞれ用意するべきだろうか。
それだって、大抵は別のステートが積み重なってて無効状態になっているはずであり、そこにアクセスして機能を動かす、というのはなんだか違和感がある。
どうしたものかな。
画面を出さないセーブとロードができなければ、先に進めないのだが。
＊
それより先に、コマンドライン引数でディレクトリの指定をできるようにしておくべきかな。
今のところ、ホームディレクトリやシステムディレクトリはハードコーディングされている。
テストのことを考えるなら、ここは変更できるようにしておくべきだろう。
セーブファイルはホームディレクトリ内に配置される予定なので、その辺を進める上でも関係してくるし。
CoreManagerを排除した構成の動作確認まで完了。
＊
モチベーションのせいか、時間がかかりすぎだがどうにかなった。
不要になった部分の削除がまだ済んでいないので、明日はそこから。
＊
その次はセーブ機能を用意するべきかな。
元々、その辺の問題で仕様変更が必要だったわけだし。