RPGの戦闘はダメージ計算式と乱数によってプレイした際のイメージはかなり変わります。 必要なパラメータをどんどん作っていっても良いのですが、有効活用されないと絵に描いた餅でしかありません。逆に限られたパラメータでも工夫次第で様々な方法があるというのが今回書いたものです。 あくまで今回書いたプログラムや計算式は一例に過ぎないので自分のRPGに合ったものを考えると良いしその方が楽しいと私は思います。 というわけで、「素早さのパラメータを活かしたこんな計算方法があるよ」とか、「こんなパラメータがあればもっとダメージ計算が上手くできるよ」とかいうのがあればどんどん書いていってください。

逆に自分の方が素早い場合（例えば自分の素早さが20、相手の素早さが10とすると）攻撃がヒットする確率は100％で与えるダメージはMAX値の50～100％となります。 Sの部分をRND(S)にすると乱数の要素が強くなりすぎてしまいますか、いくら相手より素早くても100％ヒットするということは無くなります。 乱数の要素が強すぎると感じる場合は私のADAMを使ってやれば乱数の分布を調整できるためヒットする確率やダメージの分布も自由に調整できます。 https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0fQKcdeZg もちろん、ADAMを使用しなくても自分で上手く複数のRNDや計算式を組み合わせて自分好みの分布になるようにしても良いです。

次に素早さがダメージ量そのものに影響を与える方法を考えてみます。 普通のRPGでは攻撃が「当たる」「当たらない」という1か0かどいう状態になることが多いのですがそうではなく「攻撃がかすった」みたいなのを表現するのに素早さを使うことができます。 やり方はいろいろありますが、A=(S-RND(SE))/S:DM=(AP-DP/2)*A*(A>0) のようにして求める方法があります。（APは自分の攻撃力、DPは相手の防御力、DMはダメージ量、Aは一時保存用変数） 基本はドラクエ式に近いですが、相手の方が素早い場合（例えば自分の素早さが10、相手の素早さが20とすると）攻撃がヒットする確率は1/2で与えるダメージはMAX値の0～100％となります。

RPGではなくもしも実際の敵に遭遇したと仮定した場合には素早い敵というとなかなか攻撃が当たらず、遅い敵だと攻撃がどんどん当たるイメージがあるのではないかと思います。 つまり、素早さが高ければ「身をかわす」確率がアップするわけです。 遅い敵に対してはクリティカルが出やすくなると素早さがさらにアップしますね。 これは、自分の素早さをS、相手の素早さをSE、攻撃がヒットした時の処理（攻撃力と防御力を元にしたダメージ計算）が@HITに記述してあればIF RND(S)>RND(SE)THEN @HIT みたいな感じで簡単に行うことが可能です。

最も簡単なのがターン制を無くしFFのようなATBにするという方法でしょう。これならば素早さによってゲージの貯まり方を変えていけば「素早いけど攻撃力がないキャラ」と「遅いけど攻撃力のあるキャラ」の差別化ができます。 ゲージの表示をしなくても内部で同様の計算を行い攻撃が回ってきたキャラから順番にコマンド入力するという方法もあります。 2倍早ければ攻撃のターンが回ってくる回数が2倍あるという感じです。 これによってパーティに加えるキャラやパラメータ（能力値）を選択可能なRPGの場合は素早さ優先か攻撃力優先かで考える余地が出てくるというわけです。

ドラクエ方式は無難なのですが、ありふれているというのと素早さのパラメータがあまり有効活用されていない（ドラクエIVまでは素早さの1/2が防御力に加算されていたけどV以降は「身の守り」のパラメータが導入されたため「素早さ」は行動の順番に影響を与えている程度）なので個人的にはこの「素早さ」のパラメータをもっと有効活用したダメージ計算方法を考えてみたいと思います。 ※最近のドラクエでは素早さがある程度高くなると回避率や命中率に補正が加わっている模様

