おちゃめくらぶ掲示板 - 1659321896

2152：御茶目菜子：2014/07/20(日) 23:53:55: プチコンmkIIの思い出とプチコン3号の抱負
当初の予定ならばそろそろプチコン3号が発売されていてもおかしくないのだけど先日も
書いたように発売が秋へと延期になったためお楽しみはそれまで取っておくにょ。
さて、初代プチコンが発売されてから3年4ヶ月、mkIIが発売されてから2年4ヶ月経ったわけ
だけどやはりmkIIでは何度も書いているようにQRコードに対応することで自作プログラムの
公開も簡単になり、公開されているプログラムを使う場合にも非常に簡単になったにょ。

ということで、プチコンmkIIが発売された当初の思い出話でもしてみるにょ。（初代プチコン
においては私は3DSを購入した後での購入となったので発売される前から存在自体は知って
いたもののtwitter上でのユーザーのやりとりなどはリアルタイムでは見てなかった）
プチコンmkIIを発売日に入手してからまず行ったことといえば既存のプログラムのmkIIへの
対応状況の確認にょ。
mkIIは初代と互換性はあるものの一部に仕様変更があったためそのままでは正常に動作
しないケースがあるにょ。
そのため私がすでに公開していたすべてのプログラムにおいて動作確認を行ったにょ。
その結果正常に動作しなかったのは1画面プログラムの「プチコン50m走」だけだったにょ。
これはコンソールオンリーのシンプルなプログラムだったとはいえVSYNCを入れてなかった
のが原因でmkIIは処理速度が平均で3割程度速くなったためゲームバランスが大幅に
崩れてしまったためにょ。
とうわけで、このプログラムは動作はするけど非対応扱いにしたにょ。（まぁゲーム
バランスを調整すればいいだけとはいえ、すでにスプライトやBGを使った後継ゲーム
「プチコン100m走」を発表後だったのでそのまま放置となった）

ベンチマークでのmkIIの実行速度の初代との比較、初代で作った自作プログラムのmkIIでの
動作確認、QRコード化などが終わった後はいよいよmkII専用のプログラムを制作開始
したにょ。
まず私が目を付けたのはTALK命令にょ。
これが発表されたときから上手く使えば初音ミクのように歌わせることができるのでは
と思っていたけどそれには様々な問題があったにょ。
実はちゃんと歌わせるためには1音ずつパラメータを手動で設定する必要があるためにょ。
それではあまりに面倒なので何とか簡単に歌わせることができないかを徹底的に調べた
結果がこれにょ。

　TALKを使って歌わせる方法
　http://ochameclub.web.fc2.com/petitcom/tips/talk.htm

この方法を元にお手軽さを重視して作ったのが棒歌ロイドOSPにょ。

　棒歌ロイド　OSP2
　http://ochameclub.web.fc2.com/petitcom/1page.htm#osp

OSP2というからにはOSP1もあったにょ。
OSPは単体では使えず自前で用意した適当なMML演奏プログラムが必要になるにょ。
mkIIではBGMPLAY命令がMML演奏に対応したためこのようなMML演奏プログラムというのは
不必要になったけど初代では多くの人が自分用に作っていたにょ。
私もポケコンからおなじみのOMPに加えて一般的なMML表記方法に近いプチコンMMLを
用意したにょ。

　音階演奏ソフト　OMP
　http://ochameclub.web.fc2.com/petitcom/1page.htm#omp
　プチコンMML
　http://ochameclub.web.fc2.com/petitcom/mml.htm

