相も変わらず寒い日が続いていますが、みなさんいかがお過ごしでしょうか。
体調管理しっかりしろよ、と会社でよく言われますが伝染病は自己管理だけではどうにもできないからなんか微妙ですよね。
ぶっちゃけ100人中100人がみんなウイルスを持っていないとは限らないし、無症状感染という状態がある事が分かってきた近代において、ウイルス蔓延をどうやって食い止めるかが焦点になってますね。
私は普段から他人と関わらないようにしているため、感染ルートはほぼ会社しかないんですが(^-^;
はい。そんなこんなで最近、ロックマン開発が旺盛に進んでおります(・∀・)
自分の思い通りのものが出来上がっていくのはすごく楽しいですよね。
一応コンセプトとしては、ファミコン版の初代ロックマンをWindows実行形式で遊べるようにしたもの、挙動などはメモリ解析して完全再現できるように仕上げていく、というものになります。
今のところは、基本的な動作が実装されていて、ファミコン版オリジナルでは見る事ができなかった8方向スクロール*1 も実装してしまいました。
これは以前から気になっていて、それをファミコンのソフトとして作る事はできそうな予感がしなかったために、現在のWindows環境のゲームとして構築するに至った経緯の一つでもあるのです。
ロックマンは基本的に横方向にエネルギー弾を飛ばす飛び道具が主流のアクションゲームです。
これを再現するためには、生成・参照・変更・削除ができるグラフィックとして定義する必要があります。
ファミコンの仕組みで言うと「スプライト」と呼ばれる仕組みがあり、それを使ってプレイヤーが自由に発射と被弾（消滅）を実現します。
一方で「BG」と呼ばれるグラフィックもあるのですが、これはアニメーションや座標変更ができなく動的なオブジェクトの描画には適していないのです。
まあそんな技術的な話は置いておいて、このスプライトテクスチャーの管理とか、全体通してのリソース管理方面がなかなかうまくいかなくて大変だった印象です。
実装自体はできるんですけど、モダンプログラミングの最適化というかOOD（オブジェクト指向設計）が難しい印象ですね。
動くんだけどそれって保守性とか再利用性とかが著しく損なわれてるよね？って話。
そんなコーディングをしてはダメです。
まあつまるところ、プログラミングというよりかはデザインの話になるので、これ以上は言わないですが。
（この手の話は過去記事でいっぱいしたし、なんか誰も読んでくれないみたいなのでf(￣▽￣;)）
動画の説明文にも書いたのですが、サウンドドライバーで同じチャンネルの音を同時に発音しないようにしました。
これはファミコンを実際にプレイしていた人たちなら知っている事かと思いますが、効果音（SE）が鳴っている時にBGMが変な状態になったりしますよね？
変な状態と言ったら壊れてるように言ってるみたいですがそういう意味ではなくて、BGMの音色が一部欠けてると思います。それの事です。
それはファミコンで使われる音源（チャンネル）で再生できる音が1つだけという制約から来ているもので、BGMで矩形波α/β、三角波δ、ノイズを使っている時に、矩形波αを使うSEを再生するとその時だけBGMの矩形波αの音が消えます（消えるというか再生できなくなるのです。SEがそこを使ってるから）。
この仕組みをそのまま再現しました、って事です。
ちなみにMegaMan Makerなど多くの巷に溢れているWindowsファンゲームではそれを行っている様子はないみたいです・・・
そもそもそんな事までしなくてもロックマンの魅力は十分伝わるとは思うのですが( *´艸｀)
ファミコンゲームで縦方向スクロールのゲームが少ない理由
厳密にはアクションゲームにおいて、の話です(^-^;
これについては実は私もよく知りません(笑)
そこで詳しい方に聞いてみたよ(・∀・)
ファミコンで縦スクロールのゲームが少ない理由について教えて🤔
(以下はMicrosoft 365 Copilotの回答です)
いい質問です 🤔
これはファミコンの構造そのものに由来する、かなり「ハード寄り」の理由があります。
結論を先に言うと：
縦スクロールが難しい理由は 「ネームテーブル配置」と「VRAM更新量」の問題が同時に襲ってくるから」
です。
順番にいきます。
1. ファミコンの背景は「ネームテーブル」でできている
ファミコンの背景画面は、タイル（8×8）を並べた
ネームテーブル（Name Table）というマップで管理されています。
1枚のネームテーブル
- サイズ：32×30タイル
- 解像度：256×240ピクセル
- ＝ 画面ちょうど1枚分
2. 問題①：ネームテーブルは「物理的に2枚しかない」
ここが最大の罠です。
本体にあるネームテーブル
- 実体としてあるのは 2枚分（2KB VRAM）だけ
- でも論理的には 4枚あるように見せる
[ NT0 ][ NT1 ]
[ NT2 ][ NT3 ] ← でも実体は2枚分しかない
どうしてるの？
- ミラーリングで誤魔化している
例：縦ミラー
NT0 = NT2
NT1 = NT3
例：横ミラー
NT0 = NT1
NT2 = NT3
3. 横スクロールが「楽」な理由
多くの横スクロールゲームは 縦ミラー を使います。
[ A ][ B ]
[ A ][ B ]
この配置のメリット
- 左右に進むと
👉 A → B → A → B と自然につながる - 下方向は基本スクロールしない
- 画面外（右端）に次の1列だけ描けばOK
✅ VRAM更新量が少ない
✅ 制御が単純
✅ CPUに優しい
だから
マリオは右に進むだけの構造になっているわけです。
4. 問題②：縦スクロールは「逃げ場がない」
縦スクロールをやろうとすると事情が一変します。
縦スクロールに必要なこと
- 画面の上下に新しい行（32タイル）を追加
- つまり 一気に32タイル分の書き換え
横スクロール
- 1列 = 30タイル前後
縦スクロール
- 1行 = 32タイル
量は似てますが、致命的な違いがあります。
5. 問題③：VRAMは「描画中に触れない」
ファミコンでは、
- VBlank（垂直帰線期間）
- 約 20 scanline分
- この間しかVRAMを書き換えられない
ここで問題
- 縦スクロールは
- ネームテーブル更新
- 属性テーブル更新（これが重い！）
- 1フレームでは足りないことが多い
👉 結果：
- スクロールがカクつく
- フレーム落ち
- 更新が間に合わない
6. 問題④：属性テーブルが縦に相性最悪
これ、地味だけど超重要です。
属性テーブルとは？
- 16×16ピクセル単位で色を指定
- 1バイトで 4ブロック分を管理
[ A ][ B ]
[ C ][ D ]
縦スクロールの地獄
- 新しい行を追加すると
- 既存の属性と食い違う
- 結果：
- 周囲の属性も巻き添えで更新
- 書き換え量が爆増
横スクロールだと：
- 影響範囲が比較的限定的
7. だから縦スクロールゲームは設計が特殊
この制約のせいで、縦スクロールゲームは工夫だらけです。
例①：画面単位切り替え
✅ 『ゼルダの伝説』
- 1画面ずつ切り替え
- スクロールは「演出」
例②：上下専用ゲーム
✅ 『アイスクライマー』 ✅ 『バルーンファイト』
- 縦専用なので
- ミラーリングと更新を最適化
例③：マッパー頼み
✅ MMC3 など
- IRQでラスタ分割
- CHRバンク切り替え
- 更新負荷を分散
8. まとめ（超重要ポイント）
| 理由 | 内容 |
|---|---|
| ネームテーブル | 実体は2枚しかない |
| ミラーリング | 縦方向が不利になりがち |
| VRAM制限 | VBlankが短い |
| 属性テーブル | 縦更新と相性最悪 |
| CPU性能 | 1.79MHzで余裕なし |
👉 結果：縦スクロールは「設計段階から覚悟が必要」
おまけ：だから「斜めスクロール」は地獄
- 横＋縦の更新を同時にやる
- VRAM転送量が倍
- 属性更新も複雑
だから：
- 擬似斜め
- 画面分割
- 強制1方向制限
などの妥協が生まれました。
この話が理解できると、
- 「なぜマリオは右だけ？」
- 「なぜゼルダは画面切り替え？」
- 「なぜ後期ソフトはマッパー多用？」
全部つながって見えてきます 😄
・・・だそうです。
結局ファミコンとしては、背景画面を保持するメモリが画面2枚分しかないから、それ以上の画面ページを使うスクロールなんかは簡単にはできない、って事を言われているんだろうと思います。
ようはそこについては考慮されたハードじゃなかった、という話なんでしょうね。
スーファミが発売された頃の後期のソフトなんかはROM側にビデオメモリを搭載してなんか処理してた、とかって話もあるみたいです。（上記のMMC3とか、コナミVRCとか）
それだけ難しい技術だったという事なんですね(ﾟ∀ﾟ)ｽｺﾞｰｲ
でもこうやってコードをガリガリ書くだけで再現できる現代のコンピュータ制御というか、その辺り技術の進歩に感謝するしかないですね(^^)
なんか話が込み入ってきちゃったんですが、引き続きロックマン制作進めていきますのでまた進捗上がったらここで報告しますね。
コメント