「攻撃力」「防御力」「素早さ」というのは普通のRPGならどれでも用意されているパラメータですが、ドラクエではダメージ量＝（攻撃力÷2）-（相手の防御力÷4）で計算されています。 もちろん、これに乱数が加わりますが、攻撃力÷2≦相手の防御力の時は相手にダメージを与えることができません。その際はランダムで時々1のダメージを与えるようになっています。 また会心の一撃（クリティカルヒット）では相手の防御力を無視してダメージを与えています。（攻撃力を1.5倍、相手防御力を0で計算） ドラクエ方式に近いダメージ計算を簡単に実現するDAMAGE関数を以前作ったので初心者の方は参考にしてみてください。 https://miiverse.nintendo.net/posts/AYIHAAAEAAAFVHwqYIXAtQ

時間がかかる処理は予め済ませておくというのは昔からある手法ですね。 私もこれによってプチコン3号よりも1万倍以上遅いポケコンのBASICで10fpsという高速（？）な擬似3Dのスキーゲームを作りました。 Z軸回転を予め済ませるという方法は思いつきましたが、GRPのサイズ制限上パターン数を増やせないのでカクつく問題があります。これをラスタースクロールで誤魔化すという手法は私は思いつきませんでした。 私が候補としている方法で（New3DSで）60fpsができるかは実際に試してみないと分からないですが、私が作るとしたらシンプルなタイムアタック専用ゲームになると思います。スーファミのF-ZEROも買ってから半年間はMUTE CITY Iのタイムアタックしかやってなかったくらいですから。（ダブル一点読みをマスターして任天堂の公式レコードを超える1分58秒31のタイムを出しました）

他人に「これを作りなさい」と言われたものより「自分で作りたい」と思って作る方が楽しいし挫折もしにくいと私は思います。 もしも、それが思いつかないのであれば曲のイメージからどんなゲームが合うかを考えてそこから発展させるのもありです。 普通はゲームの内容からそれに合った曲を作ることが多いのですが、逆であっても問題ないと思います。 「曲に合ったゲーム」ではなく「こんなゲームのBGMで自分が作った曲が流れたらいいな」でも全く問題ありません。 その際は、自分が作れるものと作りたいもののギャップ（作りたくても作れない状態）が発生する場合もありますが、それは実際に作ってみて質問内容が具体化してくれば回答する側も答えやすくなり解決も容易になります。

ファミコン、スーファミ、64の修理受付が終了したのは2007年10月31日なのでWiiUが来年春に生産を終了しても当分の間は修理受付は継続しそうですね。 BIG発売してある程度バージョンアップが落ち着いた段階でNintendo Switch版の開発を開始すればちょうど良い感じになりそうです。（何がちょうど良いかは謎だけど）

?BIN$(RGB(0,0,0))　のようにして適当なR、G、Bで色入力をして2進数表示をすると上記で私が書いていることが伝わると思います。

他の方が書かれているコメントに補足するとプチコン3号ではARGBの32bitで色を指定しますが、Aを省略してRGBのみで色を指定した場合は不透明色が選択され自動的に上位bitの部分を占めているAは2進数で11111111となります。 つまり、その場合の色コードは11111111（Rの8bit）（Gの8bit）（Bの8bit）という32桁の2進数で指定している状態になっているため符号を表す一番上の桁は常に1になっていて負数になっているというわけです。 正の数になるのは透明色だけです。スプライトではSPCOLORによって半透明色が表示できますが、GRPでは事実上「透明か」「不透明か」しかないため半透明色を指定（正の数で色を指定）しても使える用途はかなり限られてしまい使用することは普通はないと思います。 それを端的に言えば「普通に色指定したらマイナス（負数）になる」ということです。

私はプチコンmkIIではいくつか擬似3Dレースゲームを作りましたが30fpsと60fpsではヌルヌル感が全然違いますからね。（プチコンmkIIの性能だと私が作っている最もシンプルな方法でようやく60fpsが実現出来るレベル） （New3DS使用時ならば）プチコン3号はプチコンmkIIと比べて2、30倍は高速といってもF-ZERO系の「2軸回転タイプ」のゲームは重いですからね。 普通の方法で汎用の2軸回転プログラムを作った場合だと30fps程度が限界であるため「60fps」のこのゲームは完成が楽しみです。（ちなみにVSYNC 1を外したらNew3DSで330fps前後ありました） 私も独自の高速化の案はいくつかあるため時間があれば別のアプローチで60fpsに挑戦してみたいです。

