面白いですね〜。 実用はともかく、初心者がプログラムの流れを理解するのには向いてそうな気もするので、条件をつけた上でそっち方面にシフトして機能強化するといいのではないかと思ったりもしました。

せいらさんやツララさんの書き込みを見てて、なんとなく色んな電子楽器を作るのも楽しそうだなと思いました。楽器ごとに演奏方法（操作性）を変えてみると楽しそうですよね。 （バンブラになっちゃうかもしれませんが…）

エアバックも良いですね〜。 バグを事前や早く発見するためにもOPTION STRICTは重要ですよね。 まあ僕は１画面に収まる（収める）ぐらいの長さやサンプルの場合はつけないで書くことも多いですが、普通の長さになる場合はつけます。 規約を厳密にするのは窮屈と安全性のトレードオフですが、プログラムに慣れている人ほど安全性を重視するってことなのかもしれませんね。 まあでもせっかく宣言するんだから入力時の自動補完もしてくれればいいのにと思う事はあります(^^;

１３章ぐらいで完結しますかね(^^; プログラムで書くのはベターだとは思いつつもプチコンでの入力は大変なので、その手の解説などをプチコンでやるのは僕には厳しいです…。 Miiverseは独自の文化っぽくなってるかもしれないし、同じことを繰り返すのはしょうがないのかなと思いつつ、その繰り返しは以前教えてもらった人が今度は教える側になる形でまわってくれればいいなって思ったりしてます。 （なので僕は最近は回答を控えようと思ってます。でも補足はしてますが…）

仕事ならともかく、そうでない感じだともともと知り合いとかでもまとめていくのは大変ですし、あまり親しくない人だとかなり厳しくなるとは思います。 なのでみなさんの言われているようにリーダーの方が大事で、リーダーシップを発揮して計画性や各々の管理等、うまくコントロールする必要がありますね。 変数名がかぶるとかの技術的な面より、そっちの方が大変そうです。まあでも変数名に限らず役割がかぶらないようにした方がコントロールしやすいというのはあると思います。

この画面を見て一瞬ロードランナーっぽいなって思っちゃいました

本格的にプログラムを書くならOPTION STRICTはつけるのがオススメですよ〜。これは紙に書くとかの問題というよりはデバッグ上で大いに役に立ちますよ。

そんな命令はないと思いますが、VSYNCだとしたら、とりあえず目立ったバグの噂は聞いてませんね。

なるほどそうでしたか〜。僕は絵が描けないので無理ですが、描いてくれる人が現れると良いですね。 しものふさんは結構優しいと思います。ただどんな人だとしても、どのぐらいの時間で描いてくれるかまではわからないというか、忙しい人も多いから気長に待つぐらいじゃないと人に頼むのは難しいかも？　とも思いますねー…。

ちょっと補足するとみけらんジェロさんの言う変数を間違えているかチェックをする為には、プログラムの頭に、 OPTION STRICT をつける必要がありますよね。 あと補助輪というと上達したらつけなくていいような気もしちゃうので、もっと適切な言い方はないかなーって思いました。上級者ほどちゃんとつけてると思いますしねー。

あれ？　しものふさんに頼んでませんでしたっけ？

ちなみに公式ツールのマップ読み込みで一番シンプルに読み込むならこんな感じです。

マスクはビット演算を知らないと難しいのでわからないうちはスルーした方がいいかもしれませんね。 あとマスクの仕組みはバージョンアップで変わる可能性があります。というか今、なぜかマスクの0は全てにあたると言うことになってますが、それを改善（0はどれにも当たらない）になるかもと社長がTwitterで言ってたのを聞いた覚えがあります。

とりあえず僕の活動の最新でマップツールを公開しているのですが、その中に投稿コメントにサンプルの公開キーもあって（ツールとは違う公開キーです）、そのサンプルでBGを表示してるので参考になるかと。 他にも僕の活動の古いやつでもBG表示のサンプルを表示してるのもあるんで、そっちも参考になるかと思います。 基本的にマップツールで作ったBGはそれを読み込んで表示するためのプログラムが必要で、上記のサンプルにはそれが含まれている感じです。

６行目ですが、テキストは最終行（29行目）に表示するとスクロールしてしまうという特徴があるので、?(プリント）の最後（"のあと）に、;（セミコロン）をつければ自動改行が入らずに最終行に表示出来るようになりますよ。

処理速度に関してはそんなに難しく考えなくても大丈夫ですよ〜。 SPCOLをセットしたスプライトはシステム的に当たったかどうかを（裏で）判定している事になると思うので、判定するスプライトが多ければ多いほど実行速度が遅くなる、みたいなイメージです。 なのでまあとりあえず当たり判定の必要がないものはSPCOLしなければ良い、と考えておけば問題ないと思いますし、SPCOLしまくって実行速度が遅くなるようなことがあった場合は、思い出すようにしてみたらという感じです。

上画面の下に書いてあるようにY：FILEなので、Yボタンを押すとファイルメニューが出てきます。 ここでセーブ(SAVE)であるSを選択してfilename?の所にセーブするファイル名を入力すれば保存する事が出来ますよ。

基本的にはおふたりのように移動出来る座標を制限するために範囲外なら補正してあげればOKです。（それをしているのが追加されたIFですね） やり方としては、 X1=MIN(MAX(X1,0),399-16) と書く方法もあります。 これはMINとMAX関数を使うことでIFと同じような動作になるように数字の上限と下限を切り捨てて補正するやり方です。参考までに〜。

SPCOLはSPCOL 1のように引数だけで指定するとデフォルトのスプライトの大きさで当たり判定が出来るみたいです〜。 あと僕もSPCOLをわざわざしないといけないのはわかりにくいとは思いましたが、デフォルトが当たり判定あり（プログラムで外せる）としたとすると、デフォルトの動作が重くなる（当たり判定が多いほど処理的に重くなるはずなので）と思うので、デフォルトはなしになってるんじゃないかなとも思いますね〜。

キングさんのをベースにSTICK命令の結果は-1〜+1の範囲で返ってくるので、それを何倍かしてそのまま座標の変数に加算する、という方法もあります。 好きな方法で実現してください〜。