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

227：御茶目菜子：2010/05/13(木) 12:09:16: せっかくの自作なんだから資料を残しておかないとね
5月9日に私は雑誌投稿した自作ポケコンゲームにはすべて攻略本を作っていると書いたの
だけどそれは具体的にどんなものなのかというのを見せたくて部屋の中を発掘したけど
見つからない・・・。（発行部数が1桁というレアな本だけど自分用に1冊は残しておいた
はずなのだが・・・）
ということで、唯一見つかったのは自作の「PJ増刊96」（発行部数40～50冊程度）と
「おちゃめ通信」（発行部数50～60部程度）くらいだったにょ。
せっかくなので、そのおちゃめ通信で書かれていた「ピーチバレー開発日記」をここで
公開するにょ。（「PJ増刊96」を見ると当時私が「スレ○○ーズ」にはまっていたのが
良く分かってしまう・・・）

※基本的に当時の原文そのままだけどけんちゃんの名前は実名掲載をしていたために
　そこだけ変えている
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
　これはE500用のゲーム「ピーチバレー」を作成したときのノンフィクションドキュメント
ストーリーです。以前書いたのはいいですが、なかなか発表する機会がないのでここに
掲載することにしました。

1997年5月
御茶目菜子（以下「お」）：おちゃめソフトの今月の新作は何にしようか。
けんちゃん（以下「け」）：バレーボールとかどう？
お：でも、BASICじゃあ速度の都合上キャラクタは2人くらいがやっとだね。
け：ならビーチバレーにすればいいんじゃない。
お：それいいね。

　ということで「ビーチバレー（仮）」というタイトルで開発を開始したのである。
　翌日キャラクタ表示部分のサンプルを作ってみたが、OPASを使用してもキャラクタ4人
（もちろん2人×2チーム）を表示するだけで160m秒もかかってしまう。OPASを使用しな
ければ軽く200m秒を越えていたことであろう。実は数年前にもこのような2人制のバレーは
考案したのだけどこのキャラクタの表示の遅さがどうしても解決できずに制作を断念
しているのだ。バレーボールのゲームといえばE500では7年前のベーマガに掲載された
「だいちゃんの日記～バレーボール編～」くらいしか思い当たらないが、このゲームは
1人対1人にもかかわらずメインルーチン1回当たりの実行速度は300m秒くらいかかって
いたのである。最終目標は秒8コマ（120m秒程度）である。現時点ではこの目標にかなり
近いように思えるが、ここからキー入力判定や当たり判定、ボールの表示などを入れたら
少なくとも2倍は遅くなることが考えられるので、目標には遠く及ばないことになる。
まだこれ以上速くする余地が多く残されているので開発を継続することにした。

　とりあえず、キー入力判定（左右移動のみ）を入れてみたら、190m秒になってしまった。
せっかくOPASを使うのだから少しはグラフィックに凝りたいのでコートを立体的にして
みる。（ちなみにコートはフォント書き換えで選手はOPASのスクロール機能を用いて
表示している。GPRINTなどと違ってキャラクタの消去処理が不要なので表示のちらつきは
皆無なのである。）これにより、見た目は大幅にグレードアップしたが、処理速度は
ほとんど遅くなっていないのだ。
　しかし、これには問題があったのだ。選手にスクロール機能を用いて表示しているので
スクロールの範囲外（コートの外）には移動できないのである。これは、意外に簡単に
解決した。要はコートの外にレシーブしたボールが飛ばないようにすればよいのである。
　次にいよいよボールの表示と当たり判定（この時点ではまだネットの当たり判定は
入れていない。これが後に以外に面倒なことを引き起こすのだが・・・）を入れてみる。

お：とりあえず、動くようになったけどやってみて。
け：これって難しくない？

　それもそのはず、この時点では落下予測ポイントの表示がなかったのだ。ゲーム
バランス調整は後からでもできるので、まずはゲームの開発を進めることにした。
　とりあえず、2人用は形になったので次は対コンピュータのプログラムを作ることに
した。まず、問題となったのは思考ルーチンで、ただでさえあまり速くないプログラムを
これ以上遅くならないようにするために簡単かつ強いものを考えなければならないので
ある。
　構想の段階でコンピュータの強さは5段階（3段階では強さの差が大きすぎるし、7段階
ではあとでPFキーを使って難易度設定するかもしれないのでそのときに困るから5段階
というのがちょうどよいと思った。）に設定できるようにしていたのだが、難易度の
設定はあとからやることにしてとりあえず対コンピュータを作ってみた。

