MUGEN豆知識

MUGENにおいてあまり知られていない物事について。

以上の10項目はそれぞれリンク先の独立記事を参照。


MUGENにおける1P側と2P側の差

一般的な格闘ゲームにおいては1P側と2P側でなんらかの差(特定の攻撃がつながるなど)があることも多いが、
MUGENにおいてもやはり存在する。
MUGENではフレームの開始時点でmoevtypeがAになっているキャラクターやヘルパーが存在しない場合、
1P側のキャラクター本体のステコンが処理された後で、
2P側のキャラクターで同様の処理が行われ、その後ヘルパーの処理がなされた後、攻撃の成功判定などが最後に行われる。
movetypeがAのときは基本的にctrlが無効になるので、
お互いが行動を起こせる状態では2P側は1P側の出方を見てステートを処理しており、
この処理順が勝敗に多大な影響を及ぼす局面が頻繁に起こっている。
特に顕著なのが1F技で、ほとんどのAIでは投げ攻撃に対してhitdefattrを利用して回避行動を取るようになっているが、
発生1Fの攻撃に限り、2P側では相手の攻撃に対して回避行動やガードを行うことができるが、
1P側のキャラクターはそれができず、2P側で選択されていれば対処できたはずの攻撃をくらってしまうことになる。
またキャラクターの移動も1P側が先に行われるため、原理的には一般的な格闘ゲームに見られる1P側、2P側限定裏回りも成立しうる。
他にも1F技のように目立つことはないものの、全てのトリガーの反応が実質1フレーム遅れて
後出しで行動できるので、色々な局面で2P側が有利になりやすい。

ちなみにmovetypeがAになっているプレイヤーまたはヘルパーが存在する場合、それらの処理が優先して行われる。
発生が1Fでなければ1P側でもhitdefattrを使用してガードなどができるのはこのため。
もっともAI対AIの場合、2P側の方が打撃技に対するガード移行や超反応迎撃の試行回数が1回多いので、やはり2P側有利は変わらない。

AIに限った話ではなく、相手の挙動に即座に反応するステコン全般でこのような問題が発生する可能性がある。
キャラクターやAIの製作中には、たまには自分のキャラクターを2P側にして動かしてみよう。


MUGENの処理フレーム

MUGENでは1フレーム経過した時点で処理が完了するケースが多い。
例えばhitdefやprojectileはヒットまたはガード判定が出た次のフレームでダメージが入るため、
ヒット判定が出た次のフレーム(このときのstatenoは5000、5010、5020、150、152、154)で
hitoverride、changestateで他のステートに飛ばしたり、statetypesetを実行したりして
キャラクターのmovetypeをH以外にするとダメージが入らない。
またmugenの内部処理ではないものの、p2statenoのかわりにtargetstateを使用している攻撃も、
ヒット判定は出るがtargetstateは無効化される。



MUGENのステートの処理順序

MUGENでは毎フレームごとに-3ステート→-2ステート→-1ステート→0番以降の自分が今いるステートの順番で処理が進む。
-3ステートおよび-1ステートは、ステートを奪われていない限り1フレームにつき必ず1回実行され、
-2ステートはステートを奪われていても1フレームにつき1回実行される。
これらのマイナスの番号がついたステートは常時監視ステートと呼ばれ、どのステートも同一フレームで2回以上実行されることはない。
なお0番以降のステートはchangestateを繰り返すことで何度でも(2500回という上限は一応存在する)実行可能である。

MUGENのシステムに組み込まれているAI(デバッグキーのCtrl+1および+2で起動するもの)が起動している場合、
ctrlが有効になっていると-3ステートの前にMUGEN内部のコマンド処理が割り込むことがある。
一般的なchangestateは常時監視ステートで行われるので問題にならないが、
例外的にMUGENの内部処理に組み込まれているchangestate
(hitdefを受けたことによるくらいモーションへの移行、MUGEN内部のコマンド処理による前進、後退(ガード)、しゃがみ、
ジャンプ移行。ただし前進と後退、ガードはassertspecialで無効化できる。)は
-3ステートが実行される前に実行される。
これらの処理は-3ステートにおいてtime=0が成立する数少ないchangestateになっているので、
ジャンプ移行などを完全に排除したいときは-3ステートの末尾でそれぞれのステート番号とtime=0をトリガーにして、
ctrlを有効にしつつニュートラル(一般的には0番ステート)に引き戻すようにすればよい。
ただし下手に条件を設定するとくらい抜けや空中で立つなどということになりかねないので、
トリガーは慎重に設定すること。

ちなみに常時監視ステート内でselfstateおよびchangestateが実行されると、
それ以降のそのステートにあるステートコントローラが全て無視される。
必殺技へのchangestateをcmdファイルの上のほうに記述しなければならないのはこれが理由なのだが、
内部処理用のステコンの前に置いてしまうと本来毎フレーム処理されるはずの処理がスキップされてしまうことにある。
場合によっては致命的な問題を引き起こすので、changestateはそれぞれのステートの末尾にまとめて並べるようにした方がよい。
上記したtime=0のchangestateをわざわざ末尾で実行するよう明記したのはそのためである。
なお実行されないのではなく完全に無視されてしまうので、nullと:=を用いた変数代入もスキップされる。
裏を返せば、type=nullとしてもトリガー自体は実行されているということである。
完全に処理を排除してしまいたければ、セミコロンを使ってコメントアウトしなければならない。

