Google Chrome または Safari を使用される事を強くお薦めしますw
他のブラウザでは Javascript の処理が重いです(汗)


2024/02/28

川の流れのように2

キャラクターだけ作ってみた。



実機ではボート(自機)の緑と赤が入れ替わっているバージョンもあるので、色は後で変更するかもしれない。

2024/02/22

川の流れのように

 1981年にオルカからリリースされたリバーパトロール。


このゲーム大好きだった。

船底に穴が空いていて浸水しているボートを駆って川を上っていく。
浸水しているということはもたもたしていると沈んでしまう、ということで要するに制限時間内にゴールしろということ。
画面一番左にある黄色いバーが浸水量(=残り時間)を示している。
その隣の赤いバーがゴールまでの距離を示している。

操作性が独特で、ボタンを押している間は前進し、ボタンを離すと下に流される。
舵は前進している時(ボタンを押している時)にしか効かない。

ボタンを離すと加速は止まるが、しばらくは慣性で前進する。
このため、危ないと思ってボタンを離しても止まらずに岩などにぶつかって沈んでしまう。

この辺のクセのようなものを掴むと、この操作がとても楽しくなるんである。
逆に言うと操作が難しくて面白くないと感じる人も多く、人を選ぶゲームだった。

上流から流れてくる流木やドラム缶にぶつかったり、岩にぶつかったりすると沈没する。
またワニにぶつかると沈没はしないが浸水量が増える(残り時間が減る)。


溺れている人も流されて来る。救助すると得点になるが、救助せずに見捨てても得点にならないだけでペナルティはない。
これだけでも非情だが、溺れている人に船の切先を当てるとなんと殺してしまう(天使になって下流に流れていく)。
今なら完全にアウトやな。

面(Round)は99面あり、99面をクリアすると0面になる。
この0面は画面左右の表示がバグっているだけでなく、始まってすぐ全面壁になっていて先に進むことができずぶつかって沈没してしまう。


99面を超えるのは開発側の想定外であったのだろうが、おかしな挙動にはならず残機をすべて沈没させてゲームオーバーに持っていく処理だけは作ってあったようだ。

99面を超えて0面終了になるまでには1時間以上かかる。
「AJがリバーパトロールをやり始めると、その間ワシらはどんどん金を使う」
と当時一緒にゲーセンに行っていた友人に文句を言われたものだ。
ゲーセンのビデオゲームなんてものは普通は数分もあれば1ゲーム終わってしまうものなので、自分がリバーパトロールをやっている1時間の間に彼らはいくつものゲームをプレイして千円札を溶かしていたらしい。


懐かしのリバーパトロール。もう一度遊んでみたいものである。


というわけでとりあえずタイトル画面だけ作ってみた。


CORPORATIONの綴りが間違っているが、実機の通りにしている。

このゲームの基盤は大量にコピーされたらしいのだが、画面中央にシャチのマークのあるのが本物で、コピー版ではこのマークが無いらしい。
もちろん作るからには開発元に敬意を表してシャチマークは入れた。

ちなみにこの最後の自分で作った画面以外のスクリーンショットはネットから拾ってきたものであるが、すべてコピー版である。

2024/02/21

深く静かに潜航せよ

1979年にナムコがSUBMARINEというゲームをリリースしている。
すでにインベーダーやギャラクシアンなどが登場している年であるが、これはビデオゲームではなくエレメカのゲーム筐体なんである。


潜望鏡で覗いて、その先に見える艦船(の模型)に魚雷を当てるゲーム。

既にSEGAをはじめ他社から同じようなゲーム筐体は出ており、特に目新しさもないこんなゲームをなぜナムコはリリースしたのかよく分からない。

米Midway社のSea Wolf


SEGAのPERISCOPE
自分が幼い頃に大好きだったのは多分これ。
複数人が並んでやってた記憶があるので。

このナムコのSUBMARINEは残念ながら実機を見たことが無いのだけれど、他社より年代が新しく、また開発に3年かけたということなので演出や効果など何かそれなりに凝った部分があるのだと思う。
どこかの温泉地に生き残っているそうなので訪ねてみたいものである。

