Seaside Laboratory

使用可能な WAV ファイルの数

voice.lst はマニュアルに詳細な説明がなく、motion.lst では 9 番が無効値として予約されているため、使用可能な WAV ファイルの数は 0 ～ 8 番までの 9 個だと思われていた。

しかし、プログラムを解析したところボイスを格納している配列は 20 要素確保されていることが判明したため、実際は 0 ～ 19 番から 9 番を除いた 19 個を使うことができる。WAV ファイルの数が多くないのであれば無理してマイナスのボイス番号を使う必要はない。

マイナスのボイス番号

使用可能な WAV ファイルの数は決まっているため、範囲外のボイス番号を使用するとメモリが破壊されてしまう。

マイナスのボイス番号を使った場合、ボイス (DirectSoundBuffer) 領域の手前にあるスプライト (DirectDrawSurface) 領域から順に破壊され、特に残像用のスプライトは近くに配置されているので早い段階で破壊されてしまう。

スプライト領域には余分に確保された未使用データが存在するので軽度の破壊であれば耐えることができる。

Num には意味がある

キャラクター作成マニュアルには、以下のような記述がある。

必殺技等で使えるのは、1000 ～ 1299 行までです。

単なるガイドラインのようなものかと思いきや、

Num のスタートは (技の始まりは) COMMAND.LST の CmdNum を 10 倍した数値を指定するのがベストです
COMMAND.LST が 0 ～ 99 まで技が固定してあるように 0 ～ 999 までは 10 倍の数値で始まり
基本動作系のモーションは 10 以上はみ出ることは避けて下さい。

と書かれているように、command.lst と motion.lst の行番号には暗黙の変換ルールが存在する。KFX は motion.lst の Num から command.lst の CmdNum を逆算し、この逆算した CmdNum を使って状態判別を行うことがある。

• 空中に居る相手に CL が 0 または 1 の攻撃を当てたとき、それが基本技なのか非基本技なのかを判定。基本技の場合はダウンせずに復帰する。
• 浮いている相手に追撃したとき、その前に当てられた CL が 4 または 5 なのかを判定。

モーションの詰め込みなどで関係のない行番号を使用すると状態判別が正常に行われなくなる。

Sp カウンターの仕組み

キャラクターにはモーションの経過時間を保持するためのカウンター変数があり、以下の動作を繰り返している。

1. カウンターに 1 を足す。
2. カウンターが Sp 未満の場合は最初に戻る。
3. カウンターが Sp 以上になったら 0 でリセットして次の行へ遷移。

ところが、何故かキャンセルしたときだけはカウンターが -1 でリセットされてしまうため、結果的に遷移先の行が 1F 伸びてしまう。

Ci ってなんぞや

リストのパラメーター名には英単語の略称のようなものが使われており、例えば Sp なら Speed、De なら Depth といったように簡単に推測できるものがほとんどだが、Ci だけは何の略称なのか不明である。

キャラクターの属性情報を雑多にまとめたものなので Character Information の略かと思ったが、hitcheck 上では「CIRCO」という表記になっていて謎は深まるばかり…。

ジャンプ開始行の Ci を 0 にする

サマーソルトキック等のコマンドに上方向の入力が含まれる必殺技は、入力が遅いと先にジャンプしてしまうため、その後にコマンドが完成しても無視されてしまう。このシビアな入力を緩和すべく「ジャンプ開始行の Ci を 0 にして先にジャンプが出たとしてもキャンセルで必殺技に遷移させる」というテクニックが考案された。

このテクニック、よくよく考えてみると実に奇妙なのである。Ci が 0 ということはプログラム上の認識はニュートラルであり、ニュートラルはジャンプに遷移可能なので、理論上は上を押し続けている限りジャンプ→ニュートラル→ジャンプ…と無限にループすることになる。

実際そうならないのは「モーションの行番号が変化しないと遷移しない」という仕様に因るもので、同じモーションへの遷移は変化がなかったと見なされ、結果的に無限ループが抑制される。

遅延する音声

新たなモーションへ遷移したときにだけ音声が再生されるよう、再生の条件は「Sp カウンターが 0 のとき」となっている。「Sp カウンターの仕組み」に書いた通り、キャンセル時は Sp カウンターが -1 でリセットされるため、音声が再生されるまでに 1F の遅延が発生してしまう。

