まあただ正常に動作しているのであれば無理に合わせる必要はないのでそのままでもいいとも思います。ただ頭の片隅にでもこのことを入れておいてもらえれば、何かあったときに問題を解決するヒントになるかもしれないです。って感じですかね〜。 なんとなく始めの本題とはだいぶ話が逸れてしまった気がしますが…(^^;

スプライトの出現（SPSET） スプライトの絵（画像）変更（SPCHR） スプライトの位置変更（SPOFS） スプライトの表示／非表示（SPSHOW／SPHIDE） スプライトの消去（SPCLR） ※ただし画像変更や位置変更はSPANIMでも可能。 スプライト関係の命令は他にもありますが関係性的にはこんな感じもあり、SPSETは引数によってはSPCHRと同じような初期状態を持てるのでSPSETでやってしまう人が多いように思います。 実際の内部ロジックまではわからないのでSPSETとSPCHRでどのぐらいの処理の差があるかはわかりませんが、SPSETはSPCHRと比べて絵を変える以外の初期処理もしているのではないかとも予測され、単純に絵を変えるSPCHRよりは処理が重いのではないかという気もします。（正確に計測したわけではないので実際のことはわかりませんが…）

違いますよ〜。絵を変える時って感じですよ。 たぶん今、絵を変えるときはSPSETしちゃってるんじゃないですか？　本当はもう既に表示しているスプライトの絵を変えるのであればSPCHRの方が適しているって感じです。

SPCHRはSPを使用する時じゃなくてスプライトのキャラを変更したいときですよ〜。なのでSPSHOWでの表示やSPOFSでの位置変更などとは無関係です。

りゅうまごさん、説明ありがとうございます〜。 その通りいわゆるアトリビュートで公式のマップツールにもあるのですが公式ツールではONとOFFしかないのでPUCHI-MAPでは0〜255までの値を設定できるように幅を広げました。 通常当たり判定などではキャラ番号で判定することが多いですが、アトリビュートを使うとマップキャラ単位で予め１だったら当たる０は当たらないなど自分で決めておいてプログラムではアトリビュートをチェックするだけで判定が出来るようなったりします。そうするとたくさんマップキャラの種類があっても一度で判定できるのでうまく使うと便利だと思います。 ただマップキャラ単位でマップデータ単位ではないので、見た目は同じでもアトリビュートが違うみたいな事は出来ません。（見た目が同じキャラを描いておけば可能ですが絵の容量が大きくなってしまいます）

SPDEFを使っているのにSPSETで細かく指定しているというところでおそらくきちんと機能を理解してない気がしますねー…。 こうやまさんの説明のSPDEFで絵の転送というのはちょっと違うような気がします。（便宜的に言ってるのかもしれませんが） SPDEFでGRPから指定した範囲の画像をスプライトとして定義（この時に原点や反転などの付加情報も決められる）しておいて、SPSETではその定義番号を指定するだけで前もって準備してあったスプライトを表示出来るようにする、みたいな感じです。 SPSETはスプライトを初めて表示する時に利用して、それ以外でキャラクターを変更するときはSPCHRやSPANIMなどを使用する、というやり方が一般的なやり方ではないかと思います。

正式というか正確には、かな…。 SPSETの書き方はSPDEFをしなくても表示できるだけで、SPDEFと同じ処理になるわけではないのですよー…。

正式には同様の処理ではないという罠…。

消すというか再定義で変える事は出来るって感じかなぁ

僕は最後には実は呼んでません…。まあでもテキストが見えなくなるようなら、それは解消させて終了してるかな…。適度な初期化を気分によってしてます。。。

ACLSは遅いのと初期化し過ぎるのが問題にはなりますが、それが許容出来る内容ならとりあえず使うのはありがと思います。 ただ通常は始めや最後に使うケースが多いとは思いますね〜。

いえいえー。色々あって、とても楽しそうな画面ですね！　しかもなぜか将棋のコマまで！？(^^; RPGの完成期待してます〜。頑張ってください！！

PUCHI-MAP使ってくれてありがとうございます〜。 マップデータは公式ツールとほぼ同じ形式なのですが、それを読み込むためにはプログラムが必要になります。（これは公式ツールでも同様） で、そのプログラムですが、僕のプロフィールにも書いてある「BGMAPサンプル集：VKA3NXAY」の中に含まれるBGMAPVIEWのサンプルが一番シンプルで再利用しやすいと思います。 このサンプルの1〜33行目（1行目は宣言なので一応なくてもOK）を自分のプログラムにコピーしてくれば、LOADBGという命令が使えるようになるので、 LOADBG "DAT:SAMPLEMAP2" のような感じで表示する事が出来るようになります。 （その辺は37行目からを参考にしてみてください） まだ不明点などがあったら言ってください〜。

ちなみにDATAはカンマ区切りや改行で連続していくつも書けますがBGに合わせて１行を横１列に合わせる事が多いですね。またその際にはその１行をどう管理するかというのがあって、カンマ区切りで１データをBG１つにする場合もあるし、文字列を使って１データに横１列まとめてしまう場合もあります。 文字列にする場合は、どの文字をどのBG（キャラ）に割り当てるかなどを自分で決める必要があるので、単純に１データに１BGよりは複雑になりますが、うまくやるとDATA文が見やすくなって、編集しやすいデータになります。 とまあ、色々あるんで聞きたいことがあったら聞いてください〜。 単純にプログラムのサンプルが知りたいだけだったら、僕の活動の日付：2014/12/19に「BGをREAD,DATAを使ってプログラムで配置するサンプル」があるんで、それを参考にしてみるのもいいかと思います。

返事がないようなので久しぶりに書いてみます。 まずどのぐらいプログラムを知っているかによって変わってくるんですが普通のプログラムは出来る感じですか？ DATAを使ってマップを表示するには、当然ですがREAD, DATAが使える必要があります。またマップを表示するのでBGPUT命令も必要ですね。 さらに大体はループして表示するんでFORなども利用する必要があります。 またDATAの形式は決まってるわけではないので、どういう風にデータを持つか決めないといけないです。それによってプログラムも多少変わってくる感じです。 どんな感じのが希望だったりしますか？　それによって回答も変わると思いますよ。

オートインデント（ON/OFF出来る）や自作命令や変数の自動補完（これはナルミンチョさんのオートコレクトと同様かな？）があるといいですね〜。基本的にプチコンはキーボードより入力が大変なので補助機能が多い方が嬉しいです。

やり方的には例えばランダムでRを決めた時にカウンター用の変数も初期化（たとえば60に）して、その変数が0になるまではループの際にはカウンターを引くだけにしてRは変更しないで、0の時だけまたRの変更とカウンターの初期化をする、みたいなやり方があります。 プログラムは書きたいですが今スマフォであまり文字を打ち込みやすくないので、代わりの人に任せるか、そのうち誰も書いてなくて時間が出来た時に書きますー

抜け出せなくなるパターンは同じところを回ってしまう事が多いと思うので、ある程度の移動軌跡を記録しておいてそれと同じ場所は移動確率を減らす（過去に近いほど確率は大きいとか）するとかもアリなのかな？って思ったりもしました。

昔は閉所恐怖症ではなかったですが、今は身動きできないほど狭いとちょっと怖くなる感じがありますねぇ…。

FILESの情報などでファイルサイズや更新日など、もう少し細かい情報が取れるといいなぁ、と思います。（出来ればソートして取得とか出来ると楽でいいかも…）