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

223：御茶目菜子：2010/05/09(日) 12:18:32: ポケコン談義（補足）
先日行われたオフ会でのポケコン談義の中からその場に居合わせてなかった人のために
ポケコン談義で私の口から出たものを2つだけピックアップして書いてみるにょ。
とはいえ、その場で録音していたわけでもないし直接相手に話すのとテキストによって
不特定多数に伝えるのでは異なるためにいつものように補足を多めにしているにょ。
また、その場に居合わせていた人であってもあれはこういう意味で言ったのかと感じ
取ってもらえれば幸いにょ。

(1)ポケコンゲームは妥協の産物である
(2)雑誌掲載は難しくない

以上2点について書いていくことにするにょ。

(1)ポケコンゲームは妥協の産物である

ポケコンはCPUの演算性能、画面表示性能が低くメモリも少ないしということで一般的な
PC用でのゲーム作りとかなりかけ離れているにょ。
スペック的にはシャープに置けるPC-E500シリーズやG800シリーズは80年代の家庭用の
主流だった8ビットパソコンと同レベルであるためプログラミングの考え方もそれと似た
ようなものなのだけど画面サイズが小さく色も基本的には白黒二値だし、デフォルトでは
和音演奏もできないということでゲームにおける表現力は80年代の8ビットパソコンと
比べて大きく劣るにょ。
したがって、ポケコンゲームには妥協が必要不可欠となるにょ。

しかし、「妥協」というとネガティブなイメージを浮かべる人も多いのではないかと
思うにょ。
十分に高いスペックのポケコンがあれば自分が作りたいものをそのまま具現化することは
可能なのだけど現実的にそんなものは存在しないし、高いスペックをフルに活用するには
高い技術力も必要になるため個人でできる範囲のことを越えてしまう場合が多いにょ。
したがって、「スペックが低い」ということは逆にハードルを下げてくれるのに有用とも
言えなくはないにょ。
もっとも、高いスペックをフル活用しない場合、言い換えれば今のハイスペックなPCで
ポケコン並のゲームを作る場合はメモリや速度のことを考えずに作れるため逆にハードルは
下がるだろうけどね。

ただ、ポケコンの場合そのメモリの少なさや性能の低さにチャレンジするという行為、
つまりゲームを作るという行為そのものがゲームといっても過言ではないにょ。
しかし、メモリの少なさや処理速度の遅さは簡単には克服できないにょ。
もっともこれはマシン語である程度はどうにかなる（マシン語であっても速度は有限で
あるためBASICよりは桁違いに速いというだけにすぎない）わけだしBASICの高速化も有用
といえるにょ。

メモリに関しては私は無駄にグラフィックに凝らないことやメインルーチン以外はメモリ
消費量優先のプログラミングを行うことで改善しているにょ。
無駄にグラフィックに凝らないというのはグラフィックそのものがウリとなっている
ゲームでない場合は、そのゲームの本質的おもしろさが分かるレベルのものを用意する
ということにょ。
特にゲームの本質とは全く関係ないタイトル画面でグラフィックを使いまくるというのは
そういう私の方針からは外れてしまうにょ。

実際に私が作ったゲームにおいて見てみると「シュプール」の場合、プレイヤーの
グラフィックは正面、右、左の3通りしか用意してないにょ。
OPASを使っているためグラフィック数をもっと増やして人物がなめらかに動くようにする
ということはいくらでも可能なのだけどそれをやらなかった理由は単にそこまでしても
ゲーム内容そのものは変わらないからにょ。
人物は5度単位で29パターンの角度で動作しているので最大29枚のグラフィックが必要と
なるにょ。
1枚が12x16ドットで48バイトとなり、現行の3パターンと比べると26パターンの増加と
なるために48x26＝1248バイトとなるにょ。
このシュプールのリストは約8KBであるためそれだけで15％サイズが大きくなってしまう
ことになるにょ。
それだけのグラフィックを用意するのも私自身が面倒だというのもあるけどそれ以上に
入力する方も面倒だと私は考えているにょ。

