ピンボールをシミュレーションするには、いくつか考えるべき要素がありますが、相手がリアルタイム3D表示シミュレーションですから、たとえCPUが貧弱であってもそれなりの演算精度と高速処理を同時に実現する必要があります。

そこで私がまず検討したのは盤面を如何に数値化するか（盤面をどうマップ化するか）、ということでした。まず思い浮かんだのは、高解像度のマトリクスにおけるビットイメージで盤を形成するビットマップ方式と、少し低解像度ながら各マス目に角度などの物理情報を持たせるバイトマップ方式です。

ビットマップ形式の場合、ボールも盤もビットイメージですので、両者が接近して重なり合うビットの状態から、接触する角度を割り出して速度に反映することになります。このためにはボールも盤もかなりの大きさ（解像度）のイメージとして用意してやらなければ、自然で滑らかな動きを持たせることはできません。最初、試しにテストルーチンを作って動かしてみたのですが、階段で積み木を転がそうとするようなもので、とてもうまく行かない（転がらずに跳ねる）ことがわかりました。この方法であれば、グラフィックエディタやコマンドで画面に適当に壁を描いてやると、それに沿ってボールが転がるのでとても面白いのですが、8ビットのパソコンでシミュレーションとしてやるものではない、と早々にあきらめました。

一方、バイトマップ方式の場合、マップの各領域に予め角度情報や機能情報を書き込んでおくため、マップ作成は面倒ですが、計算は楽になります。そこで現実解としてまずバイトマップ方式を採用することにしました。

次にマップの内容をどうするかですが、これはつぎのように決めました。

• 計算速度を優先するため、ボールは大きさのない中心位置情報のみで取り扱い、壁にボールの半径に相当する厚みを持たせる。
• “壁抜け”を防止するため、壁の厚みは2～3マス持たせる。すなわちボールの直径は内部計算上、5マスとなる。
• アクセスを最速で行えるよう、1マスは1バイト（8ビット）とする。
• 1マス8ビットの情報を以下のとおり割り付ける。
  Bit7 役物（機能動作）フラグ。1で役物。
  Bit6-5 壁の場合は反発係数。役物の場合は役物番号または反発係数。
  Bit4-0 壁の場合は壁面角度。役物の場合は役物番号または壁面角度。
  オール0は何も無しの領域。オール1は壁の中。
• 壁面角度は30角形の角面の一つとする。

こうしますと、マップ情報をピックアップした後、計算前の条件判断処理が非常に少なくてすみ、基本的な処理時間を計算に当てることができます。すなわち、まずマップ情報をピックアップして、ゼロフラグが立っていれば、そのまま次の位置計算へ、サインフラグが立っていなければ、下位5ビットとその上の2ビットに分けて反発加速度計算へ、サインフラグが立っていれば、役物番号に応じた個別処理ルーチンへ間接分岐する、といった具合です。

ここで角度情報とは、壁面の法線ベクトルに相当するもので、それぞれの角度に応じたsin,cosの値を8ビット精度で格納したテーブルを用意してあり、ボールの速度が、壁面角に対して衝突の向きにあれば、x,yの速度成分について反発計算を行って衝突加速度を算出するわけです（壁と言うよりは力場のイメージですが）。

角度情報を30角形とした理由は、

• 垂直角は必要だが、水平角は持たないほうが良い（ボールがそこで止まってしまい、そのまま壁に沈み込んでしまう）ため、4で割れる角形数を避ける。
• マップの1バイトにできるだけ多くのフラグ情報を詰め込むため、角度精度は最小限にしたい。
• 作図してみて、30角形でも感覚的に十分円に近いと思われた。サブシステムのCIRCLEコマンドが64角形、アルキメデスが円周率を求めたときは96角形だったので、この程度の精度でもよいと考えた。

などです。

またボール側の位置計算については次のように考えました。

• 計算速度をキープするため、固定小数点演算（整数演算）とする。
• ピンボールの面白さは、速度、加速度の幅の大きさ（変化のし方）にあるため、最低でも1バイト（255倍）は有効桁数を持たせる。
• 壁を突き抜けるのを防ぐため、位置と速度は異なるバイトとする。すなわち、

  |--------|--------|--------|
   76543210 76543210 76543210
   <-位置------------------->
   <-速度---------->
   <-加速->
  

  という構造の物理量表現を与える（x,yとも）。
