全貌が見えなくて判断しにくいんで公開キー出してみるのもいいかも？

ORと＋は同じではないですが、ビットのかぶらない数値同士であれば＋もORとほぼ同じ役割で使えますね。 文字数も1文字減るし理解して使う分には問題ないと思いますが、まったく同一というわけではないのでそこだけ注意って感じですね。 ボタンの値に関してはもともとかぶらないように割り当てられてるわけなので＋でも同じように感じると思います。 あとおかっぺBEERさんが言うように定数的な定義をするときは＋で繋げるのもわかりやすい気がしますね〜。

素直にあまさとしおんさんに教えられたように、C=CHKCHR(X1,Y1)にすればよいかと…。

特定のジャンル（RPG等）に特化してゲームを作りたいならツール系も良いかと思いますね〜。ただ普通のプログラムとは違うと思っておいた方がいいです。（一部スクリプトなどでプログラムが使える部分があるものもありますが） 何を使うにしても完成させるには根気が必要なので頑張ってください！

そういえばテキスト（コンソール）でやりたいんでしたっけ？ その辺の詳しい仕様とかも書いておくと良いかもです。

いろんな方法があるしどれが正解ってわけでもないと思います。ケースバイケースですしね〜。 チーム開発とか出なければ自分に合った方法でやればいいんじゃないかと思います。 僕は基本的には可読性重視ですが、プチコンの場合は画面が狭いので変数名が長いと変数名で意味がわかるのはいいんだけど構造としての可読性が落ちてしまうのが悩みどころで、結局中途半端な長さの変数名にしちゃいますね。 GOTOで飛ぶのはソースがスパゲティーになりやすいので嫌われますが、昔の行番号で指定する時代ならともかくラベルで指定する場合はラベル名などである程度わかりやすく処理できますし、流れをちゃんと意識して使う分には問題ないような気がしてきています。まあこれもケースバイケースですね〜。

