ちょっと試してみましたが、とりあえず３行目の後にもVSYNCをいれたら正常に動作するようですよ。他のところもVSYNCで問題なさそうです。 僕も更新周期を合わせるという意図ではVSYNCの方が適していると思っています。のでループの中ではVSYNCを使うんですが、上記のようにボタンの情報更新のタイミングはイマイチ自信が持てないので、場合によってはWAITを使うようにしたりもしています。 とくにDIALOGやINPUT命令の後のタイミングとかだとボタン情報が想定外になった事があった気がするんですよね。なので上記の命令の後にはWAITをいれて次のボタン情報（メインループなど）に備えたりすることもあります。 と言いつつバージョンアップなどで細かい挙動は変わってる可能性もありますし、もしかしたら今ならVSYNCだけで問題ないのかなって思ったりもしますけどね。 ＞あまさと　しおんさん

あれ？　あまさと　しおんさんのコメントに対する意見ですが、僕の認識ではVSYNCの方が取りこぼす可能性があるような気がしています。 と言うのは、WAITは必ず最低１フレームは待機する（のでVSYNC周期は確保される）のに対し、VSYNCはメインループの重さによってはウエイトが入らない（から取りこぼす可能性がある？）からです。 といいつつ僕も細かい内部の動作はわからないので正確な事はわからないです。ただ僕は前にVSYNCで処理していたときに取りこぼしたのかうまく処理できなかったことがあったので、以降はメインループのVSYNCではない時でボタンの情報が確実に欲しいときは念のためにWAITにしています。 おそらくこの辺の挙動についてはおちゃめさんが詳しいような気がするのですが、間違っていたらすいません。

BGPUTやBGFILLによるBG表示自体は知っている感じですか？ READ、DATAを使ったBG表示がわからないという事だったら、以前僕が書いたこの辺りも参考になるかもしれません。 https://miiverse.nintendo.net/posts/AYIHAAAEAADHVHhkXOo6ng

みなさんが言っているようにボタン情報は一定時間（１フレーム）毎に更新されるので、間にVSYNCやWAITが入らないと変化しない（前のボタン情報のまま）の場合があります。 なのでボタン処理の後にまたすぐボタン処理がある場合は、その間にVSYNCやWAITを経由するか確認して、経由しない場合は間に追加するなどしてボタン情報を更新してあげる必要があります。 基本的にVSYNCでも問題ないとは思いますが、ボタン情報を更新するという意図であれば確実性を重視してWAITにするという方針もあります。 とりあえずどちらでも良いので試してみて確認してみてください。

若いのならば数学に限らず色んな事に興味をもって勉強して欲しいと思います。プログラム（ゲーム）に限って言うならば数学・物理あたりは知っていると便利ですが、英語もわかると最先端の情報（ほとんど英語発信が多いので）に触れる機会が多くなると思うし幅が広がると思います。 みなさんが言っているようにとにかく色々知っていることがプログラムの幅を広げてくれるので、とくに若いうちは吸収力も高いので、色んな事に興味を持って勉強することがプログラムの力にもなると思いますよ。

僕的にはBREPEATを使うのは、コマンドカーソル的なものがオススメ。 普通のキャラクター移動なら、ぴくとさんやおちゃめさんの方法で、移動量を変えたり、移動処理に入るのを数フレームに１回みたいなタイミングにしてスピード調節するのが良いと思いますよ〜。

みんなが書いてあるようにGOSUBはRETURNで呼び出し元に次に戻ってこれるので、すぐに帰ってくる予定があるならGOSUBが良い。 ただしGOSUBしておいてRETURNで戻らないで何度もGOSUBをする（とくにループないだと起こりやすい）と、いずれエラーになるので注意！

あとパターン２で「ここに入ってしまう」に遷移するのはごくごく自然な動作です。とくにおかしくもありません。 というのはパターン２の呼び出し側のLOOPを終えた後は、その下のWHILEに入るからです。 なんとなくDEF呼び出しの感覚がGOTOに近いのかと思いましたが、DEF呼びだしはどちらかというとGOSUBに近いです。なので呼び出したら、DEFが終わったら呼び出した後に戻ってきますし、そう考えればパターン２もとくにおかしな動作ではありません。 ただ上記の理由もあって、今のプログラムはちょっとゴチャゴチャしてる印象はありますね。

基本的に、関数（やユーザー定義命令）の中で、その外（呼び出し側）のループに対してBREAKをするということは出来ません。ただもしかしたらプチコンでは出来るのかもしれませんが、その場合も処理としてはあまり好ましくないと思います。 詳しくはみてませんがりゅうまごさんが色々と返事をしてくれていそうなので、その辺を参考にして、わからないところは質問すれば、また教えてくれると思いますし、僕も気づいたら返事します。 頑張ってください！

これから他の言語も覚えていきたいという感じだとしたら出来るだけGOTO、GOSUBは使わない方が移行した時に楽だと思いますよ。 ただsayさんも言われているように、GOTOやGOSUBはBASICの特徴でもあるので、あえてそれを封印せずに使ってみるのも面白い面はあります。 ただだとしてもGOTOは使い方を間違えるとスパゲティーなソースになりやすいので、自分でも言われているようにGOSUBだけ解禁するというのもありかもしれませんね。 あとだとしてもDEFを覚えることはプログラムの幅を広げられるので、わからなかったら質問するなりしながらきちんと覚えた方がいいとも思います。

