DL しました…… が、ゲームのルールが良く分かりませんでした。

14行目でボタン受付 15行目でAボタンなら GOTO @A Aボタンでない場合、16行目が実行されます → 13行目に戻る。 つまり今のままでは、Aボタン以外を押した場合、16行目が必ず実行されてしまいます。 改善するには、GOTO @LOOP する前に、Bボタンが押されたかどうかのチェックをする必要があります。 また、21行目の後半の GOTO @HOTOPLAY は意味がありません。 GOTO @LOOP2 が実行されるので、後半の GOTO @HOTOPLAY は一生実行されません。 後は画面からでは分からないのですが、ラベル @A や @B はちゃんと作ってありますか？ 誤字や脱字はありませんか？(@HOTOPLAY とか如何にも脱字っぽいです)

DLしました！ 特にバグは見当たらなかったんですが、部屋が三角形になってるっぽいところが気になったくらいかなぁ……

コードを書く、という形での合作はするつもりはありませんが…… １．サロさんがコードを書く。 ２．もしエラーが出たら、「その近辺の各命令をどういうつもりで書いたのか？」の細かい説明をつけてここにアップする。 ３．それに対して、こちらから「どうしてエラーになるのか？」を説明する もしくは、 １．サロさんがしたい事があるけど、処理の流れが分からないから質問する ２．それに対して、こちらから「こういう流れでやればいいと思う」と提案する こういう形でなら協力してもいいです。

気づいたら　スパゲッティが　出来ている

どんな時に、といえば、「MMLが間違っている時に出る」としか言いようがないかと…… 例えば、次の命令ならエラーになります。 BGMPLAY "AB:D"

というか、beans さんの例は2進数の話ではないですね。 ビット演算の例だと思います。

16進数をあらわす場合、&H を数字の前につけます。 例）10進で10 = 16進なら&H000A 後は同じです。

ざっとみた感じ、跳ね返る理由は、 IF X>=45 THEN SX=SX-1 等の式にありそうですが…… これ、何を意図してるんでしょうか？ 単純に移動させたくないなら、SX=0 とかにすれば良さそうなものなんですが。

一番簡単に思いつくのは、カラーコードかなぁ。 あれは16進で表記すると、2桁ずつで色指定が出来るので。 赤味を減らしたい、とか青味を強めたい、だとかが簡単に出来ます。 次に情報をビットで扱う時かな。 ちょっとわかりやすい例が思いつかないのですが…… 例えばゲームに主人公がいて、彼にいくつか状態変化が発生するとして、それを記録するとか。 攻撃力アップ状態、防御力アップ状態、無敵状態、スピードアップ状態、があるとして、これの持続時間が15ターン以内、だとかなら…… それぞれ変数にして管理してもいいんですが、これを1つの変数として扱うなら、16進は便利です。

作れます、が詳しい説明は非常に面倒くさいので簡単に。 １．プログラムの基本的な組み方を勉強する(DIRECT モードとEDIT モードの使い方等。公式サイト参照) ２．スプライトの勉強をする(キャラクターの表示方法) ３．ボタン入力を検知する方法を勉強する ４．キャラクターの動かし方を勉強する ５．ＢＧの勉強をする（ステージの表現方法） ６．キャラクターが変なところにいかないようにする方法を勉強する （地面の下に落っこちたり、壁にめり込んだりしないように） ７．重力の勉強をする （キャラクターがジャンプしようとした時に、どういう動きをするか？） ８．敵が勝手に動く方法を勉強する ９．スプライトの衝突関連を勉強する

可能です。 T=0 WHILE VSYNC INC T WEND をする事で、1/60秒毎にT が1ずつ増えます。 なので、Tを条件判断に使う事が可能です。

> なんでそんなに完成にこだわるの？ 完成しなくたって経験になればいいじゃん それで飯食ってるわけじゃなし。 前提として、 「合作をしようという話に乗っかる人は、"何かソフトを作りたい"という気持ちの上で参加する」 と思っている、というのがあります。 折角、時間を割いて参加してみたのに、結局没になった…… というのは、寂しいと思います。 何事も経験、とは言います。けれど、 「こんなの無理、出来ないからプログラム係は辞退します」 「作れる人がいないから、解散しますか」 と何回か見かけますが、その後、また同じ事を繰り返すのも見ていると、本当に経験になっているのかなぁ、と思います。

だから、れいさん（そして、他の多くの"機能改良・強化案"を募集されている方）のように、 「（自分でプログラムを作って、その上で協力を求める」 という形であるならば、合作という形も非常に良い経験になるとは思います。 合作自体が失敗しても、ソフト自体は完成するわけですし。 (こういう点で、付属素材が多いプチコンはよい環境ですよね)

個人的にはれいさんの意見に同調したいのですが、ここの環境においては、やはり「まずは一人で作ってみる」が大事ではないのでしょうか？ 何故かといえば、 「システムを考えればプログラムの人がどうにかしてくれるだろう」 という考えでデザインをする人が大量発生してしまうと思うからです。 つまり、「そんな事言われても、自分の力じゃ実現出来ないよ」と投げ出す流れになる事を危惧します。

さすがにコードを全部書くつもりはないので、自分で頑張ってみてください。 分からないところを答えるくらいの事はしてもいいので、コードを書いてみて、実行してみて、それでもまだ分からない、というところが出たらまたどうぞ。

上ボタンが押されているか確認する時の例 WHILE TRUE B=BUTTON() IF B==#UP THEN PRINT "上ボタンが押された" END VSYNC WEND 上記でPRINT しているところで、キャラクターを移動させるサブルーチンを呼び出します。 (GOSUB命令) 一度に説明されるのも大変でしょうから、一旦ここまでにしておきます。 キャラクターの移動が出来るようになったら、また言ってください。

さて、次に主人公を自由に動かすにはどうすればいいのか？ これは、 １．十字ボタンが押されているかどうかを確認する （BUTTON 命令） ２．押されたボタンに対応して、キャラクターを移動させる (IF 命令) ３．１に戻る (WHILE ～ WEND 命令) 本当は移動先が正しいかどうかのチェックも必要ですが…… 今の段階では考えずに、まずは十字ボタンで動かせるようになる事に集中してください。

例) ACLS FOR I=0 TO 9 LOCATE X+I,10 ' 文字を表示する位置です PRINT "@" ' 文字を表示します VSYNC 3 ' プチコンは速度が速いので、少し待ちます LOCATE X+I,10 ' 移動する前に、文字を消す為の座標指定です PRINT CHR$(0) ' ここで文字を消しています NEXT

質問１、とありますが、その内容を実現するだけでも結構行数が必要です。 なので、もう少し細かく分けて考えると良いと思います。 最初に、文字を移動させる手段について。 BASIC において文字を移動させるとは、つまり ・移動元の文字を削除する ・移動先に文字を表示する の二つを行う事です。 この二つは、どちらもLOCATE 命令とPRINT 命令を組み合わせる事で実現が可能です。