R-1) 初期処理
R-2) イベント発生フェイズ
R-3) [Player's Turn] ユニット選択
R-4) [Player's Turn] 移動先座標選択
R-5) [Player's Turn] 最短移動
R-6) [Player's Turn] 攻撃相手選択
R-7) [Player's Turn] 攻撃処理
R-8) サブルーチン：生存判定
R-9) [Enemy's Turn] 最適探索
R-10) [Enemy's Turn] 敵さん側最短移動
R-11) [Enemy's Turn] 攻撃処理
R-12) サブルーチン：生存判定
R-13) ターン終了処理、R-2) に戻る

R-1) 初期処理
マップの初期化やロード、音楽を鳴らす云々で、プログラムを書いていると絶対に必要になる部分です。また、ステージスタート時の会話もここに含む場合があります。それゆえに初期「設定」ではなく、初期「処理」としています。

R-2) イベント発生フェイズ
ここから１ターンが始まります。特定ターンにおける会話イベントなどはここで発生します。なお、１ターンというのは、全キャラクターが行動を１回終了するまでの時間のことです（ＳＬＧ以外では通例サイクルと呼ばれます）。フェイズあるいはフェーズは、１ターンの中の特定の流れを示す言葉です。「移動フェイズ」「戦闘フェイズ」などと使われます。

R-3) ユニット選択
どのプレイヤーキャラを操作するかを選択する部分です。前回のサンプルアプリにもちゃんとありましたね。実際のＳＬＧではキャラに合わせてボタンを押すと、行動の内容を選択するメニューが出たりしますが、今回はそれらはやりません。即移動にしちゃいましょう。

R-4) 移動先座標選択
サンプルアプリで実装済み。移動可能地点の表示と、光らなかった場所はクリックしても動けないよ、という処理までここに入ります。

R-5) 最短移動
選んだ地点に行くための経路はすでに計算されているので、あとはその通りに動いていくだけです。とことこ。

R-6) 攻撃相手選択
移動終了した地点の隣接もしくは攻撃可能地点に敵さんが居た場合、攻撃に移れるわけですが、対象が複数居た場合はどれを狙うか選択することができます。その処理です。

R-7) 攻撃処理
読んで字のごとく。アニメーションが本来入るわけですが、鷹月はむろん実装するつもりはないです。それはそうと、ダメージの与え方などは各人のデザイン能力が問われます。この講座では、鷹月ぐみなが９５年に発表したＴＲＰＧシステム「サイラジア・ワールドＲＰＧ」のダメージ判定処理をそのまま使います。改めて考えなくて良いから楽〜。

R-8) 生存判定
ダメージを受けてＬＰが０になったら生存判定です。サブルーチンとわざわざ書いているのは、R-12) で全く同じ処理をするからです。こう書いてあれ、と思った方はいるかな？
確かにR-8) はダメージを受けたのは敵側だろうから敵側の生存判定、R-12) はプレイヤー側の生存判定というのが基本的なんですが……そこはそれ、範囲魔法で自分も巻き添えをくったりとか、反撃されてやられたとか、将来の拡張目的というやつです。

R-9) 最適探索
前回のセッションで解説した、敵さんそれぞれの移動目標地の探索処理です。

R-10) 敵さん最短移動
移動のルーチンは、R-5) とまったく同じです。動くキャラクターが違うだけ。

R-11) 敵側攻撃処理
もちろん敵側にも、攻撃相手選択のルーチンはあるんですが、それらは攻撃処理の中に統合できます（別に切り分けても構まなかったのですが……）。ユーザにウェイトを入れるか入れないかという差で選んでみました。

R-12) 生存判定
R-13) ターン終了処理、R-2) に戻る
実装はしないでしょうが、ターン終了時まで有効な魔法だとか、ライフの回復とか、ゲームの場合はいろんな要素が出てきます。それらのステータスを調整する処理がここにきます。