OMPは独自表記ではあるもののプチコンの100倍くらい遅いポケコンでもリアルタイムで
構文解析ができるくらい高速でMMLデータも非常に小さく済みそして何よりリストそのものが
短いというのがメリットにょ。
つまり、あまりリストが長くならないためメモリの少ないポケコンや手動でリストを入力
する必要がある初代プチコンではメリットが大きかったにょ。
OSPではこれらのものと組み合わせて使うのだけどOSP1はどういうものかをアピールするため
OMPと一体化して公開したにょ。（OMPと合わせても1画面に収まるコンパクトさ）
ただし、OMPは慣れないと使い勝手が悪いため自前で用意したMML演奏プログラムが使える
方が良いだろうし、OSP1では音長が不正確な場面もあったためそれを補正するアルゴリズムを
考えたので他のMMLと組み合わせられてより正確な発声ができるようにしたのがOSP2という
わけにょ。
恐らくパラメータを個別設定しなくても済むプログラムの中では最も短く最も正確
（キレイ）に歌わせることができるプログラムにょ。（OSP2よりキレイに歌わせるためには
上記のように1音ずつ個別にパラメータ設定をしないと無理）

自動で歌わせるプログラムはもうこれ以上無理なのでTALKではなく別の命令を使ったものを
作ってみようと思っていた矢先にYAMAHAからボーカロイドキーボードが発表されたにょ。
ミクミンP氏がそれを元に速攻でタブレット端末（Windows）向けにソフトウェアでそれと
同様なものを作ったにょ。
ソフトウェアによる実現はプチコンでもできそうだと考えて私も作ろうと思ったものの
プチコンだと基本的にマルチタッチは無理（後日擬似的にマルチタッチを行うことが
できるプログラムを作ったけど実用にはほど遠いレベル）ということで文字入力と音階
入力をどのように行うかが非常に問題となったにょ。
ミクミンP氏と同じくフリック入力で行うプログラムを作った場合には片手で音階部分を
ボタンで入力する必要があり、音階演奏は非常にシビアとなるにょ。
それならばそのフリック入力的な操作をボタンで行えばタッチパネルが自由に使えるため
そこに鍵盤を表示すればボーカロイドキーボードっぽいものはできるにょ。
というわけでできたのがこの棒歌ロイドキーボードにょ。

　棒歌ロイドキーボード
　http://ochameclub.web.fc2.com/petitcom/bo_kb.htm

mkIIの発売から1ヶ月間はTALKばかり使っていたのだけど次に私のターゲットとなったのが
GCOPYにょ。
mkIIはGRP画面が4面に増えてそれを自在に切り替えられることに加えてGCOPYが加わったため
GRPだけで大抵のゲームはできそうな感じになったにょ。（速度面の問題を除けば）
GRP画面の一部を切り取ってスプライトのようなキャラ表示に使ってもいいけどスプライトでは
実現が困難なスクロールに使っていろいろ作ってみたにょ。
スクロールなんてBGでやればいいと思うかもしれないけど実は速度を重視しない場合にはGRPの
方が表示も判定も簡単にできる場合が多いにょ。
そこで初心者でもGRPのスクロールを使ったゲームを作れるようにと書いたのがプチコン講座の
第7回にょ。

　プチコン講座　第7回　グラフィック面（GRP）をスクロールさせよう
　http://ochameclub.web.fc2.com/petitcom/p007.htm

この最初の部分に書いているCAVEを見て分かるようにGRPを使えば1ドット単位で構成された
画面のスクロールも簡単にできるし、判定もGSPOITで簡単にできることが分かるにょ。
これは1画面プログラムのような文字数の制限のあるプログラムにおいては非常に大きな
メリットとなるにょ。
それが一番よく分かるのが「プチコン100m走mkII」にょ。

　プチコン50m走
　http://ochameclub.web.fc2.com/petitcom/1page.htm#50m
　プチコン100m走
　http://ochameclub.web.fc2.com/petitcom/1page.htm#100m
　プチコン100m走mkII
　http://ochameclub.web.fc2.com/petitcom/petit_olympic.htm#100m