以下、AI製作者向け
-3ステートで内部処理に加えてAIのchangestateが行われていることがあるが
-3ステートではAIのchangestateを行わないほうがよい。
それどころか、AI関係のステコンはごく一部の例外を除き、全て-1ステートで処理した方がよかったりする。
というのも、たとえ同一フレームであっても、-2ステートの内部処理を経由することで
キャラクターの状態が全く異なることがありうるからである。
オリコンやMAX発動の最後の1フレームなどがわかりやすい例で、
-3ステートの時点では最後の1フレームが残っている→
-2ステートでカウントが進み、オリコンorMAX状態解除→-1ステートの時点では解除済み、となる。
実際の対戦では両者の最後の1フレームは技の硬直中であったり
持続時間を十分残した状態で超必殺技を使って強制解除となることが大半でほとんど問題にならないのだが、
キャラクターのシステムによっては1フレームの差がきいてくることもある。
フレーム単位で自分のおかれている状況を判断しているAIならば、なおさら差が生まれやすい。
こうした問題があるので、-3ステートには「相手にステートを奪われているときは実行したくない内部処理」のみを置き、
-2ステートに「相手にステートを奪われているときも実行したい内部処理」
-1ステートに「-3、-2ステートの処理の結果を見て実行したい内部処理とchangestate」を記述するのが無難である。


スケール関連

飛び道具の倍率

CNSのSIZE内「xscale」、「yscale」を任意の数値に変更するとキャラクターの表示倍率が変化する。
ここでproj.doscaleが1になっていると、projectileのスケールも上記の倍率通りになる。

しかし、projectileの代わりにhelperを用いた飛び道具の場合は一括して変更することは出来ない。
CNS内を「type = helper」(=の前後の空白は有ったり無かったりなので気をつけること)で検索し
size.xscale = const(size.xscale)
size.yscale = const(size.yscale)
スケールの値をこのように設定すれば本体の倍率が適用されるようになる。
ただしもともとスケールを変更してあるhelperの場合はまた別。

飛び道具の出現位置がずれる場合が多いので、その時は
「type = helper」、「type = projectile」で検索し、
直下の「pos」を倍率及び基準位置(postype)に従ってすべて変更。
さらにキャラ本体の移動速度や弾速もスケールにあわせ全て調整しなくてはならない。
本体およびhelper用の全てのステート内のVel系全命令、それともしもGravityが
使われているならConstのMovement>yaccelもチェックしよう。
projectileの場合「velocity」「remvelocity」がチェックの対象である。

大雑把でいいと割り切っているなら上記の作業全てをやる必要は無いが、きちんとしたものにしようとすると
作業量はかなり多いので気をつけよう。
作業に入る前に、変更前のキャラをどこかに保存しておこう。また、一時的に変更前のキャラと作業中のキャラを
両方登録しておき挙動を比べてみると良い。特に、もしそのキャラを動画に使用するつもりならば、
技の当たり具合やコンボの繋がりにおかしな影響が出ていないかのチェックには充分に念を入れよう。

なおWin版MUGENを使っているなら(多分使っているだろうが)次の節も参照しておいた方が良い。


Size>scaleの問題点

キャラの倍率を自由に変更できるConst>Size>xscaleおよびyscaleだが、実はWin版MUGENでは
yscaleを1以外にすると影や床の反射像の表示位置が狂うという問題がある。
(xscaleの方は1以外を使用しても特に問題は無い。)
解決方法は無いらしく、強いて言えばyscaleを1から変更しないことが対策である。
後からscaleなど使わずに済むように、なるべくSFF構築の時点で画像に拡大縮小をかけておくのが望ましい。

……と言われても、いわゆるD4専用キャラでは無理な話だろうが、
正規のバージョンではない流出品の本体を正しくない設定で使用していることを考えればこの程度の問題はやむを得ないところだろう。
一応D4キャラのためには、constではなくAngleDrawを-2ステートから用いて常時縮小表示するという手があって、
このやり方ならば影が正しい位置に表示される。
キャラによっては投げ技などの最中にP2用のステイトでAngleDrawを使う場合もあるが、
その場合でもちゃんと双方のAngleDrawの効果が反映された表示になってくれる。
後からサイズを変更するのには向かないが、それをしないならばConstのxscale、yscaleを変更するよりも、
AngleDrawを使う方がより良い処理と言えそうだ。


attrの仕様

attrとは、HitDefとProjectileの中にある攻撃の属性を指定する項目である。
「特性」や「属性」といった意味のAttributeの略。

一個のattrはarg1、arg2と呼ばれる二つの部分をもち、さらにarg2は前後2文字でできている。
例えば「S,NA」というattr、コンマの前の「S」がarg1、後の「NA」がarg2である。
arg1はS、C、Aで、それぞれ立ち、しゃがみ、空中を意味する。
arg2は1文字目がN、S、Hでそれぞれ通常技、必殺技、超必殺技、2文字目がA、T、Pで打撃、投げ、飛び道具、を意味する。

arg1、arg2の1文字目、arg2の2文字目それぞれ3通りなので、3×3×3で前27種。この27種類のattrを表のようにするとこのようになる。
打撃 (A) 投げ (T) 飛び道具 (P)
立ち (S) 通常技 (N) S,NA S,NT S,NP
必殺技 (S) S,SA S,ST S,SP
超必殺技 (H) S,HA S,HT S,HP
しゃがみ (C) 通常技 (N) C,NA C,NT C,NP
必殺技 (S) C,SA C,ST C,SP
超必殺技 (H) C,HA C,HT C,HP
空中 (A) 通常技 (N) A,NA A,NT A,NP
必殺技 (S) A,SA A,ST A,SP
超必殺技 (H) A,HA A,HT A,HP

arg2は必須パラメータだが、キャラ本体やヘルパーのHitDefではarg1は必須でなく省略可能。
Projectileにはarg1も必須パラメータである。


NotHitByの仕様

NotHitByとは、キャラクターを無敵状態にするステートコマンドである。
敵の攻撃判定のattrを指定し、どの攻撃を無効化しどの攻撃を有効なままにするかを決定するが、指定の自由度はあまり高くない。

