SPANIMを使ってアニメーションをさせる場合 メリット：あらかじめ指定した通りにアニメーションが可能。（速度面でも有利） デメリット：SPANIMの書式を覚える必要がある。アニメーションを途中で終了する方法はない。 SPANIMでアニメーションをするにはいくつかの方法があるけどアニメ対象は"I"を使用するのが最も簡単。 では、SPANIMでアニメ中の定義番号を取得する方法はあるか？→無い できるのはアニメーションをしている最中かどうかの取得だけ。 取得するにはSPCHKを使用すればいい。 SPANIMをヘルプで見るとのbit03がキャラ定義の番号となっている。 bit03というのは2進数だと1000となっている（bit00が1、bit01が10、bit02が100であるため）

アニメーションを実行中かどうかのチェックを行うプログラムをどのように記述するかを考えてみます。 SPANIMを使わず自前で1フレームごとにキャラを変えていく場合 メリット：任意のタイミングでアニメーションを終了可能 デメリット：自前ですべて制御しなくてはならない。（プログラムを書くのが大変、処理が遅くなる） 方法(1)：異なる管理番号のSPを表示する。 方法(2)：SPCHRでキャラの定義番号を変える。 方法(3)：SPDEFでキャラの定義をし直す。 自分で好きなものを選択すればOKです。 今回は「SPANIMを使う」ため(1)～(3)のプログラムについては省略します。

2軸回転の難しいところは速度を上げることとカメラの設定位置だと思います。 表示するドット数が増えれば増えるほど演算量が増えるため400x240ドットの画面では96000頂点（≒32000ポリゴン）の3D処理と同じくらいの演算量になってしまいます。 ループ内では可能な限り演算量を減らすことが求められます。 あと3D空間におけるカメラの位置は自由に設定できますが、カメラ中心の一人称視点ではなく三人称視点（画面上でのプレイヤーキャラを中心に回転させる場合）の場合には「カメラの向きが地面に対して平行」という最も簡単な状態であっても三角関数を使ってカメラ位置を計算しなくてはならないためです。（その点、一人称視点ならば簡単） つまり、2軸回転を作るならばカメラの向きは地面と平行で固定、カメラ中心の回転（一人称視点）にするのが最も簡単です。

この1軸回転（Z軸回転）の仕組みをちゃんと理解できれば2軸回転も行うことができますね。 GSPOITで読み出す座標を「もう1軸分の回転」を加えた座標にすれば良いだけです。 カメラの向きを読み出し画像に対して平行（言い換えれば地面に対して平行）の向きで固定すれば「もう1軸分の回転」はただの反比例計算で済むので簡単です。 「もう1軸分の回転」を固定ではなく自由に行いたいならば三角関数を使って計算すれば良いだけです。

セーブデータ作りが面倒とか良く分からないというのであればMIKIさんのVFILERを使うと良いです。数値変数、文字列変数関係なくまとめて1回でセーブできます。 https://miiverse.nintendo.net/posts/AYIHAAAEAABEVRTtQa5Q3Q ちなみにPSTR$によって数値も誤差なく文字列化されているので安心です。

セーブを1回で完了するには文字列にするか数値配列にするしかありません。 両方が混在の場合は文字列で統一する方が作りやすいでしょう。 値に小数や大きな数を使用していた場合にはSTR$では文字列に変換する場合に丸め誤差が発生する可能性がありセーブしたものを「ロードしたら値が少し変ってしまった」となる可能性があります。 私の自作関数PSTR$を使えばそれは回避可能です。 https://miiverse.nintendo.net/posts/AYIHAAAEAABEVRTp-ZVMIg 文字列にまとめた場合には区切りコードを入れるなどをして正しく分解できるようにセーブデータを作らないといけません。

影をリアルにしようと思えば思うほど他の部分との整合性が取れなくなるし処理速度も遅くなるため妥協することも大切ですね。 簡単でそこそこリアルにしようとするならば影を自動生成するのではなく影のスプライトのドット絵を別途用意するのがベターだと思います。

るかかさんへ 乱数を自在にコントロールできるとゲーム作りに非常に大きな武器になります。ゲームにおいて乱数というのはほぼ欠かせない存在ですからね。 ちなみにこのADAMは実は1年半前にMiiverse上ですでに発表していますが、1箇所バグがあったのと当時の投稿は説明不足の部分があったので今回再投稿となっています。 前回と比べて反響がかなり大きくなっているのはMiiverseにおいてトピックスの最初のコメントや画像がすごく重要だからでしょうね。 どれだけ良いものを作っても最初の段階で「それはどんなものなのか？（どういうメリットがあるのか？）」が分からないと良さを理解してもらいにくいためだと思います。

Brainf*ckはアルゴリズムが単純であるため初心者の腕試しには最適ですね。 私もプチコンmkIIではエディタと実行環境をコミで1画面プログラムに収めました。 プチコン3号ではQSPに収めようと頑張りましたがさすがに無理でした。 ちなみに四則演算プログラム等をBrainf*ckで作りましたがさすがにBrainf*ckでゲーム作りは難しすぎて無理でした。

私が作った当時プチコンで2軸回転プログラムを作った人は誰もおらずこの方法を自力で考え出すのに数日かかってしまいました。 とはいえ、すでにポリゴンプログラムを作っていたこともあって原理が分かれば計算そのものはそれほど難しいものではありませんでした。 ちなみにポリゴンプログラムは大昔にポケコンでワイヤーフレームプログラムを作った経験があり、プチコンではGTRIに相当する三角形描画プログラムをすでに自前で作っていたこともあり、苦労したのはポリゴンの前後関係くらいです。 2軸回転が難しければ回転軸をZ軸に限定してカメラはキャラの方ではなく地面に水平に向けると私が行っているような特別なビュー変換処理が不要でピンクの線はカメラからの距離に反比例するだけになるため難易度がかなり下がると思います。 やっていること自体は単純なのでぜひ挑戦してみてください。