コンソールの基本命令しか使ってなかったプチコン50m走と比べてプチコン100m走はBGや
スプライトを使用によって見た目で大きく変わったのだけどプチコン100m走mkIIはそれから
さらに大きく見た目が変わったのがすぐに分かると思うにょ。
これはリスト短縮の恩恵というのもあるけ昨年の冬コミで頒布した同人誌「プチコン1画面
プログラムノススメ」で書いたようにBGで作った場合にはリスト短縮を駆使しても25行に
なってしまい1画面に収めることはできないにょ。
それがGCOPYを使ったGRPによるスクロールならば1画面（24行）に収まるにょ。
それだけではなくフェンスにOCHAMEの文字も入れることが可能になったため実質2～3行の
短縮といえるにょ。（フェンスに文字を入れたのは単なる自己アピールではなく二重
スクロールを視覚で分かりやすくするため）

実はプチコン100m走mkIIの前にすでにGCOPYによるスクロールを使ったゲームを発表して
いるにょ。
それがJUMPING ISLANDにょ。
このゲームはGCOPYを使えば短いリストでスクロールゲームが出来るのならば敵無しマリオ
みたいなもの（強制スクロールするステージをゴールまでクリアするだけのゲーム）は
簡単にできそうだと考えたため作られたにょ。
ステージデータなんて入れていたらとても1画面には収まらないためステージは自動生成に
したにょ。
しかし、上記の講座にも書いているようにランダムではクリアが不可能なステージが生成
されてしまう恐れがあるにょ。
スコアアタックをするためには運の要素はできるだけ減らしたいところにょ。
というわけで、超簡単な疑似乱数ルーチンも作られたにょ。

　プチコン講座　番外編　プチコンで疑似乱数を作ろう
　http://ochameclub.web.fc2.com/petitcom/rnd.htm

1画面で攻略性の高いランダム生成されたステージのゲームというわけでゲームデザインが
行われたJUMPING ISLANDだけど1画面には収まらず当初は普通のプログラム（リストの長さに
特に制限のないプログラム）として公開したにょ。

　JUMPING ISLAND
　http://ochameclub.web.fc2.com/petitcom/jumping.htm

とはいえ、せっかく1画面向けに作ったゲームなのでこれを簡略化した1画面版も用意したにょ。
それから2年2ヶ月経った今見るとやはりmkIIを買って2ヶ月くらいの時に作ったプログラムで
あるため無駄な部分も結構たくさん見つかったにょ。
これならば今作り直せば1画面版で妥協した部分をかなり何とか改善できそうな感じという
わけで早速昨晩作ってみたにょ。

　JUMPING ISLAND（1画面版）ver1.1
　http://ochameclub.web.fc2.com/petitcom/1page.htm#jump

まずは、妥協した部分の1つであるリトライ機能の追加にょ。
リトライ機能はゲームオーバー（ゲームクリア）時に任意のボタンを押すことでゲームを
もう一度プレイできる機能にょ。
これがあればいちいちRUNやSTARTボタンを押して実行するという必要はなくなるという
だけではなくmkIIから加わったホームメニューにも対応できるにょ。（これがないと
ゲームオーバーになった瞬間にメニュー画面に戻ってしまう）
単に最後で無限ループすれば良いと考えるかもしれないけどそれだともう一度プレイする
場合にはゲームを停止して再び実行する必要があるため二度手間になってしまうので
できるだけ避けたいにょ。（個人的には単に無限ループを入れただけのものをホーム
メニュー対応とは言いたくない）
実はJUMPING ISLANDの1画面版がmkII専用ゲームの中で唯一ホームメニュー非対応と
なっていたにょ。

1画面プログラムでリトライを付けるためにはリスト全体をFOR～NEXTで囲う必要が
あるにょ。
ラベルによって最初の行にジャンプなんてやっていたらプチコンはラベルのある行には
他のプログラムは書けないため無駄だらけのリストになるにょ。
あとは、任意のボタンを押すまでは無限ループとなり、それを押したらループから抜ける
プログラムをプログラムの最後（最も外側にあるNEXTの内側）に追加すればOKにょ。
これだけのことなんだけど普通に作れば2～3行分くらいは余分に必要になるにょ。
しかし、任意のボタンがAボタンで良ければLINPUT A$のようにLINPUT命令による入力待ち
とmkIIからAボタンに割り当てられたENTERボタン相当の機能による空入力によって
Aボタンを押すまでの入力待ちがいとも簡単に実現可能になるにょ。（これを最初に
導入したのが上記のプチコン100m走mkII）

