技術なんて必要最小限のものがあれば十分だと思います。分からないことはWeb検索でいくらでも調べることが可能なので重要なのは検索スキルでしょう。 ただし、やる気や時間はどうしようもないですね。特に社会人になると時間の確保が難しくなるため時間がかかる大作はいかにモチベーションを維持できるかが重要になってくると思います。 私は飽きっぽいので無理ですが（笑）

Web接続可能なPCがあれば、マイク経由でそのPCとデータのやりとりをするソフト、プチコン3号上で動作するWebブラウザソフトを作ればプチコン上で自由にWeb閲覧することが可能になります。 昔、ポケコンや8bitパソコンを使って同じようなことをしている人もいましたが、プチコン3号のマイク経由だと1200bps程度なのでテキストブラウザ程度に止めておいた方がいいかもしれませんね。

うえこうさんへ あれを見たら装着可能かどうかが一番気になりませんか？(笑) nobuさんへ うえこうさんは穴があればツッコミたい性分なんでしょう。

趣味でやるプログラミングは楽しいのが一番ですね。 ただし、上達したいならば少し話は変わってきて自分の意図した通りに動くものが作れるということが求められてきます。 プログラムの処理をちゃんと理解してそれができるようになれば中級者だと私は思います。

プログラミングは楽しいのが一番なのでそれでも問題ないと思います。 今回書いたことはQSPでも凝った作品が作れるということなのですが、これは誰にでもおスズメできるものではないです。 あとリスト短縮のための知識や技術はQSPを作る際の選択肢を増やしてくれますが、これはQSPに限ったことではなく知識や技術というのは良い作品を作るためではなく選択肢を増やすために必要になってくるものだと私は考えています。

お供機能（アイテム機能）は表示できる位置や大きさを任意に変更可能になれば良い感じになりそうですね。 ただし、アヒルを想定したような装着を行う場合にはポーズの可変機能を搭載する必要があり、アイテムによってポーズを変える機能は実現は難しそうですが。 完成を楽しみにしているので頑張ってください。

個人的には否定から入ることは良くないことだと考えています。 「こんなことをして何になるの？」「こんなのは駄目だろ」という否定を真っ先に行う人もいます。私のトピックスでもそういう意見を言う人を幾度か見かけましたが、そういうのが積もって出た考えは「否定意見は意見ではない」というスタンスです。（詳しくはぐぐれば分かる） 特に「お前より俺の方がすごい」的な考えを持っている人（自意識高い系の人）だと自分を高めるために相手を否定するため否定内容も薄っぺらで論理的な正しさも無い場合が大半であり反論するだけ無駄な力を費やしてしまいます。 したがって、論理的な正しさのない否定はスルーするのが一番です。

（続き） 実際は10240バイトという制限を設ける必要は何もなくQSPレベルの短縮であればそれよりもずっと短い時間で作れますが、それでも普通に作るのと比べて何倍も時間がかかります。 メモリ搭載量が少なかった昔のポケコン等であれば普通のプログラムであってもリスト短縮をすることが非常に有用だったですが、メモリが8MBもあるプチコンで数KB程度のリスト短縮にはほとんどメリットとは言えないでしょう。 むしろ、可読性が著しく下がるというデメリットの方が大きいと思います。 もっとも、私の場合は無意識にリスト短縮してしまう部分も多いしある程度のリスト短縮は可読性を高める際に有用だと思います。 したがって、「リスト短縮＝可読性を低下させるもの」ではなく適度なバランスを考えて行うのがベターではないかと考えます。

nobuさんへ リスト短縮は単に短くなるというだけではなくQSPの場合はリスト短縮によって完成度を高められるのが何よりも大きなメリットであると思います。 それが驚きに繋がっていると思います。 詳しくは本日書いたこちらのトピックスをご覧になってください。 もちろん、QSP以外でもリスト短縮はいくらでも可能です。 ただし、私の経験則から言ってQSPと同じ密度でのリスト短縮を行った場合にはリストのサイズの2乗に比例したくらいの時間がかかります。 10KBのプログラム（ベーマガ掲載サイズでは普通程度の大きさ）だとQSPの34倍のリストサイズ（1文字1バイトとして考えた場合）となり、約1164倍の時間がかかります。 これが限界と言い切れるQSPに1週間かかる場合にはこれが限界といえる10KBのプログラム（10240バイトに限りなく近づけたプログラム）を作るには20年の歳月が必要です。 （続く）

