私は「プチコン4」からプチコンワールドに参入したので、
プチコンに慣れている人には「常識」と思われるようなことも
まったく知らなかったので、以下に「知らなかったこと」「悩んだ点」
「次からはこうするぞと思っていること」などを記載しておきます。
（全体）
- twitterで「#petitcom」「#プチコン4」などのタグを使って進捗状況や悩みを書くと、全国の鬼神が寄ってたかって助けまくってくれる。
- 公開の際にはゲーム本体のプログラムの名前が"A"だとしたら EXEX "A" とだけ書いた「MAIN.PRG」という名前のプログラムを同梱しておく。（公開リストから直接起動できるようにするため。）
- 一度公開してしまうとプログラムを更新できないのではという恐怖があったが、同じ公開キーに対して後からローカルの最新プロジェクトの内容を上書きできるので安心して良い。
- 「こういうツールがあったらいいな」というものは、たいてい探すと既にある。（例）「プチフォントエディタ」「プチコン漢字ライブラリ」
- 「こういうサンプルプログラムはないかな」というものは、たいてい探すと既にある。（例）LMATRIXの使い方
- ソースコードのコメント等に漢字かな混じり文を使える「RMG_IME」が既にある。ソースの可読性を著しく向上させられるし、プロジェクトを公開する際の説明文をMETASAVEで登録する際にも利用者に読みやすい文章にできる。
- 公開する時の「ユーザ名」は、ローカルプロジェクトには登録できない。サーバに公開する際に NintendoSwitch本体のユーザ名がそのまま組み込まれる。本体のユーザ名をtwitterのアカウント名にするなど、公開を意識した設定にしておくと良い。
（プログラミング）
- プログラムのメインで使った変数は自動的に広域変数になるので、同名の変数を関数内で使っていると関数間で影響が出てしまうことがあるので注意。これを避けるには、VARやDIMで明示的に宣言した変数しか使えなくなる OPTION STRICT を動作モードとして設定すると良い。（ちなみに私はこのことを2000行以上コーディングしてから知ったので、広域変数の命名規則を決めて「メインでは広域変数として宣言していない変数は一切使わない」ことにしました。次にプログラムを書く時には、命名規則は維持しつつ、更に OPTION STRICT を設定すると思います。）
- SPVAR と SPFUNC をきちんと設計すると（つまりオブジェクト指向的にコーディングすると）プログラムが格段に綺麗になり、バグも作りこみにくくなります。
- とにかく、SmileBASICのリファレンスは一通り目を通した方がよい。あとから「こんな便利な機能があったのか」と知ると、ちょっとくやしい。
- LFILTERのラスター効果などは奥のレイヤーの描画情報に重ねて適用される。従って、奥のレイヤーの表現はそのままにして、手前のレイヤーにだけラスター効果を与える、といったことはできない模様。レイヤーを使う場合は、最初に表示優先順位やクリッピングの設計をしっかりしておいた方が良い。
- SmileBASICに限らないが、プログラム中に即値（48とか17とかの具体的な値）は書かない。面倒でもプログラム冒頭で CONST や ENUM を使って、プログラム中では定数名を使うようにする。バグが減るし修正も容易になる。
- スプライトの管理番号の割り付けは、作りながら考えるのではなく、プログラミングを始める前に、何に何番を割り当てるのかの番号帯設計しておいた方が良い。（そして定数で定義しておく。）