これは個人に限ったことではなく学校等で導入するならば生産終了した製品というのはどれだけ良いものであっても選択対象外になる可能性が高いです。 したがって、WiiUの生産終了によってプチコンBIGが学校のプログラミング実習で使用される可能性は極めて少なくなりましたね。 その点において非常に残念です。 とはいえ、個人で使うならば今後は壊れたら買い換えではなく修理して使えば良いというのであればしばらくは（部品の在庫の面で）大丈夫だと思います。 BIGでUSBキーボードを使って快適にコーディングしたものを3号で動作させるということも可能でありお互いの弱点を補強しあうことができるので3号をすでに使っていてBIGを買うのは個人的にはオススメです。

かなり前にNXが発売されたらそちらの方に生産を注力すると公式コメントされていたので今更驚きはしないのですが、プチコンBIG発売前だけにやはり残念ですね。 BIGが売れたらそれに連動して本体が売れて生産終了も延期・・・なんてことはないでしょうね。 少なくとも私はBIGが発売されたらBIGのためだけにWiiUを買うつもりですが、本体の生産終了が決定したらその本体の将来性はほとんど無いわけであって本体を持ってない人が新たに本体を買うに至らないでしょう。 こうなるとNitendo Switch版のプチコンの発売をお願いしたいところです。

個人的にはプログラミングは実際に自分で作っていろいろ試すというのが良いと思います。 私も未だに試行錯誤の繰り返しです。 「車輪の再発明」と言われるかもしれないですが、自分の手によって考え出したものは自分の力になると思っています。 プチコンで作ったGRP2軸回転プログラムにしろ、ポリゴンプログラムにしろすべて「自分ならどうやって作るか」という点からスタートしています。 自分で考える前にネットで調べていたら作るのは楽だったかもしれないですが、自分の力としては身に付かなかったと思います。 ただし、ある程度の経験がないと「いくら考えても解決策は出てこない」ため初心者のうちはある程度考えて分からないならば「人に聞く」とか「自分で調べる」というのも良い方法だと思います。 自分で考えることなく最初から他人に丸投げだったら「上達を放棄している」と私はみなしてしまいますが。

でんぺんさんも言われているようにプログラムには（特定の）正解はありません。 自分が想定しているように動けばどんなプログラムでも正解なのです。 したがって、自分が何をしたいのかを具体的に考えられるかが重要です。 命令を覚えた状態というのは英単語を覚えた状態、数学で公式を覚えた状態という感じです。 プログラムを作る場合は、その命令をどのように組み合わせるかが重要となります。 これはマニュアルを読むだけでは難しいので実際に自分でプログラムを作って動作させて確かめたり、他の人が作ったプログラムを読んだりするといった経験を積むことで自然に覚えることが可能となります。

でんぺんさんが書かれている「アニメーションが終わるまでウエイト」のプログラムを作る行程はこんな感じです。 毎回こんなにたくさん考えているのかというとそういうことはなく慣れてくるとここまで考えなくてもにあっさりできます。 ちなみにVSYNCとWAITは60fpsで動作しているプログラムならばほぼ同じ動作となります。（詳しくは私のプチコン3号入門講座を参照） VSYNCとWAITは入れなくても動作する場合がありますが、誤動作防止のためループ内ではできるだけ入れた方が良いです。

よって「アニメーションを1回分終了した時」をチェックするには以下の方法で可能となる。 @ANIMECHK WAIT IF (SPCHK(0) AND #CHKI)==0 THEN @ANIMECHK これは下記のように記述が可能。 REPEAT 　WAIT UNTIL SPCHK(0) AND #CHKI

これは10進数だと8、定数リテラルだと#CHKIとなっている。これは"CHK"にアニメ対象の"I"を合わせたもの。 以上より、アニメーション表示をしているスプライトの管理番号が0ならば SPCHK(0) AND #CHKI　がtrue（ここでは「1」ではなく「0以外の値」を示す）であればスプライトがアニメーションしているかどうかが分かる。 逆にいえば、この値が0ならばアニメーションは終了している。 しかし、SPANIMにおいてループ回数「0」で無限ループで設定しているとアニメは終了せずずっと続くため「0以外」を使用することになる。 もっとも素早く対応できるのはループ回数は1回のみの場合。