ほとんどOKそうですね〜。あとコータさんのサンプルに付け足すとしたら、文字列を返す関数の場合は、関数名に＄をつけるぐらいですかね。

こういうのも面白いですね〜。ただやっぱりキャラの関係で公開キーは認められないんですかね。ダウンロードしてみたいのに。

年内は無理だったようです…。 1月7日予定らしいですよ。

喜んでもらえて嬉しいですが、本当に役に立つかは不明です(^^; とりあえず公開目指して頑張ります！

ロードの時のピーガガ音が世代的に心地良い…

あ。ちょっと問題があるかもです。 定義画像とは関係ないですが、それを読み込んだファイルはそのままだとたぶんSPDEFの配列としては利用できないんじゃないかと…。その４つだけ削らないとSPDEF単体の命令では読み込めないんじゃないかと思います。（僕は定義ファイルを使ったことがないので推測ですが）

コメントありがとうございます！ ゲームの方はやるとしてもこれからって感じなので、まだまだ先かも…。てかまだちゃんとやるかも未定ですが(^^; ツールの方は簡易的なもので多機能ではないですが、とりあえず定義されているスプライトを確認するのに便利なようにしたいとは思ってる感じです。 スプライトの勉強をして試すときなどのスプライト選びなどに利用してみてください〜。

始めの４つの数字は、 ID（DEF:の文字列のアスキーコード） バージョン（今は１） 予約（０） 予約（０） みたいなので、その４つだけ無視すればあとは定義データが連続して入ってるだけみたいですよ。参考になれば。

反応くれた人がいるので、大した内容ではないですが、今夜めどに公開出来るように調整してみますね。

スマイルツールでも確認出来ますが、手っ取り早くスプライトの定義番号のキャラを表示して確認するための簡易ツールを作ってます。キャラ定義はキャラ画像とも違うので確認しづらいなぁ、と個人的に思っていたので…。 来たるべき自作ゲームに備えて（あるのか？！）って感じの個人的なツールなのですが需要がありそうなら公開するしなければまあいっかなレベルなんですが、どうでしょうねぇ。 まあほんと手抜きの簡易ツールなので微妙なのですが…。

キャラクタを動かせたと言うことは、その為のX座標やY座標の変数があるということですよね？ 画面外に出ないようにするには、その変数の範囲（座標）が画面外に行かないように調整してあげればいいことになります。なので、IF（条件文）で座標が画面外の位置（マイナスや画面サイズより大きい）になったら、その座標を強制的に画面内の位置に変更してあげればいい感じです。

プレイ専用のプチコンビューワーを無料で公開して欲しいです。割と本気で…。（公開キーからのDLだけでもいいので）

いえいえー。動きの感じは面白いと思いますよ。 ただジャンプがアナログの上なのがちょっと違和感があるんで素直にジャンプボタンにした方がいいんじゃないかなー、という気もします〜

最後に今回のプログラムをDEF命令に変更したリストをアップします。 同じ名前の変数が重複しているのに問題が起こってないことがわかると思います。

そうですね〜。というかなんでユーザー定義命令や関数が必要なのか。あった方がいいのか。みたいな感じですかねー。本当はもうちょっとちゃんと伝えたかったのですが、どんどん本来の趣旨の問題と解答というところから外れそうな気もして余計なお世話泣きもしたんでやめました(^^; 4は確かにそうすれば例のバグでも衝突は起きないので便利かもしれないですねー。一つの例としてはアリですね！ 僕の場合は、どちらかというと「らしさ」というのを重視してるところもあるんで、プチコンとかBASICらしさみたいなのはあっても良いと思うので、GOSUBやGOTOを禁止にするとか、そういうことはしなくてもいいと思ってたりもします。ただその危険性や問題点をわかったうえでならいいんですが、そうじゃないと無駄にバグに見舞われたり、スパゲティーなソースになったりとあると思うので、良い方法は知っておいては欲しいですね。

ちなみにオマケですが、DATA文で僕のリストは数字が２つ毎にスペースが入ってるのに気づきましたか？　これは読み出し側のX,Yに合わせて区切った感じで、こうすることでデータが見やすくなるというちょっとした工夫です。 あまり長文を書いても読むのが嫌になると思ったのでこのぐらいにしておきます！　質問疑問等があったら続きで語りましょう！　では、あでゅ〜

パターンC: サブルーチンをDEFに変更すると上記の問題は発生しなくなる。なぜならサブルーチンないの変数はその中専用のローカル変数になるので、呼び出し側の変数（グローバル）を書き換える可能性がゼロになるのだ！ でもでもプチコンにはバグがあって変数の二重定義のエラーが出ることが…。これはバージョンアップで直る（はず）です…。 ということでCが一番理想的なわけです。 あれ。そもそも不具合の原因書いてなかったかも…。 まあみんな正解なので、解説は他の人の書き込みを見てください！　とくにけいさんの書き込みは細かいので参考になると思います！ ということで終わり…。なんか言いたいことがうまく書けなかった…。

とりあえず理由だけ簡潔に…。あとは質問があったら対応にしようかな…。以下、理由です。 パターンA: サブルーチン側のIという変数はループカウンタとしてよく使う変数なので今回呼び出し側のIを変更してもまたどこかで同じミスをしてしまうかもしれないので危険度は高い。ただし一箇所の修正で済むので今後改修の予定などがなければアリかも。 パターンB: サブルーチン側の変数をあまり使われない名前にして衝突が起こらないようにする。この名前を適切にすれば呼び出し側が変わる危険度はだいぶ減るでしょう。ただ危険度が０になったわけではないのがちょっと問題。（GOSUBの範囲での修正ならベストかな？）

今回のケースはGOSUBを使ってるとありえる事じゃないかと思って問題にしてみました。今回はシンプルな問題なので見つけやすいですが飛び先が複雑な感じだと見落としてわからない、なんてケースもあるかなぁ、とか。 それで今回のケースの回答で来ると思われるパターンを３パターン考えていました。 A: 呼び出し側のFORループのカウンタ変数を変更する。 B: サブルーチン側のFORループのカウンタ変数を変更する。 C: サブルーチンをDEF（ユーザー定義命令）に変更する。 です。 この中で一番多いと思っていたのがAで修正も１箇所です。他、B,Cとなる毎に修正箇所が多くなってきます。 ただし理想的な変更としてはC>B>Aとなります。 って書いてて長くなりそうな気がしてきた…。どう端折ろうかな…

日も変わったし総評を。 てか思ったよりたくさんの書き込みがあって良かったです。閑古鳥が鳴いてたらどうしようかと…(^^; 難易度は高いような低いようなという感じで気づけばすぐみたいな感じでみんな正解でしたね〜。さすがです。このぐらいもう敵じゃないですね〜。