上級者で可能性を求めるのは、プチコンで存在しない機能（外部通信、3D表現など）をプチコンの機能で実現したり、短いコードでいろんなことを実現したりとか、そういう方向になってきて、ひとめ見てあんまり面白くないことが多いです。 いろんなゲームを遊びたいとか、どんなことができるかという理由ならMiiverse投稿の公開キーを探してみるか、公式ページのユーザ投稿ページにいろいろとあります。 http://smilebasic.com/user/

具体的に行きたいラベルがあって、何番目を選んだかの変数があって、この条件のときにはこのラベルに行きたい、ってあるならそれを書けばいいだけな感じです。 ちなみに他には ON 制御変数 GOTO @ラベル0, @ラベル1… ON 制御変数 GOSUB @ラベル0, @ラベル1… の命令があるのでヘルプをみてみるといいかもです。

選択画面のカーソルの場合、図だと４つ選択できるので、まず「現在何番目が選択されているか」の変数を用意して、何番目に対応するYの値を設定するようにしたほうが制御はしやすいです。 上を押したら「何番目から１引く」して、下を押されたら「何番目から１足す」をするけど、１番上にいるなら上を押しても１引く処理をしないようにしないといけません。 （同じように１番下にいるなら下を押しても１足す処理をしないようにする） Aボタンで決定するときは「何番目」の変数を元に、処理を分けるような感じになります。 たとえばさっきの作りだと、処理を振り分けるループで呼ばれるさらに別の処理で「何番目」の変数を参照して処理をする、のような作りになります。

ゲームの流れとして、たとえば「タイトル画面」「選択画面」「選択画面先のなにかの画面」「ゲームのメイン処理」などいろいろあったとして、 この画面の移動を制御するしくみが必要になります。 画面移動の制御としては、プログラムを上から順番に実行していったときにタイトル画面のループがあって、それを抜けたら次は選択画面のループがあって、のようにプログラムで順番に書く方法だと制御がむずかしくなるので、 「現在どの画面か」の変数を用意しておいて、「現在どの画面かの変数によって処理を振り分けるループ」を作り、そのなかでタイトル画面や選択画面へ移動するような作りもあります。 こうすることで、Aボタンを押したら「現在どの画面か」の変数を変更して、選択画面の処理を抜けてしまえば、処理を振り分けるループが勝手に次の画面に移動してくれるようになります。

おちゃめさんの解説の補足 スライドパッドでATAN使って角度計算しているところは方眼紙に時計や座標を書いたりすると分かりやすくなります。 （今回の以外でもプログラムの説明はあたまのなかで考えるより紙に書いたほうが理解しやすいです） 考え方はスライドパッドの入力向きを、どこかを０度の基準として角度として取得しようとしていて、プログラムで使いやすいように０度の位置を変更しています（数学なら３時の方向が０度で反時計回りに増える） 説明中の「+405」は「+360+45」を表してます MODは 割り算のあまりを求める計算で、角度の範囲がマイナス値にあると思うように動作しないので、360を足して 360の割り算を求めることで、0から359の範囲を求めてます。 円の角度とか第１象限とアークタンジェントとか中学や高校数学のお話もでてくるけど、数学ってこういうところで役に立ってきたりするのです。

誤字ミス訂正 × Ｂｈｓ０ ○ Ｂが０ プログラムは実行させたいことをコードとして書くことなので 「B==0」は「Ｂが０のとき」と解釈できるけど 「!B」は「Ｂに値がないとき（Ｂに値がある、ではない）」と解釈できます どちらもプログラムとして動く結果は同じだけど、日本語に直すと厳密には意味が違ってきます。 この厳密には意味が違うことを意識してないと、バグの原因として気づかないまま「なんかプログラムの動きがおかしい」ってのが起きることがあるので、条件式に本来の自分が動かしたい条件とちょっとちがう書き方をする場合は注意したほうがいいです。 「１以上（1含む）」の条件を「B>=1」や「B>0」と書くところ「B」と書いてみたけど、実はB が -1 のときに「B>0」はFALSEだけど「B」はTRUEとして扱われるとか、そういうのがあったりします。