これでリトライ機能が搭載できるかというとそうではないにょ。
リトライ無しだとCLEARで変数の初期化を行っていたけどそれができないため変数の
初期化の分だけリストが長くなるにょ。（これはFOR～NEXTの間にCLEAR命令を挟んで
使用することができないため）
そして、このプログラムで
はPANEL"OFF"によってタッチパネルでの操作を可能にして
いるけどそれだとステージセレクトでもキーボードが消えたままになるためそれを
復活させるためPANEL"KYA"を追加する必要があるにょ。
これが逐次RUNによる実行ならば開始時には自動的にPANEL"KYA"のデフォに戻っている
ため気にする必要はなかったにょ。
つまり、リトライ機能を追加というのはボタン入力待ちと最初の行に戻るための
FOR～NEXTを入れれば良いといだけではなく様々な変更が必要になる場合があると
いうわけにょ。
元々ギリギリまでリスト短縮されている（少なくとも2年前にはこれ以上1文字も短縮
できる余地は無かった）わけだからこれらを追加するだけでもかなり大変なことにょ。
これによってゲームだけではなくmkII専用に作られた1画面プログラムすべてにおいて
ホームメニュー対応が達成できたにょ。

1画面版のJUMPING ISLANDの初期バージョンを見てみるとリストがギリギリだった
ためスコア加算が一律だったにょ。
つまり、ジャンプ回数が同じであればスコアも同じになるためスコア争いというのは
あまり熱くなれなかったにょ。
そこでフルバージョンと概ね同じ計算式によるスコア加算法を導入したにょ。
これによって1点単位の激しいスコア争いが可能になったにょ。
もちろん、その分だけリストも長くなったのでさらにリスト短縮に必要が出てくるにょ。
あとフルバージョンのようにクリアしたときのみハイスコアとして認めるというわけでは
ないためクリア時のボーナスを初期バージョンより多めにしたにょ。（このためいくら
ハイスコアを狙うため高難度のプレイをしてもクリアできないとスコア的には厳しくなる）
実際は一律でボーナスが加算されるわけではなくて障害物のないステージが30フレーム
分だけ追加されたのでその分クリアした後にスコアが増えるだけなんだけどこれだと
単純にステージの長さを変えるだけなので1バイトも追加することなく実現が可能になる
ためにょ。

JUMPING ISLANDのウリの1つといえば自動生成の割りには攻略性の高いステージにょ。
これは乱数のシードを変えながら自動生成されたステージをたくさんプレイしてみて
もっとも攻略性が高いものをシードに設定しているというのが理由にょ。
しかし、この1画面版ではステージのシード設定をする余裕がないためCLEAR直後のものを
プレイすることになっていたにょ。
それではやはり不満があったため今回のバージョンアップの際には自分で設定が可能に
したにょ。
これは適当なシードを入れる（変数Xに適当な値を入れる）だけのことなんだけどね。
とはいえ、もはや限界までリスト短縮されていたためこれは搭載は不可能だと思われて
いたにょ。
しかし、最も外側のループカウンタの値をシードとして活用することでそれが実現
可能になったにょ。
設定可能なのはXの値が0～9の範囲内だけどシードを10通り変えてプレイした結果
X=8の場合に生成されるステージが最も攻略性が高かったのでそれを採用したにょ。
（特に重視しているのがステージ1の構成でこのゲームのチュートリアル的なステージに
するため島同士の隙間は様々なものがありジャンプせずに超えられる隙間が多くあって
ところどころにジャンプしないと落ちてしまう隙間を設けることでどの程度の隙間が
ボーダーになっているかを体感で分かるようにして、なおかつ、普通にクリアすれば
簡単にできるようにあまり左右にばらばらな島ではなく左右どちらかに偏っているような
ステージになり、ところどころ偏っている部分を活用すればジャンプ回数を大幅に
減らせるような構成のステージが自動生成されるようにした）
このデフォルトのステージ1は非常に簡単なのだけど10万点を超えようとするとかなり
シビアなプレイが要求されてくるにょ。（ギリギリのジャンプでないと到達できない
箇所もあるため普通のプレイだとそのルートに気づかないかもしれない）