確かにグラフィックパターン数が増えれば動きはなめらかになるけど内部の当たり判定も
それに伴う必要があるにょ。
とはいえ、実際はキャラグラフィックが3パターンだけど当たり判定（ポールとポールの
通過判定）は29パターンで処理しているので問題はないにょ。
だから、グラフィックパターン数が増えたからといって判定そのものを変える必要性は
ないにょ。
しかし、逆に言うとグラフィックが変わったのに当たり判定は変わってない（緻密に
なってない）ともいえるにょ。
そうなると単純計算で実質29通りを判断するのではなく個別に29通りの判定を行う必要が
あるけどそこまで緻密な動作を要求するゲームではないので問題はないにょ。

また、パターン数が増えれば移動方向が分かりやすくなるというメリットはあるけど
このシュプールの場合は背景を1ドット単位で多重スクロールさせることで速度や進行
方向は分かりやすくなっているためそこまでのプレイヤーキャラのパターン数は不要と
考えたにょ。
それでも3パターンは少ないので5パターンくらいあった方がいいかなとは思っている
けどね。

音楽に関してはゲーム性に影響を与えるものでないから無くてもいい・・・けれどそれも
プレイしていて寂しいのでOMPのような簡易音階演奏ルーチンを組み込むのがいいと
思うにょ。
直接BEEP命令を連ねていってもいいけど数音くらいならまだしも10音や20音ともなると
リストそのものが長くなるし、入力する方も嫌になるからね。
別にOMPに拘らなくても自分のオリジナルのものでいいんだけどね。

私がOMPを作る前に多用していたオリジナル音階演奏ルーチンはこんな感じにょ。

*MUSIC FOR I=1TO LEN M$:Z=ASC MID$ (M$,I,1)-25:BEEP 1,Z,20000/(90+4*Z):NEXT :RETURN

これは短くて便利なルーチンなのだけど汎用性が極めて乏しいのが難点にょ。
ドの音（BEEP 1,39）を出すためには39+25=64でアスキーコード64の「@」をM$に入れる
という方法で音楽データを作っていくわけだけどこの方法だと全部計算しないといけない
からね。
一覧表をあらかじめ作っておけば解決・・・だけど普通に入力できる文字には限りがある
ために「-25」というのはあくまで一例でプログラムによって変える必要があるにょ。（直接
入力できない文字を使用していれば入力の負担軽減のメリットが無くなってしまう）
当然、テンポもその都度変える必要があるのでせっかく作った音楽データを流用する
ことができないにょ。
したがって、速度を重視しつつ汎用性を高めたOMPを作ったにょ。
上記簡易演奏ルーチンは実質1オクターブ＋αしか演奏できないのに対してOMPならば
3オクターブ＋α演奏できる上に異なる機種であっても音楽データも共用できるにょ。

あと難しいのは速度面の妥協にょ。
グラフィック面を妥協することでメモリの問題はかなり改善されるとはいえ、速度面では
BASICを使う限りは厳しいのは確かにょ。
それでもBASICに拘るのならばやはり高速化をすべきにょ。
ポケコンBASICによるゲーム制作講座　第3章で書いたように作りたいゲームがあっても
それを実現するためには速度が必要になるからね。

速度を稼ぐための妥協として「ピーチバレー」ではキャラそのもののアニメーションはなく
1パターンの立ち絵（＋ジャンプ絵）のみとなっているにょ。
これはキャラを背景として処理することでOPASのスクロール機能を使って1つのPRINT文で
敵、味方合わせて4キャラを同時に動かしているからにょ。（背景として表示しているため
書いて消すという移動動作のうち「消す」という作業が要らなくなるというメリットがある
のと同時に表示のちらつきもなくなるというメリットもある）
もっともOPASを使えばスクロールしながらアニメーションもできなくはないけど2パターン
しかないアニメでもデータ数が2倍になってしまうにょ。
「シュプール」の場合は必要最低限の3パターンだったけど「ピーチバレー」の場合は
1パターンでも問題ないからそうしているにょ。（その上パターン切り替え操作をするため
には10m秒以上遅くなってしまうためBASICの限界まで高速化をした意味もなくなる）