さて、このようなエレメカの魚雷戦ゲームをブラウザ上で再現できないものか、と思って試しに作ってみたのがこんなの。


外枠はゲーム筐体全体を正面から見た景色。ギャラリーが見ている風景と言っても良い。
中枠が潜望鏡から見た景色でプレイヤー視点。
左45度に振っているので背景の書き割りや海の手前部分が見切れてしまっている。
下部の赤い部分はスコアや残り時間を表示するエリア。

とりあえずWebGLとか使わなくてもDOMだけで作れそうなことは確認できた。




Xの悲劇13

ガルバーラ(大きい方のピラミッド)を破壊したときの赤点滅が4つあるうちの2つしか表示されなかった。

CSSで付けた影が下図のように点滅部分を隠していたため。


なので影を変形して点滅部分を覆わないように変更。


そして・・・

ようやく最高得点を達成!
マウス使用なのでチートではあるけれど。

本家とは異なりソルバルウの無限増殖はしないし、255の次に0に戻ることもない。


2024/02/20

マイコン刑事

こんな漫画があったのね。


PC-8001の本体だけ抱えて何をしようとしてるのだろ。


 

2024/02/09

Xの悲劇12

Area14のアンドア・ジェネシス出現前に現れるはずのブラグ・ザカート(ワープ出現して5発の弾を発射して消滅する黒い玉)が出たり出なかったりしてた。

ゼビウスでは1画面内に登場する空中キャラは6つまでという制限があるので、それに引っかかってる?と思ったが、他に何か飛んでるわけでもなかった。

で、コードを見直してみたら、出現確率が低く設定されてた。
出現確率が100%だとフレーム更新毎にキャラが出現することになるので低く抑えていたのをすっかり忘れていた。
そもそも確率で制御するのは間違ってるのだけれど(今回みたいに出現しないこともあるので)、処理が簡単なのでこのまま行く。

というわけでブラグ・ザカートの出現確率を少し上げておいた。



2024/02/07

Xの悲劇11

ゼビウスは当時としては画期的なリアルな配色で、それまでのゲームにはなかったメタリックなキャラの質感がとても良かったのだけれど、1歩進むと1つ新たな不満が出るのは世の常で、

「影が無いのは不自然」

と思ったものだった。

で、ふと「DOMでキャラ作ってるんだからCSSでなんとかできるんじゃ?」と考えて、やってみたらできた。


本家には無いことなので本当に蛇足なのであるが、捨てがたいので設定でON/OFFの切り替えができるようにした。


(2024/02/08 追記)
バーラとガルバーラ(ピラミッド型の地上キャラ)の影は三角形やろ、ということでこれもCSSで作った。

2024/02/06

Xの悲劇10

 スペシャルフラッグのX位置がおかしかった。

かにかにクラブ>ゼビウスによると、スペシャルフラッグのX位置はこの図のようにして決まる。


画面横軸をバイト単位(8で割った整数値)とし、ソルバルウの位置も端数切り捨てでバイト単位にする。その上でソルバルウの左端から左方向に7バイト、ソルバルウの右端から8バイトの範囲にはスペシャルフラッグは出現しない。

このロジックを組んではいたのだけれど、計算を行うタイミングがおかしかった。

上図にあるようにスペシャルフラッグ出現直前にこのロジックによってX位置を決めなければならないのに、なんとこの計算をエリア切り替え時に行っていた。
つまりエリア1であれば森からエリア1の下端が出現した時に既にスペシャルフラッグの位置を決めてしまっていたのだ。

あかんがな。

というわけで修正した。

左図:スペシャルフラッグ出現直前でソルバルウを右側にしておく
右図:スペシャルフラッグ位置はソルバルウの-7~+8の範囲を避けるので左側になる




2024/02/04

Xの悲劇9

ブラスター(地上攻撃)がボタンを押しても出ないことがあった。

ブラスターは元々連射できず、着弾するまでは次の弾が撃てないのだが、着弾した直後はすぐに次の弾が撃てなくて地上キャラを撃ったつもりが弾が出なくて撃ち漏らすということが結構あった。