追加した機能そのものは大きくゲーム性を変えるものではなく些細なものなんだけど
それでも実際は3行分くらいは短縮しないと実現は困難なものと考えるといかにこの
2年間でリスト短縮テクニックが向上したかが分かると思うにょ。
バージョン的にはver.1.0と1.1なんだけど気分的には0.5と1.0くらいの感じになっていて
2年前には未完成だったものが2年越しでようやく完成に至った感じにょ。
恐らくこれが同一内容では限界の短さだと思うにょ。
VSYNC 2をWAIT 2に変えたり、LOCATE 0,0の代わりにCLSを使えばさらに短縮化できそう
に思えるかもしれないけどVSYNCとWAITが同じ動作になるためには常時60fpsで動作して
いる必要があるにょ。
CLSを実行すれば自動的にLOCATE 0,0になるのだけどCLSというのは0.1フレームくらい
かかる重い処理にょ。
すでに30fpsでギリギリ動作であるためCLSを入れたら派手に処理落ちしてしまうにょ。
これが常時60fpsで動作するような速度に余裕があるゲームであればこの2点の変更でさらに
8文字分短縮可能だけどこのゲームには他に短縮できる余地がないにょ。
まぁ影の疑似半透明処理をやめたり、「クリア／ミス」表示のレイアウトを考えなければ
もっと短縮できるけどこれらを削除することによって短縮してもそこからさらに入れるべき
優先すべき事項はもうないにょ。

冬コミのプチコン本でも書いたようにリスト短縮というのは優先順序を考えてから行う
必要があり優先度が低い要素を削って高い要素を入れるべきであり、優先度が高い要素を
削って短くなりましたというのは本末転倒にょ。
影の半透明表示やクリアの位置を入れる場所がそんなに重要かというとこれは結構重要な
ことにょ。
このゲームはシステム上、地面に正確な着地が求められるにょ。
そのため影の存在がないとまともにプレイできないくらい高難度になってしまうにょ。
しかし、影が不透明だと地面が見えなくなってしまうにょ。
疑似半透明な楕円状の影の中心が当たり判定のある座標なのでこれを合わせていけば
FPSのスコープ表示みたいに正確なジャンプが可能になるにょ。
このゲームはクリアそのものは簡単でスコア争いをして始めて盛り上がれるためこの
影の表現は実はゲーム性にまで影響を与えてしまうにょ。
また「クリア／ミス」の表示場所についてはどうかというとこのゲームは縦スクロール
ゲームであり、視線は画面の上方とキャラを交互に移動しているにょ。
スコア争いが重要な項目であるためスコアは上方中央付近から外すことはできないにょ。
スコアがこの位置になることに必然性があることは分かると思うけど本来であればクリア
したかミスかは音で判別可能であるため不要にょ。（このゲームは向こう岸にたどり着いた
時点でクリアになるのではなくスクロールが停止した段階でミスしてなければクリアに
なるためミスとクリアの判別は結構重要）
とはいえ、初見では分からないし、音を消している状態では分からないため表示でも
クリアかミスかを分かるようにしたということにょ。
となるとミスの表示はキャラの位置に近い場所かスコア表示に近い場所にするのが
ベターであることが分かるにょ。
そこで上手く調整しているのがこのゲームにょ。
ただの表示でも場所や方法や色については必然性があり、それらを考えることも
ゲームデザインの1つと言えるにょ。
1画面プログラムのようにリストの長さに制限があるプログラムであればすごく妥協を
してゲームの進行に必要不可欠な処理以外は削る必要性が出てくるかもしれないにょ。
しかし、すでに1画面に収まっている状態でこれらのものを削ってさらに入れるべき
優先度が高い処理というのがないにょ。
この辺の取捨選択が1画面プログラムの難しさであり面白さでもあるにょ。
そして、苦労して考えていた要素をすべて入れることができたときは感動を味わうことが
できるにょ。（例えるならば時間を掛けて完成したジグソーパズルみたいな感じ）
これを制約無しのプログラムで味わうならばよほどの大作を作らない限りはなかなか味わう
ことができないにょ。