「==」とか「!=」とか「>」とか「>=」とかは「比較演算子」と言って 左辺と右辺を比較した結果を演算結果として返す記号で、実は「+」とか「*」とかの足し算やかけ算と同じような計算記号なのです。 「3+5」は結果が「8」になるけど、「B==0」としてBｈｓ0だったらこの答えが「TRUE(値は1)」となるのです。 計算結果なので、変数の代入にもできて「X=(B==0)」とすれば変数X に 「B==0」の結果がTRUE(値は1)かFALSE(値は0)で代入されます。 IF文は比較式の部分に書いたものを TRUE(0以外)かFALSE(0)かで判断します。 BUTTON()の結果はボタンが押されてなければ 0 になるので FALSEとして扱うことができて、ボタンが押されていればボタンに対応した数値になるので 0以外として TRUEと扱うことができます。

「SAVEでダイアログを出したくない」って状況って、みんなどんな感じの使い方を想定してるのかちょっと気になるところ。 市販ゲームのオートセーブ系も基本的には直前に何かのキー入力（直前のリザルト画面からの遷移や、冒険の書に記録しますか？とか）をしているので ゲームデザインとしてSAVEダイアログの決定ボタンがゲームシーケンスとしてデザインされていればいいとは思うんだけど、現状のSAVEダイアログではカスタマイズできないから消したいってだけなのかなーと。 SAVE系って「ファイルが書き換わる場合（新規作成、上書き、削除、リネーム）は対象ファイル名の表示をさせて決定を選択させる」って思想が見えているので、完全にオートセーブみたいなダイアログ非表示は厳しいとは思うけど、SAVE命令で追加メッセージ出せたり、保存した/しない が返るようになるだけでも、十分に使えるようになるのかなーって。

ACLSって全部が全部プチコン起動状態にもっていってもらえるわけじゃなさそうなので、XON/XOFF系やらなんやかんやひっくるめて起動時と同じように初期化してくれる命令があってもいいのかなーって、最近の不具合報告の内容をみて思ってみたり。 CLEAR命令とほぼ同等だけどコードの先頭に書いておけば公開ランチャー系から起動されて前のコードの変な初期設定が残っていても正しく動作するような感じとか。

どうしても黒い画面だとすぐviのコマンド打ち込もうとする癖がでてコードに変な文字紛れ込んで危険ｗ エディタ系の開発ってそれぞれの使い勝手あるからUSBキーボード対応は結構大変な感じかもですです。

３号出たころにソフトキーボードで、スペースキーを押そうとするとトップメニュー、スマイルツールを押しちゃって大変だったけど、さすがにソフトキーボードの配置見直しはきびしそうｗ BIGにあるスマイルツール２ボタンはさすがにメモリの問題できびしそうな予感？ ※BIGならスマイルツール２ボタンからCLIPBOARD経由だけどFEPっぽく作れたので

保存ダイアログ非表示の目的って、開発者が保存決定まで操作させたあとに、さらにダイアログ上で決定ボタンを押さないといけない、ってのがほとんどだと思うので、 保存ダイアログの見た目をある程度カスタマイズできるようになればいいのかなぁ。 もしくはオートセーブ専用ファイル名でしか保存できないSAVEA命令みたいなので、「オートセーブしました [OK] 」の１秒のウェイト付きのダイアログとか。 プロジェクト内でファイル名干渉しそうなので実行ファイル名から一部抜き出したファイル名で保存とかで（実行中に動的変更不可で"@AUTOSAVE_GAME"みたいな）

Ctrl+CはWindows系以外だと停止系がほとんどだったりのもありそうかも。 （たまーにまちがえてwindows系以外でコピーしようとしてctrl+cして停止させちゃうｗ） ３号と互換の問題で 　USBキーボードのキーコード → ソフトキーボードのキーに対応する機能コード → プチコン上で処理 ってしてそうなので、ソフトキーボード上で操作できない機能はUSBキーボードで処理できなさそうな予感もするのと、Ctrl,Alt,Shiftはキーボード的にもちょっと特殊なのでプチコン将来拡張に期待してたり。 それでもPageUp/Dw あたりは欲しかったのが本音ｗ

「今後の商品開発の参考」と書いてあるのでもしかしたら、もしかしたら将来Switch版で通信系ができたりする可能性もあるかもしれないし、実は書いた要望がプチコン上で別の実現手段あって、他の人が実現手段のコードを書いてくれるかもしれないし。 とりあえず過去に誰かが書いてたり前にも書いていたりしてても、まずは書いておくのがいいと思うなーってのも。 何度も同じ要望がでてきて対応に困るのは要望言われてる側なので、それがちゃんと内部で管理されていれば困る人はあんまりいないはず

