EXCEEDの同人ソフト開発日記という名の備忘録

趣味のゲームソフト開発人。プロなのかアマなのかは不明(不定)らしい。

任天堂のソフトはいつも予定通りに出てこないって言われるけど、
ソフト作りっていうのは、そういうもの。
ゲームソフトは、期限までにやれと言われて、徹夜したり死に物狂いでやったからといって、
期待通りのものにはならない。そういうふうにすると、
結局、チームは妥協しなければならなくなる。
妥協させられて、できたものは、粗くなってしまう。
ユーザーは目が肥えていますから、受け付けてもらえない

山内 薄

ファランクス

ウチのブログ的にも、これも語らないと。

1991年に X68000 で発売された横シューティングゲームファランクス」が Wiiウェア用ソフトとして復刻され、12月22日から500ポイントでダウンロード可能になったので、早速ダウンロードしてみた。

http://www.zoom-inc.co.jp/wii/phalanx/index.html

実は、私自身 X68000ユーザーになったのがX68000後期の頃だったので、このゲームはリアルタイムで遊んでいたわけではなく、数年前にズーム社が自社ホームページ内で過去作品の無償ダウンロードサービスを行っていた際にダウンロードして遊んだことしかなかったりするので、あまりプレイ時間は長くないのだが、それでも気付いた点を幾つかあげてみたいと思う。

結論としては、良くも悪くも「別物」500円なら間違いなく買い。

個人的に残念だったのが、ファランクスを象徴している演出が再現されていなかったこと。たとえば、1面の後半の焼け野原の大地がラスタースクロールしないとか、2面の水中もラスタースクロールしないのは残念だったと思う。とくに1面後半の焼け野原の大地は、X68000版では、物言わぬ「争いの壮絶さ」をラスタースクロール+装飾スプライトを使って効果的に表現していた(と私は思う)。とくに、焼け出された鉄塔(ビル?)がさりげなく立っている辺りが、大変いい味を出していたのに、ラスター再現を削った弊害でそれらも同時に再現不可能になり、とても残念。

私はWiiでの開発経験がないので、もしかしたら無茶なことを言っているのかもしれないが、すだれ状のテクスチャを縦に並べるだけで再現できると思うし、おそらく Wiiの描画能力的にもファランクスの1面程度のものであれば、60fps は余裕だと思うのだが、実際はどうなのだろう?

あと気になった点は、やっぱり音楽。個々の好みの問題があるので、一概に良い悪いは判断できないとは思うが、個人的には、原作のFM音源のBGMをベタ流しして欲しかった。Wii版は聴いた所、ローランドの MT-32 っぽい音をしているが、よく聴くとそうでは無さそうなので、BGMは Wii版用に作り直しをしているようだ。(譜面自体はX68000版と同じ)

X68000版はハードウェアの ADPCM1音という制約上、ファランクスの場合はとくにドラムパートの欠落が顕著という止むを得ない事情があったが、Wiiであれば、そういう問題は起こるはずがないので、ドラムパートが欠落しないベタ録のFM音源+ADPCMのBGMを密かに期待していただけに残念。(ちなみに、X68000版は PCM8に対応するパッチがあったらしい)

また、今回、「Wiiモード」と「X68モード」という2種類のゲームモードがあるが、これらモードの違いが想像していたものと全く異なっており、「Wiiモード」を選択すると、一部のキャラがコミカルキャラになったり、ステージ開始時に「おやじギャグ」が出たりするというシロモノだったりする。個人的には、Wiiモードにすると、当時ソフトウェアでごり押しで再現していた回転拡大縮小が、ハードウェアアクセラレーションで滑らかになったり、新しい武器が出たり、理不尽だった敵配置が修正されたりするのかと思っていた。これだったら、初めから「コミカルモード」「オリジナルモード」としておいた方が期待を裏切らなくてよかったのでは?と思った。

それとどうでもいいことかもしれないが、CEROのセクシャル判定に該当するような演出が削除されていた。(ネタバレにつき詳細は記載しない。)

ただ、悪い点ばかりでもなく、良くなった点も多々ある。たとえば、X68000版に比べて、敵弾やキャラクターが見やすくなっている。X68000版はキャラクターが背景に対してカメレオン状態な配色だったため、とくに敵弾が見づらく、何時の間にかミスしているということが多々あった。

他には当然ながら、当時、ソフトウェアでごり押しで再現していた回転拡大縮小が、スムーズに表現されていて、おそらく当時の開発者は、こういうことをしたかったんだろうなぁ・・・としみじみ思った。(もちろん、当時のゴリ押しエフェクトも最高に輝いていたと思う。)

それで最大の改良点と言えると思うが、理不尽な敵の配置や攻撃が緩和(見直されて)おり、他にもボスや中ボスなどにダメージを与えるとその箇所がフラッシュするように変更されていて、ダメージを与えているかどうかが視覚的にわかるのようになっており、こういう細やかな気遣いがとても好感が持てた。