• 速度、加速度には上限を与える。
• 位置座標系は中央最下部を原点（0,0）とし、右を+x,左を-x,上を+yとする。
• 常時加わる加速度として、重力以外に転がり摩擦成分を速度の大きさに対する減衰加速度として与える。

意外に簡単な計算だけでコトを済ませていると思われるかもしれませんが、1ターン（単位時間）ごとに、マップ位置からボールにかかる加速度を求め、速度、位置に加算するといった擬似24ビット固定小数点演算を行うわけですので、昔のCPUには結構な負担となります。幸い、2MHzの6809でもこの程度の計算はこなしてくれ、ピンボールと言える程度のナチュラルな動きを実現することができました。

本来であれば、モーメントに基づく剛体運動の計算をしてやるべきであって、壁面に当たるときも、当然回転による挙動を加えるべきと思いますが、あまりこだわりすぎて作れなくなっては困るので、基本的な方式を思いついたところから、実際にコードを書いてみて動きを確認していきました。見た目の動きが不自然でなければ、とりあえずそれでよしとして次の開発に進んでいったわけです。

全体としては、適当にやっていった割にはうまく収まってくれて、本人にとっても予想以上の出来栄えになっていきました。特に転がり摩擦による減衰ファクターを加味した点は、動きにリアリティを与えるポイントになったような気がします。

このようにして基本となるボール運動の演算アルゴリズムを確立しておけば、後はゲームに必要なバリエーションを、このシステムの中で実現していくだけですので、比較的楽に作ることができます。

さて、盤面設計ですが、まず外形を決めるために、参考資料に掲載された正対写真を直接モノサシで計り、台の横幅をボールの直径の約25倍としました。台の縦方向は、横幅の約2倍はあるように思われましたが、実際に絵を描き出すとこれはパソコン画面にとって非常に縦長になってしまうように思えたため、またマップのサイズがかなり大きくなることが考えられたため、敢えて縮めることにし、横の1.5倍としました（ちなみにムーンボールは1.25倍と幅広です）。

マップのサイズですが、先にボールのサイズを5マスと決めていますので、幅はその25倍ということで125、ただし計算が容易なように-64～+63（127マス）とすることにしました。縦はこれに合わせて192マスになります。これにより1マスを1バイトとすると24Kバイトとなり、メモリ空間の64Kバイトに対して結構な大きさとなりました。

内部の役物は、これも参考資料の写真や現物から、大きさを割りだして決めました。たとえばフリッパーは長さ方向でボールの直径の約2.5倍、幅は根元でボールとほぼ同じ、としています。サイズが決まれば、各役物を盤面に配置し、それぞれに属性を与えていくことになります。このあたりから開発ツールが問題となるのですが、それについては後述します。

盤の基本構成が決まれば、あとはパラメータを決めていく作業になりますが、これは前述のようにピンボールの“らしさ”を決める重要なファクターです。

私が見る限り、当時の多くのソフトが失敗した理由の一つは、反発係数を大きく与え過ぎたことでした。ゴムを巻いた支柱に鉄球が当たった場合、殆ど跳ねずに、そこで止まるか横にそれるものなのですが、多くのソフトはスーパーボールよろしく飛び跳ねるのです。このように飛び跳ねると、ボールの重量感が無くなり、速度の変化も小さくなりますので、全体として平板な印象になります。そこで私はかなり意識して反発係数を抑えました。細かい数字は忘れましたが、0.2前後だったのではないかと思います（つまり衝突前速度が10であれば、衝突後は2になる）。

もう一つの問題としてフリッパーの強さが挙げられます。台に向かうとすぐわかるのですが、フリッパーでボールを打つと、普通は一番向こうの壁に力強く激突するくらい加速度が加わり、そこが一つの快感になっているのですが、ムーンボールや Midnight Magic は辛うじて向こうの壁に届くか届かないか程度の力しか与えておらず、興ざめするポイントでした。恐らくゲーム性を高めるため、わざと難しくしていたのでしょうが、実際の台であれば誰も見向きもしないでしょう。その点、メイガスではフリッパーが強くなっており、よくわかっていたように思います。

