５−１．キー入力の処理
格闘ゲームの特徴として、入力されたレバーやボタンの組み合わせが意味を持つ（コマンド）というのがあり、これはレバーやボタンがダイレクトに動作に反映される他のアクションゲームにはちょっとない特徴であります。
レバーの方向をパソコンの数字キーに対応させ、
７８９
４＋６
１２３
として表現すると、
例えばコマンドを配列において、
２　３　６　ボタン　コマンド完成　（波動拳）
というデータを定義します。
また、レバーやボタンの入力と、データが合っていれば進むカウンターを用意します。

レバー[２]入力
[２]　３　６　ボタン　コマンド完成　（波動拳）
レバー[３]入力
２　[３]　６　ボタン　コマンド完成　（波動拳）
レバー[６]入力
２　３　[６]　ボタン　コマンド完成　（波動拳）
[ボタン]入力
２　３　６　[ボタン]　コマンド完成　（波動拳）

というようなプログラムを書けばいいです。
で、下から前＋ボタンを「２３６＋ボタン」と書きましたが、こういうデータだと、厳密に下から斜め前、前に入力していかないとコマンドが成立しません。
実用的には少々大雑把でもコマンド入力が成立したことにしたいので、データを２６＋ボタンとしてしまいます。
例えばレイジングストームのコマンドは正確に書くなら１６３２１４３＋ボタンですが、簡略化して、１６２４３＋ボタンとしてしまいます。
若干アバウト気味にしたほうが、コマンドが出やすくてよろしいようです。
仮の話、いろいろなコマンドをこうして判定していく時、ものすごく高速にレバーを操作できる人間がいたとして、
２、３４１２３６＋ボタン
と入力したとき、２６＋ボタンとして認識するのがいいのか、４１２３６＋ボタンとして認識するのがいいのかというように突き詰めれば割と奥が深い話なのですが、まあその辺は各自考えたように作っていけばいいと思います。（それが難しいのか）
また、レバーやボタンを一定時間入れたままにしてから出すコマンド（タメ）を実装するのであれば、上のデータだけではなく、どれだけ入力が継続しているかを判定するためのデータも追加します。

５−２．状態遷移
格闘ゲームに限りませんが、複数の状態に変化していくキャラクターを状態遷移で表現します。格闘ゲームの場合、レバーやボタンから手を離し、何もしないでおくと最終的に立ちニュートラルになるので、基底状態を立ちニュートラルにし、そこから他の状態に遷移する設計にするといいと思います。
また、プログラムの設計として、現在キャラクターがどの状態にあるかを取得できるようにしておくと処理が楽になります。

５−３．攻撃の属性について
相手に当たったとき、相手がどういうモーションに移行するか（のけぞるだけか、吹き飛ぶか、など）と、そのときどういうエフェクト（燃える、感電、凍結など）がかかるか、を考える必要があります。

５−４．連続技（コンボ）の処理
うさはあまりコンボが好きではありませんが。
コンボというのは「回避できない連続攻撃」であり、つまるところコンボが始まると受ける側はそれが終わるまで何もできなくなるからです。何かが（ガードや回避など対策をとること）できる場合はコンボとはあまり言わないと思います。
コンボを実装するにはいくつか実装するべき機能があります。

・コンボ数制限カウンター
０になったら強制的に攻撃を受けている側を無敵状態にしてそこでコンボを終わりにしてしまうカウンターを用意します。
例えば一発目の攻撃をもらった場合、このカウンターを１０とか適切な値にセットし、弱い攻撃なら１、強い攻撃なら２、というようにコンボが当たるたびにカウンターから引いていきます。カウンターはいずれ０になり、そこでコンボは終了します。
この方法だと、無限コンボは回避できますが、コンボの段数を追求したい人にとっては、いくらすごい組み合わせを考えてもそこで打ち切りになってしまうので、不完全燃焼となる可能性もあります。攻撃が当たるたびにカウンターを減らしていくのではなく、一定の時間で減らす方法もあります。この場合はコンボの段数に制限はなく、すばやい攻撃をいかに数多く入れていくかということになります。
どちらの実装にするかは、最初のゲームデザインから決定すべきでしょう。

・ダメージ補正
コンボの段数が上がるたびに減っていく（例えば１〜０の範囲で）カウンターを用意して、コンボで当たるたびにダメージに掛け算して、実際のダメージを減らしていきます。
上のコンボ数制限カウンターを使っても同じような処理ができます。
超必殺技の発動で補正がかからなくなるというような場合この補正をリセットしてやることで処理できます。