キーボードが使えるなら嬉しいですね〜。あとは互換とファイル転送というか、例えばWiiU側で OPTION 3DS みたいにすると3DS版で使える機能に制限される（ので互換が保てる）みたいな感じであとはファイル転送で家ではWiiU、外では３DS、みたいな感じの開発が出来たらいいなぁ。 てかまだWiiU持ってないんですけどね(^^;

あまりフォローで協力してくれる人はいないと思いますが、それよりは熱意をみせていく方が良いような気がしますね〜。 ただこの手の合作は、あまり出来る人が協力してくれるのは少ないと思います。アドバイスなどはしてくれると思うので、それを元に自分で作るぐらいの気合いがないと厳しいかなぁ、と。 逆に出来ない人（？）というか初心者で何か作りたいという人の方が一緒に作ってくれる可能性が高いかも？　ただその場合は相手も初心者なので、どちらにしても一緒に頑張ろうって感じのスタンスじゃないと、って感じだと思います。 あとは作りたいもの（スクリーンショットの内容）をさらに細分化して仕様としての完成度をあげてみるなど、出来る事をやっていけば興味が出てきた人が協力してくれるかもしれませんね〜

プチコンBIGかぁ…。上位互換じゃなくてもいいので3DS版とデータ共有（＆転送）が出来ればいいなぁ…。そしたらWiiU版でキーボードを使ってとかも出来そうな気がするし…。

要望を以前言ったか言わないか忘れてしまったり他の人が言っているかもしれないというのもあるんで、ホームページの方に要望リストみたいなのがあるといいなと思います。 そこに出来ればステータスのようなもの（対応予定・却下みたいなの）もあるといいなと思います。

アホテレビデオさんは公開キーを出すつもりもないみたいですし、任天堂著作のものの画像をMiiverseに投稿することに関しては問題はなさそうなのでいいんじゃないでしょうか〜？ 既存作品を自分の力で再現するというのもプチコンの楽しみ方の一つだと思いますし、それを合法な範囲で行っているのであれば、なんの問題もないと思います。

ケインさんの言うようにユーザー定義命令／関数のループ変数で変数を宣言するのはちょっと面倒ですよね。ただスコープを考えるとローカル変数にしたいところではありますので僕もFOR VAR I=0 TO 9としたくなることがあります。 おかっぺBEERさんのIFの時のルールは意味合いはよくわかるし、僕もそれを試したことはあるんですが、どうも比較対象が左側の方に慣れてしまっていて馴染めませんでした…。この辺（比較演算子）はあまさと　しおんさんのような感じにしちゃってますね。

ケインさんのいうように管理番号は書類の方が向いてますね。僕も判子の台紙というか判子を押す紙の方のイメージがありました。 1枚の紙（管理番号）には1つの判子しか押せないけど、押し直し（変更）は出来る（前のは消える）って感じですね。 あとSPDEF命令はこの判子自体を作る命令みたいな感じですね。（実際は判子が印字する範囲を設定する感じですが） 絵で描く方がわかりやすい気もするけどMiiverseがバージョンアップしてから普通の手描き投稿は出来なくなったんですかね−…。残念です。

クセとはちょっと違いますが僕はコーディングルール的なものは結構変わったりします。ケースバイケースで色々と迷うんですよね…。 ただプチコンは文法が少ないので今のところは以下の感じです。ただこれもたぶんまた変わると思う…。 INC,DEC…使う。ただし不具合があるケースもあるんで必ずとは限らない。 OPTION STRICT…サンプル以外では使う。 カラー指定…あまり安定してない。黒などは0,0,0の方が短いので長さで決める場合もある。 1行の命令数…。基本１つ〜少なめ。とくに複数行になる長さにはならないように気をつけている。 配列、変数宣言。配列の場合はDIM。ただし普通の変数と配列を同時に宣言したいときはVAR。最近はVARに統一した方がいいかなぁ、と思ってきてる。 みたいな感じですね〜。

VSYNCはタイミング（同期）調整に使うので基本的にループに入るのはVSYNCと思えばいいと思います。 管理番号と定義番号は初心者が混乱しやすい部分だなーって思いますね。あきとさんの例も微妙にわかるようなわからないような…(^^; 定義が色んな種類がある判子だとしたら、管理番号はその判子に対して自分でID（番号）をつけるような感じかなと思ったりもします。と書いていてもなんとなくまだわかりにくい気もするし…。 とりあえずヘルプを読むときは管理番号と定義番号の意味を間違えないように注意した方がいいとは思っています。そうしないと結構混乱しますしね…

任天堂キャラの使用範囲がどこまで許容されるかはわからないので公開キーを出すならちゃんと確認した方がいいと思います。 （画面写真だけなら許容されてそうですが） 確認が取れるまでは公開キーは出さない方がいいです。公開キーを取れても後日問題が発生したり、その影響でシステムに制限などユーザーに不具合が起こらないともいえませんしね。

ケインさんの言うようにプログラムの流れを上から追っていくと通らない場所や命令などがあって、それがボタンにも影響している感じですね。確認してみましょう〜。 @HOTOPLAYは@HOWTOPLAYの間違いだと思いますが、それ以前にそのGOTOが通らなかったり＠Aや＠Bのラベル（飛び先）があるのかとか色々と問題がありそうな気もするんで、まずはプログラムの流れをきちっと追えるようになった方がいいと思います。 わからないことがあったら追加質問などをしながら、現在のプログラムを正しく理解する事が大事かなって思いますね。

何を作れるとか以前にプログラムを理解出来れば初心者卒業と言えるんじゃないですかね〜？ プログラムの理解とは、流れ・変数・分岐などの基本的なプログラムの動作原理みたいな感じで、ほとんどの言語に共通する部分です。 それが出来れば作りたいものに合わせて他の命令（スプライトやBGなど）を覚えて組み合わせればある程度までは作れると思います。そこからまた上に上がるには数学・物理的な知識やアルゴリズムなど知っておいた方がいい事が増えてくると思いますが、とりあえずプログラムを組むという事についての理解が先かなーって思いました。

スマイルツールのマップはサイズ固定なので32×32以外のマップは作れない（はず）です。ただコード的には対応している部分もありそうなのでプログラムを直接いじればサイズ調整出来るかもしれませんが…。 僕が個人的に作っているマップエディタのPUCHI-MAPなら可変サイズで作成する事が出来ますし、基本的には公式ツール互換です。ただレイヤー書き出し機能が無いのでレイヤー形式の保存に関しては互換性がないので、その機能を使っている人には向かないと思いますが…。一応バージョンアップも検討はしています。 公開キーなどは僕のマイページに書いてあります。良かったらどうぞ。

ダイレクトモードに限定している理由はなんですか？　試しに表示してみたいから？？？ スマイルツールで作ったマップを一発で表示する命令はないので、ダイレクトモードで表示したいと思ったら複数の命令を実行することになると思います。また出力がマップ形式かレイヤー形式化によっても変わってきます。 ということでとくにダイレクトモードにこだわらないのであれば、普通のプログラムの方がいいと思いますがー…