2016年12月の日記

第3作の動きも参考に、funyakのふにゃの動きの調整。
しゃがむ前にジャンプの急降下と、もっとしっくりくる空中挙動を実現したいのです。
ちなみに、funyakでは、ジャンプの跳び上がり中に、下キーでジャンプキャンセルできます。

第2作の動きも分析中。
大まかな動きは第1作に準じつつも、ジャンプ関係の挙動に大きな違いがありました。
あとは、攻撃系の操作ですね。
意外に細かく射出方向を制御していました。

funyakの動きのスピードがおかしい気がしたので、ふにゃの動きを第一作から見直してみることにしました。
まだP-Codeの解読が進んでいなくて空中の動きは調べられていないんですけどね。
地上の動きは一応把握できました。
空中挙動の修正はもう少しかかりそうですが、しゃがみ歩きなどは遠からずfunyakに搭載できそうです。

構造体のほうで行くことにしました。
速度を実測した結果、デバッグモードではクラスのほうが微妙に速かったのですが、リリースモードでは構造体のほうが速くなりました。
当初、クラスにしていた最大の理由は、無効値としてnullを使いたかったからでした。
しかし、nullを使いたければNullableを使えばよいし、実際のコードを見てみると、nullの考慮が全くできていませんでした。
無効値があったらエラーが起きるわけです。
新たにnullを考慮するコードを入れることは可能でしょうが、読みにくくなるし、デバッグモードでも構造体より遅いコードになるでしょう。
であれば、nullを使うデメリットは多い一方、使わなくする悪影響は少ないと言えるでしょう。
ならば、nullを使わない構造体を使ったほうが良いというわけです。
唯一nullを使っていたコードも、nullを使わない方式に書き換えました。

Vector2DクラスとSegment2Dクラスを構造体にする実験中。
他の様々なフレームワークではこのあたりのデータは構造体で持っていることが多く、実際、演算の都合で新しいインスタンスをどんどん生成することになるので、シンプルな構造体のほうがいいのかなと思ったのです。
とりあえず、ふにゃを100人出して行動させるテストで速度差を計測しています。

角の挙動がまだいまいちだったので、位置補正をもう少し変えてみました。
あと、そろそろ本格的にあれこれ作りたいので、状態値の追加なども。
公開はしていませんが、状態遷移表的なものも作っています。

上り坂と壁の間でじたばたする現象を修正しました。
昨日の2枚目の写真の件です。
走っていて壁にぶつかったとき、地面と壁の角度が鈍角だったら一瞬空中に弾き出され、即座に着地してまた弾き出されるというのを繰り返して、ばたついていました。
弾き出される処理自体は必要なのですが、判定が敏感過ぎたため、弾き出される距離が短い場合には弾かれなくしました。

予め指定した操作を自動で再生する機能を作りました。
ふにゃさんのときのリプレイ機能にも近い機能ですが、リプレイ以外にも使えます。
あまり機能の充実していない今作ったのは、自動テストのため。
他にも、マップ内で所定の動きを繰り返すキャラクターなどに使うことも考えています。
画像は、リプレイ入力自体のテストと、リプレイ機能を使って走る機能を確認するテストです。

管理メモの高速化など。
SQLはどのように組めば速いのかというのは、実装に大きく依存する。
それがよーくわかりました。
テストサーバーと公開サーバーで2種類のSQLの速度が逆転していました。
それも大幅に。
ちなみに、速度差を調べたのは、データの存在をINNER JOINで調べるかEXISTSで調べるか、というものでした。

声の出演やスタッフクレジット、変身や変装などの、組み合わせリストの検索に対応しました。
オープニングクレジットから探す場合は「ＯＰ：項目＝名前」、エンディングクレジットから探す場合は「ＥＤ：項目＝名前」、声の出演から探す場合は「声の出演：キャラ名＝人名」の形式です。
変装や変身も同じ要領で。

変装で例を挙げると、
「変装：アンパンマン」は変装する側かされる側のどちらかにアンパンマンが入るパターン
「変装：＝アンパンマン」はアンパンマンに変装するパターン
「変装：アンパンマン＝」はアンパンマン「が」変装
「変装：アンパンマン＝ばいきんまん」はアンパンマンがばいきんまんに変装
となります。

また、何も改良していませんが、オープンソース化しました。
一応サンプルだけは、サーバーによって動かないことがあるので修正はしましたけどね。

