一応補足しておくと、みんなが話してくれたとおりですが、配列を理解して使い出すとLENは必ずと言っていいほど使いますね。 あとMID$やLEFT$等、最後に$の付いてる文字列処理命令は、その名の通り文字列を扱い出すと必要になりますが、使ってなければ不要ともいえます。もちろん文字列を文字列以外の用途（例えばマップデータなど）として利用すればそれはそれで用います。 MID$はLEFT$やRIGHT$を内包している処理でもあるんでMID$があればLEFT$やRIGHT$は使わなくてもなんとかなります。ただ用途によってはLEFT$やRIGHT$を使った方がとくにプログラムの意味合い的にしっくりくると思います。 あと例えばですが、アドベンチャーゲームでセリフを１文字１文字話しているように表示したいと思ったとき、あなたならどうしますか？　まあ、そういうことです。

もう一つの方法として、そのプログラムの説明をぬいぐるみに話しかけながらしていくという方法もあるようですよ。

個人的な意見になるので反対意見はあるかもしれませんが、僕はそう思っています。（条件判断には&&や||） ビット演算はボタンの判定など一部の命令では必須になってしまうので、その際はANDを使うって感じです。そしたら当面、あまりビット演算のORを使うことは無いんじゃないかと思います。 ということで注意点としては、 IF BUTTON() AND 1 THEN 上を押した時の処理 はビット演算でBUTTONの結果を判定しているので、&&にすることは出来ません。 ただ質問の条件判断に複数の条件判断をつけたいとき、というケースにおいては&&や||で問題ないです。

よく使う使い方としては、こんなのもありますね。 CLS FOR I=0 TO 64 X=I MOD 8:Y=I DIV 8 LOCATE X*3,Y:PRINT I NEXT ちょっと適当ですが、要するに一つの数字（位置）からXとYの位置を算出する際に、MODだとX, DIVだとY位置に出来るみたいな。

おかっぺさんが書いてくれたので別バージョンでもう一つ。やってることはおかっぺさんと同じです。 WHILE 1 B=BUTTON() PRINT "BUTTONめいれいのもどり";B VSYNC WEND 要は終わらないループを作るのが肝なので、あとはその作り方ですね。あと通常のループと違うのは、メインループの場合はVSYNCを入れて全体の同期をとる（調和を合わせる）のが前提なので、このおまじないをいれておくって感じですかね〜。

そうですね〜。公式に仕様と明言されてない以上はバグだとも思うのですが、ただBG１つ１つが個数としてカウントされるなら縮小すると画面に表示される数が増えるのは明白なので、数の上限がハードウェア的に存在するのであれば、それは仕様になってしまうのかなという気もしますし、どうなんでしょうねー…。

ソースを見てないのでわからないですがラベルが多いという事はGOTOやGOSUBが多いのかな？ 明確にループな箇所では、FOR, WHILE, REPEATなどを使ったりDEF（関数）の方を使うようにすることでラベルの出現頻度は減るので、まあ関数はともかくループに関してはループ命令を積極的に使うようにすると解決していく問題かもしれませんね。

固定するというのは要はその位置から座標を動かさなければいいのでX座標を変えずにアニメーションだけ切り替えれば良い感じになると思いますよ。 それで背景だけ動かしたいならBGOFSなどで背景をスクロールさせる事になると思います。 へたれさんの言うようにアニメーションを自動でやるならSPANIM、手動で切り替えていくならSPCHRですね。どっちがいいかはケースバイケースです。アニメーションが頻繁に切り替わる場合はSPCHRの方が便利な場合もありますが、SPANIMも自動で便利ですしね。

命令に関しては自分が必要になった時に覚えるというのでも十分だと思いますよ。理解出来ないものを無理やり言われても納得しづらいでしょうし…。 あとはプチコンの場合はプログラムが見れるので、色々な人のプログラムをダウンロードして、見てみるのもいいと思います。例えば上記の件ならダウンロードしたプログラムに対して、LENやMID$などの検索をかければ使っていれば引っかかりますし、引っかかればそれが何をしている部分なのかなどを理解していけば、それが必要なのか、なにが便利なのか、どういう使い方が出来るのかなどが理解出来てくると思います。 理解した上で使わなくても大丈夫だと思えば使わなくても良いし、便利だと思ったら使うという感じでもいいんじゃないかと〜。