・コンボの始まりの判定
相手がのけぞりや吹っ飛びなど、やられモーションに入っているときに今出している攻撃が当たればコンボとなります。逆に、のけぞりや吹っ飛びが最後までいってしまって、通常の状態に復帰したら、コンボはそこで終わりです。

５−５．カウンターの処理
相手に攻撃が当たったとき、相手が攻撃を出しているとカウンター。
判定はそれだけですが、カウンターのとき何がお得なのかも考えてみるとよいです。

・ダメージ増加
・仕切りなおし（お互い一定時間硬直する、間合いが離れるなど）
・相手と組みあうなど特殊シーケンスの発動
・動作がスローになりコンボを入れやすくなる
いろいろですねー

５−６．食らい判定の処理
なにげなく重要な判定処理がここにくるのです。
ちょっと考えると、プログラムの処理の流れとして

１Ｐ側の攻撃が２Ｐ側に当たったか判定、ダメージ計算などの処理
↓
２Ｐ側の攻撃が１Ｐ側に当たったか判定、ダメージ計算などの処理

としてしまいそうでありますが、これではよろしくないです。
簡単な例として、１Ｐ、２Ｐのどちらも残り体力がなく、一発で勝負がつきそうな状態で、攻撃判定が同時に出たとします。
上の処理では、まず１Ｐ側の攻撃が２Ｐ側に当たり、２Ｐ側の体力が０になります。ここで決着がついてしまうので、２Ｐ側の攻撃内容は処理されることなく終わってしまいます。２Ｐ側も同じ攻撃を出したのに、処理の順番で２Ｐ側が負けを背負うことになります。つまり、

１Ｐ側の攻撃が２Ｐ側に当たったかの判定
↓
１Ｐ側の攻撃が２Ｐ側に当たったかの判定
↓
１Ｐ側の体力処理
↓
２Ｐ側の体力処理

というようにせねばなりません。
これでも並列処理ではないので、厳密に言えば１Ｐ有利ではありますが、２Ｐ側の攻撃判定が無視されることはないでしょう。
ツクールでプログラムはいじれないという場合はおいておいて、自前でプログラムを作る場合は処理の流れを考えて設計すると不公平さが少ないと思われます。

５−７．投げの処理
a)投げプログラムの実装
細かい部分はいろいろと考えられると思いますが自分（投げる側）と相手（投げられる側）のどちらが投げ処理で主導権を持つかで２通りの処理が考えられます。
・自分が投げ処理で主導権を持つ
自分の側で、投げた相手がどのように動くかをデータとして持っておき、投げが成立した瞬間にそのデータに従って相手を動かしていきます。
通常の打撃判定と投げの処理はわけてプログラムを書くことになるでしょう。
・相手が投げ処理で主導権を持つ
相手が、投げのときにどのように飛んでいくかを、移動データとして持っています。
この場合、投げは「吹っ飛び方が特殊な打撃技」として、通常の打撃判定と同じように書くことになるでしょう。

b)投げの発生する状況
処理としては次の４つが考えられます。

・ガードできない（投げ処理で実装）
相手が前の攻撃に引き続いてガードしていても自分のつかみ判定（打撃の判定と共有すると楽です）が相手に触れた瞬間に投げに移行します。

・ガードできる（投げ処理で実装）
通常の打撃と同様に判定し、相手がガードしていない状態でのみ投げに移行します。
この実装にすると、がちがちにガードを固めた相手を崩せないケースが出てくるので、別途中段攻撃を実装するなど対策が必要になります。

・ガードできない（打撃技で実装）
ガード不能技として投げを実装します。

・ガードできる（打撃技で実装）
ガードできる技として投げを実装します。がちがちにガードした相手を崩すための手段が別途必要になります。

c)投げと打撃の境界
投げと打撃をどのように使い分けさせるかについては次のパターンが考えられます。
・相手との距離によって投げと打撃を出しわける
ストIIなど、パンチボタンを押すと、ある程度離れた状態では打撃、接近した状態では投げ、とする方法です。この場合は、コマンド認識のときに相手との距離を計算し、結果に応じて投げと打撃を出しわけることになります。また、この段階で「確実に相手を投げられる状態でのみ投げがでる」ようにすることで投げ失敗（すかり）のモーション作成を省略することができます。
・投げコマンドで常に投げがでる
相手との距離に関係なく、投げ専用にコマンドを用意して、コマンドが成立したときに投げ動作を行います。
確実に投げられる状態で投げをだすとは限らないので投げを失敗した（すかり）モーションを用意する必要があります。