オープンソース化しました。
今後メンテナンスの予定などもないので、煮るなり焼くなり好きにしてもいいようにクソったれたライセンスにしておきました。

忍者ホームページで作っているわけですが、サブなだけあって更新も少ないわけで。
で、忍者ホームページは更新が長期間ないと広告がうるさくなる。
これどうにかして自動更新して広告の拡大を防げないかなと思うわけです。
定期的にFTPでダウンロードしてどこかちょっとだけ変更して上げなおしとかがいいのかな。

あるページに書く何かを執筆中…。

今使いにくいのだ。
カテゴリは一つとは限らない。
管理UIも記入しにくい。
間違えてカテゴリなしのまま配信してしまいやすい。
URLが勝手に置き換わりやすい。
間違えたフィードを修正する手段がない。
削除するのも面倒。
フィードを検索する手段もほぼない。
応用が利かない。

で、思ったのだ。
修正するより、1から作り直したほうが早いんじゃないかと。
複数のカテゴリに分類できて、
使いやすい管理画面で、
カテゴリを選びやすく、
URLを適切に保ち、
修正もできて、
削除も簡単で、
検索の手段があり、
応用的な使い方も自在な、
そんな更新情報配信システムを。

アンパンマンの過去のクリスマスエピソードをいろいろ見ていました。

ゲーム記に予言者育成学園を追加しました。
出題時点で正解が確定していないというのが面白いですね。
ある種博打っぽくもあるわけですが、出題者の期待を裏切る結果が正解だったり、回答者が全力で予言を当てに行ったりということが起こったりもします。

プログラミングコーナーに「Windows 10のUWPアプリを作る」を追加しました。
以前作っていた「牛乳飲んだ」の舞台裏ですね。
一番苦労したのはテスターとのバトルだったというわけです。

funyak。
時間でジャンプの高さが変わる処理を作り、重力を調整して、ジャンプらしいジャンプ処理ができました。
ふにゃさんのときは、高いジャンプの判定がシビアだったので、今後わかりやすくて狙った高さにしやすい仕組みを作ろうかと考えています。
あと、空中の挙動がちょっと極端な気がするので、数値も再調整するつもりです。

Sukeru。
ちょっと前に作ってソース公開だけはしていたのですが、改めてプログラムを公開しました。
ほとんどWPFのお試し用に作ったようなもので、内容はあまりありませんが、使えるときは使える気がします。

ジャンプの処理作成中。
ジャンプの高さ調整はあとで考えるとして、とりあえず最大値で跳ぶ処理だけ作ってみました。
しかし、勢いよく跳び上がる割にはすぐ落ちてくる…。
重力の設定を間違えたか？

衝突判定のテスト。
すり抜けたかどうかの判定は目で見るのが一番確実だけど、普通の自動テストは結果しか見えない。
だから、何が起こっているのかが目で見える自動テストを作ったってわけです。
画像は、すり抜け防止の対策前のテスト。
角ですり抜けるかどうかを確かめるために、中央の四角形の角に向かって四方からふにゃが飛んできます。
そして、まだ対策前なので、角をすり抜けてFailure(失敗)なわけです。
対策前に失敗しておくことをちゃんと確かめておかないと、ダメなものをダメといわないダメなテストになってしまうのです。

ゲーム画面上で確認できる単体テストの仕組みを作りました。
普通の単体テストの仕組みに乗せて自動化することもできれば、ゲーム画面で実際の動きを見ることもできるテストです。

ベータ4。
質問追加に関してバグがあったので修正しました。
Mifuminator側のバグだったので、そちらも併せてコミットしておきました。
あとは、嘘回答対策をもっと強化したいところですね。

管理画面を強化。
入力補完のかかる場所では、書く順番を考慮して候補を出すようにしました。
例えば、声の出演の項目では、アンパンマンの次はばいきんまんに決まっているのです。
ならば、アンパンマンが入力されていれば、次の行は、「ば」を入力するまでもなくばいきんまんを出せるのです。
声の出演を例に挙げましたが、オープニングやエンディングクレジットでは、似たような項目の羅列が多いので、特に効果を発揮しそうです。

検索サイト追加しました。
ただ、これ以上追加しても、微妙かな、という気がしてきました。
マイナーなところからの流入は大勢に影響を及ぼさないし、数が多くてきりがないし、だからと言って検索サイトかどうかを自動判定しようとすると、検索機能のある検索中心でないサイトが問題になるし…。
今後は、たまにリファラを調べてみて、多かった新規検索サイトを入れていくようにしようかなと思います。