MUGENにおいて結構軽視されているんじゃないかなぁと思う投げ抜け。
格ゲーをする上で非常に大切なことなのですが、
それなりに注意すべき点もあったりして意外に搭載されてないキャラも多いです。
そこでちょっとした投げ抜けのテンプレを作ってみました。
個人的には対人戦を意識したいならば投げ抜けは必須だと思います(`・ω・´)
少しでもこれで投げ抜け搭載キャラが増えたらいいなぁ…(ヽ´ω`)
ちなみに投げ抜けを搭載するとAI戦で抜けまくってしまう!
という危惧があるかもしれませんが、
CPUは食らい中recovery以外のコマンドを入力しないようなので、
投げ抜けコマンドにrecoveryを指定しなければCPUが抜けることはありません
(と思っていますが、自分が確認できなかっただけかもしれません…)。
※追記
CPUでも投げ抜けしてしまう条件がわかりました。
HitFall=1ならばCPUは同時押しボタンを連打するようです。
よってCPUの投げ抜け暴発を防ぎたい場合fall=1は指定しないようにするか、
もしくは投げ抜けできないタイミングになってからHitFallSetを行ってください。
続きを読む
2017年11月06日
2017年05月05日
常時AI起動をしながらトレモで操作可能にする
[State -3, AI起動/1]
type = LifeSet
value = 0
trigger1 = RoundState < 2 && !RoundsExisted
trigger1 = var(XX) := Y ;AI変数
[State -3, AI起動/2]
type = LifeSet
value = LifeMax
trigger1 = RoundState < 2 && !RoundsExisted
trigger1 = 1 || var(XX) := !Life*var(XX)
上記の記述を-3ステート辺りにコピペして、
var(XX)にはAI用の変数番号を、YにはAIレベルを入れてください。
たぶん既にやっている人はいると思うのですが、
恐らくあまり広まっていないかなーと思って記事にしました。
WatchモードによるAI対戦か、トレモでの確認くらいしか行うつもりが無ければ
このような記述が結構役に立つと思います。
もちろんMUGENには色んなキャラや記述がありますので、
これで正確に動かないなんてこともあり得るのでご注意ください。
あとAI起動が遅いことを前提にしてAIを組んでいるキャラとかだと
フライングすることがあったりします(^-^A;)
ちなみに変数を1つ消費しますが、上記の記述を応用すれば
トレモでAIを一切暴発させないようにすることも可能です。
一応変数を消費しないやり方もあるのですがあまりオススメはできません。
type = LifeSet
value = 0
trigger1 = RoundState < 2 && !RoundsExisted
trigger1 = var(XX) := Y ;AI変数
[State -3, AI起動/2]
type = LifeSet
value = LifeMax
trigger1 = RoundState < 2 && !RoundsExisted
trigger1 = 1 || var(XX) := !Life*var(XX)
上記の記述を-3ステート辺りにコピペして、
var(XX)にはAI用の変数番号を、YにはAIレベルを入れてください。
たぶん既にやっている人はいると思うのですが、
恐らくあまり広まっていないかなーと思って記事にしました。
WatchモードによるAI対戦か、トレモでの確認くらいしか行うつもりが無ければ
このような記述が結構役に立つと思います。
もちろんMUGENには色んなキャラや記述がありますので、
これで正確に動かないなんてこともあり得るのでご注意ください。
あとAI起動が遅いことを前提にしてAIを組んでいるキャラとかだと
フライングすることがあったりします(^-^A;)
ちなみに変数を1つ消費しますが、上記の記述を応用すれば
トレモでAIを一切暴発させないようにすることも可能です。
一応変数を消費しないやり方もあるのですがあまりオススメはできません。
2013年05月05日
IKEMENその2
もう1度今度は別の方とIKEMENのテストをしてみました。
今回はちゃんとポートを開いたので私もホストになることができて良かったです。
できればTCPとUDP両方を開いておいた方が良いと思いますが、
片方だけで良いかは未調査です。
その時に調べたのですが、現在でも環境は同一にしなければならないようです。
もし環境を別々にしていたら、通信自体はできるのですが、
それぞれにそれぞれの対戦キャラが選択されることになります。
例えば自分のキャラセレクトが
カンフーマンA、カンフーマンB、カンフーマンC
相手のキャラセレクトが
カンフーマンX、カンフーマンY、カンフーマンZ
になっているとすると、
自分からはカンフーマンAとカンフーマンCの対戦になっているはずが、
相手からはカンフーマンXとカンフーマンZの対戦に見えているわけです。
考えてみればこうしないと読み込みにかなり時間がかかりそうですね。
今回はちゃんとポートを開いたので私もホストになることができて良かったです。
できればTCPとUDP両方を開いておいた方が良いと思いますが、
片方だけで良いかは未調査です。
その時に調べたのですが、現在でも環境は同一にしなければならないようです。
もし環境を別々にしていたら、通信自体はできるのですが、
それぞれにそれぞれの対戦キャラが選択されることになります。
例えば自分のキャラセレクトが
カンフーマンA、カンフーマンB、カンフーマンC
相手のキャラセレクトが
カンフーマンX、カンフーマンY、カンフーマンZ
になっているとすると、
自分からはカンフーマンAとカンフーマンCの対戦になっているはずが、
相手からはカンフーマンXとカンフーマンZの対戦に見えているわけです。
考えてみればこうしないと読み込みにかなり時間がかかりそうですね。
2013年05月03日
I.K.E.M.E.N
IKEMENとは、MUGENクローンの1つで、ネット対戦ができることで知られたソフトです。
以前からその存在は知っていたのですが、非常にラグが大きいと
言われていたので今まで試してみたことがありませんでした。
しかし現在でも頻繁に更新されていることを知り、今ならもしかしてと思って
1人の方に協力していただいて通信テストをしてみることにしました
(それと某所で最近IKEMENの対戦募集があったので興味が再び出てきたのもあります)。
協力してくださった方にはこの場で感謝の言葉を
述べさせていただきます。ありがとうございました。
結論から言うと、現在のIKEMENはネット対戦に耐えうると思います。
協力してくださった方が非常に高速な回線である可能性や、テストに使用したキャラが
デフォルトのカンフーマンだったということもあるかもしれませんが、
今回のテスト時にはラグはほぼ無かったと言って良かったです。
今でも互いの環境を同一にしなければならないかは実は良く分かりませんが、
もし興味があったら試してみると面白いかもしれないですね。
注意点ですが環境同一化が必要なら転載が手っ取り早いですが、
転載禁止のキャラがいるのでそのことには気を配らなければならないと思います。
今回のテスト時に気付いた点を少しメモ書きしておきます。
・ネット対戦でホストになるにはポート解放+TCPである必要があるのかもしれません。
少なくともアカツキでホスト出来ていた私はホストになれませんでした。
・AngleDrawのvalueを指定すると異常なほど重くなります。
・playerヘルパーが5150ステートにいても相手が振り向くように感じます。
他の原因があるかもしれませんが、私の幾つかのキャラを戦わせると
相手の振り向きがおかしくなってしまいました。
以前からその存在は知っていたのですが、非常にラグが大きいと
言われていたので今まで試してみたことがありませんでした。
しかし現在でも頻繁に更新されていることを知り、今ならもしかしてと思って
1人の方に協力していただいて通信テストをしてみることにしました
(それと某所で最近IKEMENの対戦募集があったので興味が再び出てきたのもあります)。
協力してくださった方にはこの場で感謝の言葉を
述べさせていただきます。ありがとうございました。
結論から言うと、現在のIKEMENはネット対戦に耐えうると思います。
協力してくださった方が非常に高速な回線である可能性や、テストに使用したキャラが
デフォルトのカンフーマンだったということもあるかもしれませんが、
今回のテスト時にはラグはほぼ無かったと言って良かったです。
今でも互いの環境を同一にしなければならないかは実は良く分かりませんが、
もし興味があったら試してみると面白いかもしれないですね。
注意点ですが環境同一化が必要なら転載が手っ取り早いですが、
転載禁止のキャラがいるのでそのことには気を配らなければならないと思います。
今回のテスト時に気付いた点を少しメモ書きしておきます。
・ネット対戦でホストになるにはポート解放+TCPである必要があるのかもしれません。
少なくともアカツキでホスト出来ていた私はホストになれませんでした。
・AngleDrawのvalueを指定すると異常なほど重くなります。
・playerヘルパーが5150ステートにいても相手が振り向くように感じます。
他の原因があるかもしれませんが、私の幾つかのキャラを戦わせると
相手の振り向きがおかしくなってしまいました。
2013年04月23日
100000再生
ついに投稿した動画が100000再生に到達しました!!
見てくださった皆さんありがとうございます!ヽ(≧∀≦)ノ
マジンガのキャラ人気には驚かされますねー。
とある動画で紹介されて以降凄まじい伸びを記録してきましたが、
まさかここまで来るとは思っていませんでした。
MUGENキャラ作成タグでもここまで再生数が多いのはなかなか無いので嬉しいです。
2013年03月10日
pausetime
pausetimeを第1項と第2項を同じ値にすると攻撃側が先に動き始めます。
厳密に言うと攻撃側のヒットポーズが解けてから1F後に
攻撃を食らった側がヒットシェイクを終えて吹っ飛び始めます。
これがどうしようもないレベルで原作再現を難しくしてしまっていて、
自分と相手が動き始めるタイミングを一緒にしようとすると
ヒット硬直時間を1F短くしなければならず、そうするとノーキャンセルでは
問題無いようにできますがキャンセルする場合は当然硬直時間が1F短くなっているので
技が繋がりづらくなったりそもそも繋がらなくなってしまいます。
逆にpausetimeの値をどちらも同じにすると自分の方が先に動き始めるために、
自分と相手との距離関係がどうしても原作と異なってしまい、
特に空中コンボでは浮きがかなり変わって本来は繋がらないコンボが繋がったり、
逆に本来は繋がるコンボが繋がらなかったりしてしまいます。
この問題を解決する方法は無いのでしょうか?
※追記
新MUGENではこの問題が解決されているようです。
新MUGENを中心に見据えて調整することを視野に入れるべきでしょうか・・・?
旧MUGENキャラは新MUGENでも動かせますが逆はできませんしね。
厳密に言うと攻撃側のヒットポーズが解けてから1F後に
攻撃を食らった側がヒットシェイクを終えて吹っ飛び始めます。
これがどうしようもないレベルで原作再現を難しくしてしまっていて、
自分と相手が動き始めるタイミングを一緒にしようとすると
ヒット硬直時間を1F短くしなければならず、そうするとノーキャンセルでは
問題無いようにできますがキャンセルする場合は当然硬直時間が1F短くなっているので
技が繋がりづらくなったりそもそも繋がらなくなってしまいます。
逆にpausetimeの値をどちらも同じにすると自分の方が先に動き始めるために、
自分と相手との距離関係がどうしても原作と異なってしまい、
特に空中コンボでは浮きがかなり変わって本来は繋がらないコンボが繋がったり、
逆に本来は繋がるコンボが繋がらなかったりしてしまいます。
この問題を解決する方法は無いのでしょうか?
※追記
新MUGENではこの問題が解決されているようです。
新MUGENを中心に見据えて調整することを視野に入れるべきでしょうか・・・?
旧MUGENキャラは新MUGENでも動かせますが逆はできませんしね。
2013年03月07日
最近やってること
アカツキ電光戦記の仕様をいろいろ調査しています。
そのために60FPSの無圧縮aviでたくさんの技や動作等を録画しているので、
今までに録画したファイルの総容量は46GBまで膨れ上がっています。
これでも時間で言えば1時間にも満たないのですけどね・・・
それでもそれによって今まで分からなかったことやはっきりしなかったことを
かなり理解できるようになってきたので非常に勉強になります。
何故このような調査をしようと思ったのかというと、
もちろんプレイヤーとしてしっかりした知識を持っておきたいというのもありますが、
MUGENのアカツキをもっと原作っぽく改変してみようかなと考えてもいるからです。
もし自分で納得が行く出来で元のキャラの製作者さんの許可が下りたら
パッチ形式で公開するかもしれません。
納得いかないので公開しない可能性が結構あるのですがw
そのために60FPSの無圧縮aviでたくさんの技や動作等を録画しているので、
今までに録画したファイルの総容量は46GBまで膨れ上がっています。
これでも時間で言えば1時間にも満たないのですけどね・・・
それでもそれによって今まで分からなかったことやはっきりしなかったことを
かなり理解できるようになってきたので非常に勉強になります。
何故このような調査をしようと思ったのかというと、
もちろんプレイヤーとしてしっかりした知識を持っておきたいというのもありますが、
MUGENのアカツキをもっと原作っぽく改変してみようかなと考えてもいるからです。
もし自分で納得が行く出来で元のキャラの製作者さんの許可が下りたら
パッチ形式で公開するかもしれません。
納得いかないので公開しない可能性が結構あるのですがw
2013年02月26日
先行入力
他の人が以前導入していたのを見て私も導入したくなりましたので挑戦。
やり方はいろいろ考えましたが結局網羅的に行うことしかできず残念です。
他の方はどうしているのでしょうか?
もしかしたら非常に効率の良いやり方をしている方がいらっしゃるかもしれませんね。
もしそうであれば教えてくださると非常に参考になります。
私のやり方はコマンドが入力されたらヘルパーにフラグをセットして、
コマンドを持続させる時間を別の変数に保存しておいて
それを毎秒減らして0以上だった時に本体が行動可能だったら技発動という感じです。
なので各コマンドごとにビット1つと変数1つを消費しているわけですので
私としてはもっと効率の良い方法があるのではないかと色々考えてみましたが
残念ながら思いつきませんでした。変数代入も大量に行っているので良くないです。
続きに実際の記述を書いておきます。興味が無い人もいると思うので続きから。
続きを読む
やり方はいろいろ考えましたが結局網羅的に行うことしかできず残念です。
他の方はどうしているのでしょうか?
もしかしたら非常に効率の良いやり方をしている方がいらっしゃるかもしれませんね。
もしそうであれば教えてくださると非常に参考になります。
私のやり方はコマンドが入力されたらヘルパーにフラグをセットして、
コマンドを持続させる時間を別の変数に保存しておいて
それを毎秒減らして0以上だった時に本体が行動可能だったら技発動という感じです。
なので各コマンドごとにビット1つと変数1つを消費しているわけですので
私としてはもっと効率の良い方法があるのではないかと色々考えてみましたが
残念ながら思いつきませんでした。変数代入も大量に行っているので良くないです。
続きに実際の記述を書いておきます。興味が無い人もいると思うので続きから。
続きを読む


