コメントから判断すると本体を縦にしてプレイするゲームを作っているのかと私は思ってしまいました。 そうすればコメントのつじつまがすべて合うと思います。 Bボタンを押すと敵に攻撃して、敵が消えるプログラムの作り方は次のようになります。 Bボタンを押したら攻撃している絵にスプライトを変える。 攻撃と敵キャラの当たり判定を行う。 当たっていればスプライトを消す。 という感じになりますね。 だにえるさんがもっと詳しく書いていますが、より具体的にはどのような攻撃にするのかとかが分からないと難しいですね。

EDITモードのキーボードはエディタを同じくシステムであらかじめ用意されているものからは変更ができません。 変更はできないですが、それらをプログラムとして自分で用意すれば自分で好きなものにすることは可能です。 プチコン3号にはすでにいくつかのエディタは作られているしキーボードを作っている人もいます。それらをうまく組み合わせればお望みのものに近いことはできるでしょう。（機能的、デザイン的に気に入らなければ自分で作るという選択肢もある） とはいえ、システムであらかじめ用意されているエディタと違ってユーザーがSmileBASICで作ったエディタはSmileBASICを経由して動作することになるため速度面では不利になります。 シンタックスハイライトをリアルタイムで処理するには高速化が欠かせないでしょう。

ちなみに341.3というのは4096/12のことです。初代プチコンではMML演奏機能が備わっていなかったためこのような自作音階演奏プログラムを各個人が作っていました。 昔のポケコンでもMML演奏機能がなかったのですがBASICでは処理速度が遅く実用的ではありませんでした。したがって、私は「OMP」という独自MMLを考案して限界までの処理速度向上を行いリアルタイムの構文解析処理を行えるようにしました。 そのOMPはプチコン3号用も用意しています。プチコン3号用は処理が速いため特に高速化は行っていません。 https://miiverse.nintendo.net/posts/AYIHAAAEAABEVRTpedKpGg

すでに解決済みのようですが私のサイトの「プチコンMML」にたどり着いたのであればプチコンmkIIは半音が341.3、プチコン3号は100なのでその部分さえ修正すればプチコン3号で動作すると思います。

そういう時はいろいろなことを試してみると良いです。 画像のようなきれいなプログラムをいくつか作っていればそれが自分自身の力になるしイマジネーションも鍛えられるでしょう。 目標に向かって真っすぐ進むだけが正しい道ではないのです。

ツララさんへ ある場所にたどり着くまでに例えば2つのルートがあるとします。 前者のルートはしばらく平坦でその後で断崖絶壁を上りそして下り坂を進みます。 後者のルートは緩やかな上り坂が連続します。 最終目的地は同じです。では、初心者に対してどちらのルートを案内しますか？ ということなのです。 変態さんになりたいかを決めるのはshoumさんです。 私が気になっているのは「正方形から始めること」ではありません。特殊な条件下であっても正方形が作りやすいのは事実でありそれで本人が納得できるならばそれで何ら問題ありません。 私が言いたいのは難易度的に「六角形より円形の方が断然易しい」ということです。 ツララさん的には「六角形の方が簡単」と思われるのでしたら私から言うことは何もありませんが。

たんじぇさんへ 実はプチコン3号の場合、昔のBASICとは異なり三角関数が異常に速くて配列が異常に遅いためあらかじめ配列SNにSIN値を入れてA=SN[X]とするよりもA=SIN(X)と普通に三角関数を計算する方が速いのです。 ちなみに簡易地球儀は回転が横方向だけであるためあらかじめ回転済みのGRPを配列に入れておけば1ドット単位で演算（約13000回のループ）がGLOAD一発で済むため桁違いの高速化が可能になるということです。（スーさんが書いているやり方に近いです） ただし、あらかじめ演算処理が必要であるため起動に時間がかかるとかメモリの問題で回転処理の分解能が下がる（BIGならば問題ない）という問題もあります。 高速化といっても手法はピンからキリまでありどのような手法が許容できるかによっても変わります。

