個人的には過去の同じようなコンシューマ向けの開発環境から考えてプチコン3号がちゃんとしたマニュアルが付属したパッケージソフトならば定価9800円くらいのソフトに感じます。もしも、専用キーボード付きの特別版があったとしたら14800円くらいでしょうか。 それを考えたら1000円は破格値、500円だったら買わないと損くらいの感覚です。 とはいえ、価格が安くなってすぐに買うのは2台目、3台目の人でしょうね。 そもそも大半の人はプチコン3号の存在自体を知らないだろうしプログラミングに興味がない人の方が多数だと思います。

とはいえ、値下げの結果、今までは価格的に手が出なかった層にまで購入対象になるわけなのでこれは大きなプラスと言えます。 そして、ニュースに採り上げられて知名度アップの相乗効果があります。 値下げ前に買った人には補填をと考える人もいますが、これにも様々なコストがかかります。 ただし、安くなったからといって一気に桁違いに多くの人が来るとは思えないです。 ニュースを見てたまたまこんなソフトがあったのかというのを知りそれで買う人、1000円では買えなかったけど500円ならば買えるという人くらいです。 それでも新しい人がどんどん増えるのは個人的にはうれしいです。 Miiverseが無くなる前に私にできることはどんどんしようと考えています。

私は所持している4台の2DS/3DSは購入してすぐプチコン3号を買いました。3号の1000円は破格の安さに感じたし、BIGの3500円も高いと感じませんでした。 「欲しい時が買い時」とよく言われますが、欲しいものを欲しい時に買うというのはある程度はお金に余裕がある必要があります。小遣いの少ない小中学生が何ヶ月も苦労して3500円を貯めてBIGを買ったのに買ってすぐに1000円になったらショックになってしまう気持ちは分かるし、差額分の補填をしてくれという気持ちも分かります。 売る立場から考えると多くの人に買ってもらえるように安くするというのはごく普通の考えであるとはいえセール以外では安くなることがないほとんど無いダウンロードソフトがいきなり半額とか3分の1になるのですから。 したがって、私も値下げが行われる前に青鳥にて「安易な値下げは反感を生む」と社長に言いました。

とりあえずバグ報告 緯度90度で表示すると207行でDivide by ZEROになります。

ツララさんへ 基本的にその方法で問題はありません。 しかし、LOGを使った桁数判別はLOGの演算精度が問題になる場面もあるということも知っておくと良いかもしれません。 例えばFLOOR(LOG(1000,10))を計算してみると本来は3であるはずなのに2になっていることが分かります。 他にも1000000、1000000000、1000000000000、1000000000000000、1000000000000001、1000000000000002などで誤動作してしまうため例外処理を行う必要があります。 それが面倒ならばLOGを使わない桁数判別を行うと良いでしょう。

判定の短縮化で迷ったらまずは想定されるすべての判定を書きだしてみてそれにどのようなパターンがあるのかを見つけることが重要だと思います。 判定のパターンというとじゃんけんの勝敗判定というのがポピュラーかつ顕著で(X-Y+3)MOD 3のような方法で勝・敗・分が判別可能になります。 閏年の判定もこれと同じように4通りの判定をすべて書き出してやればよいしパターンを見つけられなければその通りIFを使って記述すればよいので問題ありません。（今回の場合だと4通りなので苦にならないと思う） 短縮というのはQSP、OSPといった制限付きプログラムでは大きなメリットとなりますが、そうでなければ大きなメリットはなくデメリットにもなります。（自分で理解できないような短縮はバグや仕様変更の際に自力で変更できない）

例えば1900年だと「100で割り切れる」という条件を満たすため!(DY MOD 100)の値は1になりますが、それと同時に「4で割り切れる」という条件も満たすため!(DY MOD 4)の値も1になります。したがって、!(DY MOD 4)-!(DY MOD 100)の値は1-1=0でとなり、28+0=28（閏年ではない）となるわけです。 「論理値 OR 論理値」は「論理値+論理値」で代用（短縮化）というのはよく目にしますが「論理値-論理値」というのは「論理値 XOR 論理値」を代用したものと言えます。 とはいえ、内蔵時計から読み出した日付のみを使うのであればN=28+!(DY MOD 4)で1901年から2099年までカバーできるため個人的にはこれでも十分だと思います。