お：コンピュータとの対戦ができるようになったよ。
け：どれどれ貸してみい。
　　（しばらくプレイして）
け：あ～！今、ボールがネットを突き抜けていったぞ！
お：何かの見間違えじゃない？
け：ほら！ほら！
お：うっ・・・。本当だ・・・。

　ネットとボールの当たり判定はポピュラーなボックスタイプ（ネット、ボールがともに
長方形であると仮定し、それが重なっているかどうかで判定する）をしているのだが、
ちょっと（1ドット）でも重なっていたら当たったと見なしているのでボールがネットを
突き抜けるのは考えられないことである。唯一考えられるとしたらボールがネットに
重ならずに相手コートまで行くことだけなのだが、本当に起こり得るのだろうか。
当たり判定の範囲は8ドットでボールの移動速度も理論上の最高が8ドットのはず・・・
なのだが、実は乱数の値によっては8ドットをわずかに越えてしまうことが判明したので
ある。
　これは困った。簡単に対処するにはネットとの当たり判定を大きくするのが一番
なのだが、現時点で限界の大きさなのでこれ以上大きくするとネットに当たってないのに
跳ね返ってしまうことさえあり得るのだ。移動距離を小さくするという手段もあるのだが
そうするとボールの飛ぶ距離が短くなるためにコートも小さくしなくてはならなくなる。
　やはり、当たり判定の方法そのものを変えるのが一番手っ取り早いと思われる。
ポピュラーな方法なのだが、直線の方程式を使った判定（ボールの1ターンの軌道を直線で
表しネットの中心線との交点を求めその交点がネット上にあるのかどうかで判定する。
このゲームではそれをさらにカスタマイズして使用している）を行うことにした。これに
より問題が解決したばかりでなく、以前よりも自然にネットの跳ね返りが表現できている
気がしてきた。

　これで当たり判定は完璧なのだが問題は異常なほどの難易度の高さである。これも簡単に
解決してしまった。コンピュータが利用しているボールの落下地点の概算場所を人間に
分かるようにしただけである。やっぱり、コンピュータだけが知っているのはズルい
からね。これによりようやく普通にプレイできる難易度になったのであった。
　あとは、コンピュータの難易度を選択できるようにするだけである。
　コンピュータの難易度の調整は硬直時間とスパイクの確率で行うことにした。硬直時間が
長くなるほど落下地点に移動するのが遅れるのでレシーブが乱れるのである。しかも、
こちらがスパイクを打ったら反応もできないので「弱い」という感じが表現できた（
単純に弱くするのなら一定の確率でレシーブしないように設定すればよいのだが、それ
だけだと一見してワザとミスをしているように見えるため複数の設定を組み合わせている
のである）と思う。
　問題は強い方である。先ほども書いたように速度とメモリという2つの規制の中で最も
効率のよいものを考えなくてはならないのだ。一番の問題はコンピュータがスパイクを
打つときの処理である。トスの角度が一定ではないため何ドット手前でジャンプすると
いう設定ができないのだ。きちんと逆算を行えばこんな処理は楽勝なのだが、それを
やらなかったのは速度とメモリの都合もあるが、こんな完璧なコンピュータでは全く
おもしろくないからである。機械のように正確にジャンプし正確にねらった場所に
スパイクする。こんなコンピュータが相手では負けても全然悔しくならないであろう。
　落下予測地点にしてももっと正確な場所は計算できるのだがあえて概算地点を求めて
いる（速度、メモリ面において有利）のだ。仕方ないのでジャンプのタイミングは落下の
何ターンか手前で行うことにする。具体的に何ターン手前にするのかはデータを取って
いき最もスパイク成功率の高いところに設定することにした。