　以上です。生存判定から全滅時の処理などに分岐したりしますが、それらは流れからは余剰だと思いますので今は無視します。ともかく、ここに示した基本と言うべき流れのＳＬＧシステムを実装する事が、このＳＬＧ講座の最終目標としましょう。ようやく完全なビジョンを示しました。そう、講義を終わった頃には、この程度のＳＬＧが作れる知識をＧＥＴしているというわけです。

S-1) 初期設定
S-2) [Player's Turn] ユニット選択（但し１キャラのみ）
S-3) [Player's Turn] 移動先座標選択
S-4) [Player's Turn] プレイヤー最短移動
S-5) [Enemy's Turn] 最適探索
S-6) [Enemy's Turn] 敵さん側最短移動、そして S-2)に戻る

敵さんＡ：猪突猛進型（ひたすらプレイヤーを追いかけてくる）
敵さんＢ：通常型（ＰＣとの単純距離差が１０以内なら近づいてくる）
敵さんＣ：守備型（ＰＣとの単純距離差が３以内になった所で近づき、以後は距離に関係なく常にプレイヤーを追いかけるＡ型になる）
敵さんＤ：ピボット型（ある地点から単純距離半径６以上の地点へは何があっても進めない。その範囲の中でプレイヤーに近づこうとする）
敵さんＥ：アーチャー（単純距離差が１０以内で近づくのだが、主人公からの単純距離差が３になる地点を確保しようとする）

... 何これ？（爆）

　あるマスへ移動可か不可かは、セッション３で紹介した探索ルーチンを使うわけですが、この判断はあくまでマップ地形からしか判断していません。キャラの存在を考慮していないわけで、このままだとキャラ同士が同じマスに重なってしまう可能性が出てきます。もちろん原則的にあってはならない事象なので、解決させなくてはいけません。
　方法としては、移動可能地点探索のさい、キャラのいるマップチップの移動ウェイト値を５０あたりにしておく事が考えられます。こうすると壁同様、絶対に止まれないからです（※１）。それはそれとして、「キャラがそのマスの上にいる」というのはプログラム的にはどう判定させると良いでしょうか。二つの方法が考えられます。

Ａ） 各々のマスに対して、その上にあるオブジェクト情報を付与する
　単純な二次元配列で解決する方法です。変数では objp[x,y] のように表します。この中に入る値として、「０：何もいない」「１：プレイヤー１が居る」「２：プレイヤー２が居る」……「１１：敵さん１がいる」「１２：敵さん２がいる」……という事にします。探索の際に対象のマスに対して、何かキャラが乗っていることがすぐ分かるだけではなく、どんなキャラが乗っているかまで一瞬で分かり、便利ではあります。しかし、マップの広さがたとえば２５６×２５６マスだった場合、６５５３６個の配列を必要とし、相当のメモリを消費する事になります。やむを得ない場合は良いとは思うのですが、たかだか今回のシステムではプレイヤー１キャラ、敵さん５キャラの６つのオブジェクトしかないのにこれはちょっと贅沢すぎます。

Ｂ） 全キャラの居場所を調べる
　Ａで丁度キャラクター毎に番号が一意に付いているのでそれは採用しましょう。プレイヤー１はキャラクター番号１番、敵さん１はキャラクター番号１１番という感じになります。さて、プレイヤーも敵さんもキャラクターと考えるなら、ｉを番号として、x[i]、y[i] という配列でその座標を一まとめにして格納することができます（x[i]: キャラクターiのｘ座標、y[i]: キャラクターiのｙ座標）
　それともう一つ、sta[i] という配列を用意します。これは、キャラクターiのステータスを示し、たとえば「d」が入っていたら死亡していることを示します。これだけ定義ができれば、ソースコードも書くのに苦労は要りません。探索ルーチンSearch() が座標ax,ayについて、そのマスに誰かキャラクターが居るか居ないかの判定は次のようになります。（Delphiソースの場合）

begin // プレイヤー側の探索ルーチン
  flg:=0 // フラグを初期化する
  for i:=11 to 15 do begin // 敵さんそれぞれに対して、
    if sta[i]='d' then continue; // 死んでるならマップに居ないだろうから無視
    if (ax=x[i) and (ay=y[i]) then flg:=1; // 該当すればフラグを立てる
  end;
  if flg=1 then 「この場所には誰かがいるので移動できないと判定」
  else 「この場所には少なくとも誰もいないと判定」
end;

　もちろんプレイヤー自身はこの判定に加える必要はありません。多少、処理するのに時間がかかりますが、敵５匹程度ですから、気にするほどの処理落ちは出ないと思います。
　まあ今回は後者の方法を採択することにしましょう。
　それはそうと、さきほど「※１」と注意マークを付けておきました。「キャラが居るマスを壁同様に扱う」、これは正しいでしょうか、それとも間違っているでしょうか？
　これはどちらでも致命的にはなりませんが、ＳＬＧのシステムが微妙に変わってきてしまいます。壁同様にしてウェイトを高くしておき、「ここ以上は進めない」としてしまうと、ゲーム中において、相手キャラは当然としても、味方キャラを越えて先に行く事ができなくなります。逆に、ウェイトは元のマスと同じだけど、単にその場所へは止まれないとした場合、そのオブジェクトを通り抜けることができます。この折衷案を取り、「自分のキャラだったら単に止まれない、相手のキャラだったらウェイトをかけておく」とすると、味方は通り抜けられ、敵は通り抜けられないというシステム（タクティクスオウガはそうですね）ができあがります。今回は単純な１番目（味方だろうと敵さんだろうとそこで進めなくなる）を採用する事にします。

　今回使おうと思っているマップチップは32×32ピクセルですが、キャラクターは32×48という、１マスを出るサイズの大きさです。この場合、ちょうど上下に並んだときに、キャラ同士が重ね合わさる事になります。

	← ちょうどこうなってくれると良いんですが……
	← 時にはこうなってしまう可能性もあるということです

Ａ） グラフィックシステムがＺレイアをサポートしている場合
　Z-Layerとは、オブジェクトの表示順を設定するための「グラフィックプレーンの高さ」の概念の事です。これをグラフィックシステムが最初からサポートしている場合、キャラクタに高さ情報を指定することにより、自動的に重ね合わせの順番を判定し処理してくれます。Ｚレイア値は高いほど手前になります。（階層と思って、あなたはそれを上から眺めていると思ってください）これがあると実装が楽です。
　具体的には、各キャラクターのＺレイア値を動的に、そのキャラクターのｙ座標に等しい値にするだけです。表示は誰を先にしようが後にしようが同じ結果になります。今回鷹月が使おうと思っているシステムは、TGWがＺレイアをサポートしているので、こちらを採択します。うーん、楽。

Ｂ） レイアのないグラフィックシステムの場合
　たとえば標準のままのHSPはレイアをサポートしていません。重ね合わせるというのは、単に上塗りしていくだけの事になります。この場合、表示（作画）する命令の順番が重要になってきます。まかり間違っても、Ａで恐らく使うことになるでしょう、

  for i:=11 to 15 do
    キャラクター表示(x[i],y[i],パーツ番号i);

// --------- For Delphi.

// ローカル変数の設定
var temp,temp2:integer;
    a,b:array[11..15] of integer;
begin
  // a[i]はキャラ番号、b[i]はそれぞれのｙ座標を入れる
  for i:=11 to 15 do
  begin
    a[i]:=i;
    b[i]:=y[i];
  end;

  // セレクション・ソート（昇順）
  for i:=11 to 14 do
    for j:=i+1 to 15 do
      if b[i]>b[j] then 
      begin
        // a[i]とa[j]を入れ替える。テンポラリが要るのがミソ
        temp:=a[j]; temp2:=b[j];
        a[j]:=a[i]; b[j]:=b[i];
        a[i]:=temp; b[i]:=temp2;
      end;

  // こうして、a[i]には表示順が入っているわけですね 
  for i:=11 to 15 do
    キャラクター表示(x[a[i]],y[a[i]],パーツ番号a[i]);           
end;

- 鷹月 ぐみな