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

走る処理の見直し中。
今は斜面を考慮したつくりになっていないので、斜面で走るとかなりおかしな動きになってしまうのです。
物理的にどんな現象が起きているかという段階から、考え直しています。

物理演算でふにゃ作るとか面白そうじゃね？

funyakが物理演算をかなり意識したつくりになっているため、本当に本家物理演算を使ったらどうなるのか試してみたい。
本格的に作るわけじゃないから、パパッと作りたい。

というわけで、Unityで試作。
ギヤバネを転がすだけで、ゲームとしては成り立っていませんけどね。

そろそろfunyakの意味を明かしましょうかね。

二つ意味があるのですが、そのうちの一つを説明します。
「ふにゃけい」の読みの通り、「ふにゃ系」です。

今まで、ふにゃシリーズは直系3作、ふわふわふにゃシリーズは3作＋亜種数作、出してきました。

3作目のふにゃさんは、キャラクターや要素も増え、ふわふわふにゃの要素の一部取り入れられました。
とても思い入れの深い作品です。
しかし、思い入れが深い分、不満点も多々残りました。

貧弱なUIを補うためVB6で作られた起動プログラムが必要不可欠だったこと。
主人公の基本的な動きの時点で不自然な動作が多数存在していたこと(風への反応など)。
見た目からわかりにくい仕様が多数存在していたこと(ヒートゾーンへの反応など)。
ふにゃ以外のキャラクターの、地形や他のキャラクターに対する反応が薄いこと。
画面が狭かったこと(歴代最小)。
ステージを選びにくかったこと。
名前の中の1文字を反転させるとたちまち卑猥かつだらしなくなってしまうこと。
上記および他にも多々不満点があったのに、それを仕様と割り切って決定事項として正式リリースしてしまったこと。

いくつかはバージョンアップで直せる可能性もあったでしょう。
しかし、今も残る問題の大部分は、修正してしまうと現存するステージの多くが深刻な影響を受けてしまいます。
仕様変更によりリプレイが正しく再生されなくなるのはもちろん、最悪、プレイしてもクリア不可能になる可能性もあります。
逆に、易しくなりすぎて、ステージのコンセプトが崩れてしまうこともあるでしょう。

バージョンアップで修正するのは根本的な解決にはならないのです。

一つの解決策として、ふにゃさんを「リメイク」することも考えました。
実際、それを試みたリポジトリがGithubに残っています。
しかし、たとえリメイクしても、同一作品であるならば、重要な部分はそのままでなければいけないわけです。
ところが、ふにゃさんには、重要な部分にも大きな欠陥があります。
それを変えなければ作り直す意味はありませんが、変えてしまえばもはやリメイクとは言えません。

2作目のふにゃふにゃは、二人で対戦できたり、坂の要素が出るなど、新しいことを試みた意欲作でした。
しかし、問題点はふにゃさん以上に多数あり、もはやバージョンアップでどうにかなるものではありませんでした。
そのことは以前から判明しており、いずれリメイクしたい旨も明記されていました。
でもリメイクでどうにかなるものではないことは上述の通り。

あれも直したい、これも直したい、でも、今までの延長線上ではそれはできない。
ならばとれる手段は、新作、これ以外にないでしょう。

新作にする動機はもちろん不満点の解消だけではありません。
旧作の開発当初は考えもしなかったけど、今はやりたいと思うこともたくさん出てきました。

Webブラウザ上でのお試しプレイ。
Windowsパソコン以外でのプレイ。
ステージファイル作成のゲーム本体への統合。
ステージファイル共有のゲーム本体への統合。
新しいキャラクターの追加。
新しい遊び方の追加。
自由なサイズでのプレイ。
自由な発想でのステージの作成。
オープンソースでの開発。

これらを実現するためには、旧作をいじるのではなく、全く新しく作る必要があるでしょう。

しかし、これらを単一のソフトウェアで実現するのは無理があるでしょう。

Windows用ソフトウェアはWebブラウザでは動きません。
新しい遊び方の中には、ふにゃ本来の遊び方とは大きく異なるものもあってよいでしょう。
オープンソースにすると、コードの秘匿ができなくなり、一本のゲームとして完成させるうえで不都合が出てきます。
さらに言うと、オープンソース化するということは、ソフトウェアの亜種の存在を認めるということにもなります。

新作への理想を叶えるためには、一本のソフトウェアでは足りないのです。
しかし、たとえ複数のソフトウェアを開発したとしても、それらすべてが同じ目標に向かうとすれば、それらすべてのソフトウェアに共通する芯があることでしょう。
その、ふにゃ系の複数のソフトウェアの芯となるべきものが、funyakという共通基盤なのです。

funyakとは、ふにゃ系の新作を作るための共通基盤を意味します。
そして、本当の新作は、funyakを使って作られます。

一般的なアニメーション機能を実装し、走る処理も改良しました。

アニメーションは、どの画像をどのくらいの時間表示するかというのを羅列したデータで表現しています。
まばたきのようにランダム性のある動きは作れませんが、それ以外はほぼこれで事足りそうです。

走る処理は、足と地面の摩擦力と、空気抵抗から加速度を計算するようにしました。
で、もうひとつ、走るのをやめて止まる処理も同じコードで動かしています。
結局のところ、走るのも止まるのも、地面との摩擦と空気抵抗で成り立っているということですね。
走るときと止まるときで摩擦の大きさを変えたり、動摩擦と静止摩擦を考慮したりもしています。
ふにゃさんのときに未解決のまま通してしまった、風と摩擦の不自然な関係も、これで決着がつきました。
まあ、この変更は、いまさらふにゃさんに反映する気はありませんが。