今回はQSPに対する考え方のみを書いたので具体的に何をどうするかはほとんど書いていません。 その割りには長々となってしまいましたが（笑） 具体例を出すには実際の作例（私が作ったQSP作品等）を元に書くのが一番ですが、短縮法というのはケースバイケースな部分が多く1つの作例を提示しただけではあまり意味はありません。 実際にどのようにすればリスト短縮が可能になり、どのようにすれば完成度が高まるかは既刊「プチコン3号QSP完全マニュアル」「プチコン3号QSP完全マニュアル PART2」を参考にしてもらえると良いかと思います。 限られたリストサイズで限られた以上のものを作るための具体的な方法をたくさん記しています。（Miiverse等で発表された作品を自力で解析するのもありです） Miiverse上でも初心者向けのQSP講座をそのうち書こうと思いますので期待せず待っていてください。

QSPは誰にでもオススメできるものというわけではなく「何よりも可読性が重要」とか「制限を設けてプログラムを作るなんて無意味」という人に対してQSP等はむしろオススメできないと思っています。 それは私自身が2、30年前にそのような論争を経験しているためこういう考えを持つ人がいるのを承知しているからです。 価値観の相違があり否定から入る人に対して反論するのは逆効果と言えるでしょう。（Miiverse上でもRVAL関数ver.2.0発表の際に痛感した） したがって、QSPに関しても「否定的な考えを持たない人」のみにオススメします。「QSPは勝利」「QSPで万全」（←この元ネタ分かる人いるのか？）というわけではありません。

これでQSPといってもいくらでも工夫できる余地があるということが分かってもらえたと思います。 ただし、凝れば凝るほどQSPといっても馬鹿にならない時間がかかってしまうのが難点です。（1文字削るために数日費やしたりとか） 労力と出来る内容を天秤に掛けてしまう人にはあまり向いてないかもしれません。（掛けた時間に比例してすごい作品が作れるというものではない） それでも「QSPはお手軽に限界まで凝りまくったゲーム（ツール）が作れる」というのが普通のプログラムと比べてメリットだと思います。 私の場合はリスト短縮そのものに興味関心があるためQSPを作ることに向いているかもしれません。 80年代のマイコン時代からプログラミングをしていますが、あの頃はメモリも少なく速度も遅い環境下で作っていたため「短くする」「速くする」が必要不可欠なものだったのでそれを引きずっているだけかもしれません。

それに対して制限のない普通のプログラムでは無茶なリスト短縮のメリットはほとんど無くデメリットの方が多いでしょう。 QSPの場合は短縮することで実装できる機能を増やすことが可能になり、ゲームやツールの完成度を高めることが可能になるわけですが、機能が増えたから完成度が高くなるという単純なものではありません。 しかし、短縮することで選択肢が増えて短縮することで完成度を高めるための余地ができるというのが非常に大きいです。 リスト短縮の目的は別の言い方をすれば「QSPで作れる選択肢を増やすため」と言えるかもしれません。 こちらで書いている100m走のプログラムのバランス調整も選択肢が増やした結果であり完成度を高めることに繋がっています。（QSPだからといってバランスは手抜きをしたくない） https://miiverse.nintendo.net/posts/AYIHAAAEAABEVRTpSM

お絵かきソフトを作る際に上記のものをすべて実装するとQSPに収めるのは非常に困難ですが、実は冒頭のSIMPLE PAINT QSPでは（簡易的な部分もありますが）それらをすべて実装しています。 OSPやQSPが初心者向けではないのはすでに書いているように無茶なリスト短縮を求められる場合も多いためです。 しかし、QSPを作る場合においては「リスト短縮は何のために行うのか」を知っておく必要があるでしょう。 「1文字でも短くする」のが目的ではなく実は優先度Aを実装すれば終わりではなく優先度Bもすべて実装したいし、優先度Cもできるだけ実装したいためです。 つまり、リスト短縮は「単に短くする」というのではなく「より多くの機能を実装可能にする」という非常に明確で分かりやすい目的が存在しているのです。