d)投げ判定のつけ方
自分のつかみ判定と相手の食らい判定で投げ成立の判定をとる場合、自分のつかみ判定を手の位置に置くと相手が空中にいる場合でも判定が成立してしまい、結果見た目や対戦バランスを崩す可能性があります。
相手の足元をつかんで投げるくらいの判定をつけておくと空中の相手を投げることは回避できます。
（打撃判定で処理する場合はヒットマークの表示などに注意）

e)投げを受け付けないタイミング
次のタイミングで相手に投げを重ねたとき、投げられないようにしておく必要があるでしょう。
・相手の食らいモーション（当て投げＯＫなら必要ない）
・相手のガードモーション（当て投げＯＫなら必要ない）
・相手のダウン中
・相手の「投げられない技」中
・相手が起き上がっている途中・起き上がって行動可能になるまでの間
・その他投げられないと決めた動作中

５−８．その他特殊な遷移
自分の状態を変化させる要素として、次のパターンも用意しておくと必殺技などの発生条件をつけるのに利用できます。
・相手に攻撃が当たった（ガードした・しないを問わず）ときと当たらないときで処理を変化させる
　乱舞技、相手に当たらないとき途中で止めるなど処理ができます。チェーンコンボ、ターゲットコンボなどもこの処理を利用して実装できます。
・相手が攻撃をガードしたとき処理を変化させる
　ガードされたとき、その技の隙を大きくするなど処理ができます。
・相手に攻撃が当たったとき処理を変化させる
　攻撃が当たったときその技を必殺技でキャンセルできるようにするなど処理ができます。
・相手に攻撃が当たらなかったとき処理を変化させる
　攻撃が外されたとき、その技の隙を大きくするなど処理ができます。
・相手の攻撃判定と自分の判定が重なったとき処理を変化させる
　いわゆる「当て身投げ」の処理ができます。また「当て身投げ」と類似しますが、「攻撃の相殺」も処理できます。

５−９．飛び道具などの実装
飛び道具は「画面内に物体を表示する」という単位でプログラムを書いておくと、「ヒットマーク（ガードマーク）を表示する」「飛び道具を表示する」などが同じ処理で応用でき、楽になります。
「１Ｐ側の飛び道具を処理する」「２Ｐ側の飛び道具を処理する」というようなわけ方で処理を書くと、特殊な処理に応用がききません。次のような点を考えておくといいでしょう。
・座標の移動
　プレイヤーキャラクターと同じデータ構造にしておくと、処理が楽になります。また、処理は複雑ですが、座標の移動をプレイヤーキャラクターが設定できるようにすると、「自分の移動に応じて移動する付属キャラクター」「コマンド入力で軌道が変わる飛び道具」などが処理できます。
・奥行きの設定
　自分より奥に表示するか、手前に表示するかを設定できると便利です。ヒットマークなどは手前ですが、付属キャラクターは奥に表示するとキャラクターが見えやすくなるでしょう。
・透明度の設定
　個別に設定できると、飛び道具は半透明、付属キャラクターは不透明というように使い分けができて便利です。
・所有者の設定
　その飛び道具が自分のものか、相手のものか、あるいはシステムのものかといった属性をつけておいて、当たり判定の処理を切りわけできます。
　自分の飛び道具、相手の飛び道具を分けないで、所有者による区別だけにしておくことで、例えば特定の攻撃が当たったときに飛び道具の所有者を入れ換えて（移動方向も入れ換えて）、飛び道具を跳ね返す処理ができます。
・飛び道具が相手に当たったときの処理
　処理の作り方によって、相手に当たった時点でいろいろなことができます。
　・普通に消滅する
　・キャラクターと同じ処理ならば打撃、投げなど特殊なダメージの与え方をする
　・飛び道具からさらに飛び道具を発生させる

５−１０．その他
かなり特殊な飛び道具の例です。
・武器を手放す、拾う
手放して地面に落ちた武器を飛び道具として扱うか専用の処理を設けるかは微妙なところですが、どちらでも解決はできます。
・武器を呼び出す
ドノヴァンのダイレクのように、手放した武器をさらにコマンドで操作したりするケースです。
飛び道具に対してプレイヤーキャラクター側で移動する軌道を設定できるような仕組みを用意してあれば飛び道具で実現できます。専用の処理でも作れます。