巫女さんファイター涼子ちゃん (PC) TAS (案)

PCゲームでもコマ送り(frame advance)は可能なんじゃないか、という思い付き企 画。コマ送り自体は実現できましたが、TAS制作にはまだまだ障害が多いので草案段 階といったところです。

このゲームはいわゆるエロゲなので知名度は低いと思われますが、ACTパートの出 来が非常に良く、個人的には傑作だと思っています(だいぶ前に 攻略サイトを作っ たりしていました)。ひそかにプレイ動画を上げてたりします:

リプレイ機能、AVI書き出し機能などについては前述の攻略サイトを参照。

TAS機能の組み込み

とりあえずコマ送りを実現するツールを作成しました(Windows XP SP3で動作確 認。listexportの吐 くコードをベースに作成)。一応ソース付き(VC専用)ですが、私はWindowsプログラミ ングには詳しくないのでおかしなところがあるかもしれません^^;

ダウンロード: mikotas-20090709.zip ※体験版に対しても有効

linmm.dll を ryoko_fight.exe と同じディレクトリに置き、ryoko_fight.exe を バイナリエディタで開いて "winmm.dll" と書かれている箇所を "linmm.dll" に書き 換えれば動くはずです。これによりゲーム中にPauseキーでポーズ、 \キーでコマ送りができるようになります。

QS/QLは難しそうだと思っていましたが、このゲームはステージ途中までのリプレ イを再生するとそのまま継続して操作できるようなので、これを利用すれば擬似的に QS/QLが可能かもしれません。現在模索中。

※追記: リプレイ再生後そのまま操作できるというのは勘違いだったみたいです。 なので、QS/QLを実現するには自前でリプレイ機能を持つ必要があると思われます。 可能かどうかは調査中。

TASとは直接関係ないですが、AVI書き出し機能は映像のみで音声は書き出してく れないようなので、そのあたりも補完できたらいいなと思っています。

mikotas 詳細

原理は単純で、timeGetTime() を乗っ取って偽のuptime(起動してからの時間)を 返しているだけです。このゲームは timeGetTime() を用いて速度制御を行っている ので、偽の値を返してやれば速度が変化するというわけです(例えば、半分の値を返 してやれば1/2倍速になる)。

APIフックの方法は色々あるようですが、今のところは偽DLL + EXE書き換え方式 を採っています。これは単に一番簡単そうだったからという理由ですが、いずれEXE を書き換えずに済む方法に移行すべきだとは思っています。

速度制御については、DLL内部に偽のuptimeと本物のuptimeを保持しておき、等速 動作中は本物のuptimeの差分から偽のuptimeを計算して返し、コマ送り中は1F分の時 間を偽のuptimeに加えて返す、という実装になっています。1F分の時間は16msとして います(リプレイファイルのフレーム数から62.555...FPS動作と推測。というより、 timeGetTime() がms単位であるために、1000/60 の小数点以下を切り捨てた結果、ウェ イトが16msになったものと思われる)。

なお、winmm.dll 内には @ を含む関数名があるので、アンダースコアに置き換え てビルドしています。本来はビルド後にDLLをバイナリエディタで編集してアンダー スコアを @ に戻すべきですが、このゲームでは当該の関数は使っていないようなの でそのままにしています。

なんとなく完成までの経緯を記してみるテスト:

リプレイファイル

リプレイファイルは *.rfr, *.rfr.sdt の2つ組で、両方が揃っていないと再生で きません。*.rfr が入力データで、*.rfr.sdt は付属情報のようです。とりあえず hex editingを行うだけなら *.rfr ファイルのフォーマットのみわかっていれば十分 です(*.rfr.sdt は埋め込みサムネイルらしきものなどが入っているが、今のところ フォーマットが不明)。

rfrファイルフォーマット

先頭12Byteがヘッダ、それ以降が入力データ。入力データは1F当たり4Byte。数値 はすべてリトルエンディアン。

ヘッダ

0x00    U32     ステージID(リプレイファイルの先頭に付く数字)
0x04    U32     乱数シード(敵の動きに影響。ステージ開始時のuptimeをそのまま使っていると思われる)
0x08    U32     フレーム数(編集時は整合性を保つのが無難。特に入力が長くなる場合は修正必須)

入力データ

Byte0が方向キー、Byte1がボタン。Byte2-3はおそらく常に0。

Byte0:

bit7    下キー押し始めフラグ
bit6    下キー
bit5    上キー押し始めフラグ
bit4    上キー
bit3    右キー押し始めフラグ
bit2    右キー
bit1    左キー押し始めフラグ
bit0    左キー

Byte1:

bit7    (無視される?)
bit6    (無視される?)
bit5    御札ボタン押し始めフラグ
bit4    御札ボタン
bit3    ジャンプボタン押し始めフラグ
bit2    ジャンプボタン
bit1    式神ボタン押し始めフラグ
bit0    式神ボタン

押し始めフラグはダッシュ入力判定などに使われるようです。なお、2Fの間にキー を押す→離す→押す、とすることで2F連続で押し始めフラグを立てることができる (コマ送りで確認済)ので、hex editingで同様の編集を行っても問題はないはずです (通常プレイで再現可能という意味で)。

メモリウォッチ

メモリウォッチ自体はMHSなどを 使えば可能です。ただし、座標や速度のアドレスはゲームを起動するたびに変わるよ うです。

とりあえず、座標および速度はともにdouble型(64bit)であり、相対位置は (x座 標, y座標, x速度, y速度) となっています。また、おまけモード開始直後の座標は (2880.0, 3072.0) なので、これを手掛かりにすればアドレスはすぐ見つかると思い ます。また、x速度は壁にぶつかると0になります(普通に停止しても完全に0にはなら ない)。

各種調査

上下左右同時押しは特に意味がないようです(上下/左右同時押しは無入力状態と 同様に扱われる模様)。

資料

関連リンク

Back