Sp カウンターはヒットストップとともに進行が停止するため、ヒットキャンセル時はさらに遅延することになるが、KFX はヒットストップが短いのであまり気になることはない。ただ、キャンセルして「チョーすごい技」を出すと暗転による長時間の停止が発生するため、体感できるレベルの遅延になる。

大気圏離脱現象

ゲームをプレイしていると極稀にプレイヤーが空へ飛んで行ってしまい、しばらく落ちてこないことがある。

プレイヤーは攻撃を受けると状態に応じた食らいモーションが適用されるが、CL が 6 の攻撃はどのような状態であっても「ふらふら食らい」が適用される。オフセット移動などで Vy に大きな値を設定したキャラクターが運悪く「ふらふら食らい」の攻撃を受けてしまうと、ベクトルがリセットされず、もの凄い勢いで空へ飛んで行ってしまう。

ガード不能攻撃の怪

ガード不能攻撃が飛び道具に限定されているのはヒット時のチェック処理から飛び道具が漏れているためである。詳しくは「KFX におけるガード不能攻撃の怪」を参照。

行頭で発射されない飛び道具

行頭に飛び道具発射フラグを設定すると処理がスキップされてしまい発射されなくなる、という有名なバグが存在する。

KFX は以下のような順番で処理を行っているため、コマンド経由で特定のモーションに遷移すると飛び道具発射時の Sp カウンターが必ず 1 になってしまう、という構造的な欠陥を抱えている。

1. コマンド発動
2. フレーム進行 (Sp カウンター増加)
3. 飛び道具発射

飛び道具が発射される条件は「遅延する音声」に書かれているものと同じなため、Sp カウンターが 0 以外になると発射されなくなってしまう。キャンセル時は Sp カウンターがズレるため、1F 遅れる形で発射される。

移動コマンドの謎

移動コマンドは通常のコマンドとは違って専用のプログラムで処理されているので、コマンド参照に必要な CmdNum とモーション参照に必要な AmnNum 以外は全て無視される。CmdNum はプログラム側からの番号指定があるため、実質カスタマイズ可能なのは AmnNum だけとなる。

CmdNum が変更できなかったり Std が 000 でも動作してしまうといった不可解な挙動は、全てこの特殊処理が引き起こした現象である。

コマンドによるバッファーオーバーラン

コマンドの読み込み処理は Command の最後が攻撃ボタンであることを前提としているので、最後が方向ボタンになっているとバッファーオーバーランが発生する可能性がある。詳しくは「KFX をバッファーオーバーランで破壊する」を参照。

キャンセルバグ

Std はキャンセル時に無視されるので、キャンセルが適切に設定されていないとキャラクターの動作がおかしくなる。詳しくは「殺意 RYOU とキャンセルバグ」を参照。

Std が 000 のコマンド

Std に 000 を設定した場合、キャラクターの状態と Std が一致することはないので発動しないと考えるのが自然だが、実際は command.lst を読み込んだ時点で Command が無効化されている。

KFA では、Std が 000 のキャンセルコマンドを定義することでキャンセル時にのみ発動する技を作ることが可能だが、KFX だと Command 自体が無効化されるので KFA のような使い方はできない。

多ゲージ消費技の仕組み

同じコマンドを定義することで多ゲージ消費技を作るテクニックは、元から用意されている仕組みやテクニックの応用ではなく、単にバグである。

command.lst は、コマンドの有無にかかわらず小さい番号から順に全てのコマンド (0 ～ 129) がチェックされる。発動可能な「チョーすごい技」が見つかる度に 1 ゲージ消費され、最後に見つかったコマンドが使われる。

このバグによる奇妙な振る舞いについては「カノンリベンジャーの奇妙なコマンド」を参照。

詳細仕様

マニュアルなどに書かれていない enemy.lst の詳細仕様。

• 使用可能な行数は 40 行。
• Command に 5 などの非対応文字を使用したときの挙動は未定義。
• Command の先頭に攻撃ボタンがあると正しく読み取ることができない。

距離認識バグ

エネミーは正常に動作しているのか検証するのが難しいため、プログラムの解析が行われるまで気付かれなかったマイナーバグが存在する。

• 相手との距離を保持した変数を確率値で上書きして破壊する。
• 各行の条件チェックを行う度に乱数を生成しているので確率が不正確になる。

閾値バグ

本来、閾値に 0 を設定した行は選択されないはずだが、比較演算が不正確なので選択されてしまうバグがある。詳しくは「KFX の enemy.lst に潜む閾値バグ」を参照。

ステージ画像の折り返し