高速化の実際の例としては私の簡易地球儀QSPを見てください。 QSPで出来る範囲内の高速化処理を行っていて3DSでテクスチャ付きの球体をグリグリ回転させることが可能です。 https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0feIaGUYA とはいえ、今見たら無駄な部分が見つかったのでもう数％の高速化は可能だと思います。（QSPに拘らなければ桁違いの高速化も可能）

上記の方法によって私は昔は雑誌に掲載されていたゲームを高速化改造のみで平均3倍（最高9倍）の処理速度のアップができました。 ただし、高速化は追求すると可読性が落ちたり、メインテナンス性が落ちたりします。 仕様を変えたいと思った際には対応が難しくなったりするためそこまで限界まで高速化が必要なのかも考えておくと良いでしょう。 私が昔ポケコンで作っていたプログラムは限界まで処理速度を稼ぐため可読性、メインテナンス性は無視してひたすら高速化を行いました。 そのお陰でベーマガに掲載されたゲームはオールBASICのゲームなのに編集部の人に「マシン語で作られたゲーム」と誤解されるくらいの速度に達することができました。 元が遅ければ遅いほど高速化の効果は抜群ということです。

そして、次に他の皆さんが書いているような高速になる記述方法が重要になってきます。 これは様々なものがあり書き切れませんが、プチコン3号特有のものとしては乗算より除算の方が高速であるため乗算を除算に書き換える（X*2はX/0.5にするという感じ）、配列変数は極端に遅いためできるだけ使わないようにする（まとめて処理可能な場面ではARYOPを使うことで最大90倍の高速化が可能）というやり方などがあります。 実際にどの程度の効果があるかは元のプログラム次第ですが、数倍程度の高速化は十分に可能だと思います。 しかし、元のプログラムがすでに速い場合はそれを体感することは難しいです。（60fpsを超えてしまうとほとんど無意味）

昔の8bit機を使っていた頃は処理速度は切実な問題だったので私も様々な方法によって高速化を行ってきました。 まず、高速化において最も重要なのはボトルネックとなっている部分を知ることです。表示がボトルネックになっているのか判定処理がボトルネックになっているのかを知らずに行っていると頑張って高速化した割りには効果が薄いという結果になってしまいます。 高速化において一番重要なのはアルゴリズムの改善です。同じ処理を行うのにその計算手順、処理方法は1つとは限らず無数の方法があります。その中で最も高速なものを選ぶと良いです。 高速化においてアルゴリズムの改善と同じくらい重要なのがメインルーチン内の処理を減らすことです。メインルーチン内では不要な処理があったらそれを省くというのが高速化に繋がるというだけではなく多重ループになっている場合はループ回数を減らすことが高速化に繋がります。

個人的には「難易度が高いからダメ」と言っているのではなく「不必要に難易度が高くなる方法を選択するメリットがない」というだけです。 わざわざ茨の道を案内する必要はないのです。

というわけで、「当たり判定が難しく回転が必要な多角形」と「当たり判定が簡単で回転が不要な円」のどちらが簡単かという話になり私は後者の方が簡単と言っているだけにすぎません。 もちろん、上記のようにコインがすべて正方形で回転もしないという特殊な条件下で良いならば簡単であるためそれで完成とするならばそれでも良いですが「それが完成したら今度は六角形のハニカムタイルで作ってみて、最終的に円形のコインのを作ってみるとか。」というのはさすがにどうかなと思ってしまいました。 もしも、「多角形のコインのゲームを作るのが目的」で最初に試しで円のコインで作ってみてそれを元にハニカムコインに発展させるというのでしたら私も同意していたのですが。（難易度的には円＜＜ハニカムなので）

多角形の中でも正方形だけは特別に簡単でコインが回転しない（画面に対して辺が水平、垂直に向いたままの状態）ならば作るのは容易です。 ただし、それは特殊な環境すぎてそこからの発展が極めて困難です。 仮に五角形、六角形にしようものならば線分同士の当たり判定が必要になってきます。これは初心者にはかなり難易度が高いです。そして回転が加わると・・・。 実際に自分で作ってみれば分かりますが、円を使った判定ならば当たり判定は簡単、回転処理は不要です。（コイン同士の摩擦を考えれば回転が必要になってくるけど現時点で導入する必要はない）