ちなみに、128bit X68090 SHARP の広告はそのまま残っていた(笑)

乱数発生器(ルーチン)を発見。もちろん元コードは 6502 で書かれているため、それを 680x0 にコンバートしないといけないわけだが、ここで問題が・・・

端的に言うと、「不定期な割り込みが発生した際、その時の CPU レジスタ値とキャリーフラグを種として保存し、実際に乱数値を得る時には、さらにその時点でのキャリーフラグを混ぜて使う」という風になっている。そのため割り込み発生時のキャリーを種に使うという時点で、同じアルゴリズムを採用することは厳密には不可能に等しいが、幸いにもこの乱数発生器は「ゲーム開始直後の最初のステージをサイコロを振って決める」という用途でしか使用していなかったため、それほど拘る必要もないのかもしれないが、例えば乱数発生器の再現度がシステムを大きく左右するようなゲームの場合(ドルアーガの塔の扉や鍵の位置など)他所様はどうしてるんだろう・・・とか、ふと思った(ぉ

良い意味で笑った

EXCEED2009-11-27



表示遅延フレーム数を設定します。

この値が大きいほど、操作入力が画面に反映されるまでの
時間のずれ(遅延)が大きくなります。

1V(Fast)は今作のデフォルト値になります。
移植元となるアーケード基板に比べて、ほんの僅かながら
遅延が軽減されており、反応速度が上がっています。

2V(PCB)は、基板とほぼ同等程度の遅延になる設定です。
アーケード版とのより高い互換性を期待する場合には、
こちらの設定と1V(Fast)を比較してみて
ご自身の感覚に合う方を選択して下さい。

0V(Tearing)は、最も遅延を軽減できる設定です。
しかし、代償として画面に「ティアリング」と呼ばれる
ちらついた感じのノイズが発生してしまいます。

3V(Slow)は、基板に比べ遅延を増やした設定となります。
遅延の体感用であり、常用はお勧めしません。

ここの所、作る方に回りすぎなので一息入れる意味で他所のゲームをプレイ。

実はこの「虫姫さま」アーケードで稼動しているところを目撃したことが一度も無く、「魂斗羅」と同様に私的「本当に稼動していたのか?」ゲームで正直な所、購入予定は無かったのだが、移植担当がエムツーとのことで通販予約しておいたのだが(自分でも購入動機が根本的におかしい気がする・・・)失礼ながら、発売日のことをすっかり忘れていて、宅配便が届いてその箱を開けて初めて気付いたという始末。
(余談ではあるが、知り合いのゲーセン店員(だった人)の話では、当時インカムがあまりにも悪く、登場後一週間以内には撤去されてしまったとか・・・)

そのような訳で、原作のプレイ経験がない上に、そもそも弾幕シューティングにおいて移植版とオリジナル版の違いが分かってしまう程のプレイ技能を持ち合わせてはいないので、なんともいえないのだが、おそらく移植度は高いんだと思う。
勝手な想像ではあるが、元の基板は SH3 133MHz というかなりオーバースペックな仕様らしいので、従来のCAVE/PGM基板と違い、オリジナルソースの方で処理落ちは故意に起こしていると思われる。よって全一レベルのプレイヤーでも納得な移植度なんじゃないかなぁ・・・とも思う。

というか、データロードがかなり速いし、オプションメニューのマニアック度合いが普通じゃないとか(16:10の画面モードや、遅延入力設定、15KHzモニタの擬似再現モードまである)丁寧過ぎる作りがエムツーらしい。

それで、肝心のゲームは意外にも「弾銃フィーバロン」のようなプレイ感覚。せっかくなら「フィーバロン2」として、1990年代のディスコをモチーフにして、BGMはもろ「作戦名ラグナロク」な作品にして欲しかった気がする(笑)

ちなみに、チーフプログラマーの一人に、「けんじょさん」がいらっしゃる模様。間接的に毎日大変お世話になっております。


そういえば、発売前にアマゾンから来た予約開始のお知らせメールには呆れ果ててモノが言えなかったよ・・・・(苦笑)

6502エミュ一段落

Windows用の 6502エミュレータが一段落。これから X68030版の制作に移ることになるが、今回は plastic神の技術サポートと、このWindows用エミュの先行開発のお陰で、思いのほかスムーズに開発が進む予感。

良い意味で予想外だったのは、Windowsで作成したエミュレータ上でブレークポイントやウォッチポイントを仕掛けて内部動作を追う際、エミュレータ自身は完全に自作なもののため、中身も当然自分で全部把握している訳で、例えば


ある開始アドレスからある終了アドレスに、0x03 以外の書き込みがあったあと、5フレーム後の V-BLANK が来た瞬間にブレークをかける

のようなことが、エミュレータ側のコアをちょっと書き換えるだけで容易に実現できるため、普通のデバッガ以上の柔軟なデバッグが可能だったこと。

今度からは、X68000に移植する際は、一度 Windowsエミュレータを作成してから、移植開始した方が結果として、大幅に開発時間を削減できそうだ。