おかしいなと思ってコードを見たら、

//着弾後すぐに次弾を撃てないようにする
if( m_nCount >= 24 ) {
    return false;
}

のコメントと着弾直後から0.4秒経過しないと次弾が打てなくなるコードが。

なんでこんな処理を入れたのかまったく記憶にない。
恐らくプレイ動画を検証していて次弾はすぐには撃てないのだと判断したのだろう。
でもたぶんこれは勘違い。
だって実機で次弾がすぐには撃てなくてイラッとした経験がないから。

なのでコメントとコードを削除した。
これで地上キャラの撃ち漏らしが減るはず。スペシャルフラッグも見つけやすいはず。


またアンドアジェネシスの4つの砲台(アルゴ)の当たり判定が厳しいようだったので、これも見直した。

>

当たり判定はかにかにクラブ>ゼビウスにある
この図を参考にしている(マゼンタで塗られた箇所にブラスターの照準の枠が入っていれば当たりとする)のだが、アルゴだけは何故か範囲を狭くしていた。

この図を見ても分かる通り、1Pと2Pでは当たり判定の場所が少し異なるのだが、1Pでしか遊べない作りなので2Pのことは気にしてない。

他にもアンドアジェネシスから逃げるブラグザが撃ててしまう不具合も見つけた。
点数は入らないが、アンドアジェネシスを倒したときに上方に逃げるブラグザが撃ててしまっていた。

他の敵キャラ同様に破壊可能のフラグを立ててしまっていたため。
シオナイトとかと同じように破壊不能に修正。

シオナイトと言えば、シオナイトがソルバルウにドッキング(?)しようとしたときに、マウスでひょいとソルバルウを上に動かすと、シオナイトがドッキング(?)できずにそのまま画面下方に去ってしまう、というものがある。


前のフレームのソルバルウのY座標と今のソルバルウのY座標が極端に違うとシオナイトが追いつけないため。
修正が面倒だし、キーボード操作ではそんなこと起こらないし、ちょっとおもしろいのでそのままにしておく。

それから本家の動画を改めて見ると、ソル出現時にも破壊音がしていたので、これも同じようにした。






2024/02/03

Xの悲劇8

 エリア14の1つ目のアンドアジェネシス出現前とエリア16の最後で出現するブラグザカートであるが、


ブラグザカート
ワープ出現して自機に向かって扇状に5発の弾を撃ち、その後消える

間違ってガルザカートを出現させてた。

ガルザカート
画面上方から高速にやってきて、全方向に32発の弾と4発の誘導弾を発射し、その後消える

エリア14やエリア16でガルザカートが連発して来て、こんなに難しかったっけとは思ってたのだけれど、今まで調べてなかった。
資料を確認したらここで出るのはガルザカートではなくブラグザカートだった。

めっちゃ鬼仕様になっとったwww

これは定数の定義名を紛らわしくしてしまったのがそもそもの誤り。

ブラグザカートは OBJECT_BZAKATO
ガルザカートは OBJECT_GZAKATO

そりゃ間違えるって。
今は修正済み。



2024/02/02

アルフォスを作りたい4

マップを作り始めた。
開始直後の1画面分だけ。スクロールはしない。


背景スクロールなんて、div要素にbackground-imageで背景画像を指定して、background-positionを変化させれば済む話で、ゼビウスではまさにそれをやっているのだけれど、これはアルフォス。PC88に画像ファイルを指定して表示させる機能なんてものはない。
Graphic-RAMにデータを転送し、データのビットが立っている部分が光る、それだけである。

左側の海岸線の部分を拡大するとこんな風。


データの0の箇所が青、1の箇所が黄色になっている。
背景に使用するのは1プレーンだけなので0か1かだけで背景を表現するのだ。

しかし、いくら0と1だけといってもマップ1つ分の背景データとなると膨大な量になる。
なので表示する単位を決め、様々なパターンを用意して、それを配置するのである。

いろんなスクリーンショットを見て回った所、32x2の単位でパターンが用意されているようだった。



