自作ゲーム＃０２ - 巨人戦機 GIANTS -

【ジャンル】　縦スクロールシューティング
【初リリース】　0.1b　（98年8月）
【分類】　フリーソフトウェア
【動作環境】　Classic起動○
【サイズ】　628kB
【識別】　kj08

★指数的にインフレする斬新な得点システム、おざなりなグラフィック、全てはMacのハードウェアを使いこなす実験だった。

　GIANTSは，とあるMacのゲームを考える同士が，ネットの片隅で話題にしていた「Mac上でフルスクリーンでグリグリ動くゲームマシンのようなゲームができるか。しかもMacのモデル（能力）の縛りを可能な限り緩く。」といった命題に対して出した1つの答えであったように記憶しています。

　だいたい当時の環境（97〜98年のiMac登場以前）だと，Mac，Windowsともに，一時的にパソコンの進化が止まってしまって，あまりワクワクさせる要素がなく，リリースされるラインナップもロクな物がなかったように記憶しています。
　で，その当時のターゲットとなるマシンはといえば，95年くらい長期間リリースされ続けたデスクトップ機（PPC601,604eの80Mz〜200ＭHz），並びにパフォーマ（PPC603，〜200ＭHzくらい），それとあまりパッとしない印象の最新アーキテクチャを採用したG3機くらいでしょうか。もちろんゲームを動かす上でハイエンドなスペックを要求することは論外で，ターゲットは岸部史郎一家がイメージキャラクターだったパフォーマ級に絞られることになります。（PIPINも類似の最低スペックだったような。）　Windowsの世界でもMMXのpentium266くらいがハイエンドで，pentiumの133とか166あたりが一般的だったかと思います。

　Macでゲーム機のようにゲームを作る上で問題になるのが，デカい画面でゲームができないということでした。これは，パソコンの解像度が高いため，画面上の大きな範囲を描き換えるためには大量のビットマップ（メモリ）転送が必要になり，自ずと，小さなウインドウで作られるか，パズルのような，フレームレート（画面描き替えの周期）の低い静的なゲームに絞られるようになります。（但し，かなりスペックは必要だが，MarathonやDOOMのようなものはあった。しかしこれは意外とフレームレートが低い環境でも受け入れられるような作りになっている。）しかし，僕はそれでもMacでなんとかしたいと色々試行して，GIANTSを作ることにしました。

★問題の解決
　まあ，どっちにしろ僕にできることは描画をなんとかするくらいしかないんですけどね。別の知識が必要そうなな，音楽ドライバや，サウンド周りまでは弄れそうにないんで。
　GIANTSでは，ほとんどのマシンには搭載されている，640*480の解像度でゲーム画面がいっぱいになるように設計しました。実際に書き換える部分は，縦シューとして丁度よい正方形（縦長だと小さくなってしまうので）のディスプレイ上のサイズ512*480，内部的には256*240の画面にしました。256*240というのは破烈兎Exの画面よりかなり小さく，当時のマシンレベル的にも結構軽く全描き換えバッファ処理ができるレベルでしたが，問題はディスプレイ表示するところです。面積4倍の部分に拡大して表示するわけですから。
　結局その辺はコンパイラでは見えない痒いとこまで手が届くよう，アセンブラレベルで最適化した画面転送ルーチンを使用することで，なんとかすることができました。ポイントは，バス幅の考慮，転送の方向，命令の展開，使えるレジスタは有効に使う等だったと思います。それでもスペック内に収まるかは無印603のラインナップにはギリギリのようで，1ラインごとに間引いて表示するモードや，小さな画面で表示するモード，さらには描き替え自体をもスキップ（コマ落ち）するモードも選べるようにしました。このくらい考慮すると，非PPCの040/25MHz程度のマシン（PCだと486DX/33くらいのマシン?）でもそこそこ遊べてしまうという。

　ちなみにWindows系のPCだと，320×240ドットのフルスクリーン環境がハード的に用意されているようで，Macプログラマが頭を抱えている問題を，悩まずに通過してしまうという点は羨ましい限りですね。

★VBL割り込みについて
　スクロールシューティングのような，動きの激しいゲームを作る上で問題になるポイントに画面の書き換え周期というものがあります。
　家庭用ゲーム機やゲームセンター等で遊ぶ場合，キャラクターはディスプレイの中に張り付いて動いているかのように見えると思いますが，これは人間の目の錯覚で，毎秒60回程度周期で画面が更新されていると，スムースにアニメーションしているように見えます。これが毎秒30コマ程度の割合になると，動いているオブジェクトの輪郭がブレているように見えます。ですから品質の高いゲームを作りたいのなら，毎秒60コマ程度の処理ができなくてはなりません。

　また，画面の更新周期を毎秒60くらいにすると，別の問題が生じてきます。たとえば，ウインドウのような大きなオブジェクトを，左右に素早く畚かすとウインドウが横方向に割れて見えたり，画面が横に割れて見える「ティアリング」という現象に遭遇します。これはディスプレイの表示更新がオブジェクトの画像メモリ書き換え中に起きてしまったことに起因します。これを防ぐには，更新のタイミングを計ってその後に一気に書き換えてしまうという方法がとられます。これをVBL（垂直帰線）待ちと言います。
　これを行うと，本当にキャラクターが画面に張り付いて動いているように見えるのですが，いかんせんこの周期はハードウェアごとに統一されておらず，昔の13インチディスプレイや，640*480のモードだと67Hz，800*600とか1024*768だと，60Hzや，75Hz，85Hz，iMacに至っては119Hz等となっているのでそのまま同期したら，プレイする環境毎にスピードがかわる，もしくは表示コマのばらつきが生じることになり本末転倒になります。（iMacなら，2回のVBLで更新すれば59.5Hzとなり，丁度よさそうです。）
　残念なことにこの問題にはこれと言った解決策は存在しなかったようです。ユーザーに想定する環境を強いるか，ティアリングを気にしない等，スマートな方法はあきらめる。尤も当時のMacにはそこまで求めるゲームは無かったようですけど。（後になってこの問題が某所の板で論争になることは興味深いことです。）
　GIANTSではこの辺はユーザに設定してもらえるようにしました。デフォルトで内蔵タイマーによる同期，任意にVBL待ちを使えるよう設定メニューにいれておきました。

　今はどうなんでしょうか。液晶が基本ですからモノによって反応の早さが随分違いそうですよね。

　おざなりなタイトル画面。実はクラリスワークスのドローオブジェクトにによる、ベクトル線のみの描画だったりします。表示時に病かが見えたり（笑）
　巨人戦機GIANTSという命名は，どうせ実験作なので，ちょっと危険な橋を渡ってみたかったのです。

　高速でスクロールする雲と、低速でスクロールする地表が60fps以上で２重スクロール。

　無意味に弾を沢山出したい．．．そんな風に思っていた時期が僕にもありました（笑）

　某ガレッガとか蜂の得点アイテムを，さらに指数的に得点数が伸びる斬新なシステムにアレンジすることにチャレンジ。

　ボス機BHM（通称ミスター）
　「私は誰」って、Mac ユーザにほとんど分かる人はいませんでしたとさ。

　optionキーを押しなら選択できるメニューで、高レベルのゲームをプレイすると、弾が棒に．．．