３号は外部キーボード使えなくてBIGしかちゃんと触ってないけどBIG側でも書いた３号でも無さそうな機能を書いてみる ・LR押したときに出てくるSAVE,LOADの時のLOAD側のダイアログをDIALOG関数で呼べるように（ファイル名入力で保存側はあるっぽいので） ・LOAD前にファイルサイズを取得する関数がなさそうなのでCHKFILEの戻り値がFALSE/TRUEから 0/ファイルサイズ にする（既存コードが混乱しそう）か、専用のファイルサイズ取得関数がほしい（読み込みダイアログには表示されてるので ・公開キーたくさん保存してて開発してるとプロジェクトディレクトリごっちゃになるので、ディレクトリ２段階とか、公開キーで保存したプロジェクトは公開キーマークつけるとか振り分けたい ３号で外部物理キーボードは欲しいけど実現はほぼ無理っぽいのでBIGでコード書いて３号に転送で我慢中。

・カメラ撮影機能が欲しいけど、カメラ機能は大人の事情で実装見送ったようなのをどこかで見かけたし、カメラ使えたら何作るかなーって考えると大人の事情にひっかかりそうなことだらけだったので、カメラほしいけどあきらめようｗ ・ハードウェア機能を使うための公式の使い方サンプルが欲しいかもです。 　TECHDEMOがそうだとは思うけど、機能ごとに抜き出したミニマムコードあたりを。 　（MICで録音→(PCM/WAVSETA)再生 とか機種依存してるのもあるし） ・WIDTH 16,16 で参照するフォントのGRPFデータ(1024x1024)の範囲取得・更新する方法が3.5.0では無かったかもです。

実行無限ループや実行画面からの回避方法がシステムとして必要なのを考えるとCtrl+CとF5が含まれるCtrlとファンクションキーはむずかしいのかなーって思いつつも、 INKEY$自体がコンソール入力キャラクターコードを取得なので、ASCIIコードに振られて無いCtrl,Alt,やじるしが存在してないのはしょうがないのかなぁと。 mkIIのKEYBOARDシステム変数っぽいのが将来実装されて、補助キー関連が取得できるようになればいろいろできそうな感じですねー

・ファイル読み込み一覧にはファイルサイズ表示があるのに、ファイルサイズ取得できる手段がなさそうだったので CHKFILEの戻り値をファイルサイズにするか、ファイルサイズ取得関数実装に期待 ・F7/F8のファイル読み込みのダイアログを DIALOG関数に実装（ファイル名入力の保存側のほうはあるっぽいので） ・mkIIにあった「KEYBOARD」システム変数のような実装に期待 　（カーソルキーやPageUP/DnなどのINKEY$で取れないUSBキーボードのキーがあるので） ・ファイル管理系の名前・日付ソート切り替えがUSBキーボードで操作できない？ ・公開キーダウンロードディレクトリと自分のプロジェクトがごっちゃになるのでなんとかしたいところです →ディレクトリ２階層分とか、公開キーで生成したディレクトリが目印でわかる・ソート可能のようにとか、PageUp/Dwでスクロールとか

ツイッターにもいろいろ書いたけどこちらにも。 基本的に「プチコンをUSBキーボードメインで開発」についてです ・ローマ字変換中にソフトキーボードの変換状態アイコン以外に 英字/カナ/ひら の表示（LRキーでスロットファイル名が表示されるような感じで） →うっかりUSBキーボードの「ひらがなカタカナローマ字」キーを押すと状態がわかりづらいので ・PageUp/PageDown でスクロールが画面１ページ分固定なので半ページも指定可能に →他人のコードをブロック単位で追うときには半ページのほうがみやすいはず ・コードを１行以内の範囲選択して検索したときは選択範囲の単語を検索の入力初期値のほうが便利かも（オプションで動作指定が無難？） ・ファイル管理がUSBキーボードだけでプロジェクトを選択できてもファイルの選択できなさげ？

やじるしキーがBUTTONで取れるかなーって期待したけど結局ダメっぽかったのが。 新しくスマイルボタン２で漢字変換作るにしてもATOKキーバインドは実装諦めて別の方法で実現かなぁと考え中。