nobuさんへ これはどんなジャンルのゲームでも同じですが、開始してすぐにゲームオーバーになってしまうようなゲームだと面白さの本質を分からずプレイすることになるためnobuさんの考えも一理あります。 重要なのはゲームバランスです。 この辺は他のゲームと何ら変わりません。 ただし、クレーンゲームの場合は景品があることで本質部分が楽しめなくても（景品を目的として）楽しめる作りになっているという違いがあります。 この辺はパ チ ン コ等のギャンブルにも共通する部分がありますね。 そうなるとプチコン3号でクレーンゲームを作る場合のポイントも見えてきそうですね。 「景品を取るまでの過程が楽しめるか否か」「景品が欲しいと思わせるようなものになっているか否か」ということです。 難しいですが、ぜひ頑張って完成させてください。

TERA(LL)さんへ クレーンゲームを「ゲーム」として考えた場合は全くその通りですね。 他のゲームと同じようにステージクリア（景品ゲット）そのものよりもゲームプレイ中（配置確認→アームの挙動→景品のゲット）にいかに楽しめるかが重要ですね。 ただし、1回100円というコストパフォーマンスが悪いゲームに熱狂できるのも目当ての景品があるからなので面白さの本質ではないものの景品はゲームを楽しむ大きな要因になっているのも確かだと私は思います。

そうまさんへ それを意味する「インスパイア」という便利な言葉があります。 どんなゲームだろうと100％オリジナルは無理なので多少は何らかの影響を受けています。 例えば、マリオの影響を受けて横スクロールアクションゲームを作る人もいます。 具体例を挙げるとるかかさんも「魔導物語」の影響を受けて「まじっくすと～り～」を作りましたね。 これは著作権的には問題がないし自分が好きな作品に触発されて作るのはモチベーション的にも良いことなので「（本当は作りたいのに）似ているから作らない」という人よりは16777216倍以上に良いことだと思います。

アイデアが似ているだけならば何ら問題はありません。 というわけで、改めてnobuさんのゲームを見てみるとクレーンゲーム自体はただのアイデアであるため何ら問題ないです。 2Dのクレーンゲームを作ったら誰が作ってもこのような配置になり、バッジとれ～るセンター登場以前にも似たようなゲームは多数存在します。 唯一気になる点といえばアームのデザインがバッジとれ～るセンターに似ているというくらいです。 著作権的な面では見た目が「ありふれたデザイン」であるならば創作性がないものとして判断されているためアームのデザインをありふれたデザインに変えれば問題ありません。 そうすれば「オリジナルのゲーム」として自信を持って投稿しても大丈夫だと思いますよ。

著作権では見た目のデザインは保護されますが、アイデアは保護されません。 アイデアを保護していったらルールが似ているものは作れなくなるためです。（アイデアは特許として登録する必要があるけど「発明」的なものが保護されるだけなのでゲームのアイデアとして特許の取得は容易ではない） トップビューのフィールド、ランダムエンカウントによる戦闘、フロントビューによる戦闘シーン、ウィンドウ表示によるメッセージはすべてドラクエで採用されているためもしもアイデアが保護された場合にはこれらを使うことはできません。 無論、これはドラクエで初めて実現されたものではないためアイデアが保護されるならばエニックスはドラクエ自体も作ることができませんでした。 スマホの「釣りゲーム事件」でも似ている表現をしているため裁判となりましたが、表現上似ている部分はアイデアにすぎないとして上告は棄却されたという判例もあります。

もう大変な避けゲーとかはどうでしょうか？

私も概ねnobuさんと同意見です。 プログラムを作るというとあらかじめ正解があってそれを編集画面で入力するというイメージを持っているかもしれませんが、よほどシンプルなプログラムで無い限りそうではなく試行錯誤を繰り返して作られます。 そうやって、「自分ができること」というパーツ（この処理はこういうプログラムで出来る！）を少しずつ増やしていきます。 過去に作ったことがある感じのゲームやツールだったらその「自分ができること」というパーツがすでにあるためそれを流用することである程度スムーズにプログラミングが可能になりますが、そうでないならばやはり試行錯誤が必要になります。 最初から完全な状態（自分が思っているような感じ）のものを作るというのは無理なので試行錯誤によって少しずつそれに近づけるというのを知っておくと良いかもしれません。

定数リテラルは自作のSUFFIX関数を使って調べてみたところ整数型でした。 SUFFIX https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0fSfxRUkA プチコン3号では実行時に仮想マシンコードに変換されるため#REDと-524288は処理面においては全く同一のものと言えます。 また、PI()は3.1415926535897931という値に変わります。要するに実数型の定数リテラルといっても過言ではないですね。自作のPSTR$関数を使えばこの値は簡単に分かります。 PSTR$ https://miiverse.nintendo.net/posts/AYIHAAAEAABEVRTp-ZVMIg

""を使わず頭に0を表示したいならば?0;123で0123と表示可能になります。?0+123では頭の0は表示できません。（?"0";"123"と?"0"+"123"は両方とも"0123"と表示される） ※ヒント　0（れい）さんはアフロだから

というわけで、「戦略シミュレーション」を作るならばまず必要なものといえばやはりマップ表示ですね。 当然マップ表示だけではダメでキャラ（ユニット）の移動が必要になります。人間vs人間のゲームで無い限りは敵キャラの思考ルーチンも必要ですね。 あとは各ユニットの性能と勝利条件を考えれば完成しそうです。 これは一般的な戦略シミュレーションの構成であり実際に作るならば上記のように具体性が必要になってきますが、残念ながら私にはりまは、ねむいだよさんがどのようなゲームを作りたいのかがよく分かりません。 したがって、上記の必要な要素の中から自分が真っ先に作ってみたいものを選んでそこから着手してみると良いでしょう。