ファイアボールにおけるフリッパーの内部計算は、たしか次のように考えました。

• フリッパーの動作範囲角度は上下それぞれ同じとする（数値は忘れた）。
• フリッパーの速度はボールの最高速度の半分とする（不確か）。
• フリッパーの動きに合わせて、1マスずつフリッパーの位置が変わるバイトマップを用意し、フリッパーキーの押され方に応じて読むべきマップを一つずつ変えるようにする。
• ボールがフリッパー領域に入ったら、メインマップの代わりにその時点で対応するフリッパーのバイトマップを読むものする。
• フリッパーは縦方向の速度を持つものとし、ボールがフリッパー面に衝突した場合はy方向の加速度を与える。この加速度は衝突個所のx座標とフリッパーキーの状態で決まる（先端＝盤中央に近いほど衝突加速度が大きくなる）。仮に下向きに当たれば当然、ボールを叩き落とすことになる。
• フリッパー自体の衝突反発係数は低めに抑える（可動部のため、固定部よりも衝撃を吸収してしまうと考えられるので）。

この結果、一番下がった普通の状態から、ボタンを押して上がり切った状態まで、フリッパーだけで左右15個ずつのバイトマップを持つことになりました。これだけで10Kバイト近くになりましたが、ピンボールはフリッパーが命ですから、この処理が意外にうまくいったことが、ゲームの質を高めることにつながったのではないかと思います。

なお加速度はフリッパーが回転運動をしていることからx,yの両方を与えるほうが正しいのですが、とりあえずyだけ与えてみても結構それらしく動いてくれた（狙ったところにボールを打てる）ため、それで良いことにしました。ハード的も開発環境的も制約が多かったため、ちょっと作っては試す、ということの繰り返しだったのです。

ピンボールらしさを担うもう一つの要素に台揺すり、台傾けがあります。ピンボールのボールは盤面に乗っかっているだけですので、台に水平方向の衝撃を与えたところで、殆ど影響を与えることはできません。つまり衝撃を与えるとすれば、ボールが別の何かに触れているときに、そこからボールに対して加速度が加わるようにして、初めて効果が現れるわけです。むしろゲームの中では台をそうっと傾けて、ボールのコースを曲げてやることのほうが重要で、実際に多用します（もともとTILTは傾きの意味ですね）。

ところがパソコンピンボールは、誰が始めたのか知りませんが、ボールの軌道に衝撃？を与えてランダムに曲げるという奇妙なマナーが一般化してしまいました。このことはOh!FMに載ったムーンボール評価記事を読んで初めて気づいたのですが、これではピンボールの面白さを半分奪っていることになります。

そこで私は、水平方向の台揺すりと、左右への傾きを加える台傾けの両方をそれぞれ物理的な裏付けをもってサポートすることにしました。先に述べたようにボールを動かす基本ルーチンは出来上がっていたため、こうした要素を加えることは簡単でした。

まずスペースキーが押されたら、y方向の加速度をスイング状態で発生させ、ボールが反発処理に入っていればこの加速度を加味するようにしました。つまり壁その他に触れていなければ、台揺すりは全く役に立たないのです。さらにスペースキーがスイング中の加速度を増幅するようなタイミングでさらに押されたら、TILTとするようにしました。左右については、フリッパーボタンが押されたときに若干ながら加速度を与えるようにしていますが、これはあまり体感として効果が出ませんでした。

台傾けのほうは、専用の傾けボタンを左右に別に用意し、それらが押されている間はx方向に若干の重力加速度が加わるようにしました。これにより、ボールがフリッパーの間をすり抜けて落ちそうなときに力任せで救済する、あるいは右のレーンに入りかけたボールを無理やり左に入れる、といったピンボールらしい操作が可能になりました。

このようにして実現した従来にない高いボール操作性については、かなりの斬新さがあったと自負していたのですが、実際にはあまり評価されることもなく、むしろ台揺すりのときにハードウェアスクロールを利用して画面を揺さぶったことのほうが、ウケたように記憶しています（ちょっと残念）。