上の2段のオレンジ枠の部分、3段目の白枠の部分、一番下の赤枠の部分の内容(ビットパターン)は同じである。

なので仮にオレンジ枠のデータをパターンA、白枠のデータをパターンB、赤枠の部分をパターンCとすると、この部分のマップは
A,A
A,A
B,B
C,C
と表現できる。
こうやってデータ量を減らしているのであるな。
なにせPC88などの8Bit機のメモリは全部で64Kバイトしかないのだ。キロやぞ。ギガでもメガでもない、キロ。
しかもシステムが使用していて使えない領域もあるから、実際使えるのは50Kバイトほど。
PC88の画面(Graphic-RAM)は640x200x3プレーンであるから、ここに画像を表示するためには48キロバイトが必要になる。
画像データ1枚だけで空きメモリがなくなる。

しかし、全パターンの洗い出し、どこにどのパターンが使われているかの調査、などなど考えると気が遠くなる。
完成できない気がしてきたw

ちなみにゼビウスの場合はこういう背景画像を貼り付けてスクロールさせている。

大きさは1024x2048、256色なので1ピクセルが1バイト。なのでデータサイズは2048Kバイト。







アルフォスを作りたい3

 文字を表示する画面だけ作った。





ここで「お?」と思うことあり。
プレイ画面の左端の黒い縦の帯である。


ただでさえ狭いPC88の画面なのに、なぜここに何も描画しないエリアがあるのか。

この黒帯の幅は32ピクセル。
はは~ん、なるほどね。
これも昔のパソコンゲームではよく使われていたテクニック。
この部分には実は何かが表示されているのだが、その上から黒い「■」の文字を書いてそれを隠しているに違いない。

PC88ではテキストを表示する領域(Text-RAM)はイメージを表示する領域(Graphic-RAM)とは独立していて、Text-RAMの方がGraphic-RAMより上にあるので、イメージは文字に隠されるのである。
文字は縦x横=8x8ピクセルなので、ここには横方向に4列、縦方向に25行黒い「■」が書かれているはず。

なぜここを隠すのかというと、ここを画面転送するイメージのバッファとして使用するためなのだ。
イメージデータをメモリからGraphic-RAMに転送するのは遅いので、表示速度が必要なイメージについてはこの隠した領域に予め描いておいて、それを見える領域にコピーするのである。
同じGraphic-RAM間の転送であれば処理は簡単で速いから。
例えばアドベンチャーゲームやRPGでは会話シーンで登場人物の瞬きや口の動きをアニメーションさせるためにこういうテクニックを使っていた。

アルフォスのキャラクタのほとんどは32x16ピクセルなので(前回記したようにピクセルは縦に長いので縦のピクセル数は少ない)、画面左端に幅32ピクセルの隠し領域を用意して、ここにイメージを配置していると思われる。
プログラムを解析したわけではないので想像でしかないが、恐らく自機(ニーモニック号)や発射する弾、敵キャラなど表示速度が要求されるものがここに描かれているはずである。
右側のスコアなど表示している部分も隙間の黒い部分には裏にキャラクタが描かれているかもしれない。

PC88の実機があればText-RAMを非表示にして化けの皮を剥がすことができるのだけれど、それは叶わないし、ブラウザで再現するにあたってこのテクニックを使う必要はたぶん無い。
でも、自己満足のためにわざとやるかもw
そもそも遊ぶのに何の得もないG外しをわざわざやってる時点で自己満足だし。


2024/02/01

アルフォスを作りたい2

フォントデータを作ってタイトル画面を再現してみた。


フォントは画像ではなく、指定した位置にピクセルがあるかどうかを1または0で表したデータを作って、それをプレーン毎に描画している。

一番上のタイトル「ALPHOS」、4行目の「NAMCO」、一番下の「ENIX」は文字が大きいが、これは小さい方のフォントを横方向に2倍に引き伸ばしている、いわゆる倍角である。

左がデータをそのまま表示したもの、右が左のデータを横に2倍にして表示したもの

こんな風にしてデータ量を抑える工夫をしていたのだな、という発見であった。