幸いPC-E500系は元々ポケコンの中では速い方だし、高速化のためのテクニックは多数ある
ためにポケコンの中では最も高速化の恩恵が多い機種ではないかと思われるにょ。
そのテクニックに関しては「E500BASICの高速化のすべて」に主要なものはまとめている
けどオフ会のときにとりあげたのはGOTOによるテーブル処理にょ。
これによって「シュプール」の複雑な操作、「ピーチバレー」（2人対戦ができるビーチ
バレーゲーム）のように複雑な対戦型ゲームのキー入力判定もGOTO命令1つだけでで
まかなえてしまうにょ。

あとその恩恵で速度ペナルティゼロでどこでもポーズ機能が可能になったにょ。
一般的なPCやコンシューマゲームではポーズ（一時停止）ができるのは当然なのだけど
ポケコンゲームの場合は余分なIF文が必要になるため使われないことが多いにょ。
またただのポーズではなくポーズ中は自動電源OFFにも対応しているのが私のゲームの特徴
となっているにょ。（これはWAIT設定を解除するというだけの初歩的なテクニック）

それに加えて私のゲームで特徴的なのはメインルーチン内でIF文を使わないことにょ。
実は大抵の場合、論理式よりもIF文の方が速いのだけどそのIF文よりもFOR～NEXTを用いた
方が速いにょ。
無理にIF文を使わないようにすればかえって遅くなるけど「シュプール」ではポール内の
通過判定のみ「ピーチバレー」では敵の思考ルーチンのみIF文を用いておりあとは使わ
ないでも済むような構成にしているお陰にょ。

このように「妥協＝ネガティブ」という意味で使用しているわけではないことが分かると
思うにょ。
すべての面において妥協するのではなく別の面では妥協をしないで限界にチャレンジして
みたり、バランスを最重視するということをやっているなどのポジティブ思考で妥協を
行うことがポケコンゲームには重要になってくるにょ。
それが私の場合は主に高速化にシフトしているというだけにょ。

確かに高速化はポケコンでは恩恵が大きいにょ。
PCゲームならば遅いゲームでも速いPCを使えば問題ないため高速化なんて無意味になる
場合もあるけどポケコンの場合（特にPC-E500系の場合）そういうわけにもいかないにょ。
とはいえ、G850系はポケコンの中でもトップレベルに速くOPASを使い画面表示は5倍、
トータルでも（他の高速化を合わせて）3倍近く速くなった「ピーチバレー」もG850で
作れば労せずそれと同等の速度が出せてしまうかもしれないにょ。（G850のGPRINTはE500
よりも4～5倍速い上に演算速度も2倍程度速いため）
しかし、最初から諦めていたら「シュプール」「ピーチバレー」といったゲームを作る
ことはできなかったにょ。

だからこそ、ポジティブな意味で妥協を行う（理想に達することはできないけどより高い
ものを目指している）ということは重要になると思うにょ。
端的に言えばトレードオフが重要ということにょ。（トレードオフだと「何かを捨てて
何かを得る」というイメージがあるけど私は何も捨ててないと思っている場合もあるため
「ポジティブな妥協」というオリジナルワードで表現している）

(2)雑誌掲載は難しくない

さて、今ではネット上で不特定多数の人へ簡単に自分が作ったゲームを公開できさらに
その反応もネット上で見ることができたけどネットが普及する前はそういうわけには
いかなかったにょ。
確かにパソコン通信（ポケ通）などでは可能だったけどそのためのハードルは高いにょ。
したがって、雑誌に投稿してそれが掲載されるということを目標としている人も大勢
いたにょ。
ポケコンソフトを掲載している月刊誌は私が記憶している限りでも専門誌のPJを除けば
ベーマガ、I/O、Pio、プログラムポシェット、The BASICなどがあったにょ。