ふにゃの走るアニメーションを実装。
しかし、このような実装で本当に良いのかという疑問もあり…。

ふにゃが地面に着地する処理を作りました。
あと、早くもごちゃごちゃになりそうな様子だったので、ふにゃの状態管理周りを整理しました。

ふにゃの動きに関して整理。
走るときにかかる力は2つ。
足に対する地面の摩擦力、身体に対する空気の抵抗力。
ふにゃさんのときは、この2つがごっちゃになっていたからおかしくなっていた。
2つは独立してかかる力なので、別々に考える必要がある。
ただ、摩擦力にかかわらず終端速度を同じにしようと思ったら、摩擦力に対して空気抵抗が充分に小さい必要がある。
そうすると、空気抵抗を強く受けるというふにゃのコンセプトに反することになる。
うーむ。

ふにゃ1のソースコード解析中。
ふにゃの原点から、ふにゃの本来の動きを確かめるのです。
そして、そのまま取り入れるわけではないですが、funyakを作る参考にでもしようかと考えています。

重力状態作成中。
今回、重力状態と無重力状態は設定ではなくリアルタイムで切り替えられるので、キャラの動きの処理の前に、重力の判定処理を差し込んでいます。
マップの一部が無重力状態になるとか、無重力状態を作り出す新キャラとかも考えています。

dynamic型使ったらだいたい何とかなったので、マップオブジェクト読み込みも作成開始。
事あるごとに明示的なキャストが必要になるのは面倒ですが、意外と複雑にならずに行けそうです。

マップデータの読み込みを作成中。
JSON.NETから来るデータがどんな形式かまだよくわかっていないので、まだ手探り状態です。
XDocumentとして取得するのはうまくいきませんでした。
XDocumentはXMLのルールだから名前付きのルート要素が必要なんですね。

マップデータ読み込みのためのプロジェクト作成中。
基本的にはこちらもJSON形式にするつもりです。
画像データはさすがにバイナリにしますが、それ以外の情報はテキストとして扱える形で。
マップごとにファイルを用意して、ステージ全体の情報も別ファイルで用意して、それらのファイルと画像等をひとつのアーカイブファイルにまとめてステージファイルとするという形を考えています。

CompositionTarget.Renderingが意外とFPS安定してくれないので、内部的なFPSを安定させる処理を作りました。
描画が可変FPSでも、処理は1秒に60回行われます。
表示の1フレームと処理の1フレームが合わなくなるので見かけのFPSが一緒でも結構かくついたりしますが。

当たり判定作成中。
2箇所に同時に当たった場合の処理を作成中です。
挟まれるとすり抜けるというのをどうにかできないものか…。

当たり判定作成中。
浮遊状態で壁に当たったときの挙動を作りました。
斜め線に対応したのはもちろんのこと、ふにゃさんのときと同じ方式ですり抜け防止も行っています。
壁に当たると壁に沿って滑るように動きますが、このやり方を応用すれば壁で反射というのもできそうです。

氷の息が斜めの壁で反射するというのも実現できそうです。
これは、ふにゃふにゃのときに、やろうと思ったけど泣く泣く諦めた要素でした。
ふにゃさんのときは、反射はしたけど、斜めじゃないから出来たことでした。
それが、妥協なく実現できそうなのです。

よく考えたら、息が球状でしかも壁で反射するって変なんですが、ふにゃが攻撃に使う「息」は、エネルギー弾系属性ブレスなので、わりと跳ねるのです。
なんとかボールに出てきたなんとか人がよく使うなんとか波みたいな概念なのですが、ふにゃの息は弱いので、気を使いこなす戦士じゃなくても跳ね返せて、それこそ、何の能力も持たない壁でも跳ね返せちゃうのです。
なんか変な気もしますが、そういうものなのです。

当たり判定作成中。
今回はふにゃふにゃのとき以来の斜め線が復活するので、この辺りをもっとしっかり作り込もうと考えています。

スプライトエディタ完成。
厳密にはテスト用プログラムの中に作った簡易的なエディタなので本当の完成からはまだ遠いのですが、エディタでないと入力が面倒な項目は滞りなく入れられるようになりました。
とりあえず、ふにゃさん仕様のふにゃのスプライトデータが記入完了。
これで思う存分ふにゃの動きをプログラミングできるってものです。

それから、ドラゴンクエスト10のプレイヤーイベントを検索および通知するサイトのベータ5を公開しました。
機能的には何も変わっていませんが、SSL対応しました。
これまでは全データが平文で流れていたのでセキュリティ上の不安がありましたが、暗号化通信に対応したので、これからはもう安心です。
本当に安心するにはプライバシーポリシーも作る必要もありますが、それはまた今度ということで。

スプライトエディタ開発中。
チップ情報をある程度入れられるようになってきました。
WPFのバインディング機能をできる限り使っています。
おかげで、C#のコードはかなり少なめです。

スプライトエディタのためのカスタムコントロール作成中。
WPFらしく依存プロパティとか積極的に使うようにしています。
とりあえずスプライトの切り出し範囲を表すチップを選ぶコントロールがいい感じにできてきました。

画像リソースの扱いを変更。
スプライトという扱いにしました。
そして、スプライトエディタの開発も開始。
単純なJSONのデータとはいえ、手打ちじゃ面倒なのです。