プログラムが実行されたときの動きが分かっている公開されているプログラムを、実際の動きとプログラムを照らし合わして、知らない命令が出てきたらリファレンス（公式サイトの命令一覧）で動きを調べて、他のプログラムも同じように動きをしらべて ってことをしていくと、「プログラムを作る」ってどんなものかは見えてくるかもです。 プログラムで出来る事って、プログラムを作る環境（プチコン３号）で呼び出せる命令のことしかできないので、あとはひたすらに命令の組み合わせなのです。 プチコン３号のリファレンス（命令の一覧）を上から眺めて、どんなことができる命令があるかだけはざーっと把握しておいて、気になったときに調べて覚えるって感じでなんとかやってきてます。

同じお絵かきツール系だと、スーさんのエディタは空メモリから確保できるだけ画面全部のundo/redoバッファを持っていた感じだけど、１５枚くらいまでしか持ってなかった記憶です。 打ち消しコマンドの変更差分をスタックに詰んでいく方法は、ちゃんと設計しないとどこで間違いが起きてるかデバッグが大変というのもあるので、機能追加がかなり大変というのもあったりもです。 （ついこの間お仕事でundo/redoをclassが無い環境で作ったときはデバッグで苦労した思い出）

たぶんちゃんとした概念とかクラス分けとかあったりすると思うけど(mementoパターンとかcommandパターンとか)、smile basicだと構造体もクラスも使えないので、配列をスタック代わりに使っている感じです。 あるコマンド（ここからここへ線を引け）を実行したときに、そのコマンドを実行する前と同じようになる打ち消し(変更差分)のコマンド（ここからここへの線のうち、色はもともとそこにあった色）が undo処理になるので、作りとしてはそうなってる感じです。 何度もコマンド実行してundoで戻り続けても、コマンドごとに１つ前の打ち消しundoが実行されるので、ちゃんと最初まで戻れるって感じです。 変更前の画面メモリ全部持つのも方法ですが、１つの点を打ったのに１画面全部持っていたらメモリがたりなくなっちゃうので、最小限の打ち消し情報を持っている設計のような感じです。

移動しようとしてる場所が通れるか通れないか判定して、通れないなら移動できない、のつくりが基本ですが、 どの家具や壁が通れるか通れないかを決めるのはマップやシステムを作る人まかせなので、通れるか通れないかの情報をどこかに持つ必要があります。 マップを作るときに通れる通れないの情報を決めておく必要があるけど、これが人それぞれいろんなやり方があって、どれも間違いではないのです。 どれが通れるか通れないかを配列で全部持つのは結構大変なので、 スーさんのとおり、レイヤー０は通れる、レイヤー１は通れないマップを作っておいて、レイヤー１でBGGETしたときになにかあれば通れない判定が楽かもです。 マップに使うGRPのうち下半分(チップ512番以降)は通れないとか判定もあったりするけどRPGにはちょっと向かないかも。 （アクションゲームだとダメージ判定用とかはしご用とか判定をもっと細かくしたりとか）

プチコンでプログラムってすごく簡単に言っちゃえば「プチコンで用意された命令を組み合わせたパズル」なのです。 ただ普通のゲームのパズルゲームとは違っていて、「プチコンで用意された命令」がほんのちょっとのことしかできないので、それを本当にたくさん組み合わせないといけないのです。 こんなことプログラムでやってみたい！ ってのがあれば、プチコンでの命令の組み合わせ方や作り方は（たくさん組み合わせる必要はあるけど）だいたい決まっているので、それをどんな感じで作るかって感じです。

プログラムを始めたばかりだといろいろ分からないことだらけだと思うので 縦と横とXYを間違えるのは、行と列とrow/columnを間違えるのに近いのもあるので慣れていく感じです。 GRP4はスプライト、GRP5はBGで、スプライトもBGも同じ画像を使うので、どっちにも同じファイルを読み込んでいると思うのです。 BGPAGEとSPPAGEで同じGRPページを指定できたりするけど、そのうちBG用の画像を別に作るなら、今のプログラムからGRP5のファイル名を変えるだけで済むので、今の書き方でも問題なかったりします。

SPで始まる命令はスプライトの表示や位置やアニメーションなど、キャラを表示するためのスプライトを操作するだけの命令なので、攻撃やダメージなどのゲームのルールは自分でプログラムを書かないといけないのです。 攻撃して敵を消すのはプログラムで書くとだいたいこんな感じ ・攻撃を選んだら（Bボタンやコマンド選択など）、攻撃を開始する処理をする（攻撃アニメやメッセージなど） ・攻撃が敵に当たったか判定をする（敵が隣や攻撃範囲に居るとか、敵の状態とか攻撃力や守備力などから計算、自分の作るゲームのルール） ・敵に攻撃が当たってたら敵のダメージ計算する（１発あてれば消える、ダメージ減算） ゲームルールとして敵がどういうふうに出てくるかもあるけど、敵の状態（倒されてないかどうかとか体力とか）の配列があったほうがやりやすいかもです。