例えばお絵かきソフトを作る場合にはタッチした座標に点を打つという機能は必要不可欠でしょう。と はいえそれだけでお絵かきソフトとして発表するには不満があり消しゴム機能や線が途切れないで引ける機能や操作によって線の太さも自由にを変えたいと思う人も多いでしょう。 どこまでを必須機能としてどこからを重要機能とするのかは各個人の判断に委ねられるところですが、前述の機能だけならばQSPで収めるのはそれほど難しくありません。 しかし、カラー対応のお絵かきソフトを作るとなると色指定機能は必須機能（優先度A）、スポイト機能は重要機能（優先度B）として実装したいところです。（この優先度は私の考えによるもの） セーブやロード機能も欲しいところですね。（優先度B） 擬似的な筆圧機能もあると便利ですね。（優先度C)

当然ながらゲーム、ツールは様々な機能で構成されています。 しかし、最大文字数293文字のQSPを作る場合においては思いついた機能をすべて実装するのは極めて困難です。 したがって、優先順位の設定は必要不可欠となります。 優先度の設定の仕方は各個人の自由ですが、少なくとも「実装しないとゲームやツールとして成立しない必須機能」「（無いと動作に少し支障があるため）できるだけ実装したい機能」「（無くてもあまり支障がないけど）余裕があれば実装したい機能」の3通りがあると思います。 それらを優先度A、B、Cとして考えた場合は優先度Aを実装することが必要不可欠ですが、優先度B、優先度Cもどこまで実装できるかが完成度に関わってきます。

「機能」というと難しく考える人もいるかもしれないですが、ここでは画面にスコアやタイムを表示するのも機能の1つと考えます。 ただし、表示の際に?S（これは「PRINT S」ということ）だけで良いかというとそうではなくLOCATEで位置指定しないと正しく表示できない場合も多いでしょう。 小数点以下の表示が行う際にはFORMAT$等を使いある程度桁数を制限する必要があるかもしれません。 整数であっても数値の桁数が減る場合（残りタイムが10から9に減る場合等）には残像を消去する必要もあります。 それらを行って「スコアやタイムを表示する機能」の実装ができます。

それでは、QSPでは凝ったものを作ることはできないのでしょうか？それも違います。 QSPであれば293文字の範囲内で凝りまくることが可能です。 QSPに慣れてない人だとリスト短縮そのものに頭を悩ませ作りたいものを作ることが難しいですが、ある程度作り慣れてくると「293文字で何ができるか」がある程度分かってきます。 搭載したい機能のリストアップ、その機能の優先順位付け、その機能を実装するために必要なコード量を把握することで「QSPで凝る」ということが可能になるだけではなく「QSPで凝ることが可能であることが分かる」ためQSP作りも楽しくなっていきます。 「QSPではろくなものが作れない」という考えで作っていると本当にろくなものが作れないということです。

「気軽に作れる」だけではなく「もっと作り込んでみたい」という人もいると思います。 私も作り出したら凝ってしまう方なのであれこれやろうとして未完成という場合が非常に多いです。1作品に数ヶ月、数年を掛けることが可能な人でしたら自分が考えた理想的なゲームやツールを作るのも良いと思います。 しかし、1週間とか1ヶ月で飽きてしまうような人だとそれは難しいためOSPやQSPはオススメです。 それは、「EDIT画面に収まる」ということが何よりも優先されるため文字数に制限があり、思いついたものをすべて付け足すということが事実上不可能であるためです。 EDIT画面に収まるということは、Miiverseではスクリーンショット1枚でプログラムリストを公開可能になるというメリットもあります。

OSPやQSPといった「使える文字数に制限のあるプログラム」は本来であれば初心者向きではありません。それはリスト短縮によって可読性が著しく低下してしまうことがあるためです。 しかし、小さいプログラムそのものは初心者にとっても有用（小さいプログラムさえ作れないのに大きいものが作れるはずがない）だしある程度のものは自力で作れるレベル（初心者を脱却するレベル）になると文字数に制限があるということが逆にメリットになる場合もあります。 それは文字数に制限があるからこそゲームに必要不可欠な部分以外の部分に頭を悩ませる心配がなくなるからです。 これは具体的に言えばオリジナルの絵を使い音楽もオリジナルにしないと・・・という考えを持つ必要がなくなるということです。 つまり、「OSPやQSPは誰でも気軽に作れるプログラム」というわけです。