進捗
グラフィッカーさんのドット絵を組み込んだ。一気にそれらしい感じに。以下はスーファミ実機での様子
……なんだこの画質は。ケーブルがもう駄目なんだろうか(子供の頃から買い替えてない気がする)
酷すぎるのでエミュレーターで撮った方も。
↓フォトライフの動画はiPhoneから見られないようなのでGoogle Photos版
実機: https://goo.gl/photos/dun3aiJf6Y9XbGUL6
エミュレーター: https://goo.gl/photos/kFWYbLomjZMe2PTJ7
近況
ある朝起きたら任天堂が真理(ダルマ)に目覚めてスーパーファミコンのバーチャルコンソールが始まっていた。ので、とりあえずゼルダとF-ZEROを買った。スーパードンキーコングも検討したが、YouTubeで動画を見ていたら、怪しい壁という壁にタルをぶつけて巡回するつらい作業のことを思い出したのでやめた。マリオワールドのゴール数の頃はユーザが勝手にやってた感じで気楽だったんだけど、スーパードンキーコングの時代になるともう「オラッ、やり込めよ」という感じでつらい。
さて、グラフィッカー氏から背景が一部届いたのでBGエディタを作って背景マップを組むことにした(今まではテキストエディタで仮のマップを作っていたが、さすがにきついので) ちなみに25行目は表示用のデータではなく、表示上の最下段(24行目)から何段目までブロックが積みあがっているかを示すメタデータとなっており、敵の思考ルーチンは地形を判別するのにここを見るようになっている。ブロックの数ぐらい数えりゃいいじゃないか、と思われるかもしれないが、スーファミの性能を考えるとこんな処理でも避けたいということである。
進捗
今週は忙しくてノー進捗でフィニッシュです、と、なりそうだったが日曜が空いたので、敵の「思考」ルーチンを作った。ちゃんと足場の高さを考えながら敵(ネコ)がジャンプしているのがわかる。
……実のところ思考なんて大層なことはしてなくて、次の足場までの高低差と距離に対してどれだけジャンプすれば届くか、というテーブルが用意してあってそれを見ているだけである。
ドット絵研
依頼しているグラフィッカーの方、実は年下なのでさすがにスーファミ時代のノウハウは持っておらず(というか私も当時は小学生だ)、じゃあスーファミ時代のドット絵で(64KBのVRAMに詰め込むために)どんなテクニックが使われていたのか簡単に調べてみましょうか、ということになった。
エミュレータでVRAMの中身をダンプして、これをJavascriptのプログラムで処理して画面を再構成するという方法で、画面を構成するタイルを分解して見ることにした。ちなみに、ROMイメージはちゃんと手持ちのカートリッジからRetrodeで吸い出して合法的な手段で得たので悪しからず。
す〜ぱ〜ぷよぷよ通リミックス(コンパイル)
固定画面のパズルゲームということで、わりと余裕のある使い方をしているように見える。このシーンで明らかに使わないパターンもVRAMに残っている。ちなみに設置済みのぷよはBGに描かれているが、操作中のぷよはスプライトになっている(落下のアニメーションだけならBGでもできると思うが、回転時の滑らかなアニメーションはスプライトが必要)
あとは、文字のパターンを見ると、コロンの下半分だけをピリオドに使いまわしていることがわかる。
ロックマン7(カプコン)
ロックマンは広大なマップに緻密な背景を描く必要があるので、ぷよ通と比べるとテクニックを駆使して詰め込んでいる印象。崩れたビルが少数のパターンで巧妙に描かれていることに注目。左右対称の物は片側だけ描いて反対側は反転して使い回す。紫色の柱?のような部分は上下反転もうまく使っている。ベタ塗り部分の共用タイルがあり、空や床などはこれで塗っている。
ちなみに8×8ピクセルのタイルを1パターン使い回すと、4bits per pixelなので32バイトの節約になる。
本当はロックマンXも見たかったんだけど、もう端子がダメになっている模様。接点復活剤を買うかカセットごと買い直すか……
キーボード型PC WP004 を買った
なんとなくキーボードPC WP004を購入して、スーファミの開発環境を入れてみた。
25年前にはン百万円のワークステーション(+任天堂提供の機材)が必要だった作業が今や2万円のおもちゃパソコンで出来るとなれば科学技術の進歩に感動すること間違いなしである。
しかし開封してすぐに気づく。右Shiftキーが明らかにおかしい。
……。JIS配列の金型を起こす金が無かったんだろうが、もうちょっと何とかならなかったのか。
しかしそこは工夫次第であり、キーボードを繋げば何の問題もなく使えますね。甘えるな。
どうしてこんなことに。
起動してしまえば特に言うことは無い、これはパソコンですねという風情。スーファミの開発に最低限必要なものはアセンブラだけだが、makeとgitを使うためにcygwinを入れる。あと、以前書いたようにSNES9xベースのデバッガーという極まった物も存在するので、これも入れる。
アセンブルの速度はCore i3のNUCと比べると倍程度遅い。ただし、1秒のものが2秒になるという程度の話なので、開発自体は何の問題もなく行えるし、エミュレータもサクサクと動く。ただ、Webで調べ物をしようとすると、そちらの(ブラウザの)遅さにストレスが溜まるので、やっぱりメイン環境にしようとは思わない。
結論
高いパソコンは良い
スーファミ進捗
背景がちょっとマシになった(そうか?)
どうせグラフィッカーさんに頼むので自分で描いたのはどうでもいい。で、そのグラフィッカーさんにプロトタイプを見せて軽く打ち合わせをした。スーファミの仕様を説明して終わりかなあ、と思っていたが、ゲーム内容についても結構アイデアが出て、内容が一気に充実した。やっぱり人に見せるというのは大事だ。
まず出た意見が、
主人公が右に走っている理由が欲しい
なるほど。自分はゲームにストーリーを求めない人間なので、それすら考えていなかった。 んー、ゲームだしとりあえず走れば? 酷すぎるか。
グラフィックは現代日本っぽい感じかなあ、と思っていたのでそれに合わせて「お魚くわえたサザエさん」的な設定を入れることにした。ドロボウ猫を追いかけるか、あるいはプレーヤーが追われる猫になるか。
……という設定を入れたことで
ダッシュ(加速)ボタンをつける
という方針が決まった。つまり、ダッシュを使わないと追いつけない(あるいは追いつかれる)ので、壁にぶつかるリスクを負ってでもどこかでダッシュをする必要がある。こんな感じかね↓
あと、紙に描いた絵を見ながら
建物のテラスの所には乗れないの?
という話が出た。これは実は重要なアイデアで、こうすると空中にブロックを配置できる。マリオみたいに不思議な世界観のゲームなら空にブロックが浮いててもいいんだけど、現代日本の風景でそんなことはできないので、空に障害物や足場が浮いていることを正当化する表現が必要になるわけである。
ただ、これには当たり判定がある場所とない場所を描き分ける技術が必要になる……ので、頑張ってください。
近況
スーパーファミコン
← 実機
しょぼいMr.Jumpみたいなゲームが動いている。技術的にはだいぶ安定してきて、グローバル変数同士が衝突しておかしくなる心配はもうないし、エミュレータで動くのに実機でバグる、なんてこともまず無くなった。
実機に持って行く時に気をつける点はそう多くはなく、I/Oレジスタ(Intel系でいうI/Oポート)の初期化、メモリの初期化、あとは以前書いたパッド入力の遅延、といったところ。