私はプログラミング自体は行き当たりばったりの無計画で作ることが多いですが、内容に関しては事前によく考えて作っています。 例えばプチコン3号で多くの人が作っているお絵かきソフトですが、自分が欲している機能は何なのか、それによって既存作品と差別化が可能なのかなどを考えてから作るという感じです。 「SIMPLE PAINT」もこんな感じで制作しています。 　 自分が好きな「アニメ塗り」に特化したお絵かきソフトを作ろう 動作が軽く、快適に使えるものにしよう 　↓ アニメ塗りに特化というのはどのようにすれば良いのか 快適に使えるためにはどうすれば良いのか 　↓ 様々なケースを想定して仕様を固める 　↓ 実際に制作開始 あらかじめコンセプトデザインを明確にしておくことで使い勝手が悪くなってしまったりどんなゲームか分かりにくいという問題を軽減することができます。

私は「企画書」は最近ほとんど書いてないですが、昔はよく自作ゲームの企画書を書いていました。個人制作では制作ラインを何本も確保するのが難しく次から次へと出てくるアイデアをすべて具現化するのは難しかったため「企画書を書く→しばらく放置→後からその企画書を読んでも面白いと感じるならば制作開始」のようなやり方を行っていました。 端的に言えば「未来の自分へのプレゼン」みたいな感じですね。 最近は企画書が必要なレベルのゲーム等を作ることはほとんど無いため事前にやりたいことを箇条書きする程度です。 これは実装忘れを防ぐ意味合いが強いですが、QSPなどの文字数制限プログラムの場合は優先順位付けをすることでより完成度の高いものを作ることができるため非常に有用な手段です。

変態というのは普通の人とは違うということなので私は中級者、上級者という分類とはベクトルが異なると思います。 変態的な技術をもった超上級者の人もいれば特定ジャンルにおける変態もいます。 要するにこだわりこそが変態の大きな要因となるため私は変態を目指して欲しいと思います。 つまり、「自分のプログラムにはこだわりを持て」ということです。

上級者を目指すならばひたすら多くのコードを読み書きしましょう。1つのことを行うのに選択肢を多数身に着けていてこそ上級者です。 上級者になればフルスクラッチで様々な処理を記述できるたりコードの最適化によってプチコン3号では普通に作ったら実現が難しいものを作れるようになったりとかができるようになります。 私が書いた初心者、中級者、上級者の分類はプログラミング技術の部分のみです。プログラミング技術とゲーム制作技術はまた分けて考える必要があると思います。 プログラミング技術は低くてもゲーム制作は巧いという人もいるでしょう。

したがって、初心者の人がどの命令を使えるようになれば中級者かというのは個人的には無いと考えています。 必要な命令を必要な段階で使えば良いので「これは中級者用の命令だからまだ早い」とかいうことはありません。 しかし、「プログラミングにおいて学ぶべき順番は決まってない」とはいえ初心者は変数、入力、出力、制御の基本命令、プログラムの基本的な仕組みを学んでおく必要はあると思います。 その後、中級者を目指すならばちゃんと仕組み(アルゴリズム等)を理解して作るということを覚えていく必要があります。 「なぜかは分からないけど動いた(動かない)」を少しでも減らせるようにしていくと良いでしょう。 中級者になれば他の人が作ったもの(プチコン3号用ではないものも含む)を参考にすることでプチコン3号で普通に実現可能なものであればあらゆるジャンルのプログラムが作れるようになります。

個人的には「○○ができれば中級者」という類のプログラムはないと考えています。 プチコンでは難しいイメージのある「3D」ですが、これも優秀なライブラリを使用したり、他の人が作ったものを改造すれば良いのでそれほど難しいものではありません。 確かに、フルスクラッチで3Dゲームを作れれば中級者と言えるかもしれませんが、あくまで必要条件であり十分条件ではありません。 というわけで、私が四半世紀前に考案した中級者、上級者判別の基準（必要十分条件）はこんな感じです。 中級者・・・自分のプログラムの仕組みを理解してそれを説明できる 上級者・・・状況に応じて最適なコードを書ける これは私がプログラミング講座等で使っている基準なので他の人の基準とは異なると思います。 私のプチコン講座ではこの基準を元に初心者を中級者に変え、中級者を上級者に変えるような工夫をしています。