どんなゲームでも共通ですが、作りたいゲームがあるならばそれをどんどん具体化していってそれを全くルールを知らない第三者に伝えられるくらい細かく説明できる必要があります。 それをプチコン3号というコンピュータに理解してもらえる形（SmileBASIC）で書き記したものがプログラムとなります。 コンピュータというのは融通が利かず指示された通りにしか動けないためあやふやな部分があるとその部分は作れません。 とはいえ、プログラミングというのは試行錯誤がいくらでも可能なので「たぶんこうかな」というのを繰り返すうちに思っていたものに近いもの（場合によっては思っていた以上のもの）ができます。 よくありがちな、「まずフローチャートを書いてそれから始める」という作り方は初心者だと逆に難しいです。まずは、考える前に手を動かしてみましょう。

点が離れるのは値の変化が大きくなっているためです。 これを防ぐにはだにえるさんが書いているように値の変化を細かくするという方法もありますが、GLINEで描くという方法もあります。 ただし、単純にGLINEで描くとtanのグラフは+∞と-∞を線で結んでしまうためそれを無くす工夫をした方が良いかもしれません。

ただ、適当に陰影を付けるだけならば半透明スプライトを使えば簡単で速度ダウンもないのですが、それだけではなくちゃんと指定時刻通りの陰影にしているんですね。（計算が面倒なのでさすがに私はここまでやろうとは思わなかった） これならば、「日の出、日の入り時刻が視覚的に分かる」というメリットがありますね。 小学校の理科の授業の学習用としても使えそうです。

マイク入力でのプレイはボタンとは違ったゲーム性になるというだけではなくボタンの場合は1フレーム単位での入力処理しかできないのに対してマイク入力はそれより遙かに細かい分解能を持っているため「ストップウォッチQSP」のように1/1000秒単位で計測可能なストップウォッチを作ることが可能になるなどの使い方もできるのでいろいろな使い方を考えるのも面白いです。 https://miiverse.nintendo.net/posts/AYIHAAAEAAASVZKbGFRP0A

MICDATAの値をグラフ化してみれば分かりますが、音を拾うとこんな感じで波打っています。（簡易関数電卓QSPのグラフ機能を使用） このためフラグ管理をしてON、OFFを判定しても1回の音で複数ON、OFFを判定してしまう場合も多々あります。これを軽減する最も簡単な方法としては私が「あいのてQSP」でやっているように一定の時間は無効化するという方法があります。 https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0f9Wj2HRA

RGB()は関数であるため定数に置き換えた方が高速になります。 定数リテラルは実行時に仮想マシンコードへ変換される際に定数へと置き換わるため#REDと-524288は全く同一のものとなります。

作る順番というのは特に決まっていません。強いて言うならば自分が作りたいと思った順ではないでしょうか？ とはいえ、RPGの制作経験がない人が最初に魔法の名前やアイテムを全部決めてしまおうとすると未完成に終わる可能性が高いためシステム部分に直結した所から作り始めた方が完成する確率はアップします。 というわけで私もキャラの移動や戦闘シーンあたりから作り始めるのをオススメしたいです。 ある程度ゲームとして形になってくれば未完成にはなりにくいです。

ボールが落下するのは重力があるためです。 坂道を転がるような挙動で行えば良いのです。（ルーレットの断面図から考えて単純な坂道ではなく曲面になっていますが、局所的に見ると坂道と同じなので角度計算をすれば落下速度は計算ができます。 しかし、ルーレットのボールはすぐには落下せず外周を回ってから落下します。 それは遠心力があるためです。 遠心力と坂道を考慮した重力が釣り合っている間（外周の壁があるため正確には　遠心力＞坂道を考慮した重力　となっている間）は外周に張り付いたように回り遠心力が弱まると坂道を転がっていくという感じです。 実際にどの程度の遠心力が加わるかは物理的に計算しなくてもそれっぽい動きになるように調整すれば良いと思います。

現実世界においても学校の部活や職場において先輩が後輩に教える際には「自分はこれだけ苦労して覚えたのだから君もそれと同じように苦労すべき」という考えの人もいますね。 古くからプログラミングをやっている人は初心者に対してそういう考えで接する人もいます。 もちろん、みんながそういう人というわけではなく「そういう人の声が大きい」というだけにすぎません。 「声が大きい人がいる」（高圧的な態度の人がいる）というだけであって実際はそういう人が多いわけではありません。 それは教える側は「ちゃんと理解してもらえているだろうか」というのが一番気になっている部分だからです。 （人によって異なりますが）相手の考えをできるだけ汲み取ろうと努力はしています。 私も精一杯分かりやすく教えているつもりですが不備な点があるかもしれません。 まともに教えようと思ったらMiiverseでは文字数が全然足ら

もちろん、必要最小限の命令（IFとかPRINTとINPUTとか）は覚えておく必要がありますが、それ以外は無理に覚えなくてもプログラミングに何ら支障はありません。 覚えておくことでマニュアルを読まずに使えるというメリットはありますが、そんなものは実際に数回使えば自然に覚えるため大したメリットにはなりません。 それに、覚えようとすると「面倒くさい」という気持ちがどうしても出てくるためプログラミングがつまらないものになる可能性があり「覚えること」はメリットよりもデメリットの方が大きいと思います。 しかし、「この命令は興味があるから使い方を調べてみよう」というのでしたら問題ありません。興味があることはどんどんやるべきです。 したがって、興味のない命令は全く覚えなくても良いです。