私が作った2軸回転プログラムはマリオカートやF-ZEROのようなゲームを作りやすくするため自キャラ（図の赤点）を中心に回転しています。（カメラは常に自キャラの方を向いていてキャラから見てどの角度、どの距離にカメラを置くかを自在に設定できる） カメラから見るとピンクの線は遠くのものほど間隔が空いていますがこれは計算によって画面上では等間隔になります。 カメラが画面のX軸に対してθラジアン回転した方向に向いている時、ピンクの線はすべてθラジアン回転しています。 このピンクの直線上にあるピクセルをGSPOITで読み出して画面に表示すれば2軸回転が完成する（便宜上ピンクの線は8本しかないですが、実際は画面の縦のドット数の分だけ高密度にある）というわけですが、ピンクの線は直線であるためX方向の増分もY方向の増分もループ内では固定であり増分量をループ内で計算する必要はないということです。

自サイトで詳しく説明しているものをかなり簡略化して図も省略しているためこれで理解してもらえるかどうかは微妙です。 私はプチコンmkIIにおいてポリゴンと2軸回転プログラムを公開していますが、正直言ってポリゴンプログラムの方が簡単にできました。（基本部分は一晩で完成） シェーディング処理による速度ダウンを改善すべく高速化処理を行ったのとUI作成に手間取った程度です。しかし、2軸回転は基本部分を作るだけで数日かかってしまいました。

ちなみに上記記載のサンプルプログラムにおいてP=1:Q=0となっていますが、これは一様分布の状態となっています。 ADAMの明確な効果を確かめるにはP、Qの値を推奨範囲に変更しておいてください。

透視変換はZ軸回転の際に同時に行うことによって高速化を行っています。 2軸回転は比較的難度が高めであるためワイヤーフレーム等で3Dの基礎的なプログラムを作ってから行えば理解が早いと思います。 私が作った2軸回転プログラムは仕組みを理解せずとも誰でも使えるものになっているはずなので2軸回転をしたいというだけならばそのまま使えば問題ないです。 私は「自分で考える前に作り方をネット等で調べる」ということをせずに作ったあとで調べただけなのでプログラムの仕組みはほとんど私の独自のものです。 したがって、これがベストな方法かと言われると微妙な部分もあるため参考程度に止めてもらえると幸いです。

そこで、Z軸回転は回転行列を使わず別の方法で行います。その方法は「画像　回転　アルゴリズム」などで検索すれば見つかると思いますが要するに元画像を回転させるのではなく読み取る段階でX座標、Y座標の角度をずらした座標を読み出すだけです。 角度というのは1ドットごと変わるものではなく一定であるためループ内は加減算処理のみで済むため高速化ができるというわけです。 ビュー変換は私は行列を使わず空間図形の方程式から求めました。GRP画像を地面に描かれているものとするとカメラの角度が斜め方向ではなく地面に対して水平だったらビュー変換そのものが不要であるため省略可能です。 ただし、X軸回転を無くしたら「2軸回転」と呼んでいいか微妙になるため私は多少速度は落ちても自由に回転できる方を優先しています。 とはいえ、普通にビュー変換を行うよりは圧倒的に高速だと思います。

私の2軸回転プログラムは大半が私の独自の方法で行っていますが、表示原理をごく簡単に説明すれば画面上のドットが元となるGRP画像のどのピクセルと対応しているかを計算によって求めれば良いだけです。 普通に考えるならば回転行列を用いてZ軸回転（ワールド変換）してそれをカメラアングルに応じてビュー変換を行い透視変換（射影変換）でパースが付くようにすれば良いですが、それだとめちゃくちゃ遅いし回転行列でピクセルが1対1で対応しているわけではないため隙間が空いてしまうという問題点があります。

ネームバトル系のゲームを作るならば文字列のキャラコードを足して割るなどをして0～1の値（0より大きい値）をSの値に設定すればそれが固定値になるしブラックボックスの擬似乱数であるためプログラムリストを見て最強キャラを見つけ出すというということはできないというメリットがあります。（自分でパラメータを生成するプログラムを作っていたらリストを解析すれば最強キャラがばれてしまう） 要するにプチコンで用意されているRND関数（RNDF関数）をそのままで使うのではなく何らかの加工をすることで便利で面白い乱数を作ることが可能になるということです。 自作プログラムでADAMをそのまま使っても良いですが、「自分好みの乱数を作る」というのも楽しいですよ。

実はこれは昔ポケコンで作ったものをプチコン3号に移植したものです。 ADAMの特色は引数を変えることで分布を自由に変えることができるという点です。 Qの値を大きめに設定すれば一様分布の範囲をこんな感じに広くすることも可能です。

ただし、希少性を高めれば高めるほど中央付近の値が出やすくなるという問題があります。 RPG等のパラメータ生成だと複数のパラメータを生成しても平均に近いパラメータばかりが生成されてしまい個性的なキャラが出来上がることはほとんどありません。 希少性とバラ付きを別々に考えることができないため「単純に複数回足して割る」という乱数は使いにくいと感じました。 ということでできたのがこのADAMです。

これで問題なければそれで終わりですが、これよりも大きな値の希少性をもっと高めたいとか希少性を自分でコントロールしたいという場合にはどうするかというともっとたくさん足して平均値を求めれば良いのです。 足す回数が多くなるほど中心極限定理によって正規分布に近いものになります。 例えば7回足して7で割ったものはこのような形になります。