変数D絡みの部分は不要に見えますが、主な処理は同じ流れですね〜。

途中段階なのはわかっていますが、STICKをTOUCHに変えただけのようなプログラムを出したら、始めは僕のような回答になると思いますよー…。基本的には提示した内容に対してのアドバイスが基本で、その先まで読むかどうかは別の問題なので…。 元がおちゃめさんのプログラムなので、おちゃめさんが回答してくれたのはわかりやすくて良かったと思います。実際それで出来たみたいですしね。 ちなみに僕が次にアドバイスするとしたら提示しようと思っていたプログラムは次のようなものでした。もう不要だと思いますがせっかく用意してあったので載せるだけ載せておきますね。 ということで、これからも頑張ってください！

boolean型の扱い（厳密度）は言語によって異なりますよね。 暗黙の了解で自動で型変換をしてくれる場合もありますし、特別な型があるわけではなく整数型の0と1などで分けている場合もありますし。 新しい言語ほど厳密にすることでのヒューマンエラー（勘違いや見落とし）を無くそうとしているような傾向がある感じがしますね。

類似の質問が無いかってのが出るのに検索機能すら無いのがネックだったりも…

ちょっと気になったのは、PRINTとかで”（ダブルクォーテーション）を閉じてないけど、PRINTやDATAとかでは”を閉じなくてもエラーにならないけど、文字列という意味では”で囲まれた文字が文字列になるので、ちゃんと”を閉じておいた方が良いような気がする。 まあわかっていて１文字削りたいとか理由があって”を書かないのはいいんだけど、LOADを見た時に普通なら”（ダブルクォーテーション）が抜けてる違和感を感じるんだけど、省略になれると違和感感じないのかと思ったので一応って感じでした。

別に作りたいもの（それがRPGならRPGでも）を目標に進めるのも悪くないとは思いますよ。ただなにを作るにしても簡単には出来ないのでコツコツをやることが大事です。 またRPGだとしても、どんなRPGを作りたいかのイメージを明確にするのは大事です。例えば見下ろし２Dと３DダンジョンRPGでは始めの表示から違いますし、システムもRPGによってコマンド選択だったりリアルタイム風だったり色々あります。自分がその中のどんなものを作りたいかのイメージが大事です。 そしてイメージが出来たら、それを分析（分解）することも大事です。そうやって細かく（小さく）していき、その小さくなったところを少しずつ覚えて組み上げて大きくしていくような作業が必要になってくると思います。 何にしても本格的なゲーム！って考えると行き詰まるのでRPGだとしても始めはなるべくシンプルなものを目指してみるのがいいですね

全・全・半・全・全・全・半

ボタンは押したボタンによって直接方向がわかるけどスライドパッドはアナログなのでその値（移動量）から方向を算出しています。通常はATANなどを使って角度から方向を求めますが、おちゃめさんの場合は４方向なら単純な移動量比較で求められるというところが優れているところです。 TOUCH命令の場合は、戻ってくる値は移動量ではないので、まずは移動量を求める必要があります。それが出来ればその移動量はSTICKの値に近い値として扱えますが、STICKと違い画面上での移動量はY座標の符号が反転するので、そこだけ逆にします。その上で、その移動量から方向（向き）を求める（やり方はおちゃめさんの応用で出来るはず）ようにすれば、目的の動作になるんじゃないかと思います。

画面のアレンジを見た感じ、アレンジを間違っていますね。STICKとTOUCHは違うので、単純に命令を入れ替えたようなアレンジではうまくいかないですよ。 元の位置からタッチされた方向を利用して方向を出すという考えは間違ってない部分もあります。その考え方の元、おちゃめさんのプログラムを応用する感じにしないと目的の動作にはならないと思いますねー…。

書き直そうと思って消したら返事が…。 タッチした方向に動く場合、タッチした場所にまっすぐ歩いてくる感じですか？ 基本的には追尾に近い処理になるので三角関数の出番ですね。

アニメーションがなくてわざわざ定義するほどでもないものであればSPDEFせずにSPSET出来るのは便利なんですが、確かに使い方が多いと混乱が増えるというデメリットはありますね。 この辺は経験である程度は回避（推測）出来るのですが、逆に初心者は経験がないわけなので難しくなってしまう部分があるんだと思います。 「どんなサンプルでも結局は一例に過ぎない」というのはその通りでプログラムの場合はとくにその面が強いと思います。なので逆に同じような内容の処理でもたくさんのやり方のサンプルに触れた方が勉強になりますし頭が柔軟にもなります。 僕はサンプルとして適しているのは目的に特化した感じでリストが短い（出来れば1画面内）ものかなと思っています。（ので自分がそういうサンプル作ってましたし） また出来るだけ公開キーでダウンロードするよりも自分で打ち込んだ方がいいと思ってもいます。