他にも役モノはいろいろありますが、まずはゲーセンで実物をとっくり観察して、その動きをプログラムで再現する、という方針にこだわって、動作原理の説明できない突飛なものは避けました。

単位時間をタイマで管理する処理は行っていないのですが、基本の運動計算ループをできるだけ高速で回すようにして、役モノなどの例外処理も加速度の値を変えるだけで対応するようにしたせいか、動きが不自然にギクシャクすることも無く、思った以上にスマートに仕上げることが出来ました。

グラフィックの全体的デザインは、ベースとなる土台を私が設計し、絵柄とカラーリングをグラフィックデザイン担当者が仕上げました。彼は開発の趣旨を良く理解してくれて、アメリカンな雰囲気が色濃く漂うデザインと、トップパネルに素敵なテーマペイントを施してくれました。

盤面のパーツは、彼がデザインを施してくれたボードに、私が積み上げて行きました。表現上、特に意識したことは、実際の台のように豆電球で光っているような雰囲気を出すことです。一見してパレットを切り替えているかのように見えますが、全て描きこみで処理しています。またパーツのパレットは、ボールの手前にくる部分と向こう側になる部分を組み合わせて立体表現になるようにしました。

ボールは、遠近縮尺とドット荒さの関係から、大きさを変えた表示パーツを4種類用意し、画面上のｙ座標に応じて、見かけが変わるようにしました。良く見ると、動いている途中でサイズが変わるのがわかるのですが、それなりにうまく動いて見えています。面白いことに、ボールの色を変えると大きくフィーリングが変わり、特に暗くすると非常に重く感じるのです。これはボールを白くするのが当たり前だったパソコンピンボールでは画期的なことでしたが、気づく人はやはりあまりいなかったようです。

フリッパーは、じつは2パターンしか持っていません。従来のピンボールは4～5パターン持っていたのに対し、後退のように思えますが、これには理由があります。最初、フリッパーの表示パーツは数パターン用意するつもりだったのですが、遠近表示のパーツを作るのはかなり面倒なので、とりあえず上下のパターンができたところでどんなふうに見えるかと思い、それだけでテストプログラムを作ってしまったのです。すると思いのほか、実物のフリッパーに近いフィーリングが得られることがわかりました。つまり従来のパソコンピンボールは動きを自然に見せようと表示パターンを多くするあまり、却ってフリッパーの反応が鈍く見えてしまい、画像的に2パターンしか持たないほうが、フリッパーの動きがそれらしく見えるのです。もちろん内部では15パターンの精度を持っていますから、荒いのは表面上だけで、むしろレスポンスが良くなった分、リアリティも増す結果となったのです。

その他の役物についても、画像的な動きにはこだわりました。

たとえば横のレーンにあるレバースイッチは、実物では曲げた針金でできていて、ボールが通過すると沈むようになっているのですが、ファイアボールではこの動きを2パターンで再現しています。

右上にあるスピナーはいわば苦肉の策で、最初は縦方向に回転する普通のタイプにしたかったのですが、うまくグラフィック的に表現できなかったため、試しに横回転するものにしてみたところ、思いのほかそれらしく動くものができてしまったのです。このスピナーの回転はボールの速度と完全にシンクロしていますが、じつは偶然の産物で、適当にパラメータを設定したらピタリ合ってしまった、という話もあります（このソフトを作っている間にはこうしたことが結構多くありました）。

ボールやフリッパーを含めた動くパーツの描き込みは全体処理速度を上げるために全てサブCPUで行っています（メインサブ同時実行）。メインルーチンは基本的にボールの位置計算に専念しており、何回か位置計算を行ったのちに表示座標系に変換してサブ側にその座標を渡します。サブ側では自前の専用表示ルーチンが走っており、ディスプレイサブシステムとして、メインからの情報（ボールの座標と表示すべき役モノのパーツ番号）を受け取って表示しにかかるわけです。このあたりはマシンのオーバーヘッドを最小限に抑えるため、MMRは使わずにFM-7と同じようなモードで動作させています。

