★☆ キャラ制作奮闘記 ☆★
かつて、拙作アテナ９５に実験的に搭載した疑似リフレクションですが。
相手の飛び道具を判定することの難しさ、ひとつひとつ、飛び道具毎に作り込みを行わなければならない等、
非常にめんどくさい作りとなっていました。
あれからリフレクションを装備したキャラを何体か見かけますが、跳ね返した後の飛び道具は種類を固定する方式を採用されている模様です。
現行のmugenの仕様からすると、最も賢いやり方だろうと思います。
が、ここでは敢えてアテナ９５方式にこだわって、話を進めたいと思います。^-^;
さて、あまりに出来がアレな９５アテナをリメイクする意味で開始したアテナ９４作成ですが、ここへ来てようやく疑似リフレクションを実装する段階へとたどり着きました。
なので、以下に疑似リフレクション Ver.2 （笑）について、解説したいと思います。
随分と前置きが長くなってしまいました。^-^;
基本的なリフレクションの考え方は、前回とあまり変わりありません。
今回特に変わったのは、相手の飛び道具を判定する方法です。
まずは前回のおさらい。
疑似リフレクションの、基本的な考え方です。
１）リフレクション技で相手の飛び道具を受けたら、
２）相手の飛び道具の種類を判定し、
３）同一型の飛び道具を相手に撃ち返す。
これが Ver.2 でどう変わったかというと、
１）相手が飛び道具を撃ったら、その情報を var にセットしておき、
２）リフレクション技で相手の飛び道具を受けたら、
３）var の値に該当する飛び道具を相手に撃ち返す。
となります。
「今、受けている飛び道具は、直近に相手が放った飛び道具である」
という考え方です。
前回はリフレクション技で受けた瞬間の、相手のステートを参照して飛び道具を判定しようとしていたのですが、その方式ですと、飛び道具を撃った後の硬直が短い場合に、相手の飛び道具を判定できなくなってしまいます。
そこで今回は、先に述べた考えの下、-2 State に相手の飛び道具をハンドリングするための、ハンドラーを設定しています。
詳しくは Athena94.cns をご覧いただきたいのですが、相手のステート番号を参照し、飛び道具を撃つステートへ移行したなら、Var へ必要な値をセットする様になっています。
つまり、相手が撃った飛び道具の情報を、常に保持しておく訳です。
ここで値をセットしたVarは、相手へ飛び道具を打ち返す際に使用します。（後述）
さて、リフレクションさせるためには、相手の飛び道具を受けたか否かを判定する必要があります。
これには前回同様、ProjCancelTime トリガーを使用します（前回のリフレクション記事を参照願います）。
アテナのリフレクション技は、サイコリフレクターですので、リフレクター本体を Projectile として定義しておきます。
で、これがうち消されたか否かを ProjCancelTime を使って判定し、真なら相手に飛び道具を打ち返す訳です。
相手に打ち返す飛び道具の設定には、Var を多用しています。
ダメージや発射速度、発射位置、HIT時の相手の速度等々、全てVarの値を取ります。
こうすることで、どんな飛び道具を打ち返す場合でも、打ち返すロジックは１つ用意するだけで良くなります。
Varにセットする値を変更することで、様々な飛び道具に対応しようという考え方ですね。^-^;
以上、前回との差異をベースで、疑似リフレクションについて述べてきました。
結局、跳ね返す飛び道具毎にグラフィック等々を用意してやる必要はあるのですが、苦労した分、跳ね返した時は妙にうれしかったりしますんで、がんばってみられてはいかがでしょう？
というところで、今回はこれにて。
さて、CNSである。
いきなりで「さて」もへったくれもないのだけれど、CNSなのである。（笑）
結構、様々なサイトで解説されているので、細かなステートコントローラの記述方法・効果等の具体的な記述方法はそちらに譲るとして、ここではCNSファイルの構造・・・というか、概念についてふれてみたいと思うわけ。
さて。
キャラを作成するうえで、決して避けては通れず、かつまたキャラの動きを司る中枢ともいえる部分。
それがCNSなのだ。
一口にCNSといっても、その構造は大きくは２つに分けて考えることが出来る。
「キャラクターの基本設定を行っている部分（コンスタント部）」と、「キャラクターの動作を設定してある部分（ステート定義部）」である。
コンスタント部では何を設定してあるかというと、
・ライフや攻撃力、防御力などのデータ設定
・キャラ表示の際のスケール設定
・移動やジャンプの際の速度設定
などである。
若干話が前後するが、各技の攻撃力は、それぞれを定義してあるステート定義部で指定してあるが、それはあくまでもコンスタント部で攻撃力を「100」と設定してある場合の値である。
例えば、立小パンチの攻撃力を、ステート定義部で「30」と設定していたとしよう。
コンスタント部で攻撃力を「50」とした場合、立小パンチの実際の攻撃力は「30」×「50」％＝「15」になる。
同様に、コンスタント部の攻撃力を「200」とした場合、立小パンチの攻撃力は「60」となる。
要するに、コンスタント部で設定した値はCNS全体に影響を与えるのだ、と理解して欲しい。
ステート定義部では、実際のキャラの動きを定義してある。
ただ、この部位もさらに大きく２つ（３つ、という方が正確だけど）に分けて考えることができる。
まず「通常の動作を設定してある部分」。
これはコマンド入力などにより制御が移され実行される部分である。
そしてもう一つは「常に実行される動作を定義する部分」である。
これはプレイヤーの操作に関係なく、常に実行するべき処理を記述する部分である。
いずれの場合も、キャラの動作を司る「ステートコントローラ」と、それを実行するための条件を意味する「トリガー」との組み合わせで記述することになる。
書き方の概念としては、おおよそ次の通り。
まず、「Statedef」を宣言し、これからなんの動作を定義するのかを明らかにする。
次に、その動作の中でどんな動きをさせるのか、必要となるステートコントローラを記述してやる。
また、併せてそのステートコントローラが実行される条件としてトリガーを記述してやる。
どのステートコントローラがどんな効果を持っているのか、詳細に知りたければ、mugenに付属するドキュメントの「sctrl.txt」を読んでみると良いだろう。
また、どんな条件がトリガーとして使用できるのかは、同じく「Trigger.txt」を読むといい。
いずれも英文だが、極端に難しい英語ではないので、中高生レベルの英語力があれば、ほぼ理解できるだろう。
なお、キャラクターの基本的な動き（例えば歩く、走る、ジャンプなど）は、あらかじめ「common1.cns」にて定義されており、基本的にはわざわざ記述する必要はない。
ただ、標準の動きとはことなる動きをさせたい場合は、自分で定義し直す必要があるだろう。
ちなみに「常に実行される動作を定義する部分」では何を記述すればよいのか、であるが、実は無理に使用する必要はない。
典型的な例としては、攻撃を喰らったときの「呻き声」を鳴らすステートを記述することである。
攻撃喰らい時のステートに手を入れても実現できるが、これは common1.cns に含まれる動きなのだ。
無理に common1.cns をさわらずとも（総じて common1.cns に定義されているステートはややこしいことが多い）、「常に実行～」にて定義すれば実現可能なので、そちらをお勧めする。
概略だけ説明すると、トリガーとして「攻撃喰らいモーション時」を設定し、Playsnd コントローラを使うのだ。
具体的な記述は、うめき声を設定してあるキャラのCNSを覗いてみるといいだろう。
簡単だけれども、CNS の概念としては以上だ。
これらを理解した上で、ステートコントローラやトリガーの記述方法を見てみると良いのでは・・・。
というところで、今回はこれにて。
音。
やはりこれがないと、キャラとしてはちょっと淋しいよね。
ちゅうことで、SNDファイルをこさえてやる訳だが・・・
SndMaker を使用してSNDを作る場合、ちょっとした準備が必要です。
そもそも SndMaker は、DOSプロンプト上で動作するアプリケーションなので、GUIを持っていない。
単純に SndMaker を起動すると、SNDファイル名の入力を促され、その後はWAVファイル名、グループ番号、アイテム番号の入力を繰り返すことになる。
登録する音が３０種類あれば、３０回これを繰り返さなければならない。
１回限りの作業ならそれも「あり」でしょうが、途中で音を追加したくなったりした場合、SNDファイルそのものを一から作り直す必要が発生するので、毎回そんなことはやってられない。
Mugeneratorでも使えば、音の「追加」もできるようだけど、いろいろ黒い噂（笑）も聞くので、やはり SndMaker を使うことを推奨したい。
ではどうするか。
それには、DOSプロンプトのリダイレクト機能を使う。
ちょっと話が横道にそれるけど、解説しておこう。
リダイレクト機能が何のことかわかっている人は、読み飛ばしてちょうだい。^-^;
そもそもDOSプロンプトというのは、「Windows」以前のOSである「MS-DOS」との互換性のために存在している・・・というか、「名残」と言う方が正しいかもしれませんね。（笑）
昔々のその昔、パソコンの電源を入れると、現在の様なGUIを持たない、DOSプロンプトの様な味気ない画面が起ち上がってきていた訳です。
で、そのDOS上では、ユーザーはコマンドを入力して、パソコンに仕事をさせていた訳です。
例えばこんな感じ。
C:\> DIR
・・・「DIR」ってのは、ディレクトリの情報を表示しなさいっていう命令ですね。
まぁ、そんなことはどうでもよろしい。^-^;
ここで知っておきたいのは、DOSの場合、コマンドの実行にあたり「標準の入力装置」と「標準の出力装置」が暗黙のうちに指定されている、ということ。
上記の例では、ただ単に「DIR」とたたいただけなんだけど、これは入力装置と出力装置の指定を省略していることになる。
省略してあるので、入力装置としては標準の「画面からの入力」が採られ、出力装置としては標準の「画面への出力」が採られているわけ。
この「標準の」入出力装置を切り替える機能を、「リダイレクト機能」と呼ぶ訳です。
上記の例の場合だと、例えばDIR命令の実行結果の出力先をプリンタに切り替えるとすると、次の様になる。
C:\> DIR > PRN
これは、「DIR 命令を実行して結果をプリンターへ出力しなさい」、という意味になる。
それとか、
C:\> DIR > C:\DIR.TXT
こうすると、DIR の実行結果が、DIR.TXT へ出力される。
さて、これを踏まえた上で、話を SndMaker に戻そう。
SNDを作り直す度に、毎回毎回、同じパラメータを入力してなんかいられませんよね？
なので、入力するパラメータをテキストファイルとして作成しておいて、これをコマンド入力元とするのだ。
例えば、SND.TXT というファイルに、入力パラメータを入力していたとすると、
C:\> SNDMAKER < SND.TXT
としてやれば、何度でもSNDの作り直しが楽にできてしまう。
長々とキーボードをたたかなければならないパラメータを、テキストファイルにしてしまう訳ね。
ちなみに上記の SND.TXT の内容（例）としては、次の様になる。
Athena94.snd 1AD2.wav 11 0 1AEB.wav 40 7 1AF7.wav 40 8 1AF6.wav 40 9 1CC9.wav 110 0 : : :
１行目がSNDファイル名で、以下、WAVファイル名、グループ番号、アイテム番号・・・と続いている。
つまりは、キーボードをたたいて画面から入力する内容そのもの、である。
これを用意しておけば、たった１行コマンドを入力するだけで、SNDファイルの作り直しができる訳だ。
もちろん、音を追加する場合は、このテキストを更新するのを忘れないように。（笑）
あと余談ですが。
音の登録順序は、グループ番号の若い順に登録するのが望ましい（必須だったかも）とされています。
SND用のテキストファイルを記述する際には、このことに留意してくださいね。
以上、ここまでが今回のお題です。
以下は、余録・・・というか、宣伝というか。（笑）
さて、SNDを作ったなら、今度はそれをCNSにて使用する訳ですよね？
どの音を何番で登録したか、いちいち覚えてもいられませんから、みなさんいろいろ工夫されていると思います。
私のやり方としては、
何番に何というWAVファイルを使用する、その内容は○○だ
という一覧表を作るようにしている。
例えば、こんな感じね。
---------------------------------------------------------------------------------------- 1000,0 : 1acf.wav : 「サイコボール」 1300,0 : 1ad0.wav : 「え～いっ」サイコリフレクター 1200,0 : 1ad1.wav : 「フェニックスアロー」 11,0 : 1ad2.wav : （死） 195,0 : 1ad3.wav : （あくび） 3000,0 : 1ad4.wav : 「はぁ～～～っ」（気合い溜め、シャイニングクリスタルビット） 190,0 : 1ad5.wav : 「アテナ、いっきまぁ～す」 ----------------------------------------------------------------------------------------
こうしておくことで、音の管理ができるようにしている。
CNSにて音を使用する場合に、この一覧を検索する訳ですわ。
で、最近になって気づいたのが、ひょいひょいっと音を追加していると、この一覧とSND作成用のテキストの内容とが、必ずしも一致しなくなってくるんですな。^-^;
２つのものを同時にメンテすることになる訳で、これが結構めんどくさいし、なかなかに抜けてしまう。
そうすると、正しくCNSで音を指定している筈なのに、「音がならない」「意図したものとは違う音が鳴る」なんてことが起きちゃう。
そこで（ものぐさな）私は考えた。（笑）
管理用の一覧から、SND作成用のテキストが自動生成されれば便利じゃん！
ということで。
その為のツールをこさえてみました。（笑）
Microsoft の Access を使って、音の管理表を作ってみた。
SNDに登録するグループ番号とアイテム番号をキーにして、用意した音のWAVファイル名をどんどん登録していくわけ。
その音が何の音なのか、日本語でメモを入力できるようにもしてありまする。
ちょうど、上の例の一覧表のイメージですな。^-^;
で、どんな順番で入力しても、DBなので、ちゃんとグループ番号順に並べ替えてくれる。
音を追加する場合も、順番なんて気にせずに、一覧に追加するだけでＯＫ。
さらには、ここからSND用のテキストファイルも出力できちゃう。（笑）
っていうか、それだけのものなんですが。^-^;
管理表とSND用テキストの２重管理をしなくてすむので、私的には結構便利で、重宝している。
もしも私と同様のやり方（音の管理ね）をしていて、やっぱり２重管理がめんどくさくて困っている人がいらっしゃるなら、私までご連絡ください。
拙作のツールをお分けいたします。
Access2000用とAccess97用の２種類が提供できます。
・・・落とし物ページに置いてもいいんだけど、Access を持っていて、かつ使ったことがある人でないと
使いづらいと思うし、用途が結構限定されるので、それほど需要はないだろうな、と。^-^;
万一、メールが殺到するようなことがあれば考えますが、まずないでしょうし。^-^;
何より、不特定多数の方にばらまいてしまうと、サポート仕切れなくなるし。^-^;
ちょっと、初期設定にクセがあるかも知れないんですよ、このツール。^-^;
（少なくとも、「Accessって何？」という御仁には、おすすめ出来ませぬ。（爆））
と、随分と長文になりましたが、今回はこれにて。（笑）
以前、「ＳＦＦにグラフィックを登録する際には、表示用の基準点の設定に細心の注意が必要」と
書きました。
今回は、具体的なケースをあげて解説してみたいと思います。
ケースとして現在作成中のアテナ９４から、立ち中キックを用いて説明します。
（余談ですが、原作にはない技です。^-^;）
この技は、「前方へ大きく踏み出してから膝蹴りを放つ」という動きをする関係上、
基準点の設定には一工夫が必要となります。
まずは図をご覧いただきたいのですが、一連のアニメーションを自然に表示させるために、
技の開始から終了までの間、基準点を固定しています。
この場合、技の終了時点で元の場所に戻ってこれないことに気付いてもらえるでしょうか。
このままですと、技が終了して静止モーションに戻った際に、一瞬キャラが引き戻される
（ワープする）ような
不自然な動きをしてしまいます。
じゃぁ、どうするよ、ってのが今回のお題です。^-^;
方法は何通りか考えられます。
ただいずれの場合も、技を定義するＣＮＳ側で処理してやる必要があるでしょう。
なので（ものぐさな私は）もっとも簡単な方法を取ることにします。
以下に例を示します。
[State 241, 3] type = PosAdd trigger1 = AnimTime = 0 x = 29
以上。（爆）
・・・一応解説しますね。^-^;
キャラの左足を基点に考えた場合、技の開始時と終了時とで、２９ドット分位置がずれています。
従って、技が終了した直後、本来の立ち位置（静止モーションが表示される座標）よりも２９ドット分
前へ（見た目）移動してしまっている訳です。
なので、技の終了時点で PosAdd してやることで、このギャップを埋めているのです。
こうすることで、技が終了して静止モーションへ移行しても、キャラがワープすると言うことを
防ぐことができます。
もっとも、この例にはひとつ問題があります。
それはこの技を途中でキャンセル出来るようにした場合に発生します。
表示位置のギャップを埋める処理は技の終了時点で行っている訳ですから、これが途中でキャンセル
された場合、ギャップが埋められないまま次の技へと移行してしまうことになります。
従って、繋ぐ技によっては、キャラが一瞬ワープしてしまう可能性があるのです。^-^;
まぁ、そういう問題はさておき。
軸位置の設定を誤ると、そのキャラの動きはどうしても不自然になってしまいます。
各技のモーション毎で軸位置をしっかり固定してやる必要があるのはもちろんのこと、
技と技（動き、といった方がいいかもしれませんね）同志の軸位置の兼ね合いも、
非常に重要となってきます。
端的な例として今回示したアテナの立ち中キックは、軸位置の関係上、ＣＮＳにて立ち位置の
操作を必要としました。
恐らくはキャラ製作を行っていく上で、このような場面に必ず出会うと思われます。
解決策はなにもここに示した方法だけではありません。
創意工夫して、あなたなりのやり方を見つけて下さい。
と、一見綺麗にまとまったところで、今回はこれにて。（笑）
一口に「キャラを作る」と言っても、初めての人にとってはなかなか難しいもの。
ある程度キャラの構造を理解して、「じゃあ、作ってみるべ。」と作業開始しても、結構途方にくれたりしません？
一体なにから手をつけて良いのやら、さっぱり・・・なんてことがままあるようで。
いや実際、私もそうでしたし。
なので今回は初心に立ち返り、私がキャラを作る上で、「こんな感じで作っていったらよかんべな」と日頃考えていることを書いてみようかなと思ったわけで。
・・・あんまりタメにはならないかも知れんなぁとは思いつつ。（笑）
さて。
一般的には恐らく、
・画像等、素材を集める
・ＳＦＦ、基本的なパレット（ＡＣＴ）を作る
・ＡＩＲを記述する
・ＣＮＳを記述する
・・・ってな感じでしょうか。
ＤＥＦファイルをどのタイミングで作るかは、人それぞれでしょうし、まぁ、大きな問題ではないと思うので、割愛。^-^;
ただこれは、あくまでもキャラの構成を基準にした考え方な訳で。
例えば、「歩く」といった動作ひとつを作る際に、この順番で作ればよかんべ、ってな感じでしょう。
じゃあ、どの動作から作っていくのよ、ってのが今回のお題。
いや勿論、これから書くのはあくまで私個人の考えですので、必ずしもみなさんがそうしている訳ではないですよ、念のため。
キャラの作成を勧める上で、やはりまず最初に作らねばならないのは、いわゆる「基本動作」と呼ばれる動きでしょう。
立ち状態、屈み動作、屈み状態、ジャンプ、ダウン、振り向き、ガード動作・・・等ですな。
とりあえずこれが出来れば、mugen上でキャラを表示させてみることができます。
で、とりあえず表示できるようになると、作りたい技（恐らくは、必殺技等の攻撃技が多数派でしょう）を作ってみたくなるのが人情ですな。
んが、しかし。
暫しまたれよ！
ここはぐっと堪えて我慢の子、まずは、必須モーションをきちんと作ってしまいたい。
必須動作とは、\docs\spr.gif に示されるような、いわゆる「攻撃喰らいモーション」です。
これがないと、相手から操作されるような状況（典型的な例としては「投げられる」場合）で、自キャラが一瞬消えてしまったり、下手すりゃ全く表示されなかったり、なんてことが起こってしまう。
最近は見かけなくなったけど、公開中のキャラでもこの辺りを後回しにしてしまい、投げたら消えるキャラってのがたまに見受けられます。
さて、必須も出来た（余談ですが、数ある必須動作を全て作り終えることを、「必須が埋まった」なんて言い方を良くします。）し、いよいよ必殺技を作るぞ！
・・・・いやいやいや、慌てる事なかれ。
攻撃は攻撃でも、まずは通常技をしっかりと作るべし。
私が最初にキャラを作ったとき（つまりはアテナを作ったとき）、この通常技を割とおろそかにしてしまっていたのですが・・・・
今にしてみれば、後悔しています。^-^;
理由はただ一つ。
通常技をおろそかにしては、決して良いキャラには完成しないから。
どんなに凝った必殺技を持っていても、通常攻撃がいい加減に作られていては、やはりＰｌａｙしてみれば興ざめしちゃいますからね。
なので、まずは通常攻撃をしっかりと作ってしまいましょう。
立ち・屈み・ジャンプと、全部ね。
サンプルキャラである、カンフーマンの通常技（判定の強さやダメージ、硬直など）を参考にすると良いでしょう。
そこまで出来たなら、やっと必殺技を作りましょう。
但し、超必殺技は、まだ。
超必は、必殺技がきちんと固まってからにしましょう。
何故、こういった順番に拘るかというと。
例えば必殺技を作る段階で、まだ通常技を作っていなかった場合。
あなたは一体、何を基準にしてその必殺技を作りますか？
ダメージや判定の強さなど、適当に作るとどうなる？
下位の攻撃（この場合、通常技）が既にあれば、これを基準にして、ちょいとグレードアップした位の技ってのに調整し易くなるでしょ？
そうすれば、極端に強すぎる技にはならないだろうし、それなりにまとまりのあるキャラに仕上がって来るんじゃないかなぁと。
何より、攻撃特性などの性格付けが、統一できるのではないかと思う訳で。
それぞれの技は格好いいんだけど、キャラ トータルで見た場合に、なんかチグハグ、ってんじゃ哀しいじゃないですか。
あとは、動きの作り忘れ、漏れを無くせるんじゃないかな。
これは、私の経験上、思うことでして。
２キャラ目を作成（つまり、リョウね）した際には、それなりに納得がいくまで通常技を作り込んでから、より上位の攻撃を作っていった（公開当時を知る人にはお分かりでしょう。（笑））のですが、自分の目で見ても、明らかにアテナとは完成度が違いましたから。
（あくまでアテナと比較して、ですよ。^-^;）
あと、画像などの素材を集める場合に留意した方がいいんじゃないかな、というポイントを。
やはり、画像を集める段階で「どんなキャラに仕上げるか」ということを、しっかりとイメージしておく方が良いと考えます。
オリジナルの再現を目指すのであれば、それぞれのコマの表示時間まで気にする必要があるだろうし、アレンジするならするで、どういった動きが必要で、どんな動きが不要かという、基準みたいなものが出来てくるでしょう。
他のゲームキャラをキャプチャするなら、何処までキャプチャすればよいか線引きが明確になりますよね。
延々、終わりのないキャプチャーロードを続けて、ついには飽きてしまった、なんてことが防げる・・・かも。^-^;
１から絵を描く場合でも、何を描けばいいのか、ハッキリするしね。
ゴールを明確にしておけば、自ずと必要な作業ってのは決まってくるから。
あとは、最初に全ての素材を一気にキャプチャーするか否かですが。
これは、どちらとも言えないかな、とは思います。
作ろう（他のゲームから移植しよう）とするキャラの画像を一気に全てキャプチャーしてしまえば、どんなキャラに仕上げるか、イメージを固めやすくなりますよね。
そういう意味ではお勧めなんですが、実作業として考えた場合、非常に気長な作業となります。
それこそ、キャプチャで力つきてしまう恐れがありますし。
かといって、各モーションを作る際に、必要となる画像だけ順次キャプチャーしていると・・・下手をすると、その都度パレット（ＡＣＴ）を修正しなければならない危険性も、なきにしもあらずな訳で。
新たにキャプチャした画像に、それまでに用意していたパレット（ＡＣＴ）に存在しない色が使われていることだって、十分考えられるでしょ？
こればっかりは、性にあった方法を取っていただくしかないのかな、なんて思ったりする訳で。
因みに、リョウを作ったときは前者（一気に全部をキャプチャ）の手法を取りました。
んで、今作っているキャラは、後者（必要なモーションのみ順次キャプチャ）の手法を取っています。
最終的に、どっちがやり安かったかは・・・・作成中のキャラが完成したら、また何かで報告するとしましょう。
・・・なんか、今回は（も？）内容がないなーとは思いつつ。^-^;
今回は、これにて。
麻宮アテナの必殺技であるサイコリフレクター。
ＫＯＦシリーズにおけるこの技は、相手の飛び道具を跳ね返す性質を持っている。
ところが、ｍｕｇｅｎにおいては、この「跳ね返し属性」（以下、「リフレクション」と表記する）が
再現できない。
そう、「できない」のだ。
以前、個人的にElecbyteに「リフレクションを実現する方法はないか」と質問してみたことがあるのだが、
その時の答えが「現バージョンではリフレクションの実現は不可能。今後のバージョンにて対応するつもり」であった。
それから２度ほどｍｕｇｅｎはバージョンアップされたが、相変わらずリフレクション用のコントローラ等が
追加された形跡はない。
どうやら、待っているだけ無駄っぽい。
それなら、完全なリフレクションは無理にしても、それに近いことが出来ないか、考えてみようじゃないか！
・・・・前置きが随分長くなったが、そんなわけで、今回のお題は「（疑似）リフレクション」。
まずは、リフレクションを起こそうとしたとき、キャラはどんな動きをするのだろうか。
1) リフレクション属性を持った技で、相手の飛び道具を受けたか否か、判定する。
2) その結果、飛び道具を受けたならば、それを相手に跳ね返す。
大ざっぱには、こんなところか。
しかし、「それを相手に跳ね返す」ことが現状のｍｕｇｅｎでは不可能なので、
ここを他の方法に置き換える必要があるだろう。
もっとも手っ取り早いのは、受けたのと同じ飛び道具を、相手に向かって撃ち返すことだろう。
「跳ね返す」のではなく、「撃ち返す」訳だ。
では、先程のキャラの動きを、もう少しブレイクダウンして考えてみよう。
1) リフレクション属性を持った技「Ａ」を展開
2) 相手の飛び道具が、技「Ａ」に接触したか否かを判定
3) 判定の結果、接触していれば、受けた飛び道具の種類を確認
4) 確認したものと同じ種類の飛び道具を、相手に向かって撃つ
こんな感じかな。
ここで、問題が発生する。
リフレクションを行う側は、跳ね返そうとする相手の飛び道具と同じ飛び道具を持っている必要がある。
且つまた、相手が撃ってきた飛び道具が何なのか、正確に判定する必要がある。
従って、必然的に跳ね返せる技が限定されてくるのだ。
全ての技を、汎用的に跳ね返すリフレクションは作れない（多分）のだ。
以上を踏まえた上で、アテナ９５のサイコリフレクターを例に、疑似リフレクションを解説する。
まずは 1) の部分。
アテナのリフレクターそのものは、速度ゼロの Projectile だ。
実際問題として、Projectile にリフレクション属性なるオプションは存在しない
（そもそも、ｍｕｇｅｎ自体にリフレクションが存在しないのだから当たり前だ）。
従って、「リフレクションを行おうとする技」を展開するだけの話だ。
次いで、2) の部分。
先も書いたが、リフレクターはProjectileだ。
これを、単位時間内に複数個発射している訳だ。
相手の飛び道具を受けたか否かは、このProjectileが相手の飛び道具によって消されたかどうかが解ればいいわけだ。
それなら、ProjCancelTime が使える。
ドキュメントによれば、このトリガーは自キャラのProjectileが相手のProjectileによってうち消された場合にTrueを返す。
従って、このトリガーがTrueを返したなら、相手の飛び道具がリフレクターに接触したことになる訳だ。
ここで再び問題が発生する。
察しのいい方は既にお気づきだと思うが、ProjCancelTime を使用する以上、判定できる飛び道具が限定されてしまう。
つまり、相手の飛び道具もProjectileである必要がある。
Helper型の飛び道具では、無理なのだ。
さらには、こちらのProjectileをうち消してもらう必要があるので、
相手のProjectileに Cls2 が設定されていなければならない。
Cls1 しか設定されていないProjectileだと、うち消さずに素通りしてしまうからだ。
っていうか、相手の飛び道具が消えてくれないと困るし。^-^;
さて、3) 4) の部分だ。
2) の時点で、相手の飛び道具は消えてしまう。
その瞬間に、同じグラフィック・威力・速度の飛び道具を撃つことで、跳ね返した様に見せかける訳だ。
そのためには、受けた飛び道具を正確に把握する必要がある。
アテナの場合、相手の飛び道具を受けた瞬間の、相手のステート番号を見ることで、相手の飛び道具の種類を判断している。
なので、もしもアテナが飛び道具を受け止めた瞬間、相手が飛び道具を放ったステートから別のステートに移行してしまっていると、受けた飛び道具が何であるのか、判断出来なくなってしまう。
お互いに画面の端に離れていると、対応している筈の飛び道具を跳ね返せないことがあるのは、このためだ。
相手のひとつ前のステート番号を知ることが出来ればいいのだが、残念ながらP2PrevStateNo などというトリガーは存在しない
（PrevStateNo はひとつ前のステート番号を返すトリガーだ）。
今のところ、どうしようもない・・・・。
もっと他にいい方法があればいいのだが。^-^;
疑似リフレクションの概念としては、大体以上の通りだ。
むしろ制限事項の方が多いのだが、実際に飛び道具を跳ね返す様は、なかなかにインパクトがある。
如何に多くの相手に対応した作り込みを行うかがカギになってしまうが、リフレクションを諦めていた人も、お試しになってはいかがだろうか。
きっと、キャラの魅力が増すと思うのだが・・・さて？
（半分、インチキみたいなもんだけどね。^-^;）
AI について、もう少し書いてみたいと思う。
前回書いたサンプル AI は、状況（相手の状態）に対応して技を出す、「対応型」とでも言うべき
AI だった。
それだけでは説明としては不十分かな、とも思うので、今回は自分から攻め込むタイプ、いうなれば
「攻撃型」AI について考えてみたい。
さて、対応型だろうが攻撃型だろうが、AI であることには変わりはないので、その基本構造は
両者とも同じだ。
結局は、状況判断の条件が、より能動的（攻撃的）になるだけのことなのだ。
なので、今回は状況判断ロジックについてのみの解説とする。
前提条件として、ＣＯＭ使用キャラ証明用のスイッチは前回と同じくVar(30)を使用。
さて、ここではもっとも典型的な攻撃型AIの例として、連続攻撃を決めるAIを考えてみよう。
まずは、普通にプレイヤーが操作して連続技を決める場合、プレイヤーはどんな判断を
しているのだろうか。
・１発目の技を出す。
・１発目がHITしたなら、２発目の技をだす。１発目が外れていたら終了。
・２発目がHITしたなら、３発目の技をだす。２発目が外れていたら終了。
・３発目がHITしたなら、・・・・・（以下、最後の技まで続く）
これをAI非搭載のＣＯＭキャラがやろうとするとどうなるのか。
・１発目の技を出すコマンドが選択されれば、１発目の技を出す。
・１発目がHITしており、２発目のコマンドが偶然選択されれば、２発目の技を出す。
・２発目がHITしており、３発目のコマンドが幸運にも選択されれば、３発目の技を出す。
・３発目がHITしており、・・・・・（以下、最後の技まで続く）
なんて感じになるだろう。
前回も説明したように、通常のＣＯＭは、ＣＭＤファイルに定義されたコマンドを
ランダムに選択して技を出しているにすぎない。
従って、連続攻撃になる可能性は、コマンドの定義数が多ければ多いほど、極めて低くなることが
わかってもらえるだろう。
さて、AI である。
AIでは、ランダムで選択されたコマンドは無視させるのだと前回書いた。
従って、１発目がHITしていれば、２発目のステートに移行するように、ステートを定義してやればいい。
例えば、こんな感じですな。
; Combo Attack for AI ; Section 1 ;[State -1,1] type = ChangeState value = 210 trigger1 = p2statetype != L ; Not Lie down trigger1 = P2movetype != A ; Not in Attack trigger1 = var(30) = 30 ; AI = on trigger1 = p2bodydist X < 40 ; Near P2> trigger1 = p2bodydist X > 17 ; Near P2> trigger1 = statetype = S ; Standing trigger1 = ctrl ; Enable Control ; Section 2 [State -1,1] type = ChangeState value = 230 trigger1 = p2statetype != L ; Not Lie down trigger1 = var(30) = 30 ; AI = on trigger1 = StateNo = 210 ; Attack by Standing x trigger1 = movecontact ; Hit! ; Section 3 [State -1,1] type = ChangeState value = 220 trigger1 = p2statetype != L ; Not Lie down trigger1 = var(30) = 30 ; AI = on trigger1 = StateNo = 230 ; Attack by Standing a trigger1 = movecontact ; Hit! [State -1,1] : : :
これは、現在試作中のアテナ９５用攻撃型AIからの抜粋だったりする。^-^;
この例では、遠距離立ち小パンチ→立ち小キック→遠距離立ち中パンチとつなぐコンボだ。
理屈としては、１発目の攻撃が相手に届いていれば２発目を放ち、２発目の攻撃が相手に
届いていれば３発目を、と次々とチェーンをつないでいく訳だ。
こうしておけば、例えば偶然２発目の攻撃をＣＯＭが出し、それが相手に届けば、３発目以降の
チェーンコンボをつなごうとしてくれることになる。
対応型よりも条件がシンプルになる分、理解し易いのではないだろうか。
ここで注目して欲しいのは、２発目・３発目では自分の状態（立ち・屈み・空中）を一切考慮して
いないということだ。
なにか、ここだけを見ると、例えば空中で地上技が出てしまいそうな気がするかもしれないが、
さにあらず。
２発目・３発目いずれも、「先の攻撃が相手に届いていれば発動」という条件になっている。
「先の攻撃」を辿っていくと、１発目の定義まで遡るが、ここでは細かく自分の状況を指定してある。
１発目が当たった＝１発目を出した＝正しい状況で技を出している、という判断をするので、
２発目以降の条件は、このようにシンプルなものになっているのだ。
さて、ここでちょっとひねって考えてみよう。
例えば、先の例だと屈み攻撃がHITしても、AI によるチェーンは起きない。
また、近距離の立ち攻撃がHITしても同様だ。
どうせなら、これらの攻撃が当たっても、チェーンコンボを狙える AI にしてみよう。
; Combo Attack for AI ; Section 1 ;[State -1,1] type = ChangeState value = 210 trigger1 = p2statetype != L ; Not Lie down trigger1 = P2movetype != A ; Not in Attack trigger1 = var(30) = 30 ; AI = on trigger1 = p2bodydist X < 40 ; Near P2> trigger1 = p2bodydist X > 17 ; Near P2> trigger1 = statetype = S ; Standing trigger1 = ctrl ; Enable Control ; Section 2 [State -1,1] type = ChangeState value = 230 triggerall = p2statetype != L ; Not Lie down triggerall = var(30) = 30 ; AI = on trigger1 = StateNo = 210 ; Attack by Standing x trigger1 = movecontact ; Hit! trigger2 = StateNo = 200 ; Attack by Standing x trigger2 = movecontact ; Hit! trigger3 = StateNo = 400 ; Attack by Crouching x trigger3 = movecontact ; Hit! ; Section 3 [State -1,1] type = ChangeState value = 220 triggerall = p2statetype != L ; Not Lie down triggerall = var(30) = 30 ; AI = on trigger1 = StateNo = 230 ; Attack by Standing a trigger1 = movecontact ; Hit! trigger2 = StateNo = 430 ; Attack by Crouching a trigger2 = movecontact ; Hit! [State -1,1] : : :
こんな感じかな？
これで遠近立ち屈みに関わらず、攻撃が１発入れば、そのままチェーンコンボを狙うAIに
なった訳ですな。
もちろん、これ以外にも方法は考えられる。
地球さんのＨＰ
では、Varを使った連続技の制御方法を掲載されているので、参考にしてみるといいだろう。
要は、コンボを狙わせるための条件（trigger）を、如何にして設定するか、なのだ。
今回の例は通常技によるチェーンコンボだったが、必殺技を絡めた連続技の場合も理屈は同じなので、
応用してみて欲しい。
さぁ、貴方も自分のキャラにAIを搭載してみませんか？
最近のトレンド(？)なのか、AI を搭載するキャラが増えてきている。
AI 搭載により、キャラの動きが格段に「賢く」なり、結果的にＣＰＵが強くなるわけですな。
キャラ作成者の「自分のキャラがボコボコにされるのは見たくない」って思いからか、あるいは純粋に対ＣＰＵを面白くしようという考えからなのかわからないが、ともかく最近の流行(はやり)であることは間違いないだろう。
さて、AI、 AI と世間は騒がしいが、ではいったい AI ってなんなのよ？ってなことで、今回のお題ですな。
まずは言葉の意味から。
「AI」とは、
Artificial Intelligence
の略で、「人工知能 」のことだ。
元々はコンピュータ用語らしいので、
アスキーデジタル用語辞典
にてその意味を調べてみると、
「言語を理解し、推論し、学習し、問題を解決するためのコンピュータのことで、簡単にいえば、人間が行なう知的な仕事をコンピュータで代替させようとするもの。」
と、定義されている。
これをＭ.Ｕ.Ｇ.Ｅ.Ｎの場合にあてはめてみると、
「プレイヤーが状況判断しコマンド入力する行為を、コンピュータに代替させようとするもの」
とでもなるのだろう。
では、実際問題として、どうやって AI を実現するのか？
地球さんのＨＰ
にて、わかりやすい説明が掲載されている(01/03/05現在)ので、詳しくはそちらをご覧いただきたい・・・なんて言ってしまうとこの記事が終わってしまうので、多少（っていうか、かなり）重複する説明が多くなるとは思うが、私なりの解釈を交えながら、敢えて以下に考察していくこととしよう。
具体的な方法は何通りも考えられる（らしい）が、ここでは、基本的に地球さん方式（たった今、勝手に命名。^-^;）を採用する。
考え方としては、先の AI の定義にヒントがある。
通常のＣＰＵの場合、技を出すにあたり、ランダムにＣＭＤファイルの記述を処理しているにすぎない。
そこには、プレイヤーが行っているような「状況判断」は存在しない。
なので、ＣＰＵに「状況判断」をさせてやればよいのだ。
ここで、ＣＭＤファイルの構造を思い出していただきたい。
;【コマンド定義部】 ; 236 波動コマンド [Command] name = "236_a" command = ~D, DF, F, a [Command] name = "236_b" command = ~D, DF, F, b ・ ・ ・ ;【ステート定義部】 [State -1] type = ChangeState value = 3221 triggerall = command = "236_a" triggerall = statetype = S trigger1 = ctrl = 1 ・ ・ ・
ＣＰＵがキャラを操作する場合、（恐らくは）コマンド定義部を読み込み、そこからランダムにコマンドを発生させ（選択し）、該当するステート定義部を処理している（と思われる）。
この辺の流れはＭ.Ｕ.Ｇ.Ｅ.Ｎのプログラムがそう組まれているため、「状況に応じてコマンドを発生させる」なんて事は、どうやっても不可能だ。
ではどうするか。
コマンド定義部で選択されたコマンドがどうであれ、ステート定義部側で条件判断を行った結果を優先させるようにするのだ。
ランダムで選択されたコマンドは、無視させる訳ですな。
但しそれは、現在キャラを操作しているのがＣＰＵである場合に限る必要がある。
でなければプレイヤー操作時にも、キャラが好き勝手に動いてしまうことになってしまうからだ。
従って、AI を実現するにあたり、やることは大きく以下の２点だろう。
Ⅰ.ＣＰＵキャラであることを明らかにするためのスイッチ操作
Ⅱ.ＣＰＵ用状況判断ロジックの組込
この２点について、順を追って考察していこう。
Ⅰ.ＣＰＵキャラであることの証明
考え方としては、「人間では到底入力不可能なコマンドを入力できれば、それはＣＰＵだ」とするもの。
例えば Time オプションを「１」にしたコマンドを、複雑怪奇な入力を行う形に定義する。
物理的に人間には入力不可能なので、プレイヤー操作時にこのコマンドが発生することはない。
しかしＣＰＵの場合、コマンド定義部に定義されたコマンドをランダムに選択するだけなので、
このコマンドを入力可能なのだ。
ここで気をつけたいのが、ＣＰＵはコマンドをランダムに選択するのだ、という事実。
少しでもＣＰＵ専用コマンドが選択される確率をあげるためには、ＣＰＵコマンドは沢山作っておく方が
いいだろう。
しかし、やりすぎにはご用心。
Ｍ.Ｕ.Ｇ.Ｅ.Ｎの仕様上、１キャラにつき定義できるコマンド数の上限が１２８個と決められているので、
この制限を超えない範囲で定義してやるようにしよう。
でなければ、このキャラを読み込んだ途端に、エラーが発生してＭ.Ｕ.Ｇ.Ｅ.Ｎが終了してしまうので
気をつけたい（なんでそんなことを知っているかというと・・・やっちまったからさ^-^;）。
さて、ＣＰＵ専用コマンドを沢山定義できたなら、今度はステート定義部でそのコマンドを処理してやる。
やることは簡単だ。
ＣＰＵコマンドのいずれかが選択されたなら、VarSet で Var に値をセットしてやればいい。
各キャラには、ＭＡＸ３０余個（正確な数は忘れた^-^;）の Var が用意されている。
このうち任意の１つを、ＣＰＵキャラか否かの判断用スイッチとして使用するのだ。
例えば、Var(30)をスイッチとして使用することにしよう。
ここでは、スイッチがＯＮになったら、値「３０」がセットされることにする。
ＣＰＵ用コマンドのいずれかが選択されたなら、Var(30) に「３０」をセットする。
;【コマンド定義部】 ; AI スイッチ用コマンド [Command] name = "AI_1" command = D, D, D, D, D, D, D, D time = 1 [Command] name = "AI_2" command = a, a, a, a, a, a, a, a time = 1 ・ ・ ・ [Command] name = "AI_30" command = z, z, z, z, z, z, z, z time = 1 ・ ・ ・ ;【ステート定義部】 ; AI swich -> ON [State -1,2] type = Varset triggerall = var(30) != 30 trigger1 = command = "AI_1" trigger2 = command = "AI_2" ・ ・ ・ trigger30 = command = "AI_30" v = 30 value = 30 ・ ・ ・
例えば、こんな感じですな。
ＣＭＤファイルのステート定義部に VarSet を書くことに抵抗を感じる方もいるかもしれないが、
ＣＮＳと同じように ChangeState 以外のステートコントローラを書いても構わない。
これで、ＣＰＵキャラの証明はできた訳だ。
Ⅱ.ＣＰＵ用状況判断ロジックの組込
さて、次はいよいよ AI の本体ともいえる、条件判断ロジックの組込を行おう。
・・・なんて書くと大袈裟に聞こえるが、要はＣＮＳを書く時と同じように、条件分岐を作って
やればいいのだ。
まずはサンプルを以下に示そう。
;【ステート定義部】 ;投げ [State -1,1] type = ChangeState value = 1500 ; 投げ技 trigger1 = P2movetype != A ; Not in Attack trigger1 = p2statetype != L ; Not Lie down trigger1 = p2statetype != A ; Not in Air trigger1 = var(30) = 30 ; AI = on trigger1 = p2bodydist X < 18 ;>Near P2 trigger1 = statetype = S ; Standing trigger1 = ctrl ; Enable Control ;無敵技 [State -1,1] type = ChangeState value = 1100 ; 昇龍拳のような無敵技 trigger1 = P2movetype = A ; in Attack trigger1 = p2statetype != L ; Not Lie down trigger1 = var(30) = 30 ; AI = on trigger1 = p2bodydist X < 18 ;>Near P2 trigger1 = statetype = S ; Standing trigger1 = ctrl ; Enable Control ・ ・ ・
上記のサンプルは、「相手との距離が１８未満のとき、相手が何もしていなければ投げを打ち、
相手が攻撃してくるようなら無敵技でカウンターを取る」という AI だ。
ここで、すべての条件（trigger）に Var(30) の判定が含まれている点に注意してもらいたい。
また、発生コマンドの内容が全く考慮されていないことも気をつけられたし。
詰まるところ、AI とはこのような条件判断による強制的なステート変更の羅列だと理解すれば
いいだろう。
逆に言えば、条件判断にて当てはまらなかった状況では、通常通りのＣＯＭ制御となる。
一口に「AI」といっても、全ての動作を制御するわけではない。
ある特定の状況の時のみ、指定した動きをさせるものだと理解していただきたい。
なお、本来選択されているコマンドを無視する必要があるので、これらの条件判断ロジックは、ＣＭＤファイルのステート定義部の先頭に置く必要がある。
ＣＭＤファイルの解決は、プログラム的には前から順番に解決される（らしい）からだ。
因みに、この応用として、複数の異なる条件（ChangeState文）を書く場合、上に書いてある条件文が先に処理される＝優先されるので、優先的に取らせたい行動を記述した条件文は、より上位に記述するようにするとよいだろう。
AI の何たるかが理解できれば、あとはこの応用だけだ。
複雑な条件判断を多く含む AI にすれば、より状況に応じた行動をとる、賢いＣＰＵキャラとなるはず。
皆、精進いたしましょう。^-^;
やはり、リョウの制作がのってしまうと記事が書けなくなりますなぁ^-^;
・・・と、いきなり言い訳から入っちゃいましたが、今回はパレットについて書いてみようかなと。
「Ｍ.Ｕ.Ｇ.Ｅ.Ｎで使用するキャラグラフィックはパレットを統一する必要がある。」なんて、以前の日記にも何度か書いたが、「実際問題、どういう意味やねん？」って方が多いみたい。
なので、今回はそこら辺の話をちょっと詳しく書こうと思うわけ。
前置きが長くなった。^-^;
そもそもグラフィックってのは、どういう形でデータ化されているのか。
その辺りから概念的にでも理解しておく必要はあるでしょう。
キーワードは「インデックス・カラーモード」
ビットマップに代表される通常のグラフィックデータは、「ＲＧＢカラーモード」になっている（と、思いねぇ^-^;）。
そのデータ格納イメージとしては、図の様になる。
| 紫 | 紫 | 紫 | 紫 |
| 紫 | 赤 | 黄 | 黄 |
| 紫 | 白 | 赤 | 紫 |
| 紫 | 紫 | 紫 | 赤 |
実際のデータフォーマットは必ずしもこうではない。
話をわかりやすくするため、イメージとして捉えてもらいたい。
それはさておき、結局のところ、各ドットが何色なのかというベタデータとして持っている訳だ（と、思いねぇ^-^;）。
これだと、複数の画像間でパレット情報の統一をしようにも、方法がないことが解ってもらえるだろうか。
さて、これが「インデックス・カラーモード」になるとどうなるかというと、
| 255 | 255 | 255 | 255 |
| 255 | 12 | 0 | 0 |
| 255 | 100 | 12 | 255 |
| 255 | 255 | 255 | 12 |
各ドットが、「パレットの何番目の色を使用しているか」というデータの持ち方になる訳だ（と、思いねぇ^-^;）。
察しのいい方ならもうお気づきだと思うが、この形式ならば、「別途パレットデータだけを用意しておき、各グラフィックはパレットの何番目の色をどのドットに使うかというデータ形式にする」ことができる訳だ。
この「パレット」データってのが、ＡＣＴファイルな訳ですな。
さてそうすると、ＳＦＦファイルに登録するためのＰＣＸファイルは、全て共通のパレットを使用する形に作っておく必要がある。
これがよく言う「パレットの統一化」作業なのね。
もう少し具体的な話をしておこう。
通常、NeoRageやキャプチャーソフトで撮った画像はＲＧＢカラーモードで記録されている（と、思いねぇ^-^;）。
従って、これらをインデックスカラーモードに変換してやる必要がある訳だ。
方法はいくつか考えられる。
エレクバイトでＤＬできるＰＣＸＣｒｅａｎを使用する方法もあるだろう。
ただ、私はこの方法を用いたことがないので説明できないし、質問されても答えられないので悪しからず。
私が用いる手法は、フォトショップを使うやり方だ。
この方法について、少し具体的に述べておこうと思う。
まず、全画像で共通に使用するパレットを用意する必要がある。
そのために、キャプチャしてきた様々なモーションの画像で、その画像でしか使用していない色が存在するものをピックアップする。
そして、これらを１枚の大きなビットマップとしてまとめる。
例えば、こんな感じですな。
こうすることで、このビットマップにはそのキャラクターで使用する全ての色が含まれている状態になる。
フォトショップでこのＢＭＰを読み込み、カラーモードを変更する。
イメージ－モード－インデックス
そうすると、どのようにしてインデックス化するか訊ねられるので、「全ての色を使用する」を選ぶ。
色の合計数が256を超える場合は、ちと問題が発生するが、ここでは割愛する。
処理後、一見何も変わっていない様に見えるだろうが、実際には先に説明した形にデータの持ち方が変化している筈だ。
で、この状態の画像のパレット情報を保存する。
イメージ－カラーパレット
パレットイメージが表示されるので、パレットを保存するのだが・・・
この時、色情報は前詰めで表示されていて、後半の使用していない色は真っ黒になっている筈だ。
Ｍ.Ｕ.Ｇ.Ｅ.Ｎの場合、一番最後のマスにある色を背景色として識別する。
なので、パレットイメージを良く見て、背景と同じ色のマスを消して、一番最後のマスに同じ色を入れてやる必要がある。
これをやっておかないと、Ｍ.Ｕ.Ｇ.Ｅ.Ｎでキャラを表示したときに、キャラの周りに四角いマスが表示されてしまう、なんてことになるので注意されたし。
そして、パレットを保存する。
これで、このキャラに使用するパレット（ＡＣＴファイル）が得られる訳ですな。
因みに、背景色をさわった為に先のＢＭＰは表示がおかしくなる筈だが、気にしない。
もうこのＢＭＰは用済なので、破棄してしまって構わない。
まぁ、残しておいたらそれはそれで、２Ｐカラーを作るときに便利だったりするのだが。
例によって、ここではこの話は割愛する。^-^;
ここまでできれば、後は単純作業の繰り返しだ。
各モーションの画像をフォトショップで読み込み、カラーモードをインデックスカラーに変更していくのだ。
このとき、インデックス化する方法は「カスタム」を選択するようにする。
そうすることで、ＡＣＴファイルを読み込みできる状態になるので、先に作ったＡＣＴファイルを指定する。
難しいことは全部フォトショップがやってくれるので、簡単っしょ？
２Ｐカラーを作るのは、冒頭の考え方を応用すれば理解できるだろう。
要は共通で使用するパレットの、色そのものを変更してやればいい。
それぞれの画像は、パレットの何番目を使用するのかしか気にしない訳だから、そのパレットが何色であっても構わない訳だ。
それには、さっき作ったＡＣＴファイルを編集してやればよい。
因みに、最近何の前触れもなく公開開始した「ActFileEditer」とは、まさにこの作業をするためのソフトだったりする。^-^;
Actファイルを読み込んで、色を変更して、名前を付けて保存する、ただそれだけなんだけどね。
最終的には、元のＰＣＸを読み込んで、パレットの何番を変更すれば、どう表示が変わるかを確認しながら作業できる様にするつもりなんだけど、まだＰＣＸは読めない。^-^;
そんな状態だけど、良かったら使ってみて頂戴。^-^;;
ＣＭになっちゃったところで、今回はこれにて。
リョウの進捗状況・・・って訳でもないのですが。^-^;
折角一からキャラをつくっているんで、今度こそTIPSを書かないと・・・。
アテナの時は、結局突っ走っちゃったからなぁ。^-^;
キャラづくりがノってくると、書いているどころではなくなっちゃったんだよね。＜言い訳。
それはさておき。
アテナの時の反省も踏まえて、今回のリョウのＳＦＦ作成には随分と気をつかってる。
それなりに整理してモーションを登録しておかないと、結構あとあとめんどくさかったんよね。
思いつくままにつくったモーションを登録しちゃっても構わないんだけど、少しでも作業を効率化
したければ、ちゃんと整理すべきですな。
後でAIRを作る時に便利なんですよ。
なので、リョウのＳＦＦは、最初に基本となる立ち・しゃがみ・歩き・ジャンプをもってきて、
次いでガード、くらい系の必須スプライト、で演出系、基本攻撃系、必殺技系・・・と、
カテゴリー（？）ごとに固めて、整理してみた。ていうか、するつもり。
・・・まだ出来上がってないからね。^-^;
ＳＦＦが整理されていると、AIRを記述する際に、ＳＦＦに登録されている順に定義していけるっしょ？
そうするとAIRの「もれ」も防げるし、なにより「あのモーション、何番で登録してたっけ？」なんてＳＦＦ
内を探し回る、なんて無駄な作業もしなくてすむ。
なにより一番の理由は、「他人に見られても恥ずかしくない」ってことかな？
ｍｕｇｅｎって、キャラのソースとでも言うべきものが簡単に覗けちゃうので、結構気を
つかってしまう。^-^;
さて、ＳＦＦの話に戻ろうかな。
アテナの時は「ＰＣＸをＳＦＦに登録する」なんて簡単に流しちゃったけど、実は結構大事な点が
多かったりする。
例えば前述の整理すべきって点だけど、もう一つ、大事な（少なくとも私ゃそう考える）点がある。
ｍｃｍというツールを
使ってＰＣＸを登録する際、その画像を表示するための基準点を設定する。
これの設定をいい加減にしていると、後々めんどくさいことになるのだ。
例えば立ちポーズ一枚目の基準点をキャラの足元、体の中心線を通る辺りに設定したとしよう。
で、二枚目の基準点を今度は左足元に設定したらどうなるか。
一枚目と二枚目で基準点がずれている訳だから、立ちポーズが表示された時にこのキャラは前後にぶれる
ように表示されてしまうはずだ。
上記は極端な例だけど、１ドット単位でのずれってのは結構やっちゃいそうでしょ？
あと、立ちモーションと歩きモーションとで基準点の位置が極端に異なると、歩きはじめた時に
キャラが一瞬ずれる様に表示されてしまうので・・・
この例だけでなく、各モーション間の基準点の位置関係にも細心の注意が必要ってことやね。
余談ですが、ＳＦＦの基準点が少々ずれていても、AIR側で補正することは一応可能ッス。
基準点に対し、Ｘ・Ｙ座標それぞれ何ドットシフトして表示するかっていう指定ができるのね。
ただその場合、カンが頼りのＴＲＹアンドＥＲＲＯＲの繰り返しになっちゃうんで、お勧めできない。
折角ｍｃｍというＧＵＩツールがあるのだから、ＳＦＦ側できっちりと設定してやる方が、遙かに
簡単だし、お手軽だ。
あと、基準点がらみでもう一点。
基準点の設定位置に対するアドバイスをば。
キャラが地上にいるときは、地面（つまり、Ｙ軸の座標がゼロ）に基準点が位置づく様に表示される。
キャラの画像を見ると、右足と左足とで高さが異なる場合があるでしょ？
きちんとキャラが地に足をつけている様に見せる為には、より上に上げられている足の高さを基準として
設定する必要があるッス。
私ゃこの点をアテナで失敗しました。^-^;
単純に一番下にある足の高さに合わせて基準点を設定しちゃってたんですわ。
結果、片足が地面から浮いている格好になっちゃった。^-^;
いわゆる「キャラの表示がずれている」って状態ですな。
最近ご指摘を受けるまで、アテナはこの状態でしたわ。^-^;
他にも注意するべき点はあるのかもしれないけど、とりあえずはこれらだけでも
やっておくべきでしょう。
とかくキャラの作成には根気が必要だといわれるけど、ＳＦＦの作成はまさに根気の勝負です。
がんばらねばっ
今回は「奮闘記」らしくなったかな？^-^;
最後にリョウの進捗状況をば。
とりあえず、必須スプライトはそろった・・・かな？
ＡＩＲやらＣＮＳ、ＣＭＤはアテナのものを流用して動かしてみても、まあそれなりに動いている。
当たり判定やくらい判定はアテナのままだし、攻撃もまだ入ってないんだけど。
とりあえず、相手からの攻撃をくらって消えることは無くなったかな。
投げられても消えないし。
今後は、イントロや勝ち・負けモーション入れて、それから通常技へと進める予定。
６ボタン化するなら、大攻撃をどうするかなぁ。
今回も合成・・・するか？
合成するにしても、ネタ（アイデア）が・・・^-^;
あと、翔吼拳、どうしようかな？
よかったらご意見、伝言板にでも
書いていただけるとありがたいですぅ。<(_ _)>
てな訳で、今回はこれにて。
・・・↑なんて大袈裟なもんでもないんですが。^-^;
11/5付けで、リョウ・サカザキの作成を開始しました。
とりあえず、落とし物ページに載っけるだけ載っけたんですが、「準備中」の表記がわかりにくかった
模様で、結構ダウンロードを試みられた方がいらっしゃった様子・・・。^-^;
ご迷惑をおかけしやした。<(_ _)>
もちょっとわかりやすく、表記を追加しました。^-^;;
さて。
ベースとなるのは餓狼伝説スペシャル版。
いわゆる「古き良き時代」のリョウですね。^-^;
個人的に、このバージョンのリョウが一番お気に入りなんですよ。
飛燕疾風脚はタメ不要だし、虎煌拳は隙が小さいし、ビルドアッパーは無敵だわ、
なんと言っても龍虎乱舞が使いやすいですから。（残裂拳のことは敢えて言うまい。^-^;）
さらには、各モーションがかっこいいんですよね。(*^-^*)
余談ですが、なんで「虎砲」なんだろう？
無敵の龍（・・・すでに死語か？）なんだから、「龍」の名を冠すべきとちゃううんか？
「虎煌拳」は「虎」を「煌」う（うやまう）「拳」だから虎を冠していても構わないのであって。
最強の虎（こっちも死語？）であるロバートの龍撃拳にしても、「龍」を「撃」つ（うつ）「拳」だから
龍を冠していてもＯＫなんであって。
ちっとも納得がいかないんですよね。個人的に。
おかしいじゃん、言葉の意味として。(-_-メ)
だからうちのリョウは「ビルドアッパー」。
絶対に「虎」砲になんかしないやいっ。
・・・だだっ子かい、私ゃ。^-^;
てな訳で、どういう仕様でいこうかというところですが。
１．やっぱり、６ボタンキャラにしたいなぁ。
２．可能な限り、元キャラを再現したいねぇ。
３．龍虎乱舞はガード不能っしょ。
４．当時のキャラにはないけど最近増えている技は・・・どうすっかなぁ？
５．覇王翔吼拳は・・・元キャラと同じく通常技とするか？ それとも超必にするか？
１と２って、結構相反する内容ですよねぇ。^-^;
結局、アレンジキャラにはなるんですけど・・・どうなるかなぁ。
４は、とりあえず後回しですな。
一通り技が完成してから考えるとしましょう。^-^;
５は・・・本当に悩んでまする。
これについては、３パターンほど考えがありまして・・・、
その１：通常技として、ばんばん使用できる。
いまのところ、「その３」でいこうかなと思ってますが・・・
がろスペの翔吼拳って、威力と隙が大きい通常飛び道具だったんで、普通に飛び道具で
うち消すことができたんですよね。
初代「龍虎の拳」版リョウの翔吼拳も、通常技でつぶせましたから、まぁ同じですわね。
けど「龍虎２」での翔吼拳は通常の飛び道具をうち消して、かつ相手に到達するという
特性をもっていたんですよね。
なので、通常技版翔吼拳は「相殺できる」翔吼拳で、超必版翔吼拳は威力が大きい「相殺不可能な」
翔吼拳としようかなと、考えているんですが・・・
ただ、そうなると２種類の翔吼拳が存在することになっちゃいますよね？
それはそれで変かなぁ？、とか思ったり。
なにより、コマンドをどうするのかという問題が発生しますしねぇ。^-^;
・・・アンケートでもとろうかしらん？^-^;
ま、なによりも今は、「動く」所まで仕上げる方が先決なわけで。
現在の進行状況としては・・・
必要と思われる全モーションを、ＢＭＰに落とし終え（全部で４００画像以上！）、
これを整理しつつＰＣＸに変換しているところ・・・です。
ついでにパレットをつくって、ＳＦＦへの登録も開始しています。
昨日、前後に歩く・しゃがむ・垂直及び前後ジャンプ・バックステップができる様になりました。
今は必須スプライトをやっつけてるところですね。
それがすんだら通常技にはいろうかな。
そこまでできたら、一度アップしてみようかなと、考えてます。
なので、もう暫く、リョウのダウンロードはできませんので・・・辛抱強く、お待ち下さいませ。^-^;
久しぶりの更新。
既に全然「日記」とちゃうなぁ。^-^;;;
日記書かないでいるうちに、アテナ嬢はほぼ完成してるし。^-^;
ま、他所のページであんまり紹介されていないことを書こうと思ってたから、その趣旨には反していないし、いいのさ♪
・・・なんて言い訳しつつ。^-^;;
今回は、ちと「番外編」で、Ｍ.Ｕ.Ｇ.Ｅ.Ｎの設定まわりのお話をば。
最近Ｍ.Ｕ.Ｇ.Ｅ.Ｎ系の掲示板で、「音がなりません」という質問をよく見かける。
原因はマシン環境によって様々だろうから、「こうすれば万事ＯＫ」なんて王道は残念ながら存在しない。
つまった人は各自情報を集め、自分と同じ状態の解決策を見極めるしかないでしょう。
よく、「音がなりません。なんででしょう？」なんて書き込みを見かけるけど、それでレス返してくれる人っていうのは、余程の世話好きかお人好しだろうなぁ。
せめて自分のマシン環境、既に試した方法、ぐらいは書かないと。
書き込みをみる人は、あなたの状態を見ていないんだから、自分だけがわかって（思って）いても通じませんよ？
逆に、必要な情報がちゃんと書かれていれば、同じ現象で悩んでいた人ってのは、ちゃんと答えてくれるもんです。多分。^-^;
まぁ、答えてあげなきゃいけない義務（ないし義理）なんてない訳ですから、レス付けてもらえないからって文句をいう（恨みに思う）のは筋違いってもんでしょう。
レス付けてもらえたらラッキー、ぐらいに考えておいた方がよいかもしれませんね。
もっとも、やはり文字だけでのコミュニケーションですから、当然取り違えなんかもあるわけで、必ずしもそれが解決に結びつくとは限りませんが。^-^;
前置き（言い訳）がながくなりました^-^;が、本題に入りましょう。
実は私の環境では、初めてＭ.Ｕ.Ｇ.Ｅ.Ｎを起動したときには音が鳴っていたんですが、キャラをいじり始めた辺りから、いつの間にか音が出なくなっていました。
キャラを作成するつもりだったんで、音が出ないのは困るってんで、いろいろ情報を集めて解決しようと努力していたんですが、なかなか解決できずにいました。
恐らくはいろいろなＢＢＳでＵＰされているうちのどれかと同じ現象なんだろうけど、自分の障害がどれに該当するのか、皆目検討がつかなかったんですよ。
はじめは音が鳴っていたのに、ある日突然、鳴らなくなった！
・・・これが私の場合の障害でした。
間の悪い事に、音が鳴らなくなったと同時期に、タブレットドライバを新たにインストールしていたんですよね。
で、それがために、音源のＩＲＱ割り当てが変わってしまったものと考えちゃったんですねぇ。
今にして思えば、これが障害を長期化させる原因でした。
あちこちのＢＢＳで見かけたのは、「音源のＩＲＱを７以下にせよ」というものでした。
私のマシンの音源（NeoMagicMagicMedia）は「９」で、ＩＲＱの変更が不可。
・・・いきなり手詰まりでしたね。(T-T)
因みにＭ.Ｕ.Ｇ.Ｅ.Ｎで音を鳴らすためには、言うまでもなく、音源がサウンドブラスター互換である必要がある。
互換性のない音源なら、残念ながら諦めるしかないだろう。
NeoMagicMagicMedia の場合（後で分かったことだが）、少なくともＤＯＳレベルではサウンドブラスター互換・・・というか、サウンドブラスターをエミュレートして動いているらしい。
冷静に考えてみれば、ＩＲＱは変更できない上に元々は音が鳴っていたんだから、アプリケーションレベルの問題の筈だと思い至るとこなんでしょうが。
ま、それはもっと後になってからわかったことで。^-^;
さて、他に有効な情報はないかってんで、さらにＭ.Ｕ.Ｇ.Ｅ.Ｎ系ＢＢＳを探します。
すると、もう１つ、良く見かける情報を発見しましたね。
「ＤＯＳ窓の環境変数に、サウンドブラスターの設定を切ってある。これを確認せよ。」というもの。
要はＤＯＳ窓で「SET」とタイプして、環境変数「BLASTER」の内容を見てみろってことですね。
敢えて詳細は記載しません（それこそ、他のＢＢＳをあたればでてくる情報ですし）が、サウンドブラスターのＩＲＱ・ＤＭＡ等をここに設定しておく様です。
この設定にて、ＤＯＳモードでサウンドブラスターが動く・・・みたいです。^-^;
で、私の環境は・・・ＩＲＱ「５」で、問題なし。
再び、手詰まり。(T-T)
音源の問題は先送りにして、アテナ９５の作成を開始する。
しかし、すぐに音の問題に突き当たってしまった。
で、やっとこさ、思い至った訳ですわ。^-^;
即ち、「元々音が出ていたんだから、音源の設定は間違いない筈。ＩＲＱの変更ができない以上、現在のＩＲＱで正解である。」だと。
では何が悪いのか？
mugen.cfg の内容は、各方面のＢＢＳで示されたサンプルと比べても、間違いはないと思われる。
では、残る可能性は・・・？
もう１つ、よくＢＢＳに出ている例がある。
「Ｍ.Ｕ.Ｇ.Ｅ.Ｎ起動と同時にミュート（無音）になっている。ALT+TABでWindowsに戻りミュートを解除すればよい。」というもの。
実は、この可能性については棚上げにしていたんですよ。
何故かというと、私のマシンだとＭ.Ｕ.Ｇ.Ｅ.Ｎ実行中にALT+TABが効かないから。
（この問題自体は未だにクリアしていないんだけど。^-^;）
しかし、もはや試せるのはこれぐらいだってんで、何とか方法を考えまして。
通常、Ｍ.Ｕ.Ｇ.Ｅ.Ｎを呼び出すショートカットの設定にて、ＤＯＳ窓を「フルスクリーン起動」にしますよね？
苦肉の策として、あれをやめて、「ウインドウで表示」にしたわけ。
もちろん、それだけではまともに画面表示されないので、Windows側の画面設定やらＭ.Ｕ.Ｇ.Ｅ.Ｎ側の画面設定やらをいじくってますが（画面をハイカラーに、Ｍ.Ｕ.Ｇ.Ｅ.Ｎの表示サイズをWinの画面解像度に合わせた）。
こうすると、Ｍ.Ｕ.Ｇ.Ｅ.Ｎ実行中でも、マウスを動かせばマウスカーソルが現れるんですよね。
で、タスクバーが本来存在する辺りをクリックしてやると・・・Ｍ.Ｕ.Ｇ.Ｅ.Ｎの画面が固まり、タスクバーに制御が移る（Windowsに戻れる）んですなぁ、これが。^-^;
この設定の難点は、Ｍ.Ｕ.Ｇ.Ｅ.Ｎ終了時にWinの画面表示が乱れること。
Ｍ.Ｕ.Ｇ.Ｅ.Ｎの画面が消えずに残ってしまうんですわ。^-^;
ま、それはさておき、やっとこさWinに戻れたので、ミュートになっていないか確認しよう。
通常、タスクバーにはボリュームアイコンが表示されてますよね。
普通ミュートになると、そのアイコンに停止マークが被さりますやん？
ところが私のWinでは、ボリュームアイコンは通常の表示のままだったんですわ。
ありゃりゃ、これも違うか？、なんて思ったんですが、まぁ、ものは試しってんで、ボリュームをＭＡＸまであげてみたんですわ。
Ｍ.Ｕ.Ｇ.Ｅ.Ｎに戻ると・・・なるんですよ、音が。
実に４、５ヶ月ぶりに。(^-^)
Ｍ.Ｕ.Ｇ.Ｅ.Ｎ起動と同時にミュートになるってのは、こういうことやったんやね。
こりゃ、アイコンみただけで諦めた人も多いんとちゃうかなぁ
・・・なんておもったんで、今回のお題と相成った訳ですな。^-^;
も少し書くと、Ｗｉｎｄｏｗの内部的にミュートになってしまっているものの、それがＧＵＩのレベルにまで通知されていないみたいです。
一種のＯＳのバグかもしれませんね。
或いは、Ｍ.Ｕ.Ｇ.Ｅ.ＮがＯＳ用のメモリエリアまで浸食してしまっているのか？
詳しいことまでは分かりませんが、ＧＵＩから音量を変更してやることで、内部的なミュートが解除される模様です。
一つ厄介なのは、一度ミュート状態のＤＯＳをミュートのまま終了させてしまうと、以後のＤＯＳはすべてミュートになってしまうみたいですわ。
少なくとも、私の環境ではそうです。
で、Ｍ.Ｕ.Ｇ.Ｅ.Ｎで、上記の操作を行うには、一端Windowsを再起動しておかないと、効果ありません。
お気をつけなされよ。
まぁ、全く同じ症状の人はそうもいないだろうけど、これ見て助かる人が１人いれば、いいかな。
実は以前、Ｍ.Ｕ.Ｇ.Ｅ.Ｎ ＪａｐａｎさんのＢＢＳでの私の書き込みをご覧になったＶＡＩＯユーザの方から、情報提供を求めるメールをもらったんです。
その人の場合、ハナから音は出ていなくて、ＯＳを再インストールしても無駄だったらしいんですね。
なんとなく、同じ問題なような気がするなぁと、思ったりもしたんですが・・・。
私の場合とは、微妙に現象が違ったようで・・・。
なかなか上手くは行かないようです。
その方にとっては、私の情報は役立たずだったわけで。
なまじ期待させてしまった分、申し訳なかったかなと、思ったりする今日この頃な訳です。
この記事が、誰かの役に立ってくれることを密かに祈りつつ・・・今回は、これにて。
更新をサボっている間にも、着実にスプライトをこさえ続け、それなりにそろってきたアテナ嬢。
で、そこで重大な問題に気づいた。
作成中のアテナはKOF95版。
と、いうことは・・・・、走っているモーションがない！
空中ガードがないっ！！
ついでに、
←このポーズがないっっ！！！サイコイリュージョンには、このポーズが欠かせないのにっ！！！！
・・・って、あるやん、なんてつっこまないでね。
このモーションもそうだけど、ないものは作るっきゃないでしょ。
さて、まずは切実な問題として、走りモーションからなんとかしてみよう。
幸いな事に、アテナはKOF95とKOF96とで、非常によく似たデザインとなっている。
これを利用しない手はないでしょ。
てな訳で、KOF96アテナの走りモーションをＮＥＯＲＡＧＥで切り出してみる。
上半身に関しては、そのまんまなので問題なし。
問題は・・・下半身やなぁ。
９６は素足にヒール、９５はズボン。腰布の色も異なる。
さて、どうしたものか？
一から自分で描けるだけの画力があれば問題ないのだけど・・・。(T-T)
とりあえず、素足をズボンの色で塗り替えてみた。
Ｍ.Ｕ.Ｇ.Ｅ.Ｎを起動、Ｗａｔｃｈモードで動きを見てみる。
・・・あかんねぇ。
思ったよりも、ヒールの高さの違いが目立ってしまうし、色を変えただけでは、やはりズボンらしくない。
仕方がないので、別の手を考えた。
まずは、アテナ９５用に集めた各モーションを並べて眺めてみた。
で、隣に９６の走りモーションを並べる。
飽きるまで眺めているうちに、９５のモーションの中に、比較的走りの「足」とよく似た「足」があることに気づく。
それらを用いて、各コマを合成するのだ。
それでも使えるパーツがないコマについては、不自然にならない程度にポーズそのものを変更して、合成した。
この方法は思いの外上手くいった。
アテナ９５の走っている姿、違和感ないでしょ？
同様にして、見栄切りポーズと空中ガードも合成してモーションを用意した。
で、これに気を良くした私は、オリジナルのモーションを作ることにした。
４ボタン→６ボタンにアレンジするつもりだったので、どのみち追加モーションが必要なのだ。
立ち大攻撃には、基本的に吹っ飛ばし攻撃系のモーションをあてるつもりだったので良いのだけれど、問題はしゃがみ攻撃。
で、アテナにはアッパー系の技が無かったようなので、しゃがみ大パンチに是非（突き上げ）アッパーをあてようと決意したのだ。
通常技対空攻撃に使えるような技なら、なおよろし。
やはり大攻撃なので、始動～ＨＩＴまで３コマは欲しい。
となるとしゃがみ攻撃なだけに、２コマ目は立ち上がる途中の姿勢になるね。
方針がきまったので、再び全てのモーションを眺め、使えそうな部品を探してみた。
やまり、まず目につくのはサイコソードのモーションですな。
アッパー→昇龍拳→よく似た技→サイコソード、の図式ですわ。^-^;
ただ、サイコソード自体、肩の力を抜いたようなモーションなので、そのままって訳にもいかんでしょう。
サイコエネルギーを纏わない通常技なんだから、もうちょっと力強くないと。
それならってんで、しゃがみガードの始動モーションから上半身を持ってきて、サイコソードのモーションの下半身と合成、これを２コマ目とした。
しゃがみガード始動モーションって、結構アッパー（ないし、昇龍拳）のでがかりって感じ、しません？
で、アッパーが延びきったコマは、サイコソードの飛び上がるモーションをベースに、勝ちポーズから突き上げた拳を合成。
右手は腰だめに構えたものを合成して、左足先は地面についている様に変更した。
（出来上がりは、「おとしもの」コーナーを参照願います。^-^;）
動かしてみても、それほど違和感はないし、いいんでないかい？
いよいよ、自作キャラといこう。
作成するは、麻宮アテナ ＫＯＦ９５バージョン。
何故アテナなのかというと・・・他人様の作ったアテナをいじくっていて、その勢いで・・・・ってのがホントのとこッス。^-^;
で、アテナと言えば、ＫＯＦ９４の声が一番お気に入りなので、是非９４で・・・・といきたかったんですが、残念ながら９４にはサイコソードがないんだよね。
昇龍拳フリーク（注１）のわたしとしては、サイコソードは外せない。
てな訳で。
作成するキャラの仕様・・・というか、こう作れたらいいなっていう^-^;、希望は次の通り。
①ベース：麻宮アテナ ＫＯＦ９５バージョン
②基本方針：再現系（注２）ではなく、個人的に「こうであって欲しかった」っていう、自己満足系アレンジキャラ。
③基本技：ＫＯＦ９５の技を一通り装備。
④必殺技：サイコボールアタック、サイコソード、サイコリフレクター、フェニックスアロー
⑤超必殺技：シャイニングクリスタルビット、クリスタルシュート、サイコイリュージョン
③について、操作系を６ボタンに変更するつもりなので、若干変更される予定。
④について、今のところリフレクターの再現について、見込みなしッス。^-^;
どうやったら相手の飛び道具を跳ね返せる様になるんかなぁ～？^-^;
⑤について・・・・。
まぁ、折角つくった技だし、入れてみようかな、なんて。^-^;＞サイコイリュージョン
とにもかくにも、方針が固まったことだし、いよいよ作成にはいりませう。
まずはスプライトを準備せねば、話になりますまい。
スプライトってのは・・・要するに、キャラのグラフィックのことやね。
たまたま某ＷＥＢページでアテナ９５のスプライト群を見つけたので、それを使用するつもりでいたんだけど・・・、いざ作成を始めてみると、結構モーションが不足していることに気づく。
いちいち補完するのもなんか悔しいので、結局、１から自分で用意する事にした。（どんな理屈や^-^;）
再び、ＮＥＯＲＡＧＥのご登場である。
ショットファクトリー機能を使って、アテナ以外の背景等を排除して、スクリーンショットを撮っていく。
これが結構大変な労力を要する。
なんか、いきなり挫折しそうな予感・・・^-^;
こんなときには、目先を変えてやるのが一番ってんで、先にパレットを作っておく事にする。
スクリーンショットを元に作ったＰＣＸをＳＦＦに登録するにあたり、それぞれのモーションで共通に使用するパレットデータを準備する必要がある。
そうしないと、Ｍ.Ｕ.Ｇ.Ｅ.Ｎで表示した際に、モーション毎に色化けを起こしてしまう事になるからね。
てなわけで、以下にわたしが行った手順をば、紹介しやす。
ここで詰まっている方は、参考にして下され。
使用するツールはフォトショップ。
まずはベースとなるパレットを準備する。
そのために、基本立ちポーズのスクリーンショットと、キャラセレ時の顔のスクリーンショット、それに必殺技なんかで使うエフェクトのスクリーンショットを、一つのビットマップにする。
なんでこんな事をするのかというと、そのキャラで使用される全ての色をパレットに含むためだったりする。
準備ができたら、そのＢＭＰをフォトショップで読み込む。
で、これをインデックスカラーモードに変更し、「使用中の全ての色を含む」様にする。
このカラーパレットを保存する事で、キャラに必要な色が全て含まれたパレットデータ（ＡＣＴファイル）が得られる訳やね。
で、安心するのはまだ早い。
このままだと、背景色も何もあったもんじゃないので、パレットのソートをしておく。
先のパレットを編集し、背景色として使用している色を、パレットの一番最後に移しておく。フォトショップでパレットデータをみた場合、一番最後の色が背景色に使われるのだ。
ついでに、近い色同士を近所にまとめるようにソートしておくと良いかもしれない。
最後に、使用していない色で、使っていないパレット番号を埋めておいた。
あんまり意味はないかもしれないが、この方が後でわかりやすそうでしょ。^-^;
ここまでできたら、このパレットデータを保存しておく。
これでアテナ９５用のＡＣＴファイルが準備できた訳やね。
さて、話を元に戻そう。
ＮＥＯＲＡＧＥで切り取った画像をスプライトの元ネタとして仕上げる訳だが、ここでもツールとしてはフォトショップを使用する。
別に必要とされる機能をもったフリーソフトを駆使してもいいんだけど、フォトショップならこれ一つで事足りるので、多用します。^-^;
いろんなソフトを使うとなると、それぞれに操作を覚えなきゃならなくて面倒なのだ。
話がそれた。^-^;;
ＮＥＯＲＡＧＥで撮ったスクリーンショットはビットマップ形式。
一方、Ｍ.Ｕ.Ｇ.Ｅ.Ｎ用のＳＦＦファイルに登録するにはＰＣＸ形式である必要がある。
なので、ＰＣＸ形式に変換してやる必要があるのだ。
あわせて、パレット情報をそれぞれのモーションで統一する必要がある。
以下にその手順の一例を紹介しますね。
全てのモーションを撮りきるのは時間を要するので、とりあえず基本の立ちポーズだけを用意した。
これ以外のモーションについても、手順は同じで良いはずなので参考にして下され。
まずはフォトショップで立ちポーズのビットマップを読み込む。
次に、この画像のパレットモードを変更する。
イメージ－モード－インデックスカラー を選ぶ。
で、次にどのようにパレットをインデックス化するかきかれるので、「カスタム」を選択する。
そうすることで、既存のパレットファイル（ＡＣＴファイル）を読み込めるようになる。
ここで、先程作成したパレットを指定する訳やね。
フォトショップの場合、パレットモードをＲＧＢからインデックスへ変更する際にパレットを指定すると、画像の色情報をパレットに存在する近似色に自動的に置き換えてくれるので便利なのさ♪
ここまでできれば、あとはこのファイルをＰＣＸ形式で保存するだけ。
こうやって必要なモーションを揃えたら、ｍｃｍを使ってＳＦＦファイルを作成、登録する。
・・・って書くと簡単なんだけど・・・^-^;
実際問題、全てのモーションを用意するのは多くの時間と根気を必要とする。
わたしの場合、立ち・しゃがみ・前進・後退の各モーションを準備しただけで、力つきている。^-^;
続きは、ちょいと気力を充電してからになりそう・・・^-^;;;
（注１）昇龍拳フリーク：
実はわたしはＳＦ２’から格ゲーにはまった人でして、当時の使用キャラはＫＥＮでした。
上昇中は完全無敵、当たれば大ダメージが期待できるが外せば大ピンチという、ハイリスク・ハイリターンな昇龍拳という技の虜だったんですよ。
因みにわたしにとって昇龍拳の定義は、あくまでも上記であるため、ＳＳＦ２Ｘ以降の「潰される」昇龍拳はかなり不本意です。
サマーソルトに負けるなんて、論外っ(T-T)
（注２）再現系：
元ネタであるゲームでの性能を、忠実に再現しようとするキャラ作成法。
本当はこっちの方が万人受けするんだろうなぁ。
ちと、今回は長文ッス。^-^;
さて、グラフィックの追加方法もわかった事だし、今度こそ技を追加してみよう。^-^;
顔グラフィックを変えた勢いで、麻宮アテナ(98)に手を加えることに決定。
このキャラ、超必が設定されていないので、これを追加することが最終目標だね。
アテナの超必と言えば、シャイニングクリスタルビット＆クリスタルシュート。
・・・なんだけど、あいにくと、ＳＦＦ内にそのモーションは存在しない。
追加するには、これらのモーションを自前で用意してやる必要があるのね・・・。
・・・めんどくさいので却下。（爆）
とりあえず、技をどうやってつくるのか、という研究材料なので、元々の技にはこだわらないことにする。^-^;
ありもののモーションを使いまわして超必をつくるとなると・・・・乱舞っきゃないでしょ。
てな訳で、追加する技はオリジナルな乱舞技、「サイコ・ダンス」（←安易な・・・^-^;）に決定。
さて、乱舞と言えば、龍虎乱舞。
無数の通常技を打ち込んだ後、昇龍系の技で締める、実にかっくいい（死語）一撃必殺の技ッスよね。
これをアテナにやらせるとして、さて、「締め」は何がえぇかいなぁ？
順当にいけば、サイコソードなんやけど・・・・
モーションがないのよ、これが。(T-T)
仕方がないので、サイコボール→サイコリフレクターと繋いで締めることにする。
方針が固まったところで、ＣＮＳの定義に取りかかろう。
Ｍ.Ｕ.Ｇ.Ｅ.Ｎ Ｊａｐａｎさんのキャラ作成講座を参考に、まずは通常技の定義をコピって来てつなげてみる。
余談だが、実際に技の追加を試みたのはＭ.Ｕ.Ｇ.Ｅ.Ｎ Ｊａｐａｎの存在に気づく前だった。
その時は、本当に単純に、通常技の定義を並べてみていたため、見事に失敗してしまった。(T-T)
ステイト番号を書き換えなきゃならん事には気づいたが、モーションのコマ数をトリガーにしているのに、
それぞれの技のコマ数をそのまま使ってしまっていたために、条件が無茶苦茶になっていたのだ。
乱舞用に新しくモーションを定義していたため、コマ数をもう一度振り直す必要があったのね。^-^;
さて、通常技が繋がったところで、必殺技も繋いでみる。
特に問題はないね。
では、テストプレイといこうか。
Ｍ.Ｕ.Ｇ.Ｅ.Ｎを起動、トレーニングモードでアテナを選択・・・
いけね、コマンド定義してねぇーや。^-^;
ＣＭＤファイルを開き、サイコダンス用のコマンドを定義する。
忘れずにステイト部分も、サイコボールのものをコピって定義。
これで、よし。
気を取り直してＭ.Ｕ.Ｇ.Ｅ.Ｎ起動。
さぁ、踊れ、アテナっ！
なんでや～～っ
何故か、技がでない。
とりあえず波動拳コマンドにしたのだが、何故かサイコボールを繰り出すアテナさん。
コマンドの定義順が優先順になる、なんて話を思い出して、順序を入れ換えてみたりもしたが、変化なし。
悩むこと数日。
わかってみれば、原因は単純なモノだった。
ＣＭＤファイルのステイト部分で、移行先のアニメーション番号が間違っていたのだ。
っていうか、サイコボールの定義をコピったまま、変更していなかったのさ。^-^;
だからサイコボール撃ってたんだなぁ。
てな訳で、ＣＭＤファイルも修正したし、気を取り直してテストプレイ。
・・・・う゛～ん・・・
だんだん相手が離れていって、全段入りきらない。
攻撃ＨＩＴ時の相手の速度を調整する必要があるなぁ。
・・・なにより、やっぱり締めはサイコソードがえぇなぁ・・・
あと、相手に走り寄ってから乱舞にうつるってのが常道でしょう。
てな訳で。
最終的に、こうなった。
技名も「サイコ・イリュージョン」に改めることにした。
まぁ、ダメージ量とか、技発動中にパワーゲージが増加しちゃったりとか、要調整な点はまだあるけど、
結構サマになってるんじゃない？
技のスペックとしては、大体次の通り。
①要パワーゲージ（Lev１、３）
②コマンドは、波動拳コマンド×２＋パンチ
③大と小とで、ダメージ量が異なる
④鳳凰脚とは異なり、ガードされても技は発動する（一応、ガードは可能）
⑤技開始の見栄切り時に飛び越されても、相手の方向に向かってダッシュ
①と②については、小でゲージ１本、大で３本使うことにしている。
ついでに、小だとサイコボールとサイコリフレクターを繋がず、いきなりサイコソードで締めている。
③に絡むが、ダメージは小で大の約半分。・・・っていうか、大が減りすぎ。^-^;
④⑤については、なかなか難儀しました。
実は、まだ完全ではないッス。^-^;
画面端で空中ガードされると、実は発動しなかったりします。(T-T)
あと、一段目で相手を手元に引き寄せる様にしているのだが、画面端で空中の相手にＨＩＴすると、
後方へ吹っ飛んでしまったり。^-^;
いろいろ難点はあるけど、まぁ研究材料としてはこんなもんやろ。
なんとなくＣＮＳの書き方も見えてきたことやし、次はいよいよ自作キャラといきましょうかね。^-^;
ＡＩＲの変更方法は何となくわかった。
１からつくるには、まだまだ充分とはいえないだろうけど、現段階では良しとしよう。^-^;
さて、今度はグラフィックの変更ないし追加を試みてみることにする。
AIRVIEWは、あくまでもＡＩＲファイルをＧＵＩで設定するためのもののようで、グラフィックそのものには手が出せない。
じゃぁ、どうすりゃいいんだろう？
悩んでいてもしょうがないんで、とりあえず情報を集めてみよう。
検索エンジンをつかって、ネットを探ってみた。
・・・Ｍ.Ｕ.Ｇ.Ｅ.Ｎって、何故か日本語の頁がすくないんだよね。
特に、キャラ作成に有益な情報ってのがほとんどない。
頑張って、苦手な英語を翻訳するっきゃないんかなぁ～・・・・なんて半ばあきらめかけていたある日、見つけましたよぉ。
Ｍ.Ｕ.Ｇ.Ｅ.Ｎ Ｊａｐａｎというページでは、キャラクターを作成するための情報が、実にわかりやすく整理された形で公開されています。
・・・で、そこで仕入れた情報によれば、ＳＦＦファイルを操作するにはｍｃｍというツールが必要らしい。
ｍｃｍを動かしてみると、単純に絵を入れ換える（追加する）だけならさほど難しくはなさそうだ。
まずは試しとばかりに、麻宮アテナ（KOF98）の顔グラフィック(大)を変更してみることにした。
何故アテナなのかというと、９８仕様なのに、９６のグラフィックを使用しているのが気になっていたもので。^-^;
ｍｃｍを起動し、アテナのＳＦＦファイルを読み込ませる。
スライダーを操作して、顔グラフィックを表示させ、Changeボタン押下、用意したグラフィックと置き換える。
簡単、簡単♪
・・・・なんて思っていたら・・・
変更したグラフィックを確認するため、Ｍ.Ｕ.Ｇ.Ｅ.Ｎを起動。Watchモードでキャラを選択・・・・
・・・あれ？
そうなんです。
色が化け化けだったんですわ。(T-T)
変更用グラフィックを用意するにあたり、ＮＥＯＲＡＧＥ等から画面コピーした物を用意していたんですよね。
単純にこれを256色に減色して使用したんですが、これでは駄目らしい。
まぁ、交換用グラフィックのパレットが、ＳＦＦ内の他のグラフィックとあってないんだろうね。
それはわかったんだけど・・・・
どうやったら、他のグラフィックとパレットをあわせられるんだろう・・・・？
悩むこと１週間。
いろいろ試した結果、フォトショップを利用した方法に落ち着いた。
①ＮＥＯＲＡＧＥでグラフィックを用意。
②用意したグラフィックをフォトショップで読み込む。
③カラーモードを変更し、インデックスカラーにする。
このとき、既存のＡＣＴファイルを読み込む。
わたしのマシン環境はハイカラーなので、256色に減色する必要がある。
故に、インデックスカラーモードに変更する。
インデックスにすると、256に減色されるし、パレットの「並び」が固定されるのだ。
で、この時に既存のＡＣＴファイルを指定してやることで、カラーパレットが他のグラフィックと同じになる。
減色時、元のパレットは指定したＡＣＴファイル（パレット）の近似色に置き換えられる。
もっとも、この方法をとるには、元のグラフィック群と変更しようとするグラフィックとで、見た目同じ色を使用している必要はあるだろうね。
手を加えた「アテナ」の場合、背景色に紫色を使用していた。
で、ＮＥＯＲＡＧＥのスクリーンショットファクトリー機能を使って背景等を取り除くと、やはり紫色が背景色になる。
なので、先の方法で上手くいったわけですね。
本体のＤＬと一緒に海外サイトで集めてきたキャラ達の所在がわからなくなってしまった・・・。(T-T)
どこからＤＬしてきたんだっけ？
・・・作者もわからないよぉ。(T-T)
さて、キャラを作るためには、キャラを構成するファイル郡の構造を理解する必要があるのは必然。
なので、「Char」フォルダ内以下の各キャラを構成するファイルを眺めてみた。
キャラを構成するファイルは、どうやら６種類。
ｘｘｘ.ＤＥＦ ： キャラクタを構成する各要素のファイル名を定義してある・・・みたいだ。
ｘｘｘ.ＣＮＳ ： キャラの動きを定義している・・・と思われる。
ｘｘｘ.ＣＭＤ ： キャラのコマンドを定義してるんだろう。
ｘｘｘ.ＡＩＲ ： ・・・・なんんだろう？ 当たり判定の定義みたいだけど・・・
ｘｘｘ.ＳＦＦ ： ？？？？
ｘｘｘ.ＡＣＴ ： 多分、カラーパレット情報だろう。・・・ってことは、↑のＳＦＦはグラフィックかな？
眺めていても埒が明かないので、とりあえずいじってみよう・・・・とはいうものの。
何をどういじればいいのやら、さっぱり。^-^;
てな訳で、再びＥｌｅｃｂｙｔｅへ。
なんと言っても開発元やし、なんかそれらしい情報があるやろ。
・・・で、見つけてきたのが「ＡｉｒＶｉｅｗｅｒ」なるツール。
謎のＡＩＲファイルを設定するためのツールとみた。
添付のREADMEをみると、mugen本体にて使用しているFontを使うため云々と書いてある。
要するに、mugenと同じフォルダに置いて実行すりゃいいのね？
とりあえず、動かしてみる。
何度か動かしているうちにわかったこと。
AIRVIEWを起動すると、ＳＦＦファイル、ＡＩＲファイルを順番に指定して読み込ませる。
そうして、画面上にキャラグラフィックとくらい判定、攻撃判定、それに座標指定時の基準点を表示できるようになる。
やはり、ＳＦＦはキャラのグラフィックを保存しているファイルであり、ＡＩＲは攻撃・くらい判定及び基準点を定義してあるようだ。
ちょっと操作系に癖があるけど、それほどわかりにくくはないね。
これで既存のキャラの判定を、いろいろいじくってみることができそうやね。
他人がつくったキャラに手を加えるのは気が引けるけど、まぁ、個人で楽しむだけだからいいかと自分に言い訳しつつ、テリーのくらい判定＆攻撃判定を変更してみる。
どうもクラックシュートのスカリ方やパワーダンクの弱さが気に入らなかったんだよね。
こうやっていろいろ試しておけば、後で自分でキャラをつくるときに、きっと役に立つでしょ。多分。^-^;
ミレニアムな年明けを迎えたある日のこと、検索サイトにてとある調べものをしていたおり、Ｍ.Ｕ.Ｇ.Ｅ.Ｎを発見する。
なにやら面白そうってんで、ＥｌｅｃｂｙｔｅのＨＰより速攻ダウンロード・・・・したはいいが、どうやらサンプルキャラが一つしかついていないことに気づく。
「ＳＮＫ vs ＣＡＰＣＯＭができるの？」なんて思ってＤＬしていたものだから、ちと落胆。
が、リンクをたどれば他ユーザ作成のキャラクターがＤＬできると判明、とりあえずお気に入り系のキャラを探す。
・・・それなりに遊べそうな数がそろったところで、はたと気づく。
「・・・どうやって動かすんだろう？」
ＤＬしたＭＵＧＥＮのファイルを冷静に見てみる。
どうやら「ＤＡＴＡ」フォルダ内に設定ファイルがあり、こいつを書き換えることで設定変更できるようだ。
キャラクターを追加するには、「ＳＥＬＥＣＴ．ＣＦＧ」を変更すればいい。
;-------------------------------- [Characters] Terry,stages/paopao2.def Andy, stages/hero96bg.DEF Ryu, stages/sfa2ryubg.def ken, stages/Birthday.def ChunLi, stages/beijing.def ;--------------------------------
↑のように、[Characters]セクションに「キャラクタのサブフォルダ名」、「自ステージへのパス」の形式で記述するとよいらしい。
自ステージを設定すると、対ＣＯＭ戦でそのキャラが現れるステージとなるみたい。
自ステージを指定しなければ、ランダムで対戦ステージが決まる。
さて、キャラの追加はできたし、起動してみるべ。
ＭＵＧＥＮ.EXEをダブルクリック！
「なんやねん、このエラーメッセージ！？」
・・・起動時の四苦八苦したもようを詳しく書いてもいいのだが、いかんせん、古い話なので記憶があやふや。^-^;
なので、ちょいと端折ることにする。^-^;;
・・・どうにか、ＭＵＧＥＮのタイトル画面があがるようにはなったが・・・色がおかしい。
一応、ゲームはできるのだが、どうも色が化けているようだ。
テリーの赤が、水色になってしまっているし、肌色もなんか青っぽい。
変更するとすれば「ＭＵＧＥＮ．ＣＦＧ」だろう。
まだ、どこか間違えているのだろう。
;------------------------------------------------------- [Video] Width = 320 Height = 240 ;This is the color depth at which to run MUGEN. You should set it to ;16 bit color unless your video card has problems with it. ;16-fastest, 24,32-slower, 8-slowest/worst Depth = 8 ;Set this parameter to 0 to disable screen stretching, and set it to 1 if ;you want to scale it up to fit the current resolution. Stretch = 0 ;Choose from "1" for VESA1, or "Linear" and "Banked" for VESA2 ;Note: VESA1 is very slow on certain video cards, especially the newer ;ones. "Linear" is usually the fastest for new cards. ;Default is "Linear". Vesamode = Linear ;Set to 1 to enable vertical retrace synchronization. VRetrace = 0 ;-------------------------------------------------------
・・・くさいのはこの辺だろうね。
もともと私のマシンは表示色をフルカラーにしていた。
なので、「Depth = 24」に変更してＴＲＹ。
・・・だめだ、ＭＵＧＥＮ起動時に、謎のエラーになってしまう。
ならば、ということで、「Depth = 16」に変更、画面の表示色をハイカラーに落としてみる。
・・・おぉ、上手くいったじゃん♪
さて、ＭＵＧＥＮ起動のためにやったことを、最後にまとめてみると―――
・Select.cfgに、キャラの定義を追加
・Mugen.cfgを変更し、画面表示色とＭＵＧＥＮの設定を合わせる
・ＭＵＧＥＮのショートカットの設定で、フルスクリーン表示にする。
・同じく、スクリーンセーバーは使用しない設定にしておく。
てなところかな？