以上がプチコンmkIIが発売から2ヶ月くらいまでの流れ（JUMPING ISLANDにおいては
現状との比較）を書いたのだけど2、3ヶ月先（再延期にならない限りは遅くても4ヶ月
先）にはプチコン3号が発売されるにょ。
mkIIにおいては発売2ヶ月間はTALKとGCOPYだけで過ぎていった感じだけど恐らくプチコン
3号は立体視と3DSに搭載されているジャイロセンサーなどの活用が当初のメインになって
いくのではないかと思われるにょ。
やはり試すならばmkIIにはなかった機能を使いたいところだからね。
ある程度使い慣れたらさらに別の機能やプチコン3号の速度を活かしたプログラムも
作ってみるかもしれないにょ。

とはいえ、やはりメインとなるのは1画面プログラムになりそうにょ。
私が1画面プログラムにはまったきっかけになったのがhonoPさんが作ったPetit Scrollや
Petit Racingをニコ動で見てからにょ。
これを見てプチコンを買ったら1画面プログラムを作ってみようと思ったにょ。
プチコンを買う前はポケコンを主に使っていたけどポケコンでは表示画面が小さいため
1画面プログラムは困難なので文字数制限があるプログラムとしては2行プログラムが主な
ものになっていたにょ。
2行プログラムというのはポケコン専門誌「ポケコンジャーナル」において一定の知名度が
あったためにょ。（MSX FANにおける1画面プログラムのように読者に十分に認知されている
レベルのもの）

私はポケコンやプチコンのプログラムは好きでPCのプログラムは特に興味を持たないのは
作っていて満足感を得られないためにょ。
私にとってはプログラミングそのものがゲームだからにょ。
作りたいものを完成させるというのも1つの楽しみではあるもののそれ以上に最適化を
行う過程を楽しんでいるにょ。
最適化と一言でいっても実行速度を速くするのも最適化だし、リストを短くするのも最適化
といえるにょ。
そのバランスを取るのも最適化にょ。

私は速度が遅いポケコンでは速度を重視した最適化を行ってきたにょ。（もちろん、リストの
大きさは無視するというわけではなく速度を気にしない部分はリストの短さを最優先にして
速度が重視されるメインルーチン内では速度を優先したコーディングをしているというだけ）
これはポケコンの中では高速な部類であるPC-E500であってもオールBASICでゲームを作るには
速度が遅いけどそれほど32KBを超えるようなサイズのプログラムを作る機会は私は無かった
ためにょ。（リストそのものの長さはRPGを作った時に32KBを少し超えたくらいでOPAS用の
データ領域を込みで32KBを超えたものならばいくつかある）
それに対してプチコンは私が作るようなシンプルなゲームであればメモリも速度も不足する
ことはないにょ。
したがって、最適化はリストの長さに向けられることになったにょ。
そのターゲットになったのが上記の1画面プログラムにょ。
これがPCでのプログラミングだと速度を優先したコーディングをしても1000fpsが2000fpsに
なってもあまり意味がないし、そもそも2倍の性能のマシンを使えば2倍の最適化の影響が
吹き飛んでしまうためあまり意味がないにょ。
2倍、3倍といった大きな高速化ならまだしも特定環境において最適化してわずかに速く
なっても別の環境だと逆に遅くなるということも十分に考えられるにょ。
PCでのプログラミングは最適化の意味がない（最新のCPUやGPUに最適化ならば意味はある
けれど自分が使っているからといって旧世代のCPUやGPUに最適化するのは意味がない）と
いうだけではなく各自のマシン環境（CPU、GPU、画面サイズ、解像度）も異なるためそれらを
想定して作る必要があり面倒というのもあるにょ。