この他ファイアボールの特徴に一つに、ハードウェア縦スクロールをうまく利用した点が挙げられます。最初、遠近表示ゆえに表示できないハイスコアやプレーヤ数などを、トップパネルとして見せることで、実物に立ち戻ったスタイルで表現できると考えたのですが、台揺すりのところで使えば面白い効果が得られることに気づき、組み込んでみたのです（やってみればコロンブスの卵ですが）。

さらに、台の下の手前のほうを、オープニングのところで見せたらもっと面白いのではないかとデザイン担当者に提案したら、そのとおりの絵を作ってくれたという訳です。遊んでいる盤ごとピンボールマシン全体が見えるビデオピンボールなどというのは、今日に至ってもそうはないのではないでしょうか（そんなことにこだわる物好きは私だけかも知れませんが）。

次なる問題は、ピンボールの盤面を作るためのツールでした。特にグラフィックエディタは、何かしっかりしたものが要ると考えていたのですが、ゲームのシステムに合ったものを入手することは非現実的でした。結局、私は自分で以下のようなツールを作り上げることになりました。

• ビットマップエディタ
  最初の盤面レイアウトだけを作るためのツールで、ライン、サークル、ペイント、ビット単位のセットリセットがあるだけの簡単なものです。
• バイトマップジェネレータ
  ビットマップをもとに、各マスの法線角度を自動計算して与えるものです。一つのビットについて、その回りにあるビットの状態から30角形のどれに当たるかをとりあえず計算して、マップ化するプログラムです。一つ一つを手でやっていたのではたまらないので、自動生成するようにしました。
• バイトマップエディタ
  ジェネレータが作るバイトマップは荒い角度でしかないため、そのままでは使い物になりません。試しにボールを転がしてみましたが、ガタガタでお話になりませんでした。そこで各々のマスの角度を確認しながら手で調整し、役物のフラグも与えていく、最終的なゲーム盤を作るためのエディタが必要になります。
  機能としては、画面の半分にマップ全体を表示してマスごとに動くカーソルを置き、角度情報を視覚的に把握できるよう、カーソルのあるマスの角度を円の中に表示するようになっていました。バイトマップそのものは裏RAMに展開し、直接FDにロードセーブできるようにしていました。
• グラフィックデータジェネレータ
  ビットマップから遠近表示のイメージデータを作る簡単なプログラムです。このプログラムを実行すると、向こうのほうから無地のピンボール台がおもむろに3D表示で現れてきます。ボールの重ね合わせ表示に対応するため、ボールの向こうになる盤面と壁面、ボールの手前にくる上面は別々のパレットで描くようにしていました。
• グラフィックデータエディタ
  遠近表示のイメージデータに実際の絵を載せるツールです。単に絵を描けるだけでは不足で、重ね合わせ表示に対応したパレットで絵を描ける必要がありました。またデザイナーに使ってもらうため、操作をわかりやすくして、色を細かく調整できる必要がありました。じつはFM-7を買った頃に自力でグラフィックエディタまがいを作っていたことがあって、その経験が活きました。パレットテーブルをポップアップウインドウで呼びだせるようなシステムにしましたので、それだけで結構なプログラムでした。これらは全てFM77AV本体で動くもので、F-BASIC V3.0+マシン語という構成で作りました。

これらのツールを作りながら思ったことは、たぶんビル・バッジも同じようなことをやっていて、それならいっそこれら自体を商品化してしまえばよい、と思ったのではなかろうか、ということです。実際、自分でもコンストラクションをリリースすることが頭をよぎりましたが、結局やめました。3Dにするための手続きがやたらと煩雑で、簡単にはできそうにも無いのと、ハイスコアコンテストをやろうと思っていたので、ずるができないようにしておく必要があったためです。

ただし、ボーナス機能としてパラメータを少しばかり調整する機能は残しておくことにしました。これはAppleⅡ用の名作A2-PB1 Night Missonがその機能を持っていて、非常に面白かったからです。といってもあくまでボーナスであって、セールスポイントにする気はなかったので、簡単には起動できないようにしました。

じつはロックンローラーのスイッチボックスを接続し、ゲームスタートの前にどちらかのキーを8回連続して叩くと設定画面が立ちあがるようになっているのですが、あまりにも条件が厳しすぎてたどり着いた人がいたかどうかは不明です。この記述を読んで今からでも試そうという奇特な方がいらっしゃいましたら、どうぞやってみてください。（管理人註*2）