したがって、「4で割り切れない、100で割り切れる」ということはあり得ないためこの4通りの判定が行えれば良いことは分かると思います。 この4つの判定を見ると3つの条件のうち1つの条件もしくは3つの条件を満たせば閏年になり、条件をすべて満たさないもしくは2つ満たした場合には閏年にはならないことも分かると思います。 ここまでくればあとは「3つの条件のうち1つの条件もしくは3つの条件を満たす」というのをいかに簡略化できるかにかかってきます。 4で割り切れるというのはDY MOD 4==0と記述できますが、これは他の方も書いているように!(DY MOD 4)に置き換えることができます。 それと包含関係を考慮した場合にN=28+!(DY MOD 4)-!(DY MOD 100)+!(DY MOD 400)がある年（DY）における2月の日数になるというわけです。 （続く）

閏年判定を短く記述したいのであればN=28+!(DY MOD 4)-!(DY MOD 100)+!(DY MOD 400)なんてどうでしょうか？ 閏年に関しては西暦が「4で割り切れる」「100で割り切れる」「400で割り切れる」という3つの条件を考える必要があります。 4で割り切れない、100で割り切れない、400で割り切れない→閏年ではない 4で割り切れる、100で割り切れない、400で割り切れない→閏年 4で割り切れる、100で割り切れる、400で割り切れない→閏年ではない 4で割り切れる、100で割り切れる、400で割り切れる→閏年 実は、3つの条件は独立したものではなく「4で割り切れる数の集合⊃100で割り切れる数の集合⊃400で割り切れる数の集合」という包含関係になっています。 （続く）

実はプチコン3号ではFPSを求める関数を作っているのでそれを使うのが最も簡単と思います。 https://miiverse.nintendo.net/posts/AYIHAAAEAADaVHh0WIkyXA こちらは表示部分は含んでいないためFPS関数の値をPRINT等を使って自分で表示すればOKです。 FPSMは0.1FPS単位で計測可能です。 こちらの方は自前の1000分の1秒を計測するTIMER関数を使っていますが、これはFPSM関数を作った後に正式に加わったMILLISECに置き換えることができます。 そうすれば0.1FPS単位の計測が可能です。 どちらでもお好きな方を使ってください。

FPSを計測にするには様々な方法があります。 プチコン3号だとメインルーチン1回あたりの実行時間をMILLISECを使って計測してそれを1秒当たりの実行回数を計算するという方法もありますが、mkIIと同様に1秒当たりの実行回数を求めるのが最も簡単だと思います。 1秒というのはTIME$で1秒を測ってもいいしMAINCNTで60フレームを測ってもいいと思います。 そのmkII用のプログラムがうまく動かないとすれば（MAINCNTLをMAINCNTに変えていることを前提に考えると）「きちんと表示がされてない」だけだと思います。 ルーチン内にFPSを表示する部分が含まれているためこの表示の後に別のPRINTを行ったり、CLSを行ったりすればFPSの表示は消去されます。その場合は一旦FPSの値を別の変数に入れると良いでしょう。

取捨選択はQSPやOSPといったごく小規模のゲームを作ってみればその重要性が分かると思うので「どうしても無駄にいろいろな要素を詰め込んでしまう」と感じてしまう人は一度挑戦してみると良いかもしれません。 サイズ制約のないゲームの場合には取捨選択のため「明確なコンセプト」が必要になります。 コンセプトをより明確化するためにはターゲットを明確化する必要があります。 「万人向け」というのは大抵の場合においてコンセプトが曖昧になりがちになります。 ターゲット（対象）を明確にするというのはゲーム制作だけに限ったことではなく講座を書いたりなど様々なものにおいて非常に有効なものです。 コンセプトが明確であれば取捨選択を行うのはそれほど難しいことではないと思います。（実際に作ってみないと分からない部分もあるけど） 実際、私自身がQSPを作る場合にもコンセプトを明確にしてから作り始めます。