　ところが、ここで問題が発覚したのだ。ボールが人間をすり抜けることが起こり得る
のである。先ほどのネットの当たり判定とは違い今度は理論上の最高速度が8ドットに
遠く及ばない（速いボールはスパイクしないようにしているため）のだ。原因は至って
簡単であった。それはボールが斜めに移動しているからなのである。
　これを完全に修正するには先ほどの直線の方程式を用いた当たり判定をするしかない
のだが、実は、単純に判定を行う（ネットの時と同様に体の中心線で判定を行う）と
ボールの跳ね返りが不自然になるのである。体の中心ではなく前と後ろの2カ所に
分けて行えば不自然さは無くなるのだが、速度面でもメモリ面でも大幅に無駄が増えて
しまう。もっと簡単に直すには落下位置をもっと正確に求めるとよいのだが、ファジー
だった動き（簡単にファジーさを出すには乱数を用いるのが一番なのだが、そうすると
弱くなってしまうのだ。乱数による影響を極力弱くしてファジーさを出すというのは
強いものを作るよりかえって難しいのだ。）が機械っぽくなってしまうので却下した。
　ここは「ネットではないのだから100％跳ね返らなくて当たり前（考えてみればそうで
ある。ボールが人間の手前か奥にあると思えばよいのだ。）」と自分を納得させて
すり抜け現象が最も起こらないような位置をひたすらテストプレイを繰り返して見つける
ことにした。

　ほぼ完成し、そろそろ正式タイトルを決めたいところである。

お：何かいいタイトルはないかい？
け：ボールを桃の形に変えてから「ピーチバレー」というのはどう？
お：それいい！ナイス！

　こうして正式タイトル「ピーチバレー」が決定したのだ。ボールを桃の形にするのは
結構簡単にできた。速度もFOR～NEXTを駆使しているためボールのアニメーション処理を
行っても少し遅くなっただけである。このときまでにかなり高速化をしていたため
処理速度は1人用で秒6コマ程度（約160m秒）、2人用で秒8コマ程度（約120m秒）と
かなり目標に近い値になった。（ともにキー入力を行ってない状態の速度）
　十分な速度といっても過言ではないだろう。

お：さすがにレベル5には勝てないじゃろ～！
け：あっ！コンピュータがサーブを落としたぞ！
お：そんな馬鹿な！

　レベル5は単純なレシーブミス（落下ポイントで待ちかまえていたにも関わらずボールを
落とすという初歩的なミス、言い換えれば「ファミスタ」のエラーなしの設定で野手が
手を挙げているのにボールを落とすようなものである）は100％しないようになっている
のだ。なのに確かにサーブを取れないのだ。これは理論上ありえないことである。もし
あり得るとしたら・・・そう、例のすり抜け現象がスパイク以外にも起こっているので
ある。普通では絶対に起こらないのだが、ある方法でサーブを打つとすり抜け現象が
かなり高い確率で起こるのだ。

け：これは「桃尻サーブ」と名付けよう

　こうして、伝説（？）の「桃尻サーブ」が誕生したのだ。これを起こらないようにする
には先ほど書いたように当たり判定を根本からやり直さなくてはならないし、それに
より速度低下は免れないのである。仕方ないので「桃尻サーブ禁止令」を出しこのサーブの
使用方法は封印されたのだ（笑）
　ここまでかかった日数は25日、テストプレイは何百回行ったことだろう。この間に
会得したテクニックについてはこのガイドブックに詳しく書いてあるのでぜひ読んで
ほしい。レベル5のコンピュータと対等（またはそれ以上）に戦えるようになればきっと
このゲームの奥深さが分かってもらえるだろう。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　97/11/22　御茶目菜子
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
初出：「ピーチバレー」ガイドブック（97年11月22日発行、と思う）
再掲：おちゃめ通信第5号（98年8月6日発行）、第6号（98年10月2日発行）

これを読めば5月10日に書いた「ポジティブな妥協」というのがどういうものなのかと
いうのが分かると思うにょ。
様々な制約のもとどっちが良いのか天秤にかけるということがあるのだけど「良い」と
思った方を積極的に選択している・・・と思っているにょ。
ちなみに「桃尻サーブ」に関しては後日のバージョンアップで桃尻サーブ対応の思考
ルーチンに改良したために完全に使えなくなったにょ。
しかし、その新バージョンはRAMカードの故障とともに消えてしまったにょ。

というわけで、このピーチバレーをOMPやALICEやPSSに対応させた新バージョンを作り
近いうちにサイト上に掲載予定にょ。（上記のようにそれに対応したバージョンが消えて
しまったためベーマガに掲載されたver.1.0からもう一度バージョンアップし直すことに
なってしまう）
とはいえ、当時のプログラムの解析作業から入らないといけないので時間がかかりそう
だけどね（笑）