「funyak」に関する日記(7)

しゃがみ歩き実装。
これでふにゃ1の基本動作は出来上がりました。
たったこれだけの実装に時間がかかっていますが、一応理由があります。
理由は大きく分けて2つ。

1つは、「全部込み」であること。
すなわち、1～3からふわふわふにゃまで取り込んだ実装になっているため、動作一つ一つにも考慮することが多くなっているのです。
で、そのうちでもっとも計算がややこしくなる斜め線を先に実装しているため、特に時間がかかっているのです。

もう1つは、「動きのコンセプトの再定義」。
これまで全作、行き当たりばったりでそれっぽくなるように実装していたため、シリーズを通して動きにあまり一貫性がありませんでした。
もちろん、重要な部分は一貫させていましたが、しゃがんだときや空中での挙動にばらつきが出ていました。
このあたりを改めてしっかりと決めて、「ふにゃはこういう動きをするものだ」というのを定義するということです。

今回のしゃがみ歩きでいうと、第1作ではもともと「地面の摩擦の影響を受けず、常にゆっくり動く」というのが動きのコンセプトでした。
第2作ではしゃがみそのものがなく、第3作では、ふにゃに影響を及ぼすものがいろいろ増えました。
で、第3作では「風の影響も受けない」という性質も加わりました。
しかし、ギヤバネには、踏みとどまりこそするものの、吹き飛ばされます。
とげとげ相手だと、見た目に反して当たり判定は小さくなっていません。
このあたりが、違和感となっていました。
であるからして、この違和感を払拭できるしゃがみ歩きのコンセプトは、「見た目通り小さく、地面の摩擦をはじめいろいろなものの影響を受けず、ゆっくり動く」ということになるでしょう。

で、しゃがみ歩きに実際の実装はどうなったかというと、
1.当たり判定の小ささは未実装。相手となるとげとげが現れてから考える。
2.地面の摩擦係数自体が未実装。ただし、地面の摩擦を受けない実装として、加速運動ではなく、等速運動としている。
3.走行速度より遅い得度での等速運動。
と、なっています。

ええ、はい。
最終的なコンセプトは、
1.見た目通りの当たり判定サイズ。
2.移動速度に関する外的要因を受けない。
3.遅い等速運動。
となりました。
加速運動が基本だったふにゃシリーズにおいて、funyakで初めて等速運動を取り入れます。
第1作でもほぼ等速運動でしたが、もう、完全に等速運動にします。
こっちのほうが、「影響を受けていない感」がしっかりしていると思ったので。

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

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

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

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

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

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

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

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

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

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

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

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

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

局所的環境の読み込みを実装。
場所によって重力が違うとかも可能です。

骨組みだけ作って中身のなかった局所的環境を実装。
あと、主人公のデータ読み込みも主要なパラメータは一通り実装。
この辺の仕組みも自動テストに使いたいので、早めに作っておきました。

ゲーム自体の動きを自動テストするための仕組み…の、自動テスト。
案外テストのための仕組み自体にもエラーがあったりするので、こういうのが必要になってきます。
でもこれさえできればテストは一気に効率化するはず。

ゲーム自体の動きを自動テストするための仕組みを開発中。
最初にゲームの状態と動きを定義して、その後実際に動かして、既定のフレーム以内に想定した現象が起きるか、あるいは想定外のことが起こらないかを自動的に判定するのです。
例えば先日話題にしたすり抜けバグのテストなら、すり抜けが起こりそうな地形と、地形に向かって動くふにゃを定義して、地形を越えそうなフレーム数まで動かして、すり抜けた位置にいるかいないかを判定するのです。
で、これを、画面に出さない自動テストと、画面に実際に動くキャラが出るテストで同じことをやりたいのです。
なんせゲームなので、数値的に何が正しいのかというのは直感的にはわかりにくく、テストの正しさはゲーム画面で確かめたいわけです。
しかし、テストが正しいことがわかったら、以後同じテストは、いちいち自分で見る必要はないのです。

WPFのテスト用画面でも自動テストができるように画面開発中。

走る処理に修正の影響ですり抜けバグが復活したはずなので、解消に向けて修正中。
…と、その前に、すり抜けバグを再現できるテストケースの開発中。

funyak。
走る処理の修正。

でも、ちょっとそれどころじゃないことがありまして…。