-
- いいね！213
S.F.
@SFPGMR
この基板は当時にしては珍しいHW回転機能を持つBGを持っていた。さらにスプライトも回転・拡大・縮小が可能、1キャラクタの大きさも128x128まで可能というとんでもない代物だった。
2020-06-05 22:05:53
S.F.
@SFPGMR
シンセおたくの血が騒ぎますな。BGMを担当した人は相当ゲーム・ミュージック界では有名な人だった。当時は知らんかったが。その後このゲームは「BGMだけはすごい」と言われるようになる（笑）
2020-06-05 22:10:51
S.F.
@SFPGMR
そうして本格的にゲームつくりが始まったわけだが、その前に企画書というのをチームでまとめなければならない。これは主にメイン・プログラマとメインのデザイナーあたりが中心になって、MTGで内容を決めていたよな気もするが、なぜかこのあたりの記憶が希薄で思い出せないんだよな。
2020-06-05 22:13:10
S.F.
@SFPGMR
私は新しい基板で雑魚敵の移動の仕組みを作り始めた。その仕組みというのはスピードXXでYYだけ移動して、そこで弾を売ったら右に離脱みたいなフローをデータにするとそれに沿って動くような感じのものだった。そしてこれを完成させるころに体調を崩してしまった。
2020-06-05 22:17:31
S.F.
@SFPGMR
そして体調を崩している間は、これまた某コミカルシューティングをヒットさせた上司が代わりに雑魚敵の配置をやってくれていた。1週間ほど休んで復帰して戻った時にはほぼ雑魚敵の動きはできていて、コツみたいなものも私に教えてくれた。これは目から鱗だったな。
2020-06-05 22:21:10
S.F.
@SFPGMR
私はarctanによる方向検知を知ってうれしすぎて、これを使用した追尾弾を発射する敵を量産した。結果各ステージのあちこちで粘着気味な追尾弾が登場することとなった（笑）
2020-06-05 22:25:18
S.F.
@SFPGMR
そういう感じで日々勉強・吸収しながら作っていったので当然粗さやバグも少し目立つものになった。その中でちょっとまずいと思ったのは当たり判定だった。
2020-06-05 22:28:52
S.F.
@SFPGMR
当時は自機のショットもかなり高速なのがトレンドであったので、敵をすり抜けるようなケースが出てきた。弾の1フレームあたりの移動距離が大きすぎてすり抜けてしまうのである。
2020-06-05 22:31:07
S.F.
@SFPGMR
これを解消するには自機弾の1フレームの移動距離を自機弾の当たり範囲に加えればい。こうするとすり抜けは発生しない。当時のこのことが思い浮かばなかった。どうしたかというと敵の当たり範囲を大きくした（笑）
2020-06-05 22:33:59
S.F.
@SFPGMR
敵の当たり範囲を大きくすると自機が当たっていないように見える（実際当たっていない）のに死んでしまうということが起こってしまう。そこでどうしたかというと自機のあたり範囲を小さくした（笑）
2020-06-05 22:35:51
S.F.
@SFPGMR
R-TYPEは自機の当たり範囲が 1x1 pixelだというのは有名な話だが、あれはきちんとゲームデザインを考えての結果だと思う。私の場合は突然死を防ぐためにやった（笑）
2020-06-05 22:39:46
S.F.
@SFPGMR
その独特な当たり判定は結果的に功を奏するはずもなく（笑）、「突然死がちょくちょく発生するゲーム」という汚名を着せられることになるのである（笑）
2020-06-05 22:43:23
S.F.
@SFPGMR
こういう基本的なところにぬかりというか稚拙な部分があると、ゲーム内容に矛盾というかおかしなところが出てきて、その辻褄を合わせるためにまたおかしな工夫をしてしまうような感じになるよね。どんどんゲームとはおかしく、つまらなくなっていってしまう。
2020-06-06 05:04:54
S.F.
@SFPGMR
グラフィックやサウンドやブランド力である程度の量は流通するし、実際この１作目のゲームも結果としてはまあまあだった。でもやっぱりねえ、そういう詰めの甘さを作品に残すというのはねえ。ちょっと後悔するよねえ。今でも。
2020-06-06 05:08:43
S.F.
@SFPGMR
ゲーム・プロジェクトの開発期間やリリース日程は決まっている。よって時間との戦いがある。自分の能力や知識以上のことをやるためには学習・トレーニングに時間を費やす必要がある。その間も刻々とリリース日が迫ってくる。
2020-06-06 06:49:14
S.F.
@SFPGMR
現状とあるべき姿とのギャップが発生して、「現状はここまで」というところで落ち着くんだけど、それはそのままゲームの品質に反映されてしまう。良ゲームを出すクリエイターの方たちはその点が平均して高い位置にあるんだよな。
2020-06-06 06:54:14
S.F.
@SFPGMR
まあそういうわけで締め切りギリギリまで粘るんだけど、やっぱり取り切れないバグも出るし、2日くらい睡眠時間がほぼない生活をすると「もうこれでいいかな..」となってしまうんだよなぁ。「些細なバグをとるか」「面白い要素を一つでも入れ込むか」の二択を迫られたら、私は後者を選んでしまう。
2020-06-06 06:57:21
S.F.
@SFPGMR
私の能力がヘボいというのは認めるとして。当時のゲーム基板はグラフィック能力に比してそれを制御するCPU側の非力な面が目立ったということ。今もそういう状況なのかもしれんが。
2020-06-06 07:01:37
S.F.
@SFPGMR
メモリという観点でもそうかなあ。その能力を生かすにはかなりのROMが必要だったんだけど、全然足りなくてね。例えば大きなスプライトをバンバン使いたいんだけどメモリの関係で我慢せざるを得なくなったりとかね。
2020-06-06 07:03:48
S.F.
@SFPGMR
最後の方になってくると「それはいいと思うけど、もうオブジェ（スプライト）を収めるメモリがないんだよなあ。。」とかなって、パレットを変えて違う敵に見せたりとかしてたね。。
2020-06-06 07:05:19
S.F.
@SFPGMR
ある時評価室にセガのアフターバーナーが入ってきて。このゲーム、ポリゴンではなくてスプライトの拡大縮小で３Dを表現するというもので。当時はまだポリゴンベースのゲームはまったくなかった時代。ポリゴンベースなやつはおそらくナムコのウィニング・ランだったと思うが、それはかなり後。
2020-06-06 07:09:09
S.F.
@SFPGMR
このゲームはどうなっているんだというくらいたくさんのスプライトを使って3D画面を構成する。ビルボード・３Dグラフィックスの極みともいえる（笑）この路線は「アウト・ラン」とか「スペース・ハリアー」とかその流れですわな。フレーム・バッファ方式とかいってたっけかなあ。。
2020-06-06 07:14:33
S.F.
@SFPGMR
画面見てスプライトの座標計算は3Dでやって、スプライトの優先はZ座標でやるのかなあと思ったね。それにしてもむちゃくちゃスプライト出るなあという。むむう。これはすごいと。しかしキャラクタ１つ1つ見ると意外にメモリで苦労してるのかなあ。。と思ったね。。
2020-06-06 07:25:34