だにえるさんが言っているように同じ管理番号をゼロから再利用する場合は、SPCLRせずにSPSETから始めても大丈夫です。SPSETは基本的に設定が全てリセットされます。SPCLRは単純に不要になった管理番号を消したいとき（そしてすぐに利用するわけではないとき）に利用すると良いでしょう。 そしてご理解されたように絵だけ変えたい（切り替えたい）なら逆に他の初期化はして欲しくないケースが多いのでSPCHRで切り替えるだけでいいと思います。 また研究の仕方としては、僕が載せたプログラムのようにテストしたい部分のみの必要最低限のプログラムを書いてみて検証するのが良いです。プログラムは大きくなってくると要因が増えて特定がしづらくなる部分もありますからね。 また簡単なチェックぐらいならDirectモードでテストしてみるのもありです。僕自身も慣れない命令はDirectモードで試す事もあります

思い込みや勘違いでというのはまあありますからねー…。形だけでなく意味もしっかり覚えておくことが大事、みたいな感じですかね。 で、スプライトの絵（定義番号）を切り替えたいならSPCHRが便利ですよ。SPCLRからのSPSETだと座標情報とかほとんど初期化されちゃいますがSPCHRなら絵が切り替わるだけなので。 アニメーション（パラパラ系）の場合は、SPANIMで”I"（定義番号）を使えば一定時間毎に絵（定義番号）を切り替えてアニメーションっぽく見せることが可能です。

そうそう、イメージとしてはそんな感じですね〜。 なので当然ですが別々の管理番号に同じ定義番号（絵）をSPSETして表示すれば、同じ絵を複数表示する事も当然可能ですし、それを上画面も下画面も同じものを表示する事も可能です。 基本的に管理番号と定義番号を同じにして扱うことはほとんど無いと思いますね〜。

管理番号はスプライトを画面に出すときにそのスプライトに番号を割り当てて管理する為のものです。なので１つ表示する為には１つの番号が必要です。 定義番号はそれとは違い、画像（グラフィック）に対してスプライトとして使う部分を定義したときに割り当てる番号です。なのでこっちの方は画面に出てなくても定義することで１つの番号を使います。こっちは画面表示とは関係ないので表示出来るスプライトの数以上の数を定義しておくことが出来ます。 （のでデフォルトでは同じ絵に対して原点が違うものと2パターン用意（定義）しているようです） 上画面、下画面で使うのが各14個だけなら、スプライトの管理番号は上画面も下画面も0〜13（合計14）番だけ使えばいいはずです。 ちなみに定義番号が400番のスプライトを表示する時には管理番号は400番を使わないといけないというわけではないですよ。

上下合わせて512個のSPなので振り分けるとどうなるかはVillitさんの答えの通りです。おそらく振り分けた以上の番号を使おうとしているからエラーになってるんだと思います。 また表示しようとしたときにエラーになってるのはデフォルトのスプライトじゃなくて自分で定義（SPDEF）したスプライトだからと言うのは関係ないと思いますね。 管理番号と定義番号がごっちゃになってる可能性もありますが、どうも説明が不十分というか推測が必要部分が多いのは僕も感じもます。 ただそれ自体はわかってないことを質問しているのでしょうがない部分もあるとは思っていますが、原因を突き止めるためには症状が発生する短いサンプルとなるプログラムを作ってみるとか、実際に不具合があるプログラムを公開した方がいいような気はします。

これを試してみてください。 ちゃんとタッチの位置が原点なのがわかると思います。

TOUCHの座標だからSPの位置が左上端になるということは関係ないと思うので、なんらかのミスや思い違いをしているような気はしますが、とりあえず動作することは大事なので自分なりのやり方を見付けたならそれでもいいのかなとは思います。 ただ間違った情報になる可能性もあるんで、その場合はシンプルなサンプルプログラムを提示するなどした方がいいかもしれないですね。

基本２ですね。紙に写す場合、写すときに間違える・入力するときに間違える、と間違える可能性がより高くなるので、その辺がネックですよねー…。 あとパスワードが文字列なら、間違えやすい文字は両方出ない（Oと０，１とIなど）とかの工夫もあるといいのかもしれません。 パスワード式は面白くもありますが、ただネットの時代だと結局通信に頼った方が楽になってなかなか生きる方法がありませんよねー…。

他の人も書いてますがSPANIMでアニメーション（"I"）を使っていますか？　それによっても異なります。 I（定義番号）のアニメーションなど、スプライトを定義番号で切り替えた場合、定義には原点座標の情報も含まれるので、切り替えた時点で原点座標が変化します。なのでSPHOMEで原点座標を変更していても、その後定義番号を変更（SPANIMやSPCHR等で）したら原点座標は定義で設定されている値に戻ってしまいます。 これを回避するには定義の方の原点を変更しておく、ということになるのでSPDEFの時にきちんと原点を設定（変更）しておく、ということになる感じです。 SPSETやSPCHR後にキャラクタを変更しないのであれば、その後にSPHOMEして原点を変更すればそれは継続するので問題ないですが、アニメーションとかしている場合は注意です。