NotHitByの記述は以下のようなもの。
[State XX, XX]
type = NotHitBy
trigger1 = (任意のトリガー)
value = (任意のarg1要素),(任意のarg2要素),(任意のarg2要素),(任意のarg2…略
このvalueにattrを書きこむことで、どの属性の攻撃判定を無効化するか指定するのだが、
この時の記述の形式はけっこう独特で分かりづらいため、しっかりと理解することが必要である。

「value =」の直後に記述するのはarg1要素。
value = S
例えばこうしてSと指定しただけで StateTypeがSの状態での判定 全てが無効化される。
注意すべきは参照しているのは敵のHitDef内のattrの記述ではなく、 敵の実際のStateType だという点。
記述上でagr1がCやAになっていてもStateTypeがSなら無効化対象であり、
もし敵がそのHitDefを維持したままStateTypeをCやAに変更すればその時点から無効化対象外になる。
ちなみにPrijectileは本体のStateTypeの影響を受けず常に記述通りの属性なのでこういうことはない。
value = SCA
こうするとStateTypeがCとAの攻撃も無効化対象に入る。完全無敵を作りたい場合この記述が一番簡単である。

arg1要素を省きarg2要素だけ指定したい場合は「value =」の直後にコンマを打ってから記述を始める。
value = ,NA
このようにすれば 通常技で打撃属性の判定 (arg2がNAのattr全て)を無効化する。
さらにNAの後にまたコンマを打てば他のarg2要素を書き加えていくことが出来る。

なおarg2要素1文字目には、N、S、Hの他にAが存在する。Allの略のAである。
value = ,NA,SA,HA
「N、S、Hの全ての打撃」を対象にしたい場合普通に書けば上のようになるが、
value = ,AA
Aを使うとこのように短縮できる。ちなみに下のようにすると、「全ての打撃と投げと飛び道具」が対象となってSCAと同じく完全無敵になる。
value = ,AA,AT,AP

指定対象は書き足せば足した分だけそのまま範囲が広がり、例外枠を作ることはできない。
value = S,NA,NP
などとすると、全ての 立属性の判定通常技で打撃属性の判定通常技の飛び道具属性の判定 に対して無敵になる。
例としてvalue = S、value = SCA、value = ,NA、value = S,NA,NPの無効化範囲を表で見るとこうなる。
+ ...

上記のようにarg1、arg2の要素はそれぞれ独立しているのだが、KOFの前転の様に「SCA全属性の打撃および飛び道具に無敵」としたい時に、
「SCA全属性の」を意識するあまりつい「value = SCA,AA,AP」としてしまうような事も有るが、これだと完全無敵になってしまう。
この場合arg1を省き「value = ,NA,SA,HA,NP,SP,HP」か「value = ,AA,AP」とするのが適切である。

キャラ作成をしていれば「立属性かつ打撃属性である攻撃に対してだけ無敵」という状態を作りたい場合なども
あるかもしれないが、NotHitByの仕様上それは不可能である。
value = ,AA とarg2要素だけを指定しトリガーにP2StateType = Sを加えるなどすれば、
意図に近い状態を作れないでもないが、トリガー成立中にはあくまでも全ての打撃に対し無敵となっているため、
タッグモードや、相手がヘルパーを多用するキャラだった場合など、
P2のHitDef以外の攻撃がある状況ではどうしても安定した結果にならない。


投げ技の最中にしてはいけないこと

正確には投げ技だけでなく、HitdefでP2StateNoを指定する技と、
targetstateを使用する技全般である。これらをさしてステートを奪う、などと呼ばれる。
ステートを奪われていると、デバッグを起動したときに画面左下に表示されるキャラクター情報の文字が黄色になる。
このとき、技を仕掛けた側、仕掛けられた側双方にしてはいけないことがある。

まず技を仕掛けた方。
相手のVarを変更してはいけない
本当をいうとこれは豆知識だとかではない。なんでかと言うと公式のドキュメントに書いてあることだからである。
sctrls.rtfかsctrls.htmlを開いて「rude」という単語を検索すれば当該の箇所が見つかる(大体を意訳すると
「貴方のカスタムしたステートでP2を処理している間には使わないでください、P2の変数を上書きしてしまいます。
とても失礼です。」というような内容)。
Helper、Projectile、Explod等を発生させてはいけない
こちらは別にドキュメントに書かれているわけではないが、理由は大体上と同じである。
HelperとProjectileはともかくExplodまで?と思うかもしれないが、
NumExplodというトリガーもあるので念の為に使用を避けた方が安全。
相手のPowerをトリガーにした記述を考え無しに使用してはならない
これはPowerはそのキャラ固有のものではない(タッグパートナーやヘルパーも共有している)ためで、例えば
『徐々に相手のPowerを減少させていき、やがてある数値を下回ったらSelfStateでコントロールを返す』というような
技を作ると、場合によってはその技は延々終わらなくなってしまう。
ただしあくまでこれは考え無しに使うのが問題なので、きちんと考えて使う分には問題はいくらでも避けられる。
技の演出中にtargetstateやtargetbindなどを使うときは考え無しにくらい判定をつけてはいけない
ワイヤーダメージや特殊ダウン(ダウン追い討ちをかけるためのダウン)など、
かけられた側が一定時間後にselfstateを実行する場合はかまわないが、
投げ技などでは技をかけている最中に攻撃側が攻撃を受けて技のステートから抜けてしまうと、
技をかけられた側がそのステートから抜け出せなくなってしまうことがある。
また技をかけられた側のくらい判定を残したままにすると、攻撃をくらってステートから抜けた際に
かけた側が何もない場所で投げモーションを取ったりと妙なことになる。
これもきちんと考えて使う分には問題はいくらでも避けられるし、見栄えも良い。
なお、くらい判定が無ければそれで安心かというと案外そんな事も無い。
例えば!GetHitVar(IsBound)でSelfStateするなど、予定外の状態になった場合に相手が抜けれるように例外処理はきっちりと書いておくべきである。

つぎに技を仕掛けられた方。
こちらはしてはいけないことが多いのでやや大雑把になるが一個一個を上げずにまとめて説明する。
勝手に状態を変えてはいけない
勝手に-2ステートでChangestateやSelfState等をするな、ということ。
当たり前に思えるが、原作で投げや当て身投げが通じないような特殊なキャラ(これとかこれとか)で、
その再現のためかこれをやってしまっているキャラは案外いる。
しかし、投げを食らわないようにするのと、投げ成立後に相手の記述から勝手に抜けるのは別である。
最悪本体が落ちることもあるのでこれらのキャラと当て身投げ技を持つキャラの対戦時は注意がいる。
相手がトリガーにしそうなものは全て変更してはいけない
例えばVelSet、VelAdd、PosSet、PosAdd、LifeSet、LifeAdd、ChangeAnim…etcである。
これらを変更する記述を-2ステート内に持っているキャラは、-3に記述の場所を移した方が良いだろう。
ちなみにこれらを意図的にやって、相手の投げ技などを正常に機能しなくさせているのが神キャラらの即死攻撃対策である。
特にselfstateで投げなどから抜ける行動はステート抜けと呼ばれ、
GUILTY GEARのサイクバーストのようなくらい抜けとは明確に区別されており、
後者はコモンステートで定義された共通くらいステートでのみ使用可能になっている。
裏を返せばステートを奪われるとこれらのシステムが使用できなくなってしまうため、
むやみやたらとステートを奪うのは考え物である。
もっとも、技の性質上こういったシステムを使用させたくないときに、わざとステートを奪うケースもあるのだが。
commandトリガーを使ってはいけない
ステートを奪った側で実行されたコマンドに対応するコマンド(コマンドの内容ではなく、cmdファイルに記述されている順番が同じコマンド)が、
なぜかステートを奪われた側でも実行されるという仕様が存在する。
そのためcommand以外の条件が甘いステコンを-2ステートに記述すると、
投げ技や当身を受けたときに暴発してしまう可能性がある。
またhelperは本体とは独立して処理を行っているので、
helper側のroot,commandトリガーが反応してしまいステコンの暴発につながることもありうる。
stateno=○というトリガーを使ってはいけない
相手がtargetstateなどで指定したstatenoの番号と、
-2ステートやhelperに記述されたstatenoトリガーの番号が重なってしまった場合、何が起こるかわからない。
stateno!=○というトリガーであれば問題は起こりにくいが根本的には同じである。
例えば本体のステートを参照してhelperからexplodなどを射出している場合、
本体が投げられた途端にエフェクトが表示されるなどということがある。
それだけならまだいいが、varsetなどが実行されていると非常に危険。
-2ステートにあるものついては、statenoトリガーを使うのではなく、
ステートコントローラごとそれぞれのステートに移した方がよい。
また、stateno!=○というトリガーであっても、statenoが重なってしまった時の対応を考えておく必要がある。
commandトリガーと同様、helperでroot,statenoやparent,statenoトリガーを使用している時も注意しなければならない。

これらはステートコントローラーをState -2内に置いている事で起こる(と言うか、投げ技を喰らっている最中でも
実行したい事がある場合のために有るのがState -2だと捉える方があっているだろう)。
記述をState -1か-3に移動させれば実効されなくなる。
どうしても-2から記述を動かすわけにいかない場合、トリガーの条件を厳密にするしかない。
例えばステートを奪われているときはmovetypeがHとなっていることが多い(ReversalDefからだとそうでない場合もある)ので、
movetype!=H、またはroot,movetype!=Hを加えるだけでもほとんどの暴発を防止できる。


p2statenoおよびtargetstateをかけた攻撃の仕様について

p2stateno

相手に攻撃がヒットしたフレームでステートが変更されるため、
デバッグのコマ送りで5000番台のステートに飛んでいるのは確認できない(prevstatenoでは確認可能)。
hitdefのattrが相手がhitoverrideで指定しているattrと重複した場合強制的にスカり、
ヒット判定やガード判定、エフェクトは一切出ない。
そのため、一見すると無敵状態になっているように見える。

hitonceが無効になっている攻撃で複数の相手を同一フレームで巻き込み、
一方が直撃、一方がガードした場合、直撃した方のみp2statenoで指定したステートに飛び、
両方とも直撃していれば、両方が飛ぶ。
p1statenoがある場合、1体でも直撃していれば指定したステートに飛び、
全てガードされていれば飛ばない。
hitonceが有効になっている攻撃で複数の相手を巻き込んだ場合、
ランダムでどちらか一方のみp2statenoで指定した飛ばす。
また、自分はp1statenoで指定していたステートに飛ぶ。
なおhitonceを明記しなかった場合、attrが投げ以外なら無効、投げなら有効になる。

p2statenoを仕込んだ攻撃と相手の攻撃が相打ちになった場合、
p1statenoに関係なく食らいステートに飛ばされるが、p2statenoだけは実行される。
selfstateで強引に戻すにしても自分以外のステートをトリガーにせざるを得ないため、
タッグできちんと動作する保障はない。
そのためp2statenoを仕込んだ攻撃のpriorityはmissにしておいた方が無難。

p2statenoを仕込んだ攻撃と仕込んでいない攻撃が同じフレームで相手に当たった場合
(以下便宜のため、p2statenoを仕込んだ攻撃を投げ、仕込んでいない攻撃を打撃と呼ぶ)
idの若い方が投げを実行していた場合、
攻撃を受けた側は投げで指定されたステートに飛ばされ攻撃側もp1statenoで指定されたステートに飛ぶが、
同時に打撃によるダメージも入る。
また、targetは投げを使ったキャラクターのみ保持され、
打撃を当てたキャラクターのtargetは無効となる。
idの若い方が打撃を実行していた場合、
1Fだけ投げで指定されたステートに飛ばされるが、その次のフレームで打撃によるダメージを受けて
5050番ステートに飛ばされ、その場でダウンする。

targetstate

投げ技などの過程でtargetstateを使用する場合もあるが、
ここではロック技やワイヤーダメージなどを想定し、
numtarget&&movehitをトリガーにしてignorehitpauseを有効にして作動するものとする。
targetstateはキャラクターの個別処理なので、最速でもヒット判定が出た次のフレームで、
常時監視ステートが実行できる状態にならないと作動させられない。
一方hitoverrideによるステート変更はmugenの内部処理にあたり、
ヒット判定が出た次のフレームの冒頭で実行されるので、
相手がhitoverrideでmovetypeがH以外に指定されているステートに飛ぶと
targetが無効になり、作動しなくなる。

targetstateを仕込んだ攻撃で複数の相手を同一フレームで巻き込み、
一方が直撃、一方がガードした場合、ガードした方の相手もtargetstateで指定したステートに飛ぶ。
これはガードされたときもtargetは有効であり、movehitとmoveguardedが同一フレームで成立すると
movehitだけが有効になるためで、targetstateのトリガーだけで完璧に回避することはできない。
また、p2statenoのhitonceのように相手を1体に限定することも不可能。
一応、targetstateで飛んだ先でgethitvar(guarded)などをトリガーにしてselfstateで戻すことは可能。
このとき戻すステートは120、130~132番ステートが妥当だが、
技の演出の関係上、どうやっても見た目が不自然になってしまうこともある。
また攻撃側の挙動が安定しないケースもあるので、
タッグ限定のバグであることから、実際には特に対処されていないことがほとんど。

targetstateを仕込んだ攻撃と相手の攻撃が相打ちになった場合、
食らいステートに飛ばされるためtargetstateが実行されることはない。
そのため、hitdefのpriorityをhitにしても基本的に問題はない。
ただし常時監視ステートにtargetstateを置く場合は
相打ちしたときに誤作動することがあるので、movetype!=Hなどが必要になる。

targetstateを仕込んだ攻撃と仕込んでいない攻撃が同じフレームで相手に当たった場合
targetstate自体はidを問わず問題なく作動し、同時にchangestateを作動させても問題ない。
またtargetはtargetstateをかけた側のみ有効になる。
逆にtargetstateが乗っていない攻撃は、攻撃が重なったフレームに関しては
相手のくらい判定や無敵状態に関係なく強制的にスカる。


技が途中で止まるorいつまで経っても止まらないorキャンセルの猶予が異常に短い

真田小次郎(ホタリュソ氏)の『無明剣・贄』、ジャック・ターナー(Andre Lopes氏)の『ストライカーテムジン』、グラント(M.M.R氏)の『魔神円月輪』などで起こる現象。
最後1つは少し毛色が違うが、原因は同じだったりする。

これはMUGENの、DOS版とWIN版の仕様の違いによるもので、簡単に修正する事が出来る。
下記の左側の記述を右側のように変更すれば良い。

movecontact = 1 ⇒ movecontact
movecontact = 0 ⇒ !movecontact
movehit = 1   ⇒ movehit
movehit = 0   ⇒ !movehit
moveguarded = 1 ⇒ moveguarded
moveguarded = 0 ⇒ !moveguarded

置換機能のあるテキストエディタを使えば楽、と言うか使わないとかなり面倒なので、おとなしく使おう。
ちなみにこの項の内容は無限小学校のMUGEN説明書にも載っているのだが、意外と気付いていない人も多いのではないだろうか。
『何かおかしいな?』と思ったらまず試してみるのをお勧めする。

立ち・しゃがみニュートラルで出せる技とstatetypeトリガー

ctrlが有効なときにキー入力により起こる立ち・しゃがみへのchangestateは常時監視ステートの前に処理される。
しかしchangestateが起こった時点でstatenoは変化するが、
実際にstatetypeやphysicsが変化するのは常時監視ステートの処理が終わった後なので、
常時監視ステートでstatetype=Cが成立するのは、
ニュートラル状態でcommand="down"が成立したフレーム(キーの↓を押したフレームと考えていい。
このとき同時にcommand="holdown"も成立する)ではなく、その次のフレームになる。
このため、kfmのようにstatetype=Cがしゃがみ通常技のトリガーに入っている場合、
↓キーとボタンを同時押しするとしゃがみ通常技が出ない。
また立ちへの移行でも同様の現象が原因で、しゃがみニュートラル状態から
↓キーを離すと同時にボタンを押しても立ち通常技が出せない。
わずか1Fではあるが、立ち通常技>しゃがみ通常技、
またはしゃがみ通常技>立ち通常技の目押しが重要となるキャラでは致命的。
特に猶予0Fの目押しは、絶対につながらなくなってしまう。
技の条件に入っているstatetype=Sやstatetype=Cを全てstatetype!=Aに書き換えれば、この問題は解決される。

なお立ちガードとしゃがみガードの切り替えに関しては、ガードステート内に立ち、しゃがみの切り替え記述があり、
ガードの正否判定がキャラクターの処理が全て終わった後に行われるので問題ない。

ちなみにキー入力によるジャンプ移行でもctrlが無効化されるのは常時監視ステートの処理が終わった後なので、
ニュートラルからキー↑要素を入れた1F目では、stateno=40&&ctrlが成立する。
この仕様があるので、サマーソルトキックのようなキー↑要素のある技のトリガーにはstateno=40を加えなくても一応出せるのだが、
出しにくいことにはかわりがないので、stateno=40でも出せるようにしておいた方がいいだろう。


AIパッチを当てる際の小技

単にパッチファイルを丸ごと上書きする前に少し手を加えてやると
1キャラ分の容量で複数のAIを使い分けることができ、またバックアップや整理も容易になる。
  1. キャラフォルダ内に新規フォルダを作る。フォルダ名はAIの製作者名などにしておくと整理する際に分かりやすい。
  2. そのフォルダにAIパッチの中身を全て入れる。
  3. AIパッチの中に新しいdefファイルがあればそれを、なければ元キャラのdefファイルをコピーし、元キャラのdefと同じ場所に置く。
    ファイル名は先ほど作ったフォルダ名と同じにしておくと良い。
  4. コピーしたdefファイルを開き、AIパッチの内容に基づいて記述を変更する。
    (例) 新しいchara.cmdとchara.cnsファイルが「AI」フォルダに入っている場合
    chara.cmd → AI/chara.cmd
    chara.cns → AI/chara.cns
    に全て変更
  5. このdefファイルをMUGENのdataフォルダ、もしくは使用アドオン内のselect.defに登録する。
なお最初からこの形式で製作されてるAI製作者もいるので、その際はこの手順を踏む必要はない。
select.defを参照すればどれが誰のAIなのか一目瞭然なので、後々非常に便利。
ただし新しく作ったdefファイルの記述が間違っていてもエラーが出ないことが多いので、確認はしっかり。
何か動きがおかしいなと思ったらここをチェックしてみよう。

最近になってこの作業を自動化するツールが公開された。
簡単なので一度使ってみるとよいだろう。

ただし、動画中にも書かれているが、適用後の確認はしっかり行うように
気をつけよう



チーム戦(Turns)で2番手以降のキャラのイントロを発生させる方法

最初から対応しているキャラもいるが、MUGENのデフォルト設定では発生しないようになっている。
そこでまずMUGENのdataフォルダ内のcommon1.cnsを開き、一番下にある [State 5900, 3] ;Intro for round 1 の記述を
[State 5900, 3] ;Intro for round 1
type = ChangeState
value = 190
trigger1 = RoundNo = 1
trigger2 = RoundsExisted = 0
trigger2 = TeamMode = Turns
trigger2 = RoundNo > 0
に書き換えてやる。
これで備え付けのcommonを使っているキャラはOKだが、
独自にcommonファイルを持っているキャラやcns内にvar持ち越し、イントロの設定などが含まれているキャラの場合
それぞれ [State 5900, 3] に相当する記述を探し出して同じように書き換える必要がある。
この場合間違った場所に上書きしたりすると最悪そのキャラが動かなくなるので、バックアップを忘れずに。
場所はキャラによってまちまちだが、片っ端からファイルを開いて 「5900」 などで検索をかけていけば大抵は見つかる。
稀に [State 5900] 以外に記述しているキャラもいるので、どうしても見つからなければ検索ワードを 「190」 などに変えてみよう。
2箇所に記述があることもあり、その場合は優先順位の高い方を修正しないと反映されないので注意。
イントロがあるかないかで動画の見栄えもかなり変わってくるので、チーム戦の動画を作る際にはこの作業をやっておくと良いだろう。

ただしこの記述は単にそのキャラが登場したラウンドのみイントロに移行するというものなので、
KOFのような特定の対戦カードになったときの掛け合いが成立しない。
trigger3 = TeamMode = Turns
trigger3 = P2Name = "kfm" || P2Name = "ryu" || P2Name = "kyo" ;(以下略)
という具合に書き加えて対応キャラを個別に登録していけば可能だが、これをいちいちやっていくのは凄まじく骨が折れる。
一応毎試合無条件で両者のイントロを発生させるようにすれば一括で成立するので、
それでもいいから掛け合いが欲しいという人は上の記述5行目行頭に「;」(半角セミコロン)を挿入しよう。

また別の方法としてはイントロ分岐用のステートを別に準備した上で5900ステートからへは毎ラウンドそのステートへ飛ばすようにし、
特殊イントロがあり、自分か相手のどちらかが初登場のラウンドなら特殊イントロへ、
(triggerall = RoundsExisted = 0 || enemy,RoundsExisted = 0 という記述を条件に追加する)
特殊イントロがなくて自分が最初のラウンドなら汎用イントロへ、
どちらでもないなら立ちステートへ飛ばすように分岐をかければ、これらの問題はすべて解決する。
ただし、対戦する両方に記述をしておかないと、片方が呼びかけているのに相手が無反応という悲しい事態も起きる。
必ず両方を対戦させてチェックしよう。



勝利ポーズ表示時間を変更する方法

独眼ちゃんやアリ氏の斬紅郎(2008年5月以前版)などで、
勝利ポーズの途中で画面が切り替わってしまう 現象が時折見られる。
逆に、キャラによっては勝利ポーズが終わったのにいつまでも切り替わらないこともある。
斬紅郎の「無限流こそ海内無双の剣技よ」という台詞の「海内」の辺りで画面が切り替わってしまう現象に空耳も合わさって、
一部では『 無限流こそ曖昧現象 』と呼ばれることもある。
それを解決するには、勝利ポーズのステートから
[State 181, 1]
type = AssertSpecial
Trigger1 = Time = [0,200]
flag = RoundNotOver
というような記述を探し、無い場合は付け加える。

もちろん勝利ポーズによって掛かる時間は違うため、 Time = [0,200] の部分はそれに合わせて書き替える必要があるが、
そこは実際にMUGEN上で動かして調整すればいいだろう。
またライフバー側の設定がまずい場合も似たような現象が起こる。代表的なのはVF5LBだろう。
fight.defの中のover.timeの数値を250ぐらいに変更すれば解決するはずだ。


常時ステートの専用記述で対応する攻撃一覧

毒などの特殊な技は、攻撃側の記述だけでは再現しにくいことがある。
そのため相手側の常時ステートに専用の記述を組み込む必要があるが、
もちろん全てのキャラがその種の技全てに対応しているわけではない。
キャラや動画を製作する時は、こういった点にも留意するべきだろう。

製作者名 キャラクター名 対応する攻撃 備考
ドロウィン氏 廿楽冴姫 アンプゾワネ
アバトワール
朱鷺宮神依
フィオナ・メイフィールド
SAIKEI氏 ユダ イチコロ
ゆ~とはる氏 マミヤ バイク 七星ゲージのあるキャラ限定
マミヤ 挑発
愛原奈都美
アル・アジフ
586氏 神尾観鈴 不幸の塊
観鈴ちんピンチ!
HAL氏 遠野秋葉 獣を焦がす
疾駆する獣を焦がす
⑨氏 赤朱秋葉
翡翠 じょうろ MBAA仕様
琥珀 現代医学の犠牲者です MBAA仕様
レン パウダースノウ MBAA仕様
ワラキアの夜 ブラック・クラック MBAA仕様
祇園城奏貴氏 西行寺幽々子 霊符「无寿の夢」
寿命「无寿国への約束手形」
水影氏 伊吹萃香 酔符「鬼縛りの術」
酔夢「施餓鬼縛りの術」
霊力ゲージのあるキャラ限定
小野塚小町 脱魂の儀
鈴仙・優曇華院・イナバ 毒煙幕「瓦斯織物の玉」
洩矢諏訪子 土着神の祟り
ミシャグジさまの祟り
IF氏 永峰希美 ウィッシュプライヤー

具体的な対応方法や記述の内容は、各々の付属txtなどを参照のこと。


MUGENデバッグキーの一覧

大会・ストーリー動画の作成や、キャラ・AIの作成などあらゆる場面で知っていると便利なMUGENショートカットキーの一覧を掲載。
F1 2P側のライフを0に
CTRL+F1 1P側のライフを0に
F2 両側のライフを1に
CTRL+F2 1P側のライフを1に
SHIFT+F2 2P側のライフを1に
F3 両側のパワーをMAXに。ゲジマユでお馴染み
F4 ラウンドリセット
SHIFT+F4 データのリロード(mugen起動中にcnsを更新して、そのまま更新データを読み込ませる事も可能)
F5 タイムオーバー
F8 デバッグデータ表示中、エラーメッセージをリセット
F12 スクリーンショット
CTRL+C 判定枠の表示の切り替え
CTRL+D デバッグデータ表示の切り替え
CTRL+I 両側のプレイヤーを強制ニュートラルステート(StateNo=0)に(はまり状態の回避に使える)
CTRL+L アドオンのライフ、パワーバー等を消去(キャラ固有のパワーバーは消せない)、用途はキャラ作成時に見やすくすることなど
CTRL+S ゲームスピードアップ(デバッグのFPSとSPEEDで確認可能)
CTRL+数字 数字には1~4の数値が入る。指定した数値のキャラをAIモードに(1なら1P、2なら2P)
CTRL+ALT+数字 キャラの消去。もう一度押すと元に戻る
SPACE 両側のライフとパワーをMAXに、時間もリセット
PAUSE ポーズ画面の表示、トレーニングモードならサンドバッグの状態の指定も可能
SCROLLLOCK PAUSE中にSCROLLLOCKを押すたびに1Fだけ時間を進める、製作中キャラの動きの確認等で使える。
ESC mugenの終了や画面を戻すのに使用


batで色々

[(mugen名) -r (アドオン名) -p2.ai 1]とやるとアドオン実行&2pAIonの効果
-h ヘルプを表示。上の画像
-r アドオン
-p2.ai 1で2pのAIon。-p1.ai 0ならwatchモードで1pが操作可能に。-p3.ai 0で3pのAIも無効化できるのでタッグの動作確認などに。
-p2.color カラー指定。12P色を選ぶ時とかに
-s ステージを指定。select.defに登録する時の「stages/aaaaa.def」という書式ではなく「aaaaa」で記載
-nomusic BGMを流さない。
-nosound BGMと効果音を流さない。
-rounds ラウンド回数を指定。0で1ラウンドだけ戦う。10ラウンド戦わせる時は、9にする。
-log 試合結果をテキストに保存する。

例.
winmugen -r MBC -p1 ryu -p2 terry -p1.color 1 -p2.color 4 -p1.ai 1 -p2.ai 1 -s geese_stage -rounds 2 -nomusic -log ryuvsterry.txt
という内容のバッチファイルを作ると、
アドオンは「MBC」で、1P側のキャラはryu、2P側のキャラはterry、1P側のカラーは1、2P側のカラーは4、1P側はAI操作、2P側はAI操作、
ステージはgeese_stage、3ラウンド戦ったら終了、「ryuvsterry.txt」というファイルを作ってログを保存する……という事ができる。
AI戦闘の勝率チェックで200ラウンドほど戦わせて結果だけ表示させたいという時に便利。
各ラウンド終了時の体力やゲージ残量も記録してくれる。通算成績を自動計算してくれないのが難点か。


起き上がり短縮

MUGENでは自分が操作しているキャラクターがダウンした時(StateNo5100、5101、5110の時)、
ボタン(FBUDabcxyzsどれでもOK)を連打するとダウン時間を短縮出来る(=起き上がりステートへ移行できる)仕様になっている。
ダウン短縮自体は実装されているゲームも多いのだが、MUGENの場合起き上がりタイミングを任意に変えられる上に
連打の速さによってはダウン直後に起き上がれる場合すらある
このためMUGENではダウン追い討ちがしづらいばかりでなく
起き攻めリバーサルのコマンド入力もタイミングが取りづらい上、
場合によってはダウンさせたのに反確という事態もしばしば起こる。
これを防ぎたい場合は攻撃側であればダウン中相手のステートを奪う、
防御側であればStateNo5110に飛んだ瞬間に別のダウン専用ステートに飛ばすといった処理を行うしかない。
一部のキャラはこのような処理を行なっているので、気になる場合は参考にするといいかもしれない。


Helpermaxについて

一部のキャラクターは、製作者が付属のテキストで「Mugen.cfgのHelermaxを56に書き換えてください」と指示していることがあるが、
実はこの修正、ニコニコで目にするようなキャラクターをWin版Mugenで動かす際の必須事項と言ってもいい。
Helperが大量に発生するのは何も弾幕を張ったときだけではなく、
演出やエフェクトにも使用されており、GM氏の3rd仕様リュウがダウン時に10個以上の視覚的に見えないHelperを管理していたりと、
意外なキャラクターがそこそこの数のHelperを発生させている。
Helperの個数がHelpermaxに到達してしまうと、飛び道具が出ないぐらいならまだいい方で、
ロック技の判定にHelperが使用されていると試合が続行不能になることもある。
こうした事故を未然に防ぐために、面倒くさがらずにWin版MUGENの上限値である56に設定しておこう。
また、Helperを使ったキャラを製作する時は、2対2の試合の時でもHelpermaxを超えない様に、
一度に使用するHelperは14個までにしておくのが望ましい。
(弾幕キャラの場合そうはいかない事もあるが)


製作者特有のMUGENキャラクターの仕様について

Luchini氏製作キャラのAIを起動する方法

該当するキャラは
の9キャラです。

氏の製作したキャラクターにはAIが搭載されているものの、アーケードモードでしか起動しません。
これをウォッチモードでも起動できるようにします。

まず、それぞれのキャラのcmdファイルを開き[state -1, AI]となっているStateを探しましょう。
幾つか見つかると思います。
その全てに

triggerall = ishometeam = 1
triggerall = matchno > 1

というトリガーがあるので、この二つが機能しないようにそれぞれの頭に「;」を付けます。

;triggerall = ishometeam = 1
;triggerall = matchno > 1

これでウォッチモードでもAIが起動するようになります。
が、このままでは自分がそのキャラでプレイする時にまで起動してしまうので、
知識のある方は簡易的にでもAIスイッチを付けた方が良いです。


水影氏制作の東方キャラについて

キャラのバージョンについて

氏のキャラはいずれも動画使用時は最新版を使用するように義務付けられている。
動画撮影時には更新日時をきっちり確認するようにしよう

受身不能時の無敵について

氏のキャラは受身可能になると全身無敵になる仕様がある。
これ自体は元ゲーの仕様の再現であるのだが、氏のキャラの場合受身不能状態であっても無敵状態になることがしばしば起こる。
これは一部のキャラがfall.recoverで受身不能にしつつもfall.recovertimeを設定している、
もしくは攻撃ヒット時にHitDefのパラメーターを使わずにステートを奪って受身可能になるまで受身動作を取れないようにすることで
擬似的に受身不能時間を設定するといった処理を行っているのに対し、
水影氏のキャラは受身不能時間が0になったら無敵になるという処理を施しているために
受身不能時間が0になると例えステートを奪われていようと問答無用で無敵になってしまうため。
これを防止するには水影氏のキャラのフォルダ内のstate-2.cnsにある。
[State 3200, 1]
type = Nothitby
trigger1 = (statetype = A)*(CanRecover+(gethitvar(fall.recovertime)=0)>0)*(movetype = H)*(stateno != [150,159])
value = SCA
という記述を無効にするか-3ステートに移すかすればよい。
ただし前者の場合は受身可能時無敵という仕様そのものがなくなり、後者ではHitDefでfall.Recovertime=0としている場合には効果がない。
いずれにせよこの改変を行う際にはよく考えた上で自己責任で行うように。

総体力について

氏のキャラはいずれもLifeMax10000、Def10に設定してある。
このためLifeAddでのダメージや相手体力の最大値を参照したダメージを与えるとダメージ量がおかしなことになることがある。
後述するKong氏のキャラ相手の異常なダメージもこれの一種であるため、動画で使用する際にはきちんと確認しておこう。


Kong氏の制作キャラについて

ダメージ設定について

Kong氏のキャラはいずれも相手のLifeMaxに応じてダメージが変化する仕様がとられている。
が、LifeMaxしか監視していないため、水影氏制作の東方キャラと対戦させた場合、Kong氏のキャラの火力が異常なまでに上昇し、
水影氏のキャラがほんの数ヒットで即死するという事態が起こる。
これは水影氏のキャラがLife10000、Def10という特殊な仕様になっているため。
これを防止する方法はkong氏のキャラフォルダ内にある(〇〇キャラ名)_-2.cns を開き、
その中から『;Life』で検索してその直下にある
[State -2]
type = varset
trigger1 = !var(30)
trigger1 = numenemy > 1
var(30) = floor((enemy(0),LifeMax/(100)+enemy(1),LifeMax/(100)/2))

[State -2]
type = varset
trigger1 = !var(30)
trigger1 = numenemy < 2
var(30) = floor(enemy(0),LifeMax/(100))
という記述のうちvar(30)= の部分をいずれも
var(30) = 10
と書き換える。
こうすることで相手のLifemaxに左右されないダメージが算出される。

なお氏のキャラはMvC2仕様にもかかわらず コンボ補正というものは一切ない。
Var(10)がダメージにかかる係数であるので、気になる人はここにヒット数依存のコンボ補正をつけるといいだろう。
ただし多段技のダメージが補正なし前提の調整であるため、ここも弄らないと非常に安くなるので注意。

AIの空中要塞化自重方法

氏の制作キャラには標準でAIが搭載されているが、一部のキャラ(アイアンマンセンチネルベガMVCジェダ等)は
ライフが減ると空中高くに舞い上がり、そこから遠距離攻撃ばかり仕掛けてくるという戦法を取ってくる。
MvCでは立派な戦術の一つなのだが、MUGENにおいてはその高度の敵への何らかの攻撃法を持たないキャラでは手も足も出ず、
詰み状態になってしまうことが多い。そこで、自重させる方法を紹介する。

1.使っているAIのcmdファイルを開く
2.『[State -1, testing flight atk mode]』を検索
3.そのすぐ下の『type = ChangeState』を『type = null;ChangeState』に書き換える。

以上で完了。手順はたったこれだけなので、大会等に出したいけど強すぎて……という場合には是非試してみよう。
ちなみにこれをやってもハイジャンプ→急降下攻撃ばかりしてくるキャラもいるが、
空爆に比べればAIでも付け入る隙は大きいのであまり問題はないだろう。

サイバーボッツキャラの勝利自爆修正方法

kong氏作の『サイバーボッツ』キャラには、本来敗北時に起こる爆発&コックピット離脱演出が敗北時に起こらず、
逆に勝利時に起こる(しかも2回)という不具合がある。
それを制御する、全キャラ共通の記述が下記。
+ 嵩張るので格納・修正前
細かいところは省くが、大まかに言えば「試合終了時、時間切れ負け状態になっていなければ爆発する」ということなのだが、
その条件に勝利時が含まれているのが主な原因。
該当部分を下記のように修正すれば、敗北時にのみ爆発するようにすることが可能。
+ 嵩張るので格納・修正後

添付ファイル