高機能エディタってみんな思い思いの仕様を持っていて、機能設計や実現可能方法確認や詳細設計までできてる人は結構居ると思うけど、それを実際にプチコン上でコーディングする時間がとれないって人がほとんどなのかなーと。 設計は頭で考えるからいつでもできるけど、コードを書くのはプチコンを目の前にしてじっくり作る時間をとらないといけないのもあってどうしても。

キーボードって「何か」に対して文字を入力するためのものなので、「何に」文字を入力させるかによって「何か」に特化されたキーボードになるのでいろいろ変わってくる感じです。 入力デバイスとしてならタッチパネルと十字キーやボタンもあるので、それらをあわせて「キーボード」と呼べる感じです。 別トピックで話題になってた便利なエディタを作る感じなので、そのエディタに向けたキーボードであればエディタのよく使う便利機能を呼び出せるようなキーが増えるのかなと思うのです。 一般的なエディタだとファンクションキーのF1～F12キーにそれが割り当てられていたりも。 プチコンキーボードもコメント用に「’」が別キーだったりするので、エディタの機能設計もキーボード側の設計にも影響する感じです。 ※テンキーモードを呼び出すなら数字キーを使ったほうが早いとおもっちゃう。

ちなみにACID MusicStudioとMovieStudioでどんな感じができあがるかはniconicoの検索で「嘆きの樹ですか」か「BPM300でわかる」で１０年くらい前のMADが見つかると思うので投稿動画一覧を見てもらえれば。 （クラブ用に勢いで作ってアップできるのだけをアップしてるので今見ると音調整甘いのもあるけど） 元動画からどのくらい加工されてるかって目線で見るとどんなフィルタやエフェクトを作る必要があるかは見えてくるかも。

本題のプチコンで同じようなことするとなると、MICで録音できて、配列に音データがあるので、音を加工する知識があればプチコンでもできると思うけど、それはそれでプチコンでACIDを作るような感じなので、先にMADを作るより作成ソフトを作る感じになるかなと。 音の加工は「C言語ではじめる音のプログラミング」の本がかなりオススメなので、フィルタの処理を実装すれば高音と低音の調整はできる感じ。 （技術系の本は高いので、学校の図書館で本のリクエストができるならしてみるのも） 映像系はデータをプチコンに転送しないといけないのでかなり大変だけど、 音が時間軸データでしかないのが、映像は時間軸＋２次元データなだけで、大体同じような感じで加工は可能だけど、音とまた違うエフェクトがあるのでそれはそれで調べないとというところ。 なににせよ専用ソフトで先にイメージつかんでプチコンで編集ソフトを作る感じかなと。

今のMAD界隈って何使ってるか全然知らないけど、当時は ACID Music StudioとMovie Studio で大体なんとかできた感じかなぁ。 最近は上位の ACID Pro と Vegas Pro がセットで当時よりは安く手に入る感じだけど、お金かけずにその辺するのはソフト情報やテクニックを調べたりしないといけないのは変わらない感じ。 音つくりと映像つくりは今は学生時代でもできちゃうから、今のうちからソフトのこと調べて、お年玉で買って挑戦してみると将来につながる感じも。

さらっと「構造体」って書いちゃったけど、たくさんの変数を１つの変数で管理できるのが構造体だと思ってもらえれば。（変数しか定義されてないクラスみたいな感じ） 構造体が使えれば関数に構造体変数を渡して、関数実行結果として構造体の中身を操作してもらうつくりができるのです。 構造体変数の定義場所がグローバルじゃなければ、その構造体の中身を操作する人は構造体変数を渡された関数だけが操作しているので、プログラムを追うのも管理するのもその関数だけを意識すればいいので楽になるのです （データへの操作がモジュール化された状態） でもプチコンじゃ１つの変数には１つの値しか入らないので、引数で複数の値を渡して複数の値を返すのには限界があって、 これを配列で渡して配列で返してもらえばそれらしくモジュール化できるけど、配列の何番目が何の値かをちゃんと管理しないと大変という感じなのです。

ちなみに、どのプログラムでもデータを操作していてて、データをいろんなルールで操作して、データをうまい具合に見せているからゲームやアプリケーションが出来ているのです。 （ゲームだって主人公の位置データを敵データや地形データをもとに操作しているだけだし、画像だって点の配列データ） プログラムでデータがどんなふうに流れているかを把握できれば、そのプログラムの動きを把握できるので、データが入っている変数名や関数名の分かりやすい名前付けはかなり大事なのです。 BASICなら「アプリケーションハンガリアン」（変数名の先頭にデータの意味合いの名前をつけてる方法）もまだまだ有効だけど、プチコンだと長い変数名だといろいろ大変なので、調べて使えそうだったら参考にしてみる程度ででも。 （ちなみに「ハンガリアン」だけだといろいろダメなほうな「システムハンガリアン」を言っていることもあるので調べるときは注意で）

