MUGENメモ　（　フォント環境：ＭＳ ゴシック　標準　サイズ10　） 　※旧メモ ｂｙＡＤＩ ●魅せ　に関してのメモ 　１．相応のリスクがある行動を成功させる。 　＞ロマン技と呼ばれる技など。リスクの大きい技が無いとどうしようもない。 　＞ゲージ技には、ゲージ消費というリスクがある。 　＞挑発はハイリスク・ノーリターンが基本。ただし地味。 　２．絶え間なく流れる攻防。 　＞どちらか一方的のやられ続ける展開が無いこと。 　＞『攻防を繰り広げる』ようなキャラでないと難しい。 　＞コンボの長いキャラは、適度な長さに切るなども考慮。 　＞睨み合いは途中途中にあってもいいが、膠着状態が続くのは微妙。 　２−１．攻撃に対して回避から反撃。 　＞単なる回避ではなく、回避から確定の攻撃をするなど。 　＞ただし、無敵回避を多用するのは、相手を選ぶことに。 　２−２．攻撃に対してカウンター。 　＞相手が攻撃してくる前提以外は１に同じ。 　＞当身も同様。ローリスク・ハイリターンは微妙。 　３．かっこいいキャラ。 　＞エフェクトが派手だったりすれば、それだけでも映えはする。 　＞地味なキャラの場合、他の部分でがんばらないといけない。 23:57 2009/09/07　最後尾 21:49 2009/09/06　追記 21:32 2009/09/05　ちょいちょい。魅せに関してメモ 21:04 2009/08/27　メモ 18:57 2009/08/19　対象の。 23:48 2009/08/13 ・・・・・ 22:07 2009/07/29　最初 　一応纏めてはいるけど、かなり雑多なメモ。 　口調がやけに偉そう。 　私はＡＩを１キャラしか作ってないので、 　　偉そうな口たたける人間じゃないんですけどね。 　しかもその１キャラだって簡易ＡＩに色々くっつけただけのようなものだし。 ● ※　Var(AILv)をレベル設定数値の例として用いていますが、 ※　　Varの()は0から59の数値を入れるものです。 ※　Var(ran)やVar(xx)も同様。 ※　AIフラグとレベルを統一しているタイプもあれば、 ※　　AIフラグとレベル設定を別々のVarにしているAIもある。 ※　Ｗｉｎ版であることを前提にしている。 ●ＡＩＬｖ論　序 　昨今、ＡＩＬｖ設定を導入するＡＩは多い。いわゆるレベル制ＡＩだ。 　強さを調整でき、柔軟な利用が可能になるという点はやはり大きい。 　そのＡＩＬｖ設定に関しての、私の考えをここに記す。 　ただし、あくまでも私の考えであって、私の考えでしかないことを念頭においてほしい。 　また、ＡＩＬｖの話だけでなく、後の方にはＡＩそのものの話も行う。 　ちなみに、ＡＩの作成方法ではない。 ●ＡＩＬｖ論　ＡＩＬｖの意義 　■ 　より多用な使い方を可能にするため。 　その為に動作や反応など、強さを調整するものである。 　設定によって全体的な強さが上下しさえすれば、 　　変化が少なかろうがＡＩＬｖと呼ぶことはできる。 　ただしいくらか調整が可能であることが望ましい。 ●●● ●ＡＩＬｖ論　２種類の条件 　■　大別 　レベル制ＡＩのＡＩＬｖ用の記述は、主に２の種類に分けられる。 　動作を変化させる難易度方式と、確率を変動させるＬｖ数値方式。 　ここでは利便上、呼称に難易度方式に難易度名称を、 　　Ｌｖ数値方式にＬｖ数値そのものを用いているが、 　　難易度方式で名称を用いないＡＩなどもある。 　　■　難易度設定方式　■　（動作変動式） var(AILv) = 1,イージー var(AILv) = 2,ノーマル var(AILv) = 3,ハード var(AILv) = 4,ベリーハード 　　という設定に決めておき、 Trigger*** = var(AILv)=1 ;イージー Trigger*** = var(AILv)=2 ;ノーマル Trigger*** = var(AILv)=3 ;ハード Trigger*** = var(AILv)=4 ;ベリーハード Trigger*** = var(AILv)=[2,3] ;ノーマル〜ハード 　　と言った条件を用いて、行動パターンそのものを変化させるもの。 　制作者によっては、呼び出すＡＩファイルを変えることで 　　難易度を変えるタイプもあるが、それもこちらに近しいものと言える。 　○主な利点 　　『難易度イメージが分かりやすい』（名称を利用している場合） 　　　　＞「イージー」で弱いんだ、「ベリーハード」で凄い強いのね、と分かる。 　　『動作パターンを細かく変えやすい』 　　　　＞イージーなら当たらない攻撃を振ったり、など。 　○主な欠点 　　『段階が多いほど、行動パターンを考えることが大変』 　　　　＞流用は可能だが、複数人分作るような感じで加減もしなければいけない 　　『これだけでは細かいＬｖ設定ができない』 　　　　＞大雑把な設定しかできず、細かい調整ができない、ということ。 　　■　Ｌｖ数値設定方式　■　（確率変動式） 　代表例としては１〜１０の間に設定すると決めておき、 Trigger*** = Random <= var(AILv)*100 　　という条件を用いて、行動の割合を変化させるもの。 　もちろん制作者によっては、調整を行い、割合が異なる場合もあり、 　　レベル数値そのものも、１０段階から９９９９９９段階まである。 　○主な利点 　　『テンプレがあれば簡単に導入できる』 　　　　＞AILv用Varを作り、動作に　TriggerAll=Random<=var(AILv)*100　などを追加するだけでもよい。 　　『細かいＬｖ設定が段階分可能』 　　　　＞微妙な調整ができればＡＩ戦などで強さを拮抗させたりすることもできるため。 　○主な欠点 　　『レベルの上下が小さいと明確な差が出ない』 　　　　＞上下の調整設定が僅かである場合は、特に。 　　『これだけでは統一された動作しかできない』 　　　　＞動作はほぼ一緒である為、何が違うの？　という程度しか違わないことも。 　■　ただ 　使われている条件式が２つ分けられるだけで、ＡＩによっては複合しているものもあり、 　　ＡＩＬｖとは別に特殊ガードの割合を数値設定方式にしている場合もあるし、 　　Ｌｖ以外の設定スイッチを入れることで、特定の動作を開放する場合もある。 　ＡＩＬｖを　[1,3] [4,6] [7,9] 10　などの区切りで難易度方式にもする事は可能。 　また制作者によっては、Ｌｖ数値方式を基本としつつ、Ｌｖ１１以上なら、 　　難易度方式と同様の条件を用いて異なる動作をさせることなどもある。 （　１〜１０を対人用、１１を対ＡＩ用、というような分け方。　） 　その他基本的な記述以外にも、Ｌｖ用記述を用いている場合も。 　■　違いを簡潔に纏めると。 　Var(AILv)を用いる条件式に用いる記号が、 　　「　= > <　」だけなら「難易度方式」 　　それに加えて「　* - + /　」なども使うなら「Ｌｖ数値方式」 　レベルの条件に等号、不等号だけであるか、 　　数式を用いているか、という違いであり、 　　繰り返すが、複合している場合も多い。 ●●● ●ＡＩＬｖ論　Random 　おさらい。 　■ 　Ｌｖ数値方式では、ＡＩＬｖ用記述そのものに組み込まれ、 　　難易度方式でも、同様の条件で複数の技を使わせるために使われるRandom。 　このRandomの性質を説明すると １．フレームごとに、0〜999の範囲の乱数を返す。 　（　約６０フレーム＝１秒　６Ｆ＝０．１秒　1F=約0.016666...秒　） ２．同じ箇所にRandomを複数使っても、別々に乱数を返す。 　（　Random!=Randomの条件式を用いれば、確認できる。　） 　と言った性質がある。 （　あと、０に近い数値が出やすいらしい。あくまでらしい、だが。　） 　■ 　次に条件の　Random < 100　は0~99の間、１０％の確率を意味する。 　しかし付け加えると「毎フレーム１０％」の確率である。 　1秒60Fが基本である為、毎秒60回、１０％の確率を繰り返すことになり、 　　計算上60Fまでに発動する確率は約99.82%となる。 （　※　ジャスト60F目に発動する確率は、0.02%　万に２つ程度である　※　） 　事実上１秒以内はほぼ確実に行動し、計算上約0.12秒でも５０％、 　　２秒以上行動しない確率は約0.00032%とまずありえない数値である。 　ちなみにＬｖ数値方式に書いた例の条件のＬｖ１も　Random <= 1*100　である。 　　コンボ動作なら0.1秒程度しか猶予がないにしても、5Fで40%はある計算だ。 　Ｌｖ１でも、１秒以内に動く＋コンボの確率が多ければ40%以上と、 　　難易度方式からすれば、イージーというよりノーマルかもしれない。 　■ 　Random < xxx　といった記述だけでＬｖの上下による差を顕著にしたいのなら、 　Random < var(AILv)*var(AILv)*10　といった記述を使えばいいかな。 　Lv10なら100%、Lv5なら25%、Lv1なら1%になる。 　1%でも1秒で40%、2秒で70%に達する為、行動しないわけではない。 　■　Ｌｖの話ではないが。 　複数の行動を設定し、行動自体の確率を一定にしたい時、 　　例えば３つ動作をつけ、行動全体の確率を90%にしたい場合は、 　　単純にRandomを複数使うとなると、面倒な計算が必要になる。 　例えば上から　Random < 300　Random < 600　Random < 900　と並べても、 　　それぞれ　30%　42%　25.2%　とややこしくなり、行動の確率も97.2%。 　（　42%は30%を引いた残り70%の60%　25.2%は72%を引いた残り28%の90%　） 　Randomを代入したVarを使えば、 　行動確率を90%とし、３つの分岐で確率を均等にしたい場合、 　　Var(ran)<300 Var(ran)<600 Var(ran)<900　と並べて行動90%各30%にできる。 　ちなみに、Ｌｖ数値方式の行動確率に割り振りを加えると、10レベル上限なら 　　Var(ran)Var(AILv)*100 　　レベルが低いほど確率を高くする数式。 　　基本と併用し、効率の悪い技を高レベルで封印させられる。 　　■　Time　EnemyNear,Time　+Random　■ 　Time>65-Var(AILv)*6 　　Lv10なら6,Time、Lv1なら60,Timeの遅延をさせたり。 　Var(AILv)*Time*EnemyNear,Time >= 1440 　　ガードなどの反応の記述として、 　　どちらかが長いTime数であればガードできるようにする、など。 （　AILv10ならTimeが　12:12　9:16　6:24　4:36　3:48　2:72　1:144　の時。　） 　Random<(Floor(EnemyNear,Time/0.6)*Var(AILv)) 　　相手の6,Timeを10とし、Lv10なら60,Timeで100%になる反応用の確率。 　　■　P2BodyDist X　P2BodyDist Y　+Random　■ 　P2BodyDist X =[xx,xx+(Random%(20-Var(AILv)*2))] 　P2BodyDist Y =[yy-(Random%(20-Var(AILv)*2)),yy] 　　対象とする範囲にブレを加え、当たらない範囲でも打つ可能性を与える。 （　これによって当たらない距離でも技を繰り出す、など。　） 　P2BodyDist X =[xx,xx+Var(AILv)*10] 　　反応する範囲を広げる、ということにもつかえる。 　　■　EnemyNear,Vel X　+Random　■ 　EnemyNear,Vel X >= Random%11-Var(AILv) 　EnemyNear,Vel X < -10+Var(AILv) 　　少し無理やりだが、相手の接近速度が遅い場合、レベルが低いほど反応を鈍くしたり、 　　レベルが低ければ相手が下がっている状態にも反応させる、などの記述も。 　　■　BackEdgeBodyDist　■ 　BackEdgeBodyDist < Var(AILv)*5 　　など、後ろが壁である場合の反応距離をより広くさせる、というのも。 　　■　その他　Varadd　■ 　特殊な反応処理の例としては、 　　特定条件下である場合、反応用のVarへAILv分加算していき、 　　反応動作側に、反応用Varの数値が一定以上であるという条件を付加させ、 　　特定条件下から脱した時に、反応用Varをリセットするという 　反応方式を用いているＡＩもある。 　と言うより、私が用いている。 　■ 　その他のＬｖ数値方式 　　■　高性能技確率設定　■ 　高性能技封印スイッチを、確率変動式にしただけのもの。 　そこで説明したように、　Random<=Var(xx)*10　といった記述を行えばいい。 　先では　Var(xx)*10<=Random　と記述したがこれは 　　封印を前提としている為、数値を高くするほど自重する。 　数値が高いほど使用させる場合には、 　　Ｌｖ数値方式の基本的な記述の応用で構わない。 　　■　Ｌｖ変動式ＡＩについて　■　※　ＡＩ論 　Ｌｖ数値方式は多段階にすることが簡単で、 　　例で出したようにＡＩＬｖを変動させることも容易の為、こちらに記載。 　処理の話だが、ラウンドをまたいでも変動したＬｖを維持する場合、 　　PersistIndexらの数値を引き下げることになるが、 　　下げた場合、最初にRoundsExisted=0でVarをリセットしてやること。 　増加式で規定以上の数値になった場合、 　　規定内へ戻るようにし、上がり過ぎないようにすること。 　色々と注意する点も多い為、なれていなければ無理に挑戦するものではない。 　これは難易度方式でも使えないことはない手法だが、 　　Lifeの量によって動作を変更させる、というＡＩも多々ある。 　簡単に言えば「試合の始めは遊び、終盤に本気を出す」ような状態。 　Ｌｖ数値方式であれば、ライフの残りに応じて 　　Ｌｖを上げていくと言うシステムもつけるのは簡単だが、 　いわゆるそういう性格のキャラでもなければ似合わないし、 　　手加減自体を好かない方もいる為、気をつけておくこと。 ●●● 　ここからただのＡＩ論 ●●● ●ただのＡＩ論　0,Time 0F反応 　私の信条　と　処理の話。 　■　!Time 　プログラムは、指定された条件のみを処理する。 　指定されていない条件を考慮することはない。 　遅延の条件が組まれていなければ、 　　一切遅延することなく、遠慮無しに行動するのだ。 　■　１Ｆ中に起こっている処理。 　処理は１Ｐ→２Ｐという順番に行われている。 　これがどういう意味を持つか、説明すると、 　　「２Ｐはそのフレーム中の１Ｐの状況が分かる」ということである。 　「２Ｐがそのフレーム中の１Ｐの状況が分かる」という事が、 　　どういう意味かを説明すると、「0,Time反応・同時始動」が可能であるという事。 　１Ｐは２Ｐの状況を「前のフレーム」の分しか知りえない。 　その為どんなに反応を早めようとも「1,Time反応・1F始動」が限度になる。 　もちろん、その差がどの程度試合に影響を及ぼすかはキャラの性能に寄るが、 　　当身だけをとっても２Ｐなら「攻撃Ｆ＝当身Ｆ→反応可能」という図式で、 　　３Ｆの小足を３Ｆの当身で返せるというわけだ。１Ｐは攻撃Ｆに＋１Ｆ必要。 　と、比べてみるものの、 　　0,Time反応・1,Time反応は、どちらもいわゆる超反応の部類。 　また、0,Time行動自体は、相手の状態にあまり左右されない為、 　　動作が終わった直後にまた次の動作を行う、ということが可能である。 　■　反応遅延　※私の信条入ってます。 　超反応を封印するにあたって、どの程度反応速度を落とすべきなのか。 　まず人間の「限界反応速度」は、0.1秒といわれている。 　　0.1秒＝6Fである為、最短遅延の基本値はそのくらいが丁度良いかもしれない。 　ただし、Timeはあくまで自身の時間基準であり、 　　0.1秒で反応の準備をすることが出来るか、と言えば疑問符。あくまで最短。 　記述としては　Time > 65-Var(AILV)*6　くらいが、 　　低レベルの場合まず反応しなくなって、丁度いいと思う。 　人間らしさを出す場合には、小さい遅延＋当たらない範囲でぶっ放し、など。 　■　要約 　AIにおいて超反応は簡単です。 　と言うより、特別に手を加えたりしなければ、 　　超反応自体が、デフォルトです。それがプログラムというものです。 　ただし、「的確に」という面では制作者の力量を問われますが。 　　 ●●● ●ただのＡＩ論　ガード・防御系統 　ややこしいことは書かない。 　■　ガードに用いる条件式の基本 　ＡＩの制作者によって異なりはするが、基本はInGuardDistである。 　この数値は、相手側で設定されているAttack.Distという 　　「ガード可能距離の内側にいる」条件である。 　またEnemyNear,MoveType=A(P2MoveType)も 　　「特殊条件」でガードの条件に用いられている場合もあり、 　その他特殊防御システムの１つとして、弾幕アクション出身のキャラには、 　　「ダッシュ中など飛び道具に対してのみ無敵状態」となれるものもいるが、 　　その動作を活かすために、InGuardDist&&EnemyNear,MoveType!=Aというようなものも。 （　NumProjは最近あまり使われていない為、機能しにくいかと。　） 　基本はInGuardDistとEnemyNear,MoveTypeであるが、 　　EnemyNear,Nameなどを用いて、対応が困難である特殊な中・下段や 　　ガード不可の技を判別することで、対処させる場合もなくはない。 　■　ガード内部処理 CnsファイルのＡＩ仕様化 　ＡＩが判断を出来るようにCnsファイルを改変するもの。 　これを行うことによって、的確な判断をさせられるようにする。 　そのものに条件記述を書く方法や、 　　ガード判断用のVarを用いて、その数値に従わせる記述方法などがある。 　Varを用いれば、どんなときにどんなガードをするかを決められ、 　　Cnsファイル内にはCommandにVarを代用する形の簡単な記述にできる 　　が、Varの制御をしっかりと自分で作らなければならない点、難しいが。 　　□　Var使用のメリット 　ガードの制御をVarSetにし、 　　一箇所でコントロールが可能である、という点、かな？ 　特殊な動作をさせる場合は特に重宝するが、必要なければ面倒なだけである。 　■　ガード待機中のCtrl 　ガードステートをＡＩ仕様化しても、問題は残っている。 　面倒なことは、一度ガードステートに飛ばしても、 　　待機中はCtrlを有しているという問題。（　キャラによってはないかも　） 　ガードステート内を維持させるようにしても、 　　Ctrlがある以上、ガードステートへ逐一飛ばしてやらないと、 　　行動を起こす可能性がある、という事である。 　といっても、解決方法としては 　　単純にガードステートへ　StateNo=[120,159]　で飛ばしたり、、 　　ガード用Varを用いて、ガードする状態である場合ガードするのでもいい。 　■　ＡＩガードの補足 　InGuardDistでのガードはAttack.Distを必要とするが、 　　Attack.Distはキャラの中心から前面にしか出ない為、 　　めくりのような攻撃や、後ろ側への攻撃はInGuardDistで対応できない。 　その補助にHelperなどを使う場合もあるが、簡易的な記述であれば、 EnemyNear,MoveType=A && (p2Dist X< 0 ) && EnemyNear,facing!=facing;後ろ・対めくり系攻撃（向きが違う限定） EnemyNear,MoveType=A && (p2Dist X> 0 ) && EnemyNear,facing=facing ;前側・対後ろへの攻撃（向きが同じ限定） 　というような条件で、一応いくらかガードできなくはない。 　ただそれもMovetype=Aに頼っている為、飛び道具に対しては無力である。その場合Helperが必要。 　加えて、後者は攻撃が後ろへ至らない場合にも反応してしまい、攻撃のチャンスを失うことも。 （　あと、後ろ・対めくり系はp2Dist X=[-30,-1]程度に抑えておくほうがいいか。感じ的に。　） 　■　防御機構 　　■　反撃・反応動作　■ 　防御システムとして、Varaddタイプの反応動作を私は用いている。 　通常動作までTimeによる遅延を行っているため、 　　反撃などを別系統にし、かつ直後に反応しないようする為である。 　簡単に説明すると、 　　緩慢な攻撃動作に対しては　＞後ろダッシュなどで回避動作を取り、 　　相手から攻撃を受けた後は　＞切り返しの為に0,Timeで攻撃を行い 　　攻撃をしばらくガードしているなら　＞ガードキャンセルを試み、 　　相手からこっぴどく攻撃を受けた後は　＞超必殺技で切り返しを行う。 　と言った分け方を、同一システムで行えるようにしているもの。 　ただし動作を行う為、ガードがゆるくなる、という欠点もあるし、 　　反撃が高確率である場合、暴れ狩りに引っかかりやすくなるという欠点も。 　何もしないわけではないが、それが仇になる可能性もある。 　ちなみに、ＡＩガードの補足で書いた攻撃のチャンスを失う危険性に対して、 　　このシステムなら攻撃もし得るため、ガードのみで対応するということが少なくなる。 　　■　グレイズ　■ 　InGuardDist&&EnemyNear,MoveType!=A　は十中八九、飛び道具であると思っていいはず。 　と言うより、通常は飛び道具系統でしかありえない状態のはず。 　である為、対飛び道具の反応として用いている。 　グレイズ機能の無いキャラである場合は、 　　P2Nameで射撃がグレイズ可能な相手を指定、確認し、 　　そうしたキャラに対してのみダッシュさせるなどの方法も。 　あるいは、飛び道具系をより確実にガードさせたい場合、など。 ●●● ●ただのＡＩ論　かなり個人的な信条。 （魅せに関して、一番上に追記メモ） 　■　魅せること、楽しませること 　見ていて面白いこと、戦っていて面白いことの為に。 　まず第一に最低限の強さは必要になる。 　AIとしての強さばかりでなく、キャラの強さも含め、 　　相手と互角の強さであってこそ、良い試合ができるわけだ。 　見ていて面白いこと、の一番単純なものは「ロマン技」だろう。 　ロマン技以外では、止めに超必殺技を積極的に用いるなど、 　　気持ちよく止めをさす、というような状況が好まれやすい、か。 　ただ、戦っていて面白いこと、というのは分からないので記載しない。 　理不尽な強さであっても、それに対抗しうるキャラ性能と腕前で互角に戦え、 　　それを面白いと思う人もいるだろうし、それでもつまらないと言う人もいるだろう。 　両方と言えなくもないことだが、制作者によっては、 　　パワーゲージ量やライフ量で、有利であると判断した場合、動作が鈍くなったり、 　　最初は本気を出さず、中盤から動きが良くなるようなＡＩであることもある。 （　前者の代表例は電池切れになるドラゴンクロウ、後者の代表例はmisobon_ism氏のＤＩＯのＡＩ。 　　ちなみにドラクロ電池切れの条件はゲージ３本以上、ライフ自分600以上相手300以下の時。　） 　良い試合を作るために、ＡＩＬｖというのも無関係ではない。 　特にＡＩ限定の大会などは、数多のキャラの強さをいくらか揃える必要がある以上、 　　単一の強さしかないよりも、強さの調整が可能なキャラのほうが起用しやすい。 　魅せる点においての禁忌は、永久。威力が低く、長く続く場合は特に。 　　永久でなくとも同じような状態が長く続くことは避けるべきである。 　それならば専用ゲージを溜めることで使えるとか、１０ゲージ技だとか、 　　一撃必殺奥義の方が、見ている分にはスカッとする。 　また禁忌ではないにしろ、ワンパターンもあまり良いものではなし、 　　ガン逃げタイプのＡＩも卑怯であると思われやすいだろう。 　作るときにも、また使うときにも注意すべきである。 　ちなみに攻撃のバリエーションが少ない、というのもワンパターンの一種である。 　　特に華の無い動きである場合は、それがつまらない、と思う人もいる。 　■ＡＩと人間 　人とＡＩとの決定的な違い、それは理解の人間と反応のＡＩである。 　例えば、自キャラの長所短所を知り、どう生かすべきかを理解すること、 　　相手の行動パターンを確認、勝つための方法を理解することは、人間の武器である。 　前者はＡＩに組み込むことはできるが、後者を組み込む事は「対○○用」となる為、 　　ＡＩとして「良い」のかどうか、制作者でも好き嫌いの分かれるだろう手法である。 （　一部のＡＩ殺しとなる技に対して反応をさせる、という程度であれば使われているが。　） 　それに、後者を組み込んだとしても組み込んだ特定の相手にしか対応できない事、 　　そして、その相手がStateNoなどの仕様を変更した際対応できなくなる、など欠点があり、 　なにより、好く見られない。 　学習ＡＩというものも一応あるが、持ちうる知識はその試合中に経験したことだけに限られ、 　　長期的な知識を持つ人間には及び得ない。ぶっつけ本番でもなければ、だが。 　ＡＩはＡＩの特権を有している。プログラムであるＡＩであるからこそ、可能なことを。 　処理を毎F把握し、その状況に対して的確な動作を行うことが可能であるということ。 　0,Timeでの超反応がその代表例であるし、完璧な目押しが可能だということ。 　攻撃範囲へ飛び込んでくる相手に対し、的確な迎撃も可能であるし、 　　相手の攻撃に対し、当身・回避などで的確に反応をすることも可能。 　強力なキャラクターの性能を最大限引き出しうるものこそ、ＡＩである。 　ただし、そこにあるものは反応だけであり、状況を判断し、 　　それに対する答えを返すだけのプログラムに過ぎない。 　そして、それを作り出すのは人である。 　人は理解するが反応に限界があり、 　　ＡＩは最速の反応をできるが、理解することはない。 　またＡＩの反応の精細さは、人の手に委ねられている。 　　□ＡＩにおけるコマンド　（※個人的な愚痴） 　かなり個人的な信条と、愚痴になってしまうのだが。 　ＡＩはコマンドが不要である特権を持つ。 　　タメコマンドのタメ技も不要であり、ＡＩ特権とも言われる。 　ただ、タメ状態を再現することは不可能ではない。 　ＡＩ用タメ動作ステートを作って、Ctrlを奪い、そこでタメの時と同じ状態にし、 　　一定時間その状態にとどまらせてからから技を出すという形なら可能ではある。 　またそのＡＩ用ステートからタメ技以外の動作もさせるように、 　　調整しておけば柔軟な対応をさせる事も一応できる。 （条件に(Ctrl||StateNo=xxx)や、タメステート内にChangeStateを設けてもいい。） 　まあタメ動作にこだわりがなければ必要ないが。 　ただＣＰＵらしいＡＩでなく、人間らしいＡＩを作るならその方が好ましい、と私は思う。 　もっと言えば、立ち状態から波動昇竜などのコマンドを入力する際に、 　　一瞬しゃがむ動作をする状態となるが、そこまで再現する需要はあるのだろうか。 　もちろん、技を振るつもりも無くしゃがむ動作をすることで、 　　しゃがみでフェイントをかけることができるようには、なるが。 　■ただの対人ＡＩ論　※極めて私個人の思いと考え。 　私は対人用ＡＩを、ただの手加減のなされたＡＩというのには抵抗を感じる。 　どちらかと言うと、私は対ＡＩというものを【ＡＩ殺し】と考え、 　　対人というものを【対人プレイヤー殺し】とも考えている。 　例えば【学習ＡＩ殺し】のキャラを作ることは不可能でない。 　技の分類にVarを用いることにより、同一のStateNoで多種の技を使う、などだ。 　この場合、対策にはStateNoの他に使用されているVarも必要となり、 　　出来うることは、EnemyNear,Var(xx)などを用いた直の対策である。 （　StateNoを頼りにしないタイプや、目で確認する人間には関係ないが。 　　ただ機能として相手の技の一種類をつぶしたりできるキャラが苦手になる。　） 　キャラに寄った話ではあるが 　対人プレイヤー殺しの代表的なものを上げれば、「間合いが分かりにくい攻撃」 　　「視認が困難・不可能になるもの」や「モーションの短いワープ」など。 　対ＡＩ殺しの代表例はシステム上の「ガード不能攻撃」や「レバガチャ技」、 　　ＡＩ上の「多人数キャラ」や「プレイヤー判定ヘルパー」などがある。 （　ＡＩばかりではないが。　） 　言ってしまえば、対人プレイヤー殺しの無い対人ＡＩは、 　　ただ単純に「対人可能ＡＩ」だとか「対人考慮ＡＩ」だとかであって、 　　超反応するＡＩも単純に「超反応ＡＩ」ではないだろうか、と。 　　▽砕いて言うと。 　いや別に対人ＡＩだとか、対ＡＩ用だとかでいいんだけど、 　　対○○用と冠するのならば、「Anti ***」のように、 　　それに対する武器を有しているべきではないだろうか、と思うのですよ。 　殺しに行かなくとも、そうしたことを考慮して作るべきである、という話です。 　例えば対人の場合、ＡＩは設定された反応しかできない。 　反応しかしないと言うのは「読みやすく・騙しやすい」ということである為、 　　そうしたパターンじみた動作をいくらか緩和すべきであると、私は考える。 　とは言うものの、具体的な案は無い。結局キャラの性能によるものだし。 　　「読み・騙し」ができない場合なら、性能のゴリ押しで勝てはする。 　一応私の取り入れている対策は「不確定動作」と呼んでいるシステム（？）。 　低確率で基本的な動作でない動作を行わせる事で、パターンを緩和させる役目がある。 　ちなみにそれと同じように「特殊反応」というのも入れ、 　　これまた低確率で基本的な反応でない動作を行わせ、パターンを緩和している。 　これらがあれば「パターンに陥る」ことがあっても、脱することが出来たり、できなかったりする。 　導入方法は簡単で、それぞれに大きめに取った範囲の条件に低確率の動作をさせるだけ。 　　特殊反応も反応動作に低確率でしないよう設定し、別の動作をさせるようにすればいい。 　もちろんＡＩそのものの反応を読みづらく、騙しにくいように調整するのもありだが、 　　少なくとも私には難しく、「不確定動作」などを用いている。 　「不確定動作」は「不安定動作」でもある為、安定しにくくなる欠点もある為、 　　その「簡易対人用システム」より、ＡＩそのものを調整することを私はお勧めします。 　ちなみに私のＡＩは「不確定動作」でTime条件を使わっていない為、 　　ＡＩＬｖを低くすると不確定動作が目立つようになり、 　　不確定動作をＯＦＦにすることでもっと弱くなる状態、 　不確定動作自体が、簡易ＡＩとして機能しているらしい。 　対人ＡＩばかりの話ではないが、 　　単一の攻撃やガードをだけしかしない場合は、特にパターンとなりやすく、 　　対人なら慣れさえすれば、その隙を突くことも容易となるような、「弱点」である。 　下段ガードしかしない、などはその極端な例で、 　　中段攻撃だけでハメ殺すことすら可能であったりする。 　■強さ 　ＡＩを作るのは人である。 　例えば、超コンボキャラであっても、 　　作る人間が「コンボを組めない」ようでは性能を引き出しきることはできない。 　１Ｆ当身のキャラであっても、使う当身の判断をいかにさせるかを 　　限られた情報から引き出すことができなければ、その当身は飾りになる。 　少なくとも、そのキャラクターが何を出来るかを知っていること、 　　そして、どのように反応させればいいかを知っておくことは大事だが、 　　何よりも格闘ゲームでの「勝つ形・負ける形」を知っておくことが重要。 　「ガード」から「立ち回り」、「技の使いどころ」など、 　　どうして負け、どうして勝つのかを分かってないと、行き詰る。 （　私なりの言い方をすれば「ゲームを制す為の意識を持つこと」が大事。　） ＞前後の隙 　例えば５Ｆの近距離攻撃と１０Ｆの中距離まで届く攻撃を持っているキャラ同士で、 　　「近距離で５Ｆ攻撃をする方」と「近距離でも１０Ｆ攻撃をする方」が戦ったら、 　　確実に近距離攻撃を食らわせていく前者の方が、強い。 　攻撃後の隙の少ない攻撃と、攻撃後の隙の大きい攻撃を割り振る際、 　　「確定状況でなくとも、攻撃後の隙の大きい攻撃をする方」と 　　「確定状況でなければ、攻撃後の隙の大きい攻撃をしない方」とでは、 　　無闇な隙を見せない前者の方が、有利に試合を進められる。 　隙の有無を考えて技を使わせることで、 　　改めていうほどの事でもないような、「格闘ゲームの基本」です。 　ただ「開始に隙のある攻撃」はイメージしやすいことですが、 　　「終了に隙のある攻撃」はイメージしにくく、それを知らないと、 　昔の私みたく、ガードで確定反撃の取られる攻撃を無闇に使わせたりして、 　　ガードの固い相手に勝てなくなる、なんてこともありえます。 　（　しかも、なぜ負けるかを自覚できない。　） 　望ましい方法としては、自身が必要な基本を知り、実際に使って、 　　何ができ、何が不利になり、何が使えるのかを知っておくこと。 　できない場合は、まず先ほど言った「隙」をよく確認しておく事。 　「発生までのフレーム数」と「Ctrlが戻るまでのフレーム数」 　　空中攻撃の最中に着地をした場合に、Ctrlがすぐ戻るものなども別途記録。 ＞ガード・反撃 　また「隙」とは異なることだが、「ガードを最優先にしているキャラ」と 　　「ガード不能技を持つキャラ」や「中段下段技が豊富なキャラ」とでは、 　　明らかにガードを優先するキャラの方に不利がついてしまう。 　もっと言えば「防御＝ガード」ではなく「防御＝ガード＋攻撃」であって、 　　重要なのはガードの精確さでなく、ガードと反撃の判断である。 　もちろん、反撃に適した技が少ないのであれば、ガードを固くすべきだが、 　　攻撃の方をよく調整しておかないと、同ＡＩ同士で戦いが無駄に長引く。 　と例であげたように、ＡＩに限った話ではないが、 　　「前後の隙」と「ガード・反撃」を考えるだけでも、強さは大分違います。 　そこに加えることがあるとするなら「判定の強さ」と「立ち回り」かな。 　ただ勿論これはキャラの癖によって比重が異なる。 　ＡＩで、特に大きい差を生み出す箇所は「対飛び道具」。 　「飛び道具を多数有しているキャラ」を想定、あるいは実践していない場合、 　　酷いと「飛び道具にガードしない」ことすらありえますので注意。 ＞判定の強弱 　判定の強さは、単純に「攻撃判定と当たり判定の差の大きさ」と考えれば良い。 　　判定が弱いと言うのは「攻撃判定と当たり判定に差が少ない」（もしくは当たり判定の方が広い） 　　判定が強いというのは「攻撃判定のより、当たり判定の方が短い」（もしくは当たり判定が薄い） 　図解すると、（　当たり判定　）【＃攻撃判定＃】でこんな感じ。 　　判定が弱い：（【＃＃＃#)】　　　・　（　　【＃＃＃】） 　　判定が強い：（　　【＃)#＃＃】　・　（　）【＃＃＃】 　砕いて説明すれば「判定の弱い攻撃と強い攻撃を同時にやった場合、 　　　判定の弱い方だけが食らい、判定の強い方は攻撃を受けない」という状態。 （　飛び道具は攻撃判定だけを飛ばす為、判定が強い、ともいえる。　） 　さらに砕けば「判定が弱ければ反撃を受けやすく、判定が強ければ反撃を受けにくい。」 　　若干違うが、大体そんな感じである。 　ちなみに発生に無敵がある技も、その砕いた意味なら「判定が強い技」に分類できる。 　判定の強弱については、攻撃判定部分にほとんど当たり判定が無かったり、 　　武器にすら当たり判定が付いていたり、とキャラによって違いは大きく、 　　何々がともいえない為、各自で確認すること。 　判定は、リーチが長く判定の弱い攻撃であれば使用を少なくしたり、 　　反撃には可能な限り判定の強い技を用いたりなどの、考慮をする材料になる。 ＞立ち回り 　簡潔に言えば「自分が得意な場所で戦う為の移動動作」などをさす。 　飛び道具特化のキャラで相手と距離を置いて戦う為の動作、 　　近接特化のキャラで相手へ確実に近づく為の動作、などなどもそれにあたる。 　「近接特化」か「中距離特化」か、「飛び道具特化」か「空中特化」か、 　　とキャラのタイプによってすることは異なるが、能力を活かす為の動作、 　　最もキャラの性能を引き出しうる戦い方をする為の「立ち回り」である。 　単純な基本は、最初に上げた近接特化での接近、飛び道具特化での後退など。 　少しややこしいものであれば、 　　ゲージがあれば近接、ゲージが無ければ逃げてゲージ溜め、 　　突進攻撃からすぐ遠ざかりまた突進攻撃のヒットアンドアウェー。 　飛び道具を出した直後に接近しての攻撃なども、立ち回りとも言える。 　中距離などで適切の動作が無い場合に前後へ動いたり、 　　あるいは壁際を嫌ってジャンプなどで相手を飛び越えようとする、なども。 　いかに効果的な攻撃の出来る場所にいるかが立ち回りの基本。 　上手く攻撃が出来ない、という場合は、 　　これを見直す事で改善できることもある。 　少なくとも、自身の苦手な間合いにい続けることは厳禁である。 ＞で。 　「前後の隙」「ガード・反撃」「判定の強弱」「立ち回り」 　ＡＩを制作する際、考慮すべきことはこの４つの他、 　　当然のことである技の性能やコンボ、ゲージ回収率とゲージ技のことなど。 　あとＡＩは特殊な記述をしなければ、相手に合わせた動作をできません。 　　その為、汎用的に用いる事の出来る反応記述をお勧めします。 （　例えば相手に合わせる「相手の間合いの外から」という記述すらも困難です。　） 　ちなみにこうしたゲームの得意な人は意識してか、 　　もしくは無意識でも、そうした必要な要素の「意識」があります。 　どうすればいいかが分かるわけで、ＡＩを作るにもいくらかスムーズにできます。 　分からないのであれば、必要なものを「知識」として知り、 　　それをＡＩに実行させることが必要になります。 　まあ、手操作がいくらかできて、損はありませんけど。 [New] ＞調整 　単一の相手でなく複数の相手と戦わせ、 　　多用な相手に対応できるようなＡＩであることが望ましい。 　特にコンボなどは、相手の大きさや重さによって入らないこともある。 　　「基本」の他、できれば「高身長」「低身長」「チビキャラ」などを想定しておく事。 　（　判別は相手の「頭部の高さ」で大体だが、知ることはできる。　） 　また相手の戦い方によって、封殺されてしまう可能性を考え、 　「近接型・突進」「近接型・迎撃」　（　格闘ゲームの王道キャラ　） 　「近接型・投げ」「近接型・当身」　（　投げキャラ・当身キャラ　） 　「設置型」「中距離型」「遠距離・射撃型」　（　設置・トリカゴなど。　） 　というような多用なタイプの相手と戦って調整すること。 　高性能なキャラはこのタイプ分けで複数のタイプを持っているものですが、 　　できれば極端なタイプの方が、封殺の有無は確認しやすい。 　場合によっては自身で「調整専用ＡＩ」を作る、というのもありかと。 　　と言うより、調整専用キャラが私は欲しい。 　まあ高性能なキャラであれば、性能のゴリ押しで 　　大体の相手に安定することはできるが、並みのキャラではそうはいかない。 　最初の方は極基本的なキャラ相手に調整し、快勝できるくらいになったら、 　　いわゆる強キャラなどを相手に調整を行う感じ、かなあ。 　調整専用キャラがいるとすれば、その強キャラなどの前に 　　それで調整を行って安定させる、と言う感じかも。 　限界は、いわばキャラクターの限界だが 　　ＡＩの限界があって始めて「限界」である。 　あらゆる状況に対応できるようなＡＩを作ることは困難だし、 　　ただ単に強いだけがＡＩではありません。 　調整用ＡＩだってＡＩですし、見るためだけのＡＩもあるでしょう。 　勿論強さに対して挑戦する、ということを楽しいと思う人もいますが、 　　あまりに強すぎても、挑戦できる人、楽しめる人は限られてしまいます。 　戦うこともＭＵＧＥＮですが、 　　作ること、見ることもＭＵＧＥＮのはずです。 ・・・調整用キャラ考。 （）で目的を書いてはいるが全て「ガード・攻撃・接近」の事。 　・遠くからダッシュ攻撃や突進技ばかりに重点を置いた突進ＡＩ 　　ダッシュ攻撃などが素早いキャラや、優れた突進を持つキャラで。 （　迎撃能力・ガード判断を調べる為　） 　・近づいてきた相手を迎撃する事に重点を置いた迎撃ＡＩ 　　無敵のある昇龍技を持ったキャラや、極めて素早い攻撃を持つキャラで。 （　無闇な近づき方をしていないか調べる為　） 　・基本的に突進型で、とにかく投げばかり用いる投げＡＩ 　　投げ技の多用なキャラで、かつ使い勝手か判定が優秀なキャラで。 （　ガードと迎撃の判断を調べる為　） 　・当身を超反応高確率で出したり、コンボを中断して当身するＡＩ 　　複数の当身技を有し、かつ発生か対象が優秀であるキャラで。 （　無闇な攻撃、反撃をしていないか調べる為（あまり、どうしようもないが）　） 　・設置を多用しつつ移動も行い、容赦なくＡＩを殺すＡＩ 　　設置→攻撃をそつなくこなせるキャラで。 （　特にガード判断を調べる為　） 　・中距離で長いリーチの技を多用し、相手を近づかせない半迎撃ＡＩ 　　リーチが長い他、判定も強い技を有するキャラで。 （　無闇な近づき方をしていないか調べる為、中距離編　） 　・全画面、長距離リーチや、射撃でのトリカゴなどを用いるＡＩ 　　優れた遠距離技を有し、かつそれに制限の緩いキャラで。 （　ガード判断と接近の確実さを調べる為　） ・ガード直後の反撃のみをするＡＩ 　　迎撃型と同じような、もしくは優れた切り返しを持つキャラで。 （　対ガードへの攻撃判断と攻撃の甘さを調べる為。　） ・・・ ・・・調査用キャラ考。 　主に、大会などでキャラの調査を行うために使えそうな 　　ＡＩとキャラの性能がどのようなものであるかを確かめる為だけのキャラ考。 ＡＩ調査 　あくまで判別の方法であり、それぞれが悪いとかではない。 　　システムの違いによる極端な試合をさせないよう住み分けをするためである。 　・超反応判定 　　Player判定のHelperをMoveType=Aで相手の目の前に一瞬だけ出現させる。 　これで相手が必殺技などを使う場合「超反応反撃を用いるキャラ」とも判断できる。 （　しかし、反応の計算式によっては超反応防止がありながら反応してしまう可能性も無くは無いが。　） 　出現させるフレーム数は基本２Ｆ程度で、 　　判定を行う側１Ｐ・テストを受ける側２Ｐの場合 　　Time=1で消す前に、相手の状態がMoveType=A&&Time<2であれば判定を下すなど。。 　もしくはTimeで消さず、攻撃判定を出して当たるか当たらないかを判定するというのも。　 　　反応の技に無敵があるか無いかでも、大勢への影響はかなり違うため。 　・ガード判定 　　AttackDist設定のされたHelperを相手の目の前へ張り付かせる。 　これでガード状態動かない、というような状態になった場合「ガード最優先キャラ」と判断できる。 （　ガード最優先の場合、特に相手がガード崩しを持っていないと試合が長引き過ぎてしまう。 　　互いにガードが硬く、かつ牽制しあっている場合はそれもそれで面白いが。　） 　・特殊ガード判定 　　相手の目の前にHitDifを出現させ、しばらく攻撃をさせて消す。 　それに対してブロッキングだと言った特殊ガードを使うかどうかの判定で、 　　成功率が高い、むしろ完璧である場合は「高性能ブロッキングキャラ」とできる。 （　ブロッキング有り同士であればいいが、無いキャラの場合極端に不利となることも。　） 　連続攻撃の回数を減らし、攻撃の頻度を上げるという形でも可。 　　連続での特殊ガードが出来ない場合はそちらの方が分かりやすい。 　・ガード崩し判定 　　ただ中下段のばらけさせたガードをするようにさせるだけ。 　基本的なガードに対する能力を調べるためなので 　　対しゃがみは屈みガード、対立ち対空は立ちガードくらいの判断で。 （　ガード崩しに乏しい場合、ガード合戦で試合が長引きすぎたりしかねない。　） ・・・ 20:31 2009/09/11 ■メモ・ちなみに。 　「硬直状態」や「単一反応」は、人間にはいいサンドバッグです。 　例えば「攻撃に対してガード」だけの反応では、ガード不可攻撃の的です。 　「立ちに対して立ちガード・屈みに対して屈みガード」も同様に、 　　立ち下段や屈み中段などの特殊な技に対して全くの無力です。 　対処法は「攻撃に対してガード以外の防御」を取ったり、 　　ガードの上下は適度にバラけさせるなどありますが、 　　その場合は確実な防御を行えなくもなります。 （　あるいは学習装置をつける、と言う方法も。　） [Old] ＞最低限について 　ＡＩを作る際に、どの程度の強さにするのが丁度いいか、 　　なんて話を聞きますが、それを悩むなんてナンセンスです。 　自分がどの程度の強さを作りたいのか、それとも限界に挑戦したいのか。 　ＡＩＬｖならRandom>Var(AILv)*100とかでいいから、 　　出来るだけやってみるくらいでいいと、私はそう思います。 　もちろん、単純な強さだけでなく、 　　見ていて面白いかどうかなどを考慮に入れてもいいでしょうし。 　少なくとも、「どの程度の強さ」と言うのは、 　　限界を決めるときにする話ではなく、調整をするときの話です。 　で、とりあえず誰を目標にすればいいか、と言うのは確かに悩む話です。 　適当な強さに定評のあるキャラとＡＩに相手をしてもらえばいいだけですが、 　　癖の強い相手だと、強さの調整に変な癖が付いてしまいかねない為、 　　１キャラでなく、複数キャラを目安にするといいかと。 　私は最初リュウとかケンとかを目安にしてましたし、 　　最初は並キャラから始めるといい、のかな？ 　・・・と言うより、自分で使ってどの位の相手が倒せるのかを調べて、 　　どのくらい苦戦したかを目安に調整すればいいんじゃないかな。 　あと、「最低限でもどのくらい強いのか」すら分からないのは論外じゃないかな。 ＞最大限について 　キャラクターとしてでなく、ＡＩとしての最強を求める。 　それはつまり、キャラクターの性能を最大限引き出す、という事。 　「いわゆるエクストリームリー」のようなことですが、それでも制作者によっては、 　　「他の制作者に理解しがたいほど、精巧なＡＩを組み込んでいる」場合も、あったりします。 　それは先に言った「前後の隙」だとか「ガード・反撃」だとかだけの話でなく、 　　「的確に状況を判別させる」という事までに行き着く話になります。 　それこそ「学習ＡＩ」といわれるようなものも、含むでしょう。 　ただ、キャラの性能という限界もあります。 　　そして、性能と目的によっては、差異もあります。 　ＡＩの限界というのは、人間の限界とプログラムの限界、 　　双方ともそこへ達することを要し、容易ならざることでしょう。 　まあ、言ってしまえば、「どこが限界か」と言っても限界なんて知りません。 　限界なんてものは、あらゆる手を尽くし、あらゆる知識を身に付け、 　　あらゆる計算を行い、そしてまたあらゆる手を尽くすことによって、 　　分かるもの、かもしれませんから。 　適度なところで妥協し、強さそのものよりも、 　　面白さを優先してみてもいいじゃないですか。 　戦うだけが、ＭＵＧＥＮではない。 　　見ること、作ること、それらもＭＵＧＥＮなのですから。 ●●● ●ＡＩ作りの配慮 まとめ不足。 　(Alive)(RoundState=2)(Ctrl||MoveContact)は絶対に注意すべきこと。 　■Alive 　Aliveは「生きている」という条件であり、動作の大前提である。 　特殊なシステムが無い場合、!Alive(死んでいる)の状態では動けない。 　精確に言えば、!Aliveの状態で動いてはいけない。 　Alive(もしくはLive>0)の条件を怠ると、 　　タッグモードなどで「ライフを失い倒れている」にも関わらず、 　　動作を行うといった「ゾンビバグ」が起こってしまう。 　■RoundState = 2 　「試合中」という条件がRoundState=2である。 　これを用いないと、フライングをかましたりする可能性がある為、 　　特殊なシステムが無ければ、全ての動作にこの条件を用いて、 　　試合中にしか動かないよう、気をつけること。 　特殊なシステムの一例として、 　　試合開始前に歩行動作のみ可能であるキャラクターたちもいる。 　■Ctrl || MoveContact 　動作の前提条件は、Cmdなどのファイルに従う。 　動作のほとんどは(Ctrl||MoveContact)の条件下で行えるもので、 　　(!Ctrl&&!MoveContact)での技もStateNo=xxといった条件が加えられているはずである。 　これらの設定に欠陥がある場合、バグといえる挙動を起こしかねない。 　なお、MoveContactを用いるコンボは基本的に、 　　Cmdなどのファイルで可能なコンボ以外、行わせない事。 （　別な言い方をすれば、手操作で可能なコンボ以外させないこと。　） 　■StateType 　動作の前提条件は、Cmdなどのファイルに従う。 　StateTypeはしっかりと確認し、 　　StateType=Aの条件、StateType!=Aなどの条件をつけておく事。 　これに欠陥がある場合、浮遊バグなどが起こってしまう。 　また地上＝(StateType!=A)ではあるが、 　　StateType=Sの状態で、StateType=Cが条件の技を使わせる事は、 　　小さいながらも改変である為、注意すること。 （　タメ技のタメ省略は「コマンドの省略」だが、それは動作そのものの改変である。 　　ただ通常の「立ち状態から・屈み状態から」の違いは切り替えの1F。　） 　■AI用State,AI用Helper 　最低限であれば必要無いが、より作りこみたい場合に使うもの。 　もちろん、本来の挙動から外れることをさせないのは大前提で、 　　分からないのであれば、無理に使ったりしないこと。 　AI用のStateは、例えば、 　StateType=SのStateNo=0からStateType=Cの技を確実に使わせたい場合に、 　　しゃがみ動作を行わせるAI用Stateを作り、 　　そこからTimeなどでChangeStateを行わせる、 　ということもできる。 　タメ技の再現は上に書いてあるように、 　タメ時と同じ状態になるようにするAI用Stateを作って、 　　そこで溜めた後タメ技へChangeStateをさせたり、 　　もしくは溜めている状況でなければ別の動作へChangeStateしたり。 　どちらにもいえることだが、AI用StateではCtrlを0にすること。 　そして繰り返すが、本来できない動作は行わせないこと。 　　あくまで動作の再現の為だけである。 　細かいところで言えば上で書いた、 　　立ち状態でしばらく待った状態からの波動拳は一瞬しゃがませるなど、 （　Stateを+20000で作り、(StateNo=0&&Time>30)*20000などとするとか。 　　でもその場合ちょっと歩いてからだとしゃがんだりしない為、 　　　専用のVarでも作って管理してやる方がより再現度は高くなるかも。　） 　いらないような部分まで再現させることも不可能でない。 　ちなみに、別制作者本体にAIパッチを作るである場合は、 　　制作者によってAI用Stateを禁じてることも無くはないと思うのでそこは注意。 　再現を目的としていても、許可しているのかどうかは確認しておくこと。 　AI用Helperをガード補助などに用いる場合、 　例えばGuardDistに上下の制限は無い(はずの)為、 　　出現させる位置はとても下か、とても上にしておいてもいい。 　壁端確認用Helperも端に到達した場合、 　　上下どちらかに移動させておく方が、たとえ当たり判定が無くとも 　　範囲内であった為につかまれるなんてことがないかと。 （　神経質になる問題ではないが。　） 　AI用Helperの数は、多くても３つ程度、 　　可能な限り１つにするべきかと、私は思う。 　特にHelperを多数用いるキャラクターの場合、 　　ヘルパー制限に引っかかりかねない為、いくつも使うことは厳禁。 　またこちらも、AI用Stateと同じように、 　　あくまで動作の補助の為だけにとどめること。 　HelperTypeをPlayerにするなど、言語道断である。 　こちらは特に、Helperをよく知らない場合は使わないこと。 　■タッグ戦の配慮 　＞１．ゾンビバグを起こさせない（動けないときに動かない） 　ＡＩの基本をしっかりとしておくこと。 　ＡＩを制作する上で「死んだ状態の挙動」を見ることは極めて少なく、 　　最初から考慮に入れておかないと気づくことも難しいため、 　　ちゃんと覚えていないと、ゾンビバグに気づかない、という事態が起こる。 　タッグ大会などを行う場合でゾンビバグに悩まされているなら、 　　ＡＩフラグを立てる場所のすぐ下に、 [State a, AI FlagReset] Type = Varset var(ＡＩフラグ) = 0 Trigger1 = !Alive || Life < 1 ;死に状態 　といった記述を用いることで、 　死んだ場合にＡＩの動作は封じたりできる、はず。 　AIフラグ自体を強制起動状態にし、かつ死んだ場合にＡＩを止めたいなら ;強制起動用 [State a, AI Flagset] Type = Varset var(ＡＩフラグ) = (Alive||Life>0) TriggerAll = 元々用いられていたＡＩフラグ記述のAll部分をここに入れる。 Trigger1 = var(ＡＩフラグ)!=(Alive||Life>0) 　というような記述方法もある。（細かく変えればいいかな。） 　フラグがＡＩレベルと兼用である場合は、(Alive||Life>0)の後ろに*xでレベルを設定すればいい。 　例：(Alive||Life>0)*10　で数値は１０になる。 　もしくは、AI記述の直前に ;死亡中 [State a, Dead] Type = ChangeState value = 5150 Trigger1 = StateNo=5150 　と記述し、AI処理を行わせないようにする、など。 　＞２．EnemyNearは死んだ相手も対象に含まれています。 　死んだ相手も含まれている為、上手く機能しない場合も多いです。 　EnemyNear(Var(***)),などが、ポピュラーな対象処理。 　　Enemyの場合もおそらく同様だが、共有することはできないかと。 　私の場合は、 [State -3, EnemyNear(0)];EnemyNear,Alive Type = Varset V = ***;Var変数 Value = 0 TriggerAll = !IsHelper ;ノットヘルパー Trigger1 = NumEnemy = 1 ;１．相手が一人 Trigger2 = NumEnemy > 1 ;２．相手が二人以上 Trigger2 = EnemyNear,Alive ;　　　もっとも近い相手が生きている。 Trigger3 = NumEnemy < var(54) ;３．数戻し。 [State -3, EnemyNear(1...)];!EnemyNear,Alive Type = Varadd V = ***;Var変数 Value = 1 TriggerAll = !IsHelper ;ノットヘルパー Trigger1 = NumEnemy > 1 ;相手が二人以上 Trigger1 = !EnemyNear(var(54)),Alive ;現在指定の相手が生きていない Trigger1 = RoundState = 2 ;かつ試合中 　こうした記述でVarを設定し、 　　EnemyNear,と記述する所を、 　　EnemyNear(Var(***)),として対象を選ばせている。 　記述は相手が３人以上であっても対応できるが、 　　方法が無い為実際に対応するかどうかはわからない。 （　Player判定のHelperはEnemyNearで対象にならないみたい。　） 　ちなみにP2BodyDistなどは、StateNo!=5150の最も近い相手を対象とする。 　　（　StateNo,5150とは、死亡ステートのこと。　） 　用いる事のできるP2タイプのものは、 　P2BodyDist X　P2Dist X　P2BodyDist Y　P2Dist Y　（距離・P2限定） 　P2MoveType　P2StateType　P2StateNo P2Life 　P2Name　などがあり、 　Name限定で、２番目に近い相手を対象にするP4Nameも存在する。 　P2で参照できずEnemyNearで使いうるものは、 　　Vel X・Vel Yの速度や、Fcingなどや、BackEdgeBodyDistとか。 　もちろん、リダイレクトの方式はEnemyNearやEnemyばかりでなく、 　　Varに目的の相手のIDを記録し、PlayerID(Var(***))とする方法もあり、 　　そこらへんは各自の調整。 　ただしEnemyNearなどで、自身の変数などを操作している場合は、 　　上記の方法だと対応できず、思わぬ挙動を起こすこともありますので注意。 　例はあくまで、生きている一番近い相手を決める為だけの方法です 　　ちなみに、デバック表示を用いて確認しましたが 　P2****は、一番近いStateNo!=5150の相手。PlayerタイプのHelper含む。 　EnemyNear,****は、一番近い相手。Helper含まず。 　Enemy,****は、敵で一番ID番号の小さい相手。Helper含まず。 　　のようです。 　P2の処理は、StateNo!=5150　らしい　です。 　詳しいことは内部処理が分からないのでわかりませんが、 　　StateNo,5150とは、死亡ステートのことで、それを除外する模様。 　＞３．タッグモード時の最低限の動作に対する配慮 　専用タッグのＡＩではなく、タッグモードに対応したＡＩの話。 　本当に最低限になるが通常のキャラであれば 　　「バックダッシュをさせない」程度でもいい 　で可能であれば、 　　もう一人の相手も考慮にいれて動作を作る、などがある。 　細かい話は分からないので書けません。 ■メモ 　※リダイレクトは対象が存在しない場合、デバックでエラーメッセージが出ます。 　Enemy,　は一番ID番号の小さい敵。 　詳しく言うと「1P,3P vs 2P,4P」と考えた場合、 　　1P3P側は2Pを　2P4P側は1Pにリダイレクトされます。 　Enemy(0),はEnemy,と同じ。 　Enemy(1),で、1P3Pは4Pに、2P4Pは3Pへのリダイレクト。 （ただし、発生とIDの差異があるかはわからないので、確実かどうかは別。） 　EnemyNear,は相手の状態に関わらず最も近い敵。 　調べていない為、正確であるかはわからないが、おそらくX座標のみ。 　EnemyNear(0),はEnemyNear,に同じ。 　EnemyNear(1),は２番目に近い敵へリダイレクト。 　EnemyNear(!(EnemyNear,StateNo!=5150||NumEnemy=1)),でP2に近い対象反応。 　（State,5150は、死亡ステート。P2がStateNo判断である為。） ■メモ２ 　擬似学習だとか、相手の状態を記憶させたとしても、それらはただの条件式。 　どういった条件で、どういった行動をさせるか、考えないと意味が無い。 　勿論、行動の為に必要な条件式が書けないと、行動も意味が無い。