ミニマップですが、別にこれもローグライク必須ってわけでもないのでTIPSの方に。
通路の壁を描画するタイプと床を描画するタイプがありますが、床を描画するタイプでつくってみます。
当然ながら、マップ座標の1マスごとに1ピクチャ使って描画していきます。
なのでマップサイズが100×100だったら、最大1万枚+αのピクチャを使うので、どこかにミニマップ用のピクチャ番号をどかんととっておくといいと思われます。
さて、とりあえず床のドットとなる小さなピクチャを用意しましょう。
1×1ピクセルだとさすがに小さいですが、2×2ピクセルとか3×3ピクセルとかでいいと思います。
で、なるべく処理を軽減させるために、ランダムダンジョンを生成した時点で、あらかじめ不透明度0で全部ミニマップを表示してしまいましょう。
マップ横サイズ×マップ縦サイズ分ループさせて、移動可能なマスには床ピクチャを描画します。320×240なら1マス16ピクセル、640×480なら1マス32ピクセルなので、ここらへんを使えば画面上の描画座標も簡単に取得できそうです。
あと、マップ座標とピクチャ番号に互換性を持たせるとのちのち便利ですね。
こうしてあらかじめ不透明度0で描画しておくことで、1ターンごとの処理が主人公とその周囲の床ピクチャをピクチャ移動で不透明度255にすることだけで済みます。
ローグライクではとにかく処理の重さに余裕がないので、極力処理量を減らす努力が必要ですね。
で、床描画ができたらオブジェクト系をその上のレイヤーに描画していきます。
こちらでもオブジェクトのIDとピクチャ番号に互換性をもたせて、移動処理のついでに自分のピクチャのミニマップを動かしたりすると楽なんじゃないかと思います。
1ターン処理を呼び出すトリガーとなるPC操作イベントをつくっていきます。
基本的にPC操作イベントはキー入力受付を無限ループさせるイベントですね。
並列実行のイベントでキー入力を受け付けてもできなくはないですが、自分がローグの崖を作った経験からすると、並列実行イベントはバグの温床なので、極力使うのを避けたいところです。
中身はこんな感じ。「1ターンの処理を実行」から呼び出されているイベントです。
[ループ地点]
キー入力受付：決定、キャンセル、四方向、サブetc…
↓
条件分岐
1．決定 攻撃処理を呼び出してループ中断
2．キャンセル メニュー処理呼び出し
3．四方向 移動可能なら移動させてループ中断
4．サブとか 方向転換とかその他もろもろ呼び出し
↓
ウェイト1フレーム
[ループ地点へ戻る]
簡略化したものですが、だいたいこんな感じです。
ようは、ループ内でキー入力を常時受け付けるようにしておいて、キー入力されたらそれに対応するイベントを呼び出し、なおかつターンを進める場合はループ中断して、このイベントを呼び出している「1ターンの処理を実行」イベントに戻ってNPC操作なんかを進める、という感じですね。
並列実行のイベントではないので、NPC操作中にキー入力を受け付けてしまってターン処理が二重に呼び出される、とかいうバグも防げます（ローグの崖ではそれで何度泣いたことか…）。
あとは状態異常で行動不能になっていたり行動制限がかかっていたりする状態なんかを追加していけば、PC操作はわりと簡単に完成するんではないかと思います。
ターン制を曲がりなりにも実装したので、いよいよAI構築に入っていきます。
ローグライクではこのAI行動処理を1ターンごとに、存在するオブジェクト数分ループさせるので、超高頻度で呼び出す処理になります。
そして、お分かりでしょうが、このコモンイベントの内容によってゲーム自体の処理の重さが決まってきます。
自分でもローグライクを作った結果、快適速度で主人公を移動させつつ、処理の重さを気にさせない（コンマ以下のつっかかりが気にならない程度の）コマンド数はだいたい1ターンに2～3万が限度ってところでしょう。
それ以上を超えてくると、移動のたびに体感できるレベルでつっかかったりするので、とにかく無駄な処理を省くつもりで作っていきたいところです。
で、AIをつくるまえに自分なりに思ったことを書いておきますが、ここの処理は意図的に簡略化させた方がよいです。
気合入れて「超高度なAIつくってやるぜー！」ってつくりだすと、かなり後悔することになります。
AIは必要最低限にしておいて、ゲームの深みは攻撃処理とかで出せばいいや、くらいの気持ちでつくっていくとちょうどいいんじゃないかと思います。
サンプルは以下の通り。
1．行動可能判定。行動不能なら終了。
2．攻撃判定。使用できる特技に応じて、特技の効果範囲内に敵がいるか判定。敵がいたら攻撃処理を呼び出して終了。
3．攻撃しなかった場合、移動判定。移動するのであれば座標関連のDBを動かして、キャラピクチャ（ないしイベント）の移動描画処理を呼び出す。
シンプルですが、だいたいこんな感じになるのではと思います。
移動判定に関しては、目的座標とか目的オブジェクトとかいう概念を活用するとつくりやすいでしょう。
目的が設定されていればその座標ないしオブジェクトに接近するように行動、目的が設定されていなければ、近くに（自分から見て）敵状態の生物がいればそいつを目的に設定、みたいな感じで。
純粋な不思議のダンジョン系ローグライクの場合は、フロアの循環のために、目的座標に部屋の入り口の座標なんかを利用することになりそうです。
AIは作り込めば作り込むほどゲームの奥深さを増す可能性がありますが、作り込んだ分だけ処理が遅くなるということを常に頭に入れておくとよいと思います。
15/01/06改稿
メインループから呼び出される、1ターンの処理を実行するコモンイベントをつくっていきます。
まぎれもなく、ローグライクの根幹たるコモンイベントです。テンションがあがりますねぇ（）
おおざっぱな内容はこんな感じ。
[ループ地点]
プレイヤーの操作受付
↓
分岐1：プレイヤーが何らかの行動をした場合
NPC操作
状態更新
（この過程でプレイヤーが死亡したらループ中断して、メインループからゲームオーバー処理を呼び出す）
分岐2：プレイヤーが階段を下りた場合
ループ中断して、メインループから階層を更新する処理を呼び出す
分岐3：プレイヤーが何もしなかった場合
ウェイト1フレーム
↓
ループ地点へ戻る
ということで、みれば分かりますがローグライクをやっている間はこのコモンイベントを延々とループさせ続けます。
要するに、プレイヤーがなんらかの操作をするのを監視して、操作されたらNPCを動かしたりするって感じですね。
何の入力がなくても、ウェイト1フレームを入れてあるので、もちろん50万エラーにはなりません。
階段を下りたりゲームオーバーになったりするのは大きく場面転換する処理なので、ここでは行わず、一度メインループまで戻してから、メインループから直接呼び出してもらうことにします。
なんだかひどく簡素に見えますが、これで後はプレイヤー操作とかNPC操作とかの中身をつくっていけば、ローグライクが完成しちゃうんですね～。
ね、簡単でしょ？
15/01/05改稿
いよいよローグライクの中身ですね～。
ダンジョン生成が終わったら、次にアイテムやワナやキャラをどうやって管理するか考えることにします。
・アイテム管理
まぁいろいろ方法はあるでしょうが、個人的には全マスDB+アイテム個別IDでピクチャを使った管理をお勧めします。
アイテムを置くときはマップの全マスの配置アイテムデータを保存しているDBにアイテムの個別IDを書き込み（X5Y10にアイテムID3を置くんだったら全マスDBのデータ5項目10に3を代入とか）、アイテムが拾われたり消滅したりしたら全マスDBから消去する感じですね。
それから、アイテム情報の管理はひとつのDBにまとめてしまうことを強くおすすめします。
装備も消費アイテムも、落ちているアイテムも持っているアイテムも、全部ひとつのDBにまとめておいた方が後々絶対に楽です。処理が簡単になる＝バグを減らせるので。ローグの崖で痛い目にあった僕がいうので、これは間違いないです…。
手持ちアイテムの管理については、こちらもいろいろと方法があるでしょうが、個人的には手持ちアイテムのID（102、103とかの数字）をだけを保管するDBをつくって管理することをお勧めします。
もちろん床落ち状態と区別するために、アイテムのステータスとして「手持ち状態」と「床落ち状態」を区別する項目は必要になりそうですね～。
そういえば、ワールドフロンティアでは主人公専用の手持ちアイテムDBを廃止して、キャラクターのステータス内に文字列で手持ちアイテムなる項目を設けました。
こうすることで敵も主人公と同様複数のアイテムを持てるようになったりして管理が楽になることもあるので、興味のある方はそっちの方の記事もご覧いただければと思います。
・ワナ管理
長くなりましたが、ワナ管理です。
こちらは性質上アイテムと似ている（アイテムやワナと同じマスに共存できない）ので、ほとんどアイテムと同じで構わない気がします。ワナ用の全マスDBをつくって各マスにあるワナ情報を保存、主人公が一歩動くたびに全マスDBを参照して、ワナがあるんだったら起動、壊れたら消去みたいな感じで。
アイテム管理を作り終えた人なら、特につまることもないのではと思います。
・キャラ管理
キャラ管理も実はアイテム管理と似たような感じですね～。
全マスDBをつくってキャラの位置情報を保存、キャラが移動するたびに情報を書き換えるだけです。
ローグの崖ではキャラの管理はマップイベントを使っていましたが（配置したらグラフィック変更・死んだら透明画像にグラフィック変更みたいな感じ）、全力でピクチャによる管理を推奨しておきます。
やってみると分かるんですが、マップイベントだと主人公と他キャラとの間に微妙な動作タイミングのズレが生じるんですよね。
他にもいろいろ不便なことが多いので、キャラ管理はピクチャによることをお勧めしておきます。
表示座標はマップチップのサイズ×マップ座標+αで、方向なんかはパターン番号や自動パターン切替を使えばどうにかなりそうですね。