ゲーム上のステージサイズは 640x240 となっているが、画像ファイル上では 320x480 となっていて、横長のステージを途中で折り返したような形で格納されている。これはおそらく DirectDraw の制約に因るもので、DirectX 3 SDK のドキュメントには以下のように書かれている。

DirectDraw does not permit the creation of display memory surfaces wider than the primary surface.

DirectDraw はプライマリサーフェスよりも大きなディスプレイメモリサーフェスを作成することができません。

DirectDraw は画面 (プライマリサーフェス) のサイズを超えるスプライト (ディスプレイメモリサーフェス) を扱うことができないので、ステージ画像はこの制約に引っかかってしまう。この制約は「画像を複数のパーツに分ける」という単純な方法で回避可能だが、ラスター構成のビットマップ画像を左右で分割しようとすると座標計算が面倒になるので、上下に分離するという方法がとられたと思われる。

ただ、実際は一度にまとめて読み込んでいるので、この特殊な形状は古い DirectDraw に対応していた時代の名残と思われる。KFX の前身にあたる KOKFX は DirectX 3 を使っているため、ステージ画像が STAGE0.BMP と STAGE1.BMP という 2 つのファイルに分かれていた。

この仕様は KFA に引き継がれる際に「左右半分に割ったものを縦に配置」と解釈されることになったが厳密には「画面サイズに分割して縦に配置」が正しい。もし KFX が大きなステージに対応していたら、サイズ 1280x240 のステージは 640x480 ではなく 320x960 になっていたであろう。

何でもプレイヤー基準

KFX はプレイヤーと飛び道具の処理が一緒くたになっているので、所々で不具合が発生している。有名なものとしては以下のようなものがある。

• 飛び道具がヒットしたときにプレイヤー側のヒット分岐が有効になる。
• 曙フィニッシュかどうかはプレイヤー側の Ci で決まる。

この他にも攻撃結果がプレイヤーの座標によって変わってしまうというマイナーなバグも存在する。飛び道具による攻撃であってもプレイヤーの状態が参照されるため、飛び道具が当たった瞬間にジャンプすると空中からの攻撃と判定され、のけぞり時間が大幅に増加する。

地面にめり込む飛び道具

基本的に飛び道具は地面に接触すると消滅してしまうが、処理順番の妙によって地面にめり込むことが可能な瞬間が存在する。

飛び道具は以下のような順番で処理されているが、

1. 飛び道具移動
2. フレーム進行
3. 画面外チェック

画面外チェックの前にフレーム進行があるので、移動によって地面に接触したとしても、次の行に設定されている攻撃判定が地面から浮いていれば消滅しなくなる。描画はフレーム進行の前に行われるので、飛び道具が地面にめり込んだ瞬間を見ることができる。

画面端の挙動

KFX は画面端の処理が少々特殊な作りになっているので、GOU の「みうらんぶ」を当てると奇妙な現象が発生する。詳しくは「君はぶらじーる現象を知っているか」を参照。

ガードゲージの秘密

KFX の逆アセソースを調べていたら「ガードゲージが増えると防御力も増える」というコードを発見して感心していたら、

「ガードしすぎて腕がしびれてきた」ゲージが多いほど防御量は上がります。

ヘルプに何気なく書かれていた。

マニュアルの間違い

KFX 付属マニュアルに書かれている悲しい間違い。

是非ご覧下さい
CMAKER フォルダにはキャラクター作成キット、解説テキストを用意しました。

キャラクター作成キットは KFX 1.00 にしか収録されなかったので、キャラクターを作る気満々になっても作成キットが見つからず、挫折すること間違いなし。本体とは別に kfxcm100.lzh という名前で単体配布されていた時期もあった。

作った技をゲーム中で見る場合、HOME CLR キーで判定を表示しておいて、ROLL UP と ROLL DOWN でスピード調節をすることができるんですが、それを使用するとどのように技が出ているかわかりやすいでしょう。

スピード調節機能は存在しない。便利そうな機能だけに無かったときの落胆は大きい。

リソースデータのカスタマイズ

マニュアルには記載されていないが、下記ファイル名と同じファイルを KFX のディレクトリに配置することで、リソースデータの一部をカスタマイズすることができる。

moji.bmp のみ KFX 1.31 から対応 (といっても最終版) で、ディレクトリも system ではなく kfx.exe と同じ場所に配置する必要がある。

エンディングの間違い

エンディングが始まると「CONGLATULATIONS」という文字が上に向かって流れていくが、正しい表記は「CONGRATULATIONS」。