原理的には移動要素のX軸成分とY軸成分を別々に範囲計算して、跳ね返り地点に来たら該当する軸に毎回足してる移動成分の符合を反転してやってるんですね。 もしかしてベクトルで移動方向を保持して三角関数でX軸とY軸方向の移動量を計算して弾幕を動かしているなら、反転した後の移動成分から角度をATAN()で計算して、方向を保持してる変数に代入してやればいいんじゃないです？

ははぁ、手で拭いちゃったから手を拭う紙が無いとノブを回せないんですね。 DEFの中で無限ループにハマって何時までも外に出れないみたいな。

画面中の適当な位置に点を置いて、その点に線が引っ掛かって曲がったりしたら面白そう。

BGが表示中の座標が知りたいならプログラム中でBGPUTした時にその座標を記憶しておく変数を用意しておくのが手っ取り早い方法ですけど、下画面はデフォルトサイズのBGキャラだと横20縦15個で敷き詰められるので[20,15]の二次元配列を用意して、BGを置いたら1を、消したら0を代入しておけばいいんじゃないです？ あと多次元は要素数の掛け算になるので、一次元配列２種類だと数が全然足りないと思いますよ。縦5横5の範囲なら5×5で25個は必要になるはず。

逆に言うと一次元配列の要素数を割り算すると多次元に出来るってことですね。 上手く使うと512×512以上のサイズの画像も扱えたりしますよ。 二次元以上の多次元配列で要素数を後から増やしたり減らしたりする場合はメモリ管理が大変になるので、予め余裕を持って宣言しておいて、範囲外は弾く仕様にした方が楽かも。

意味不明なら詳しい人に解説を頼めばいいんですよ。 スポーツ中継も解説者が居ないと「今のプレイは何が面白かったの？」みたく内容の10分の1も楽しめなかった、なんてことになりかねませんからね。 幸運な事に、このコミュニティには凄腕の解説者陣が揃ってると思いますよ。

スプライトのテクスチャを上から下へ(奥から手前へ)順に、テクスチャのドットの拡大率を少数で滑らかに表示することで、要するに一点透視図法の原理になってるんですね。 これって原理さえ分かってしまえば応用しまくり出来るんじゃないです？

平たく言うと「遊び方を考える遊び」がこのゲームの遊び方になるのかな？ まず「何したいのか自問する」ところから始まるのでハードルは高いですよね。 メイドインワリオみたいな「〇〇を〇〇しろ！」的なお題を出してくれるプログラムがサンプルに入っていたら便利なのに。

５月病ってやつですね。 ストレスの正体はストレスホルモンっていう分泌物の影響なので、十分に休息を取れば自然に治るので気にする必要無いと思いますよ。 春は色々とプレッシャーの多い季節ですけど、人命に関わる事以外なら大抵は時間が解決してくれますからあわてないあわてない。（一休さん）

水掛け論ってやつですね。 WATER TALK GUNだとよりそれっぽいかも。

自分の経験上、他の人と被った方が面白い物が出来上がったりするので気にする事無いと思いますよ。 それに行き詰まって別のプログラムに浮気してるときに、前作ってたプログラムを離れた視点で見ることによって改良点が見えて来ることとかありますし。

音声認識って要するに音で当たり判定するようなもんじゃないんです？ マイク入力からの信号を一定の区切りで数値化して、予め設定してある定数とIF文で比較して判別してやるみたいな。 応用すると2次元の画像をスライスして横1ラインを一つの数値に変換して、予め用意してあるパターンと照合、みたいな画像認証も出来そう。

文字列の正体はASCIIコードみたいな変換コードのアドレス番号で記述される、いわゆる「記号」なので、BGPUTする時に番号で置く絵を指定しているのと同じ様なものだとイメージするとわかりやすいかも。 数値をアドレス番号に変換するのがSTR$()命令ってわけですね。 システムファイルのフォントのグラフィックデータをグラフィック画面に読み込んで表示させると、BG画面と似た様な構造になってるのが何となく掴めるかと。

50音表記の利点って母音と子音がマトリクス状に配置されてて空間的に文字の配置が把握出来ることだったりするので、LボタンとRボタン同時押し状態の時だけカーソルが傾き感知で動いて、上にクイッっと持ち上げると加速度感知で決定、バックスペース&キャンセルはBボタンとかやったら面白そうですね。実用性ガン無視ですけど。

おー、フラクタルな感じでいいですね。

RND(0)とRND(1)の結果が同じだったり、プチコンの中で例外処理してる「仕様」みたいなものなんでしょうか。 試しにPOW(数値,乗数)の逆関数のLOG(数値,底)で、数値に1を指定すると底がどんな数でも0が返って来るんですよね。 ちなみにLOG関数は数値に0を指定すると底がどんな数でも、逆に底に1を指定すると数値がどんな数でもエラーになるみたいですね。

ご褒美目当てで競争してるとライバルを蹴落としたくなるかもですけど、競争自体がご褒美になると、むしろライバルの大事さが身に染みると思いますよ。 忍者の水走りの術じゃないですけど、お互いが相手を足場にして追い抜き合う事で足元を気にせず何処まででも突っ走って行けますし、方向性が同じで且つ力量も同等の相手じゃないとこういう関係にはなれませんから。 ちょっとクサい台詞かも知れませんけど、ライバルと一緒に誰も見た事の無い地平の先を見てみたいって思いません？ 結果じゃなくて過程を楽しめるようになるには何事も当面の意味は分からなくても続けてみる事が大事なんですけど、ここは騙されたと思って「継続は力なり」を実践してみたらいいんじゃないです？

上が見えてれば相手を蹴落とすって発想は出て来ないですねー。 先に到達すればいいだけですから。 先に到達できたなら相手を引っ張り上げるくらいの余裕が欲しい所ですけど。

まず前提として配列を使う時は配列名をDIMで宣言しないと使えませんよね。 単純に考えて、その処理を事前に済ませておく分だけ速くなるんじゃないです？ 設定した配列に定数を代入してプログラム実行中は読み込みにだけ使うなら、代入の処理も省けて更に速くなると思いますよ。 特に用途が決まってないなら、わざわざ「0」や「""」を最初に代入しなくても配列の要素をPUSH命令などで増やした時点で実数型や文字列型など型に応じたメモリーが確保されるので無意味かと。 使用できるメモリー残量が少なくなるとスペックが低下するのは、何回もPUSHやPOPで使用メモリ量を変えたときに、メモリ領域が虫食い状態になって空きを探すのに時間を取られるからだと思うので、最初に使用量の限界を決めて、その中でやりくりするようにすればスペック低下は起こらないと思いますよ。

ソニックの漫画的な足グルグル表現はアニメーションパターンどうなってるのか参考にしたくなりますよね。 シッポマリオのアラレちゃんのキーンなポーズも捨てがたいですけど。