1019
昨晩はFacebookのAPIを叩く方法を調べるのにずいぶん時間を使ってしまいました。あいつ、せっかくiOSと連携しているのに、プロフィール画像一枚とるのにも開発者登録とアプリＩＤを要求してくるのですね。もっとうまい方法があるはずと思っていろいろ調べたけど、無駄な時間ぽかった。はー。
あと自作ダイアログビューのレイアウトエンジン（LayoutConstraint作るだけですが）を書きなおすのにも時間を使ってしまった。こっちは完全に趣味が高じたばっかりにという感じなので（完全にではなくて以前のものに現実的な不満はあったのだけど）、なにやってんだという感じ。まあ、夜中にテンション上がっちゃうことってのはあるよね。はー。
今日も夕方に起きて仕事。Googleの周辺検索APIを叩くところ。これで一応画面は出揃ったはずで、あとはシナリオ待ち。あとで直すってほったらかしてたところをぷちぷち潰してゆく（あんまりおもしろくない）作業をしようかしら。あ、設定画面のこと忘れてた（けどあそこは僕の分担から一旦外れてるしな、相談しないとわからないや）。
昨晩寝る前にふと思ったのだけど、連続量将棋ってのはどうだろうか。普通の将棋は時間と空間とが離散化されているけれども、それを連続的に行う。どんな風に拡張するかというと、普通の将棋の１ターンを「時間Δtごとに自分の駒の一つを選び、Δt×（駒の速度）だけ移動する」と考えて、あとはΔt→0の極限っぽい感じにする。すごく素朴な直観に従うと、そうすることで自分と相手が交互にプレイするのではなくて同時に進行するようになるし、自分の駒も一度に一つではなく、自分の駒全体で合計が1.0になるような「重み」を各駒に割り振って、各駒は各々の移動可能速度に重みを掛けた量だけ移動するようになる。
移動方向についても、もともとの駒の移動可能方向の重ね合わせで書ける方向にはすべて移動できるようになる。速度は、将棋の駒が伝統的にムーア近傍を採用していることから、たとえば王将ならば斜め方向への移動がちょっと速くなるだろう。直進と斜めの中間については、タンジェントが有理数ならば直進と斜めの必要回数から算出することができる。
ところで、駒の移動速度を定義するにあたって問題になるのが飛車や角で、なぜならば彼らは移動量に制限がないからである。なので便宜的に実質最大値の９マスを速度としてやるほかないだろう。彼らは全方向に移動できる。また先に述べた理由から角のほうが飛車より斜めへの移動の分だけ強い。香車はあいかわらず直進しかできない。
あとは駒を取るイベントであるが、もはやターン制ではなくなるために、「どちらの駒が相手を取った」という区別はできなくなる。従って駒同士が衝突した際には互いの駒を交換して手駒にする、などの対応が妥当であろう。当たり判定は適当な半径の円でよい。
ここまで書いたところ、「桂馬はどうするのか」という指摘をもらった。確かにこれは重要な問題で、僕は将棋にまったく造詣がないのでなんとも言えないけれど、飛び越えることができる性質はきっと戦術上重要だろう。しかしこれはどうしたって連続性と相性が悪い。なにか「溜め」のような仕組みを導入して、溜まっているパワーの分だけ瞬間移動ができる、というような対応がいいだろうか。悩ましい。
というところまで考えたので、あとは誰かがどうにかしてくれるといいかなと。
はー、なんかまた具合悪くなってきた気がする。うー。