プチコンでモジュールをちゃんと設計しようとすると、構造体使えないからモジュール実行結果を構造体で返してって感じでのモジュール分割がかなり大変なんですよね。 編集画面も２画面分割できないので、変数定義部分やDEF定義先をみながら処理が追えなかったりするので、やっぱり大規模系はかなり自分なりの工夫が必要になる感じですね。 プチコンだと処理分岐用変数がこの値のときはこのルーチンを呼ぶ、ってのがあまりきれいに書けないのもあって、処理の流れもやっぱり独特の自分ルールって感じになっちゃいますね。 (switch-caseや関数テーブルが使えたら便利って思うけど、それっぽい書き方もできなくはない) なんだかんだで独特なプチコン＋SmileBasicだからこそ、独特の管理方法をみんなで開拓していく感じかもです。

保守とかそういうのは第一種情報処理技術者試験（ちょっと前はソフト開発、今なんだっけ？）とかその辺めざすといろいろお勉強したりするけども、 実際問題そんなにうまくはいかず、現実は締め切り（開発期間と人数と納期）の戦いなので結局はプロジェクトメンバーがなんとかがんばってなんとかなるって感じなんですよね。 ゲームじゃないお仕事だと、これ作って欲しい→リリース→次はこれ作って欲しい→リリース、って感じな流れになるので、 次に作って欲しいのをうまい具合に聞き出したりして、それをふまえたモジュール設計をして作るって感じですね。 でもプチコンだとれいさんがいろいろ書いているとおり、主に名前空間の問題（変数全部がグローバルなので別モジュールで変数名がかぶる）でモジュール分割がかなり難しい感じなのです。

＞実行速度が配列より三角関数の方が早い BIG出たころにライフゲームっぽく854x480x2の配列でデータ計算させて全ピクセルにGPSETしたら全然フレームレートでなかったから、GPSETが重たくてBIGだと配列もある程度重たいんだろうなぁとは思ってはいたけど、 そこまでプチコンの配列って重たいんですね。 結局配列が重たいから回避したい場合って ・配列使わないで計算で対応できれば計算で回避 ・どうしても配列を使わないといけないところの高速化はプチコンじゃ難しい という感じなのかな？ 表示しないGRPnを512x512配列で使うとか、使わないスプライト管理領域(SPDEF,SPVAR)やBG管理領域(BGPUT/BGGET)を構造体や配列に使うとかを実験してみたら早くなりそうなのかも？

計算処理がある場合、変数が影響しないのであれば使用する範囲ですべて計算しておいて、その計算済み結果（定数）で置き換える、のもあります。 MIKIさんの col[] に色を先に計算しておく小さなことから、 スーさんのGRP4に0～65535パターン全部書いておく大きなところまでいろいろとあります。 変数が影響する計算でも、変数で計算する前までの値を先に計算することで早くなる場合もあります。 たとえば、三角関数系の計算が重たいので256(の倍数)くらいの配列を0度～90度として先に計算しておくのもよくあります。（マイコン系の世界だとまだまだ現役） ※おちゃめさんのQSP(QuarterScreenProgramかな? 1/4画面でおさまるプログラム)にこだわらなければ高速可能なのはたぶんコレ 結局重たいのはいろんな重たい処理×実行回数（ループ回数）なので、ちょっとずつ減らしてく感じです

重たいのって ・命令が重たい（絵を描く、配列アクセスなど） ・やりかたが重たい（アルゴリズム） に分けられて、この組み合わせで処理が早くなるものを選ぶという感じです アルゴリズムとして、ループがFOR X: FOR Y: FOR C などで３段階になっていれば、最後のFOR C の処理は X*Y*C回数分実行されて、ここに重たい処理（命令・アルゴリズムGOSUBやDEF）があると全体として重たくなります。 その処理が１つ前のループで処理できないかとか、ループの中で処理しなくてもいいかとか、そもそも別のやりかたがあるのかとか、処理を考え直すのも高速化につながります 命令としては表示のように値１つ渡して１回表示する命令を何回も呼ぶより、まとめて値を渡して一気に表示する命令のほうが早いです （内部処理として表示準備処理を何回も実行するか、まとめて1回するかの差）

MIKIさんのプログラムを動かせたら、どんな処理をしているか１行ずつ解析していくといろいろ勉強になったりします。 ・def f で定義された関数(ユーザ定義命令)は 素早さ配列を引数に渡すと、素早さ配列の何番目が早いかの配列を返してくれる。 ・def f の中の var で宣言された index と、 def f の外で var で宣言された index は別の変数で宣言される（最後に代入されて同じ内容になるけど） ・rsort tmp, index は、tmpの並び替え結果で index も同じ並び替えをしてくれる このへんを意識しておけば、動きはみえてくるかも。 解析して分かったことをプログラムにコメントで書いたり、紙に書いたり、この変数にこの値が入ってるとすると結果はこう動くはず、って感じで考えると理解しやすくなるかもです。