さて、問題はそれらに投稿して掲載されるかということだけどPJとベーマガにしか投稿
経験がない私だけどそれほどハードルは高いものではないと感じていたにょ。
とはいえ、私自身100％の掲載率を誇っていたわけではないのでやはりボツになったもの
というのはあるにょ。
ただ、工夫次第ではいくらでも掲載率を高めることは可能にょ。

まず最低限必要なのは必要事項が抜けてないことを確認したりテープにちゃんと記録
されているか照合することにょ。
そしてゲームの場合重要なのは致命的なバグがないことを確認することにょ。
普通にプレイして発生するバグがあるようなものは論外にょ。
ここまでは必ずやっておくべきことにょ。

そしてこれからがようやく本題にょ。
「ドキュメントは簡潔に分かりやすく書くこと」「プレイしておもしろいと思ったものを
投稿すること」が重要にょ。
前者に関して言うとあまり長いものだと誌面の都合で掲載できなくなることもあるし
あまりに簡潔すぎて内容が分からないようだと編集部でテストプレイしても面白さが
伝わらない可能性があるからね。
したがって、私はたいてい編集部用に投稿ゲームの攻略本（冊子の場合もあるし1枚紙の
場合もあるけどものによっては20ページ、イラスト入りというものもあった）を作り
それで内容を分かりやすくしていたにょ。

後者に関してはいくら技術的にハイレベルであっても遊んでいてつまらないものだったら
掲載は無理だからね。
ポケコンBASICによるゲーム制作講座　第5章で書いたようにテストプレイを行うことが
重要となるにょ。
完成した喜びでそのまま投稿してしまうというパターンもあるけど喜びによって客観的に
そのゲームを判断できてない場合も多くなってしまうにょ。
本来なら作った本人ではなく友達などにプレイしてもらい感想を聞くのが一番なのだけど
それが難しいならばせめて自分がプレイして楽しいかどうかを見るのが重要にょ。（ただ
パズルゲームやアドベンチャーゲームのように最初から答えが分かっていたら楽しめない
ゲームの場合はそれができないけど）

そのためにも完成してしばらく様子見をするのも重要になるにょ。（しばらくしてみたら
「つまらない」と自分で気づきそのままお蔵入りしてしまうこともあるかもしれないけど
そんなゲームだと投稿してもボツになるだろうし）
また、アクション系のゲームの場合速度によって面白さが変わることもあるため(1)で
書いたように速度では妥協をしない（マシン語を使う、BASICの限界に挑戦する）という
のも1つの方法にょ。

あと私の場合はそれに加えて入力する人のことを考えて同じゲーム内容であればリストを
なるべく短くなるような措置をとっているにょ。
これは(1)で書いたようにグラフィックに関しては妥協をするというのも1つの方法と
なるにょ。
あと雑誌投稿時代には間に合わなかったけどALICEのようなチェックサムを使うというのも
雑誌等の紙媒体で公開（もしくはテキストによる公開）においては有用といえるにょ。

以上簡単に書いたけど何も工夫をしなければ採用されるかは運次第にょ。（たまたま
投稿数が少ない月で他に掲載可能なものがないならば必要最低限のものさえ守られていれば
掲載されてしまうかも）
しかし、工夫をしていけば掲載率はかなりアップさせることは可能になるにょ。
したがって、雑誌掲載そのものは難しいことではないのはそのせいにょ。

という感じでオフ会でのポケコン談義で出てきた一言にに大幅な追記をしてみたにょ。
実際顔を合わせて1対1で話すならばここまで書かなくても分かる人には分かるけどね。
そういうことで、ポケコンBASICの話題ならいくらでも出せるのでもしも私とリアルで
ポケコン談義がしたいという奇特な人がいれば言ってにょ。
もしかするとそこで（2人だけの？）オフ会が開催されるかもしれないにょ。