一応そんな感じですが、色々と検討してみたいと思います〜。ありがとうございました！

「マップのファイルはステージ(街・フィールド等)ごとに用意するのか、大きな１枚のデータで表示位置を変えて使うものなのか」に関しては、それこそケースバイケースですね。 マップの最大サイズは決まっていますし、ファイル分割しても問題なければわけた方がやりやすい部分があると思います。ただ都度ロードが入ることにはなるので、ダンジョンなどである程度まとめられるものはまとめちゃうこともあると思います。 ただ一枚にまとめるとうまくやらないと隣がみえる、ということも出てくるので注意なのと、広大なマップを作る場合はどっちにしてもサイズ制限に引っかかるので地域によって分けたりなどの工夫が必要になると思いますね。

＞めがねさん バグ報告ありがとうございます〜。確認してみます！ １の下画面のガイドライン表示も検討して問題なければ対応してみます。 ２は確かにそうですね。というか僕も途中でそう思っていたのですが、すっかり忘れてました(^^; サンプルに関しては、そのマップのサンプルデータが欲しいですね〜。結局サンプルを作るのもかなりの手間になってしまうので、その提供があるならある程度は対応出来るかも…って感じもあります。 正直、マップの段差については正確にやるのは難しいというかケースバイケースなので通れる、通れないを組み合わせて出来ないものに関してはサンプルとしては難しいかなと思っています。 ただＡに関しては、マップのレイヤーの使い方次第なところもありますし、ＣとＤは想定していましたが、当たり判定やマップの書き換えかなって思ってるのでサンプルとしては出しやすいものかと考えています。

僕は条件判断なら&&や||を使ったほうがいいと考えています。それで明確にビット演算の時のみANDやORを使います。

了解です。頑張ってください〜。 ほんとツール系は、手を入れだすと次から次へとやっておきたいことや要望などが出てきて（自分でも出る）きりがなくなってしまいますよねー。 僕もその辺の区切りは難しく感じていますが、いつまで経っても出せないのも微妙なのでどっかでキリをつけてますね。（といいつつマップツールはまだ正式公開出来てませんが…）

僕と同じ症状かはわかりませんが、ＢＧは表示出来る数に限界があるようで縮小すると画面を埋めるのにその限界数を超えてしまうことがあって、そうなると超えた分は表示されないってことが発生しています。 これがバグなのか仕様なのかはわからないのですが、今のところは縮小表示の際に起こる不具合だと思っています。

PUCHI-MAP v0.92(DEBUG版) ファイル名：PUCHIMAP / 公開キー：NKAKXE3X 更新です。普通の利用法では起こりにくい症状ですがエラーで止まってしまう事が発生したので修正しました。 よろしくお願いします。

２は文字列が行をまたいでしまったときに選択できないって感じです。上で言ってる文字を送れてないってのにも影響してるのかな？？？ あと下ボタンで候補呼び出しでも大丈夫そうな気がします。基本的に文字選択は横に広げる感じなので、ＰＣの変換でも縦に選択を広げることはあまりないような気がしますし…。

SPSET 0,0で、SPSET 管理番号,定義番号（キャラクタ定義）なので、今は管理番号０にキャラを割り当てて表示してます。 管理番号は自分でつけるもので、同じ番号だと今出しているものに対しての指示になります（なのでSPOFSで0番で位置を変えている）が、別の管理番号を使ってキャラを表示すれば、一度の複数のキャラを出す事が出来ますよ。

将来的にはFORは覚えておいたほうがいいですよ〜。 あえて二人と違う書き方をするなら、 N=1 FOR Y=0 TO 9 FOR X=0 TO 9 BGPUT 2,1+X,1+Y,95+N N=N+1 NEXT NEXT まああまり変わらないか…

FORが無い時代？に生まれていたかと思うとゾッとしますね