ファイアボールのネーミングは、開発の中でもっとも苦々しい思い出なのですが、Laverさんの紹介コメントで触れられているので、簡単にご紹介しましょう。

ネーミングについては私は結構こだわるほうで、とにかく自分で名前をつけたくて仕方ありませんでした。「トリガーハピー」というのは、割りと最初から考えていた名前で、当時よく読んでいた平井和正の小説の中で、トリガーを引くことが病的に好きな発砲マニアのことを指すと書かれていたところから来ています。私としては、とにかくフリッパーから手が離せないほどのめり込んで欲しい、ということでこの名前を考えていました。

ところがハミングバードソフトのほうでは、広告の締め切りに間に合わないとかで、私に相談せず、名前を勝手にデザイナーと相談してティップトップと付けて、広告に出してしまったのです（ちなみにティップトップというのは、デザイナーがモチーフにしたビリヤードの用語なのですが、語感がポップ過ぎて使う気になれませんでした。私はもっと凄みのある名前にしたかったのです）。

あとで知らされて、怒りのあまり「もうやめる、出さない」と言ったところ、それは困るが、ティップトップの名前を全く取り下げることは出来ないし、トリガーハピーの名前は良くないと思うので、もう一度名前の候補を出してくれたら、全員の投票で決めなおそう、と説得され、10以上も候補を出した結果、ファイアボールの名前が残ったという訳です。「ファイアボール」は当時これまた気に入っていた大友克洋のSFコミックのタイトルからとったもので、特にゲーム自体とテーマ的に関連がある訳ではなく、主に語感でボールの付くものとして挙げてみただけです。

オリジナルはファイヤーボールだったような気がしますが、「ヤ」は語感的に好きでなく、伸ばすと間が抜けるような気がしたので、今のようにしました。ティップトップの名前は、「ティップトップピンボール」という形で残したほか、ハイスコアコンテストの方をティップトップコンテストというタイトルにして活かすようにしました。

そのほか、マニュアルの原稿は全て自分で作りました。役モノの名前は良くわからなかったので、適当に付けました。扉に「Bill Budgeに捧ぐ」という意味の献辞を入れたのですが、肝心の名前のつづりを間違えてしまい、大変恥ずかしいというか申し訳ないことをしました。

パッケージの絵はデザイナーが一晩徹夜して作ったもので、少しばかりチープなのですが、時間の無いところを良くがんばってくれたと思います。ちなみにこの絵をモチーフにしたテレカも作ったのですが、さてどうなったのやら。

ファイアボールはMSX2へも移植されましたが、これはハミングバードソフトが外注でさせたもので、私はタッチしていません。一応、内部アルゴリズム（技術資料）、ソースリスト、グラフィックデータなど、キモになるところは全て提供しましたので、基本的には同じソフトになっているはずです。先方からは、こうしたソフトとしてはよく資料が揃っている、とコメントがあったそうです（ソースだけのところが殆どだったとか）。私はプレイしていないのでわからないのですが、それほど悪い出来ではなかったと聞いています。

このほか関連するソフトとして、ログインのプログラムオリンピックに出した二つの作品（管理人註*3）があります。もともとロハで提供するという虫の良い企画ですので、ハミングバードソフトからも「時間をかけずに適当なものでいいよ」と言われており、こんなものでいいのかなと思いつつ、せっかくなので、それなりに遊べるものを作った憶えがあります。

Laverさんがコメントされていたように、ハミングボールはボール運動ルーチンの基礎検討の途中に作ったもので、まだフリッパーが開発できていなかった頃、試作ルーチンをベースに作りました。ボール以外の部分はFMの標準ディスプレィサブシステムを直接コールして描いています。

ライズのほうは、ファイアボールの資産を活かしてでっち上げたもので、衝突アルゴリズムも完成していましたので、グラフィックや操作方法にも凝ってみました。出来ればパドルをアナログ入力で動かしたかったのですが、加速するということで折り合いました（やたらと難しいゲームになってしまいましたが）。タイトルは私が好きだったハーブ・アルパートの「RISE」からもらいました。