◆移植できず・・・

　実はこのゲームに出てくる２面のボスキャラはタイトーのシューティングゲーム「DARIUS」のものです。なぜ、そんなキャラクタがでてくるかというと、昔I/Oという雑誌で「DARIUS移植したら１００万円」というコンテスト（？）があったのです。で、欲に目がくらんで（笑）、資料を請求したのですが・・・。送られてきた資料を見て驚き桃の木三しょうの木、ブリキに狸に洗濯機。ただのキャラクタの図だけ。こりゃ、ひどいと思いました。こんなイラスト（ドット絵ですらない）だけで移植してみろというわけです。仕方がないので私は自分でいろいろ調べました。いまだに、その資料は残っていますが。
　で結局メモリの都合上、断念してしまったのですが、ボスキャラは描いてあったので、もったいないなあと思い、このゲームに登場してもらったというわけです。攻撃方法もまったくおなじです（いや〜ばれなくてよかった＾＾；）。←（TAITO、DARIUS 24体戦えますか事件以来、非常に危険なのだ。こんな所でバラしてもわからないはず・・・う〜むぅ）

◆XEVIOUS, FantasyZone, Space Harrierそして・・・

　移植したゲームもあれば、それらしきものを作ったりしてきましたが、このSIDE ROLL -F-も、某ゲームの影響があります。そのゲームの名は「R-TYPE」というアイレムのシューティングゲームです。
　よって出てくるものは巨大戦艦とか、自機についているビット（グラディウスのオプションのようなもの）とか、迷路のような所とか、もろもろ。とにかく詰め込むだけ詰め込んだシューティングゲームといってもいいくらいです。自機の装備は左右または前方に移動させる事ができるSRFというオプション、そして通常のショット（３連射）、SRFから発射されるレーザーとなっています。敵を倒したりすると、ランダムにパワーアップアイテムやボーナスアイテムが現われます。これを取るとレーザーが長くなったり、ボーナス得点が入ったりします。

◆System-7Bと同時進行

　このゲームはMZ-700用ゲームシステム「System-7B」と同時進行で作られました。System-7Bに入れたほうがよさそうなものは、System-7Bに移動させ、そうでないものは逆に持ってきたり試行錯誤していました。おまけに最後の段階になってMacIIのおかげで（FirstRoad / System-7Bの項目参照）、呼びだしアドレスが変わったり最後の最後まで調整していました。さらに、System-7Bにこういう機能もあるよと宣伝もしないといけないわけでタイトル画面のFの文字の拡大縮小は、そのために存在していたりします。

◆BGMがない・・・

　このゲームはBGMがありません。というのも、作る人が近くにいなくなった、というのがその理由です。以前、SB/FZの曲を作ってくれた塚田君は高校の同級生だったのですが、SB/SG制作の頃には２人とも別々の会社に勤めていました。社会人になると結構出会う時間が少なくなるものです。某事件後、何年間も音沙汰なしといった状況でした。
　MZ-700からMacでゲームを作るようになって、西尾さんという方と出会い曲を作ってもらっています。そのうちDungeonStreet IIのBGMも作ってくれるはずですが（＾＾；

◆個人制作と団体制作

　高校や大学の仲間が集まってゲームなどを作るのは、今では珍しい事ではありません。個人で作る人もいれば団体で作る人もいます。私の場合は、今になっても「個人」で作っているといった状況です。西尾さんと私の２人で電話やメールでやりとりしつつ作っているわけです。個人で作るいい所は、デザインからプログラム、キャラクタや背景、BGMまで思いのまま（実力によりけりですが）にできる事でしょう。しかし、大抵裏目に出てしまう事が多く、特に「ひとりよがり」なものになってしまいます。こういう場合は「移植」ものの方が、かえっていいのかもしれません。

◆おわりに

　MZ-700用シューティングゲームは、このゲームが最後となってしまいました。とかく入れるだけ入れてしまって、やる事がなくなってしまったからかもしれません。この後はEyelarthやEugeaなど、今まで挑戦したことのなかったジャンルをめざす事になりました。
　同じジャンルのものばかり作っていると、飽きてしまうというのもあります（私は結構飽きっぽい方なんです・・・）。

◆プログラム的なこと、スクロールの技

　スクロールゲームもたくさん制作するとノウハウがたまります。このゲームの段階では背景用に仮想画面を使用する事がなくなってしまいました。どういう事かというと、今までは次のようにして背景をスクロールさせていました。





●その１
（１）背景用仮想画面をスクロール
（２）スクロールブロックカウンタが０になったら次の背景を書き込む
（３）背景を合成用仮想画面に転送

●その２
（１）背景用画面に両端がうまくつがるように背景を描いておく
（２）スクロールカウンタに応じて背景の転送位置をずらして合成用仮想画面に転送

その２は、その１と比べて１回背景をスクロールさせる手間がなくなるため高速化する事ができます。が、その２を改良すると「背景用仮想画面」が不要な事に気付きます。つまり背景のブロックを、縦長にしておきそれをタイルのように合成用画面にはりつけます。スクロールカウンタに応じて合成用仮想画面に描画する背景ブロックのX座標を変更すれば、ちゃんとスクロールしているように見えるというわけです。が、この時点では同じ背景をはりこむ事しか考えていませんでした。これが、最後のスクロールゲームである「EUGEA」になると、異なるブロックを配置し、さらに３重スクロールまでこなしてしまうという無茶な領域にまで踏み込んでいきました（速度も速くなっている）。
　スクロールカウンタについて補足しておきます。スクロールカウンタは、２のn乗にしておくのが便利です。私の場合は８か１６にして使っていました。これは、８だとか１６だと非常に都合がいいからです。特にスクロールカウンタを減算していき０未満になったら７に戻すなどの条件判断が不要だからです。つまり以下のプログラムは等価（結果が同じ）という事です。スクロールカウンタは８としています（０から７まで変化し、７、６、５、４、３、２、１、０のように減算されます）。

●その１
　count = count - 1
　if count < 0 then count = 7

●その２
　count = ( count - 1 ) AND 7

　つまり、その２で「論理演算」を行って条件判断を減らしているわけです。当然速度も速くなりますし、プログラムもシンプルになります。