そして文字への色付けであるが、これは2プレーンを使ってタイルで表示している。


NAMCO の N の部分はこうなっている。黄色の部分はプレーン1に描いたもの、赤の部分はプレーン2に描いたものである。

パレットによる重ね合わせをするため使える色が黒、青、赤、黄色、白しかない状態なので、こうやってタイル(市松模様)にして他の色を表現しているのだ。

1文字に付き0と1の羅列のデータだけ持っておいて、大きさや色は表示するときに工夫する。昔のパソコンでは当たり前の技術だったのだと思うけれど、こうやって調べてみると味わい深いものがある。

なんでピクセルが縦長なのか、と思うかもしれないが、昔の8bitパソコンの多くは横の解像度(一般的に640ピクセル)に対して縦の解像度は低かった(一般的に200ピクセル)のである。
そのためピクセルが縦長になっている。
なのでブラウザ上で再現する際も縦は200pxとし、transform:scale(1,2)として縦に2倍に伸ばしている(厳密には2倍きっちりではなくて小数点以下の値が付くのだが、整数倍にした方がきれいに見えるのでそうしている)。

余談だがなんでナムコの商標が表示されているかというと、ゼビウスとは違ったゲームであるとは言え、「なにマネしとるんじゃ、ごるぁ」と言われないために一応許可を取ったということらしい。
アルフォスの開発にも販売にもナムコは一切関与していない。



アルフォスを作りたい

ゼビウスを作ったのでアルフォスも作っておこう、と思った。
あの天才森田和郎が初代PC-8801で作ったゼビウスもどきである。

ゼビウスのコードを流用して作ればサクッとできると思うけど、それじゃあつまらない。
あの天才森田和郎が、クソ遅い初代PC-8801でも遊ぶに足りる速度を確保するために考案したパレットによる重ね合わせ、その後多くのゲームがそのテクニックを真似た、所謂G外し(RGBの3枚のプレーン中、Gのプレーンを独立させる)をやってこそのアルフォスである。

遊ぶ側からしたらまったく意味はない。

というわけで各グラフィックプレーンに見立てた3つのcanvasを用意してみたのだけれど、canvasにパレットなんて概念は無いから(そりゃそうだ)、色数を犠牲にしてマスク処理を行わずに重ね合わせを行う、なんてことしなくてもcanvasが複数枚あるならその時点でもう重ね合わせはできてしまっている。

これではいかん。
ワシはG外しがしたいんじゃあ。

色々考えたけれど、各プレーンはメモリ上に仮想的に持つことにして、重ね合わせた結果をcanvasに反映させるくらいしか思いつかない。

メモリDCに描いておいて実DCにBitbltするようなものであるな。これでG外ししたことになるのだろうか。


ちょっと行き詰まってしまったので、とりあえず起動画面だけ作ってみた。
まだグラフィックは使用しておらずテキストのみである。


もちろんただの演出であって、88のBIOSも無ければBASICも走っていない。
しかも映るのはほんの一瞬だw
すぐに次の画面になる。


とりあえずここまで。






2024/01/27

Xの悲劇7

どうやらキーボードで操作する場合は

  X:ザッパー
  Z:ブラスター

というのが一般的らしい。

逆に設定していたのだけれど、自分は散々この逆の設定でテストしていたので今更変更するとプレイしにくい。

ということでこれも設定可能にした。


 

シャボン玉ゲーム

 今更ながらEscaping Bubbleでピンクシャボン玉が出にくいと感じたので出やすくした。


当時は結構すぐにピンクが出た記憶があるのだが、コードを見ると「こりゃ出にくいわな」と思えるものだった。

で、その後のUFOキャッチャーだが、これも当時は百発百中で掴めてたのに今やったらなかなかできんかったw

でもこちらは変更しない。
イライラするのがUFOキャッチャーの醍醐味やからね!(そうか?)

やりながら、全部UFOキャッチャーのゲームというのも面白いかもしれない、と思った。
まだアイデアが2個くらいしかないので、もっと溜まったら作るかも。

とりあえず久々に出会った小悪魔ちゃんであった。