最適化による高速化は場合によっては無意味ではなくなるけどコードのサイズの最適化
（コード短縮）も一定の長さのコードのみ可能なコンテストに参加するというのでなければ
全く無意味にょ。
そもそも昨今の開発環境において「1画面プログラム」といっても1画面というのがPCの
解像度や設定文字サイズによって変わるため全く意味がないにょ。
したがって、こういった最適化を楽しむならば環境が固定化された昔のパソコンやポケコンや
プチコンであってはじめて意味があることにょ。
もちろん、昨今の開発環境において最適化そのものが無意味というわけではなくある程度は
必要になる場面もあるけどコードの視認性を落として最適化をするというのは無意味なこと
といえるにょ。
したがって、視認性は二の次で速度や短さを優先したプログラムはこういった固定環境で
趣味のプログラムのみに有用なことといえるにょ。（趣味ならば自分が楽しめることが
すべてであり正しいことや間違っていることというものはない）
上記のように2年越しでようやくできたJUMPING ISLANDの1画面版もプチコンという固定環境
だからこそ意味があったわけだからね。（純粋に2年間のリスト短縮技術の進歩によって
実現可能になったわけだし）

初代プチコンにおいて1画面プログラムは画面写真1枚で公開が可能だったり、短いので
リストが入力しやすかったりでメリットも大きくて公開プログラムにおける1画面
プログラムの割合は多かったけどmkIIになってからは減ってしまったにょ。
これはQRコード対応で大きなプログラムも簡単に公開可能になったというのもあるけど
「1画面プログラムはサイズが小さいから初心者向き」ということはなくて実際はその逆で
あるためにょ。
取捨選択を求められて普通に作る以上の知識が要求されてくるためどちらかというと玄人
向けにょ。
プチコンは最初は玄人が使っていた割合が多かったけど気軽に公開や利用が可能になった
ため初心者が多くなったため相対的に1画面プログラムの割合が減ったと考えるとすべて
説明が付くにょ。（もしも1画面プログラムが初心者向けならば1画面プログラムで溢れて
いる状態になっているはず）

さて、1画面プログラムが玄人向けかというとその1つが文字数の制限にょ。
最大29文字x24行の696文字で作る必要があるにょ。
これはMSX FANにおける1画面プログラムの規定（40文字x24行の最大960文字）と比べて少し
少ない文字数であるもののプチコンはデフォルトでスプライトキャラがあるということを
考えるとそれほど不利な文字数とはいえないにょ。
しかし、上記のように事実上ラベルが使えない（GOTO、GOSUBは使えない）というのもあるし
1行が29文字に収めなくてはならないため1行の終わりをぴったりにするというのは処理の
依存関係を明確にしてない限りはかなり難しいにょ。
長い条件判定などはできないため論理式などを使ってリスト短縮をするのが必要不可欠な
要素になってくるにょ。（引数の多いGCOPYなどはそれを使ったらその行には他のものを
書くことができなくなる）

プチコン3号ではそれが1行の文字数が増えたというだけではなくエディタの折り返しの
ON/OFFが付いたため1画面プログラムを作るためのハードルは大幅に下がることが予想
されるにょ。
それに解像度が上がる分だけ表示できる文字数も増えるため取捨選択もその分だけ楽に
なるからね。
ただし、1画面プログラムはリストを公開することでぎゅうぎゅう詰めになっているという
のをアピールが可能になるけど公式サーバ上でのみの公開となるとそれは他の人にはあまり
伝わりにくくなるにょ。
1画面プログラムカテゴリがあればまた変わってくるだろうけどハードルが下がって1画面
プログラムが活気づくかというと現時点では微妙な感じにょ。
私としてもやはり張り合う相手が欲しいのでぜひ他の人も1画面プログラムを作って欲しい
ところにょ。（だからTipsコーナーに書いているテクニックは遠慮せずにどんどん使って
欲しい）
というわけで、プチコン3号が発売されても私がやることはmkIIとはあまり変わらない
ような気がするにょ（笑）