なかなかこの手の共作は難しいところがありますよね。 不可能ではないと思いますが、どの分野でもいいですが、ある程度出来る人が中心にリーダーシップをとって、みんなをまとめていく力がないと難しいと思います。そうじゃないと大抵は空中分解しちゃいます。 あとは公開出来ないのは寂しいので、マイクラだとしてもマイクラ風という感じで、まったく同じ物を目指すのではなくて独自色をいれていけば公開も問題ないと思います。 と、なかなかハードルは高いですが頑張ってください。

一応。オワたず(^p^)ゝさんも指摘されているように、公開キーは後からでも削除される可能性があります。（むしろそれが多い？） そして公開キーを削除される＝違反をしている場合、下手するとアカウント凍結（二度と公開出来ない？）の可能性も出てくるので、著作権的に危ないとわかっているならば公開キーは発行せずに個人だけで楽しむのが無難ですよ。

キャラクターの位置はXとYに入っているので、出現位置を変えたい場合は、@IDOUより前のところで X=200 Y=200 みたいにすればその位置に変更出来ますよ。 ちなみに今はなにも設定されてないのでデフォルトの0になってる感じです。 また@IDOUの中に入れてしまうと毎回座標が初期化されてしまうので気をつけましょう。 その辺はプログラムの流れをちゃんと理解すればわかるとは思いますが、そんな感じですね。

おそらく以前回答してくれた人は、キャラクター座標がX,YじゃなくてX*5+200とかになっているので、それを指摘した感じなんでしょうね。 X*5+200とかの場合、画面の中心を基準にキャラクターの位置を決めているので、そういう意図がある場合をのぞいて、あまりキャラクターの座標としては適しているとはいえません。なので素直にXとYをそのままキャラクターの位置（SPOFSの位置）にした方がやりやすくわかりやすくなると思いますよ。 ただ今回の場合はキャラが３ついて同じX、Y座標を使っているので、その辺の調整は必要になると思います。

あ、そもそもXとYが座標そのものじゃないんですね…。となると単純にそこにいれても制限とは関係なくなっちゃいますね。 SPOFS 0, X, Y の場合は上記で移動制限になります。ただそういうわけではないので下の４行のIF文は今の処理への移動制限としては機能しない感じにになってますね。 間違えたことを言ってしまいすいませんでした。

これだけだとどう返事して良いかわかりませんが、まずはステージクリア式のアクションゲームを作れるようになる感じですかね〜。 その後、そのステージをコンストラクション出来るようにエディタを作り、統合していけばマリオメーカーみたいになると思います。 ただそもそもとしてゼロから作るのは大変な作業だとは思うので、その辺は少しずつ頑張ってみてください。 具体的な質問があるときは、また質問をすれば返事がもらえると思いますよ。

単純に移動制限をかけたいだけなら下の４行を１７行目に追加するだけで３つ全てに移動制限がかかると思いますよ。（３つとも同じ座標変数なので）

イマイチ意味がわからず…。とりあえず下の４行は今は実行すらされないですよね？ 今のプログラムだとスプライト０〜２が同時に同じ位置に動く感じになってますよね？　これをスプライト２だけ下４行の移動制限をつけたいという感じなのでしょうか？ ちなみに複数のスプライトを同時に別々に動かしたい場合は、座標となる変数をその分複数用意（配列の場合もある）するか、もしくはSPOFS 0 OUT X,Yなどで、そのスプライトの今の位置を取得して、それに対して処理をする、みたいな感じになります。 何にしてもちょっと意味が読み取れてない部分があって正確に判断できないのですいません…

DEFには主に２種類の方法があって、一つは関数、もう一つは命令になります。 関数の場合は（）がつき、RETURNで値を返します。返せる値は基本的には１つです。（配列などにすれば変わりますが） 命令の場合は（）は付かずに値を返す場合はOUTを使います。OUTを使った場合は、その変数名に値を入れる事で返せます。 なので今回のように３つ値を返したい場合は、 DEF GGET X,Y OUT R,G,B A=GSPOIT(X,Y) RGBREAD A OUT R,G,B END と命令にすれば一応目的は達成できると思います。（ちょっとRGBが同じOUTでまぎわらしく見えますが…） とりあえず基本はそんな感じですね。

今更ですが更新したのでここにこっそり公開。 PUCHIPACK v1.90/公開キー：W2CQF3D4 GPAGEを戻すようにしてみました。 またPUCHI-LOADERとPUCHI−SAVERを統合したPUCHI-FILERを新規追加しました。それに伴い、LOADERとSAVERは最終バージョンとなります。 PUCHI-FILERはLボタンを押しながらPUCHI-LAUNCHを起動するとショートカットで起動する機能も付いているので、統合的に活用してもらえたらと思っています。 正式なアナウンスはいつになるか（するか）不明ですが、とりあえずよろしくお願いします。