横から失礼します。 ループするラベルの他にIF文が成立したとき用の別のラベルが無いからじゃないです？ ちなみにTHENの後ですぐ改行しなければENDIF要らないですよ。

スプライトの座標を決めるのに使っている変数SXとSYの値を変化させる式が変じゃないです？ 左右にだけ動くようにしたいなら変数SYの方は変更しなくてもいいはずなので、りゅうまごさんも指摘されてますけど、７行目は SX=SX+X*4 として、８行目は消しちゃえばいいんじゃないです？ ちなみにスライドパッド入力からの値は傾けてない時を0としてプラスとマイナスで返って来るので、変化量はそのまま足し算で問題無いんですけど、８行目で-Yを使っているのは、表示座標だと下方向がYがプラスの方向になるからマイナスで向きを反転させてるんですね。

クイズは罰ゲーム盛り上がりますからねー。 アメリカ横断ウルトラクイズの○×ドロンコダイブとか、後半になると現地のアトラクションを絡めた手の込んだ罰ゲームあったり。

タッチされた瞬間の判定は、TOUCH命令でタッチされている時間を取得する変数の中身が0（タッチされてない）の時に0ではない数値（タッチされている）になったという判定をしてやればいいので、ループの中のTOUCH命令の直前にOLD_Tみたいな変数を用意しておいて、先ずその変数とTOUCH命令実行後のSTTMを比較するみたいな「タッチされた瞬間判定」を作ってやる必要ありますね。 指定の場所は定数、というか予め最初に変数で定義しちゃうと楽だと思います。 ちなみに範囲を指定するときの比較演算子は「==」を使うと『点』の判定になっちゃうので、「>」や「<=」とかを２つ使って『線』の判定にして、それをX軸とY軸分の２つ用意すると四角形の範囲を指定できますよ。 円形や三角形の範囲を指定したいとなるとややこしくなったりするんですけど、不可能ではないので、余裕があったらチャレンジしてみるのもいいかも？

GPUTCHR()命令でスプライトやBGにこの文字で意味深なプログラムを書いて背景に使ったりしたら、怪しげな雰囲気出そうですね。

普通に英文で大文字と小文字を使い分けする理由と同じだと思うんですけど、単語や文章の始まりがどこなのかが分りやすくなるのが使い分けする利点なんじゃないです？ プチコンだとOSPみたく1行にむりくり詰め込む書き方するとかじゃなければ、一行に一つの処理を書いていけば読みやすくなるので、使い分けはそんなに必要無いかも。 確か変数名も大文字小文字の区別しても綴りが同じなら同じ変数として扱われますよね？ あるとすれば気分の問題？

回数に応じて「貴様、そんなにやりたいのか？」みたいな憎まれ口や、しばらく放置すると「いつ連打をやめろと命令した？」とか煽り文句を表示したり・・・ で、100回達成したらしたで 「気に入った、このゲームをプレイしてもいいぞ！」なんて・・・ ・・・うーん、元ネタ知っててもムカつきますね。

うーんと、このプログラムで言うと弾の部品は変数SX,SYと発射フラグの変数Fと文字列の"-"ですね。 で、出したり消したりする仕組みをLOCATE命令とPRINT命令とCLS命令で実装と・・・ 11行目のIF文で、ボタンを押されたらF=1して発射中の状態にしてますよね。 とすれば、12行目の実際に弾を表示する処理の部分はFの値に応じて、実行するかしないかを選択する必要が出て来るのでは？ 13行目で弾の横座標が画面端に来たらF=0して表示しない様にしているのと同じ処理を、表示する処理にも応用してやれば・・・ お手上げするのはまだちょっと早いっスよ。落ち着いて。

魅了：敵味方が逆になる。 ズッコケ：次の行動が一回キャンセル。 あくび：3ターン後に眠り。 パニック：混乱状態が仲間にも伝染。 しゃっくりはなった時じゃないとあの辛さは分かんないですよねー。

ホタテの貝殻っぽいですね。

プログラム中でリセットするなら再設定というか上書きするのが常套手段だと思いますけど、記述が長くなるのが嫌ということならDEFでまとめちゃえばいいんじゃないです？ グラフィック系命令でも既に他の絵を置いてある領域を使いたいときは透明色で上書きして消すか、クリアー系命令で消去してから使いますし。

自然な感じですねー。 表示されてる地形の端の断面は、表示内の段差の壁面と少し色を変えてみたりするといいかも。

もう３人もホームってますね。

配列にDATA文を一気に読み込ませるのは他にCOPY命令を使う方法もありますね。 別途読み込む時の目印にするラベルを作らなきゃいけないのでちょっと面倒ですけど、要素の不足分は自動で追加されたりしますし。 COPY A,"@NUM",10:COPY A$,"@WORD",10 @NUM DATA 0,…,10 @WORD DATA "かきくけこ",…,"わ　を　ん" みたいな感じで。

DEF 関数名 OUT A A=45 PRINT A END みたくDEFの中で使った変数をOUTの後に書いておくとDEFの外に取り出しておけたりしません？

アドバイスするとしたら、ものを作る時ってまずサンプルを分解して同じ様に組み立てて動作確認するのが基本だったりするので、サンプルプログラムをいじって画面がぐちゃぐちゃになった時に、『「どこ」を「どういじったら」こうなった』っていうのを覚えておくといいですよ。 例えばこの会話プログラムも、顔の部品にしている文字列の所とか、分りやすい部分から色々変えてみるといいかも。 そうすれば差し替えても大丈夫な部品っていうのが分かって来ると思いますよ。

このソフトの遊び方って、「砂場があります。さぁ遊べ！」みたいな感じですからね。 お城を作ってもいいし、水路を作って水が流れるのを眺めててもいいし、他の人が作った砂山を滅茶苦茶に壊してもいい。 でも砂を自在に弄るには、ちょっとしたコツやルールを覚えないとダメですよって感じですかね。

友達や先生の口癖なんかを注意深く観察したりすると、NPCのキャラ作りに役に立つかもですね。

速度は距離÷時間なので、速度を落とすなら距離を少なくするか時間を多くするの２通りの方法がありますけど、時間を多くする（VSYNCに１以上を指定してボタンが反応する感覚を長くする）ともっさりした感じになるので、距離の方を少なくする方がお勧めですね。 あとXとYに足し引きしてる数の方をいじらなくても、SPOFSに使ってる引数を直接 SPOFS 0,X/2,Y/2 みたいな感じで小さくしてやってもいいかも。

まずは固定画面で横25×縦15の２次元配列を用途別に幾つか用意しておいて、各配列を参照しながら各種判定って感じですかね。 マップだけでも移動コスト・地形効果・侵入可能か不可能かなどのデータが必要になりそうですし、兵種毎にそれらの判定に違いがあったりしたらもうワケ分らなくなりそう・・・。 期待してます。