風呂敷をどんどん広げあれこれ詰め込むのは私もよくやりがちです。しかし、ゲームにおいて1+1=2ではありません。 これは「面白い」と思う要素をどんどん付け足していったらどんどん面白くなるというものではないということです。 重要なのは取捨選択です。 これは大作ゲームであってもQSPのようなごく小規模なゲームであっても何ら変わりがないと思います。 その取捨選択をするには本当に行いたいものを見定めて（コンセプトを明確にして）各要素をプラスすることでどのようなメリットがありデメリットがあるかを把握する必要があります。 ゲームの本質はリスクとリターンであり、リスクばかりではストレスが溜まるし、リターンばかりでは単調になります。 分かっていてもこれを頭の中だけで行うのは困難です。 個人的には企画なんて難しく考えずにとりあえず作りたいゲームのひな形を作りそれから先は作りながら考えれば良いかと思います。

実数型の有効桁数を超えるような値を正しく計算するには多倍長演算プログラムを作れば良いです。様々なアルゴリズムがあります（詳しくはネット検索してください）が、全桁を配列に入れてそれを筆算で解くような感じで計算するのが簡単ではないかと思います。

整数ではコウランさんも書かれているように9007199254740992までならば正しく表示が可能ですが、小数においては注意すべき点が2つあります。 1つは有効桁数による丸め誤差です。内部では2進数で記録されているため0.1のような数値も循環小数になってしまい誤差が発生します。（詳しくは下記リンク参照） https://miiverse.nintendo.net/posts/AYIHAAAEAAASVZKdAWi67g もう1つは小数を表示する場合は小数第9位以下は表示がされないことです。（0.000000004は0と表示される） これを回避するにはFORMAT$を使うか、私の自作関数PSTR$を使うしかありません。

これはバグではなく仕様です。 プチコン3号の実数型は一般的には倍精度浮動小数点型と言われているものでこれは64bit（2進数で64桁）で値を表現しています。64bitのうち符号が1bit、指数が11bitであるため仮数部は52bitとなります。 つまり、有効桁数は2進数で52桁分となり、これは10進数だと約16桁となります。要するにプチコン3号の実数型は最大でも16桁分の精度しかないため大きな数を計算してそれ以上の桁数になった場合には下の桁が0で埋められるわけです。POW(2,100)とか計算してみると分かると思います。

これが分かれば「大量の敵や弾が同時に動くゲーム」というのも同時ではなく1フレームの中で順番に動かしていけば良いことが分かると思います。 もっとも、プチコン3号の演算速度はかつての8bit機が主流だった1980年代のパソコンのBASICと比べて数100～数1000倍も速くて1つの命令を実行するのに数100ナノ秒～数マイクロ秒程度です。（ナノ秒は10億分の1秒、マイクロ秒は100万分の1秒） したがって、ぱっと見では「同時に実行して見えている」というのもあるかもしれないですね。

bはかせさんへ otta777さんも書いているようにSPANIM等の例外はありますが、基本的にプチコン3号の命令は順番に1つずつ実行されています。 ただし、実行と反映は同時に行われるわけではないため疑問に感じているのではないかと思います。 実はPRINTにしろGFILLにしろ画面上に表示する命令は実行した瞬間に画面に表示されるわけではありません。表示更新のタイミングで画面に表示されるわけです。表示更新のタイミングは約1/60秒（1フレーム）ごとにやってきますがこのタイミングを作る側は考える必要はありません。 それはVSYNCという便利な命令があるためです。 このVSYNCによって表示更新のタイミングまで自動的に待ってそれから次の命令に移ってくれます。

逆三角関数というのは三角関数の逆関数です。長さを元に角度を得る関数です。 ATAN（アークタンジェント）・・・TANの逆関数（直角三角形で言えば底辺と高さを元に角度を求める） ASIN（アークサイン）・・・SINの逆関数（高さと斜辺を元に角度を求める） SCOS（アークコサイン）COSの逆関数（底辺と斜辺と元に角度を求める） ATANならば使った経験があるのではないかと思います。 ASIN、ACOSはATANから三平方の定理によって導出可能なので使用したことがないのかもしれません。

ゴールド会員の期限が切れてもすでにアップロードされたファイルが消えることはない（非会員である上限の10個を超えてアップロードできないだけとなる）ためアップロードを頻繁に行わないけどアップロードできるファイル数（もしくはアップロードできる1フォルダあたりの容量）はたくさん欲しいという人であれば1ヶ月単位で買ってゴールドの会員中にまとめてアップロードするとお金の節約が可能です。（毎月コンスタントにアップロードするような人だと半年分まとめて購入する方がお得）