技術的読み物　Offentlich die Kunst　“Amaranth3開発裏話”

H17/11/07記述

●アマランス３開発裏話

　「裏話」といっても、“技術公開シリーズ”と銘打っている以上、技術的な話題をメインにお話ししていく予定です。徒然なるままに書いていきますので「脱線有り」ということで。

　アマランスIII

　「時代はスチーム・パンクだ！」ということで、アマランスシリーズもこれに倣った・・・・といってしまうと身も蓋もありませんね。ゲームの題材にも流行と廃りがあるのは事実。それにもともとアマランスシリーズは時空間を超えたオムニバス形式の物語ですので、時代背景には無限の広がりがあって当然(?)なのです。これは言い訳ではなく、本当に最初のストーリーが作られたときからそういう設定なのです。ですから、社内会議では「学園ラブコメアマランス」や「宇宙SFファンタシーアマランス」などの案も出る始末(?)です。
　面白いので少し詳しくお話しすると、前者の舞台は現代の東京都内の某公立高校。もちろんリアンとディンはそこの生徒です。リアンもディンも日本人とドイツ人のハーフということで。教育を通して人間を堕落の道に誘い、世界を自己の物にせんとする存在が倒すべき敵です。食パンをくわえて家を飛び出すディン、クソが付くほど真面目な生徒会長のリアン、この凸凹コンビが力を合わせて・・・・・言うまでもなく、このシナリオは没です。

【画面１】ゲーム起動画面

　後者の舞台は遙か未来（数億年後）の超巨大人工惑星。それも数十万年に渡って造り足されて巨大化したという設定です。そこで幼なじみとして育った青年リアンとディンが、とある疑問からこの人工惑星の起源を探る旅に出ます。その中で二人は歴史に隠れた謎の知的生命体の存在を知ることになります。そしてその存在がこの人工惑星の起源と深く関わっており、現在もある恐ろしい目的のために存在し続けていることを・・・・・ま、こんな感じですので保留です。別のRPG用にシナリオは保管中です。
　どちらもアマランスシリーズである必要はありません。でも、絶対神という設定のリアンとディンのキャラクタで作ることもできます。・・・・・脱線してます。のっけから思いっきり「技術的」でなくなってしまいましたね。「つかみはNG」ということで。

　フルマウスオペレーション

【画面２】データ選択メニュー

　さて、気を取り直してアマランスIIIのシステムについて。アマランスIIIのシステム上の最大の特徴は「フルマウスオペレーション」という点にあります。マウスというポインティングデバイスが一般に広く普及し、PC-9801ユーザのほとんどが持っている時代になったことが背景にあります。ビートバイスからアマランス２までは「ジョイスティックによる快適なプレイ」というものを想定していましたが、アマランスIIIではこれがマウス操作に変わったわけです。
　マウスを使ったツールであればビートバイスの頃から作っていましたが、いざゲーム製品となるとノウハウはほぼ皆無です。風雅セレクションで「カルカッタ」というフルマウスオペレーションのゲームは出していましたが、こちらはRPGとは全く別物の計算パズル。参考にすらなりません。マウスを使った仕様の模索がはじまりました。

　まず、ゲーム中の各種項目選択メニューの操作は迷うことなく直感的なものに決定しました。【画面２】のように、マウスカーソルに追随してリアルタイムにメニューカーソル（赤い帯）が移動し、ワンクリックで決定するというものです。誤操作に関しては、重大な個所のみ確認メニューを表示するという方法で対処しました。

【画面３】移動先カーソル

　問題はフィールド内の移動をどのようにマウスで行うかという点です。方向ボタンをフィールド域の横に配置する案、フィールド域自体に透明な方向ボタンを重ねる案、フィールド域の周囲が方向ボタンになっている案などが考えられましたが、どれも今ひとつ直感的ではありません。
　そこで考えられたのが、プレイヤーキャラクタであるリアンを中心にマウスカーソルの相対方向で移動方向を決定する案です。【画面３】のように、リアンの斜め左下方向にマウスカーソルを持って行くと、リアルタイムに方向を示すカーソルの形状が変化します。この状態で左クリックしている間、その方向にパーティーが移動するという仕掛けです。画面がスクロールしている間はカーソルとリアンの相対位置関係は変わらないので、クリックし続けるだけで自然な移動ができます。MAPの端に到達した場合は、リアンたちがカーソルに向かって移動し始めます。カーソルに完全に追いついてしまうと移動が止まります。この状態では、カーソルを移動させると、それを追いかけるようにリアンたちが移動する感覚です。

　しかし、まだ問題は残っています。スクロールならびにキャラクタの移動はプログラムの仕様上８方向と決まっていましたから、例えばリアンとマウスカーソルの相対方向が何度から何度までを「上向き」と判断するのが妥当かということを決めねばなりません。はっきり言って、ここは試行錯誤です。
　結局、８方向各45度角としました。つまり、上向きはリアンの上方・左右22.5度づつの範囲にカーソルが入っているときとなります。この範囲をチェックするには必然的に三角関数が必要になりますが、真面目に数値演算ライブラリを使うとそれなりのCPUパワーが消費されてしまいます。まだV30マシンが現役を続けていた当時、少しでも負荷を下げるため、独自の高速タンジェント近似式を作って処理しました（ほとんど気持ちの問題なのですが、そこはこだわりということで・・・）。

　ところがまだ直感的な操作を実現するには到りません。それは実際のMAPには複雑な地形が数多くあり、障害物にひっかかってしまうということです。ここはマウスオペレーションだからこそ大きな問題になってしまうのです。キーボードやジョイスティックであれば素早く障害物を避けながら移動することができますが、マウスだとそうはいかないからです。どうしてもマウスカーソルの移動に時間がかかってしまい、思うように移動することができず、プレイヤーにストレスがかかってしまうのです。

【画面４】マウス操作による移動例

　これを回避するには、プレイヤーキャラクタが自動的にそれもごく自然に障害物を避けてくれる必要があります。アマランス１や２もある程度自動的に障害物を避けるようにプログラムされていましたが、アマランス３ではそれをさらに強化し、コの字型にへこんだ部分以外ではまず引っかからなくなっています。これはプログラム的にはかなりの労力なのですが、こういった苦労をプレイヤーにはまったく気付いてほしくないという気持ちもあり（それだけ自然に動くということ）、ちょっと複雑な心境になります。
　具体的にどのように避けているかですが、プレイヤーキャラクタの足元幅よりも幅の狭い障害物は障害物に接触していない側に避け、同じ幅であればランダムにどちらかの側に避けます。そして障害物の幅が広い場合、両側に障害物が無くなるかMAPの端に到達するまで１PCGづつスキャンして、より障害物が無くなるまでの距離が短い側に避けています。実際の処理は他にも同時に考慮する点が数多くあるためもっとずっと複雑ですが、少なくともこれくらいの処理は行っているということです。風雅システムとしては当然(?)、この部分はアセンブラでプログラムしています。

　妥協策としてのライン抜き

　アマランス３にはアマランス１や２に比べて見た目で大きく変わった点が何点かあります。ひとつはキャラクタが大きくなったこと。これはアマランス１や２に比べ、身長が２倍（32×64ドット）になっています。それから、MAPのビジュアル度がアップしていること。これは同時に表示できるPCGの数が２倍（512個）になっていることによります。そしてMAPフィールドが全体的に“暗く”なっていること。実はこれはMAPフィールドのみ奇数ラインを抜いて表示しているからなのです。【画面５】のように拡大してみるとよくわかります。つまり、実質的に縦方向の解像度が半分になっているのです。これは会社設立当初からビジュアルにこだわってきた風雅システムとしては非常に大胆な仕様であるといえます。

【画面５】ライン抜き

　では、何故このような仕様になったのでしょうか。これはひとえにメモリ容量の不足によるものです。キャラクタのサイズが倍になれば当然必要メモリ容量も倍になります。特にキャラクタはアニメーションパターンも多く、画面に同時に何種類も表示しようとすると驚くほど大量のメモリが必要なのです。簡単に計算してみましょう。仮に32×64ドットで奇数ラインを抜かなかったとすると、キャラクタパターンの１枚あたりの必要メモリサイズは、
　　　　4×64×5＝1,280バイト
となります。単色1ドットに1ビット必要ですから、横32ドットを8で割り、バイトサイズ(=4)に変換します。これに高さの64を掛けます。そして16色表示のため、B（青）・R（赤）・G（緑）・I（輝度）・M（マスク）の5プレーン分をさらに掛けて、1280バイトとなります。
　さらに、上下左右4方向分のアニメーションパターンが各3パターンづつあるので、
　　　　1280×4×3＝15,360バイト
となります。つまり、１キャラクタあたり15KBものメモリが必要となり、１セグメント(=64KB)に４人分しか収まらないということです。パーティーだけで３人いるのですから、これではNPCが１人しか表示できないことになってしまいます。若干の速度低下を我慢するとして、キャラクタの表示ごとにセグメントの切り替えを行うとしても、もう64KBものメモリを確保することなど事実上不可能なのです。
　このような理由でやむなくMAPフィールドのみ半分のメモリ使用量で済むようにライン抜き表示をしているのです。
　ただ、これによってMAPのPCGのメモリサイズも半分で済むため、これまでの倍の512個が同時表示できるようになったのです。また、表示に必要なCPUのパワーも半分になりますから、スクロールも非常に軽くなり、画面全体の激しいPCGアニメーションを行ってもへっちゃらです。
　さらに、ただでは転ばないのが風雅システム開発部。奇数ライン抜き表示を逆手にとって、戦闘モードでこれを有効に活用しているのです。

　超お手軽半透過合成

【画面６】呪術アニメーションの半透過合成

　アマランス３の戦闘モードのひとつのウリが、派手な呪術アニメーションです。【画面６】がその一例、火吹き亀召還呪術「マクファーガ」です。ＭＡＰ域全体を埋め尽くす高速アニメーションが、ＭＡＰに半透過合成されて表示されます。留意してもらいたいのは、PC-9801VMでも十分高速に表示されるという点です。
　現在でこそMMX搭載CPUや超高速グラフィックチップが普及し、高速な半透過合成（アルファブレンディング）が当たり前にできるようになっていますが、当時はメインCPUが低速なV-RAM相手に演算を実行せねば実現できませんでした。それにそもそも同時16色表示では半透過表示自体が非現実的です。要するに、半透過合成の高速アニメーションなど不可能に近かったのです。
　ところがそこは発想ひとつで簡単に実現できてしまうのです。答えは先の「奇数ライン抜き表示を利用する」です。奇数ライン抜き表示をしているMAPフィールドの奇数ラインは常に黒であり、早い話が全く表示に利用されていません。そう、呪術アニメーションの表示にこの奇数ラインを利用するのです。縦方向に１ラインごとにMAPと呪術アニメーションが描画されると、ごく自然に50%：50%の半透過合成に見えてしまうから不思議です。専用の奇数ライン描画関数はアセンブラで最適化を施したものですし、ベタ表示をするだけでよいので、アセンブラによる最適化と相まって実に高速です。
　このようにアマランス３ではごくごく手軽に広範囲高速アニメーションを実現しているのです。

　もちろん１＆２のいいとこ取り

【画面７】オーバーラップビジュアル例

　当然といえば当然ですが、シリーズ旧作で好評だった機能（仕様）は、アマランス３でより磨きをかけて引き継いでいます。
　その代表とも言えるのが【画面７】のような「オーバーラップビジュアル」です。ゲーム画面のMAP域や飾り枠、ステータス域に重ねて大型CGを表示する手法を指します。これだけのことで臨場感がグッと増します。
　そしてテキスト画面と外字定義（ハードウェアPCG）を利用した「天候の表現」もそのひとつです。「ぽつぽつ降る雨」や「どしゃ降りの雨」、「しんしんと降る雪」など、シーンに合わせて合成表示しています（【画面８】）。これはテキスト画面ならではの高速な合成表示を利用して、高速広範囲のアニメーション合成を実現している部分です。

【画面８】テキスト画面アニメーション合成による天候の表現例
左が「ぽつぽつ降る雨」、右が「どしゃ降りの雨」

　また、MAPの切り替え効果のブラックフェードアウト／インも、アマランス１＆２に引き続いてテキスト画面合成が利用されています。違いはセミグラフィックではなく、外字定義を利用しているところでしょうか。

　いいところ取りといえばもうひとつ、【画面９】の装備確認変更ウィンドウがあります。見た目もアマランス２のものとほぼ同一です。もちろん操作はキーからマウスへと変更され、より快適になっています。これはメンバーの装備の確認／変更における、風雅システムのひとつの解答でもあります。

【画面９】装備確認変更ウィンドウ

　このウィンドウであれば、一目でパーティー全体の装備状態が把握でき、直感的に装備着脱・確認ができます。左列の装備アイコンにカーソルを合わせてクリックすれば、装備中品以外の一覧が見られます（【画面１０】）。所持品の破棄（捨てること）もこのメニューで行います。もちろんヘルプも見られます。

【画面１０】持ち物リスト

　ちなみに、このウィンドウのカーソル（黄緑色の四角）はテキスト画面のセミグラフィックを利用しています。その理由は「色」にあります。つまり、アマランス３の標準アナログパレットに無い色を使うことによって、カーソルが目立つようにしているのです。テキスト画面の色（８色）は原色に固定されているので、アナログパレットを使ってグラフィック画面の色を変更していると、１６色＋αの色として使えるわけです。

【画面１１】効果内訳グラフ

　あと、これはアマランス２にはなかった機能ですが、【画面１１】のようにカーソルをメンバー名に合わせて左クリックすると、現在の装備による「効果内訳グラフ」が表示されます。ＤＰ（=Defence Point＝防御力）を例にとって説明すると、全体で57ポイントあるＤＰが、基本値（■色の部分）つまりそのキャラクタの経験値によって決定される部分が約3/5を占め、残り2/5をアーマー（■色の部分）とシールド（■色の部分）がおよそ半々で担っていることがわかります。
　右側のＱＰというのは"Quickness Point"（＝敏速性）のことで、手っ取り早い話が「身軽さ」を表します。このグラフだけは隣のＡＰやＤＰと異なり、本来持っている身軽さが、どれだけ装備によって減っているかを表しています。つまり、白色の部分が最終的な現在の身軽さを表しているのです。
　この機能も直感性を大切にするために取り入れられました。

　BGM演奏とMIDIドライバ

　冒頭の【画面１】を見てもわかるように、アマランス３はFM音源の他にもMIDIによるゲームBGMの演奏に対応しています。「Nr.4 アマランス２スクリプト制御技法」の中でも紹介しましたが、自社開発の高機能MIDIドライバがすでに完成していましたから、用意するのはMIDIデータです。アマランス３のBGM曲数は全24曲と、シリーズの中では少ないのですが、それでも実際に作曲するのは大変な作業です。ところが、アマランス３ではFM音源・LA音源・GS音源の３種類の音源用の曲データが最初から入っています。つまり、24×3＝72種類の曲が入っているわけです。曲にこだわる風雅システムとしては、このあたりの労力は惜しまないということで。

　さて、今更の宣伝文句はさておき、風雅MIDIドライバーにはまだ紹介していない自慢の機能があるのです。それは目立たないのですが、場合によっては有ると無いとで大違いな機能なのです。

　まずひとつが割り込み番号の指定が０～２の間で指定できるという点。これは、通常のPC-9801にMIDIインタフェースを接続するとINT2が自動的に割り当てられるものが、一部のノートタイプ98ではINT1になったり、PC-H98シリーズではINT0になったりするという問題の回避に役立つのです。当初はそれぞれに合った専用のMIDIドライバを後からフロッピーディスクに入れてユーザに送ったりしていましたが、後にコマンドラインから指定ができるようにしました。

　そしてEMSメモリ（メモリ窓タイプの拡張メモリ制御方式）に対応すること。これは、フロッピーディスクでプレイする場合は特に関係ありませんが、ハードディスクにインストールしてプレイする場合にはちょっと嬉しい機能なのです。風雅MIDIドライバは、EMSドライバが組み込まれている環境で起動時にEMS使用の指定があると、演奏データ領域をEMSメモリに確保してコンベンショナルメモリ（一般のプログラムが使用できるメモリ領域）を節約しようとします。ユーザの環境によっては十分なコンベンショナルメモリを確保できず、ゲームの起動が面倒になるケースがありますが、この機能によってそれが大きく軽減されるはずです。
　とはいえ、風雅MIDIドライバ用の演奏データはメモリ上でもかなり圧縮された状態ですので、せいぜい10数KBなのですが・・・・・（こっちの方がスゴイかも）ちなみに、ディスク上ではさらに圧縮されていて、そのまた１／３程度になっていたりします。もちろん全曲が１本のファイルにまとめられています。
　ちなみにEMSでは16KB単位で拡張メモリを制御しますが、MIDIドライバはこれを２つ分、32KB使用します。

　さらにもうひとつ。MIDIインタフェースの有無を自動認識します。少なくとも私は他社でこれを実現しているのを見たことがありません。この機能により、「MIDIインタフェースが接続されている環境でのみ、BGM演奏の音源にMIDI音源が指定可能になる」というようにプログラムできるようになるのです。つまり、誤ってMIDI音源を持たないのにMIDIでのBGM演奏を指定してしまい、悲しい思いをするといった不幸が避けられるわけです。
　この機能の実現が難しいのは、MIDIインタフェース側に接続の有無をチェックするための機能が用意されていないことによります。これは試行錯誤を交えながら、そこそこ時間をかけて実現した機能で、実際にはかなり複雑な手法でチェックしています。詳細は今でもヒミツです(^_^;)。

　アニメーション

　アマランス３の大きなウリのひとつが、有名アニメプロダクション協力によるアニメーションです。【画面１２】のようなアニメーションがオープニングとエンディングに使用されています。アニメーションは１シーンに使用するCGの量が一気に増えるので、グラフィッカの負担も非常に大きくなります。また、それに伴ってメモリの使用量も多くなってしまいます。フロッピーディスク上のCGデータは、例によって独自の改良型多段圧縮によって縮めましたが、メインメモリ上の容量はそういうわけにはいきません。さらにアニメーションはそれなりにテンポよく進まないとシラけてしまうので、高速化も必要です。このように当時の環境（10MHzのV30マシンが残っている）でストレス無くアニメーションを実行するためは結構工夫が必要だったのです。

【画面１２】オープニングアニメーションより

　表示速度に関しては意地(?)で最適化した超高速PUTルーチンがあります。問題はいかにして高速にフロッピーディスクからCGデータを読み込み、いかにしてメインメモリを節約するかということになります。
　前者はデータを多段圧縮して小型化したことにより、必然的に読み込み時間が短くなりました。データの復元に要する時間は微々たるものですから無視できます。後者はCGデータの圧縮を完全に復元するひとつ手前の状態でメインメモリに格納しておくことで実現しています。つまり、CGはメモリ上に圧縮された状態で保持され、表示時に高速復元されているのです。もちろん、復元したCGは直接画面に表示されるのではなく、メモリ上の仮想画面内に蓄えられてから高速表示されます。

　アマランス３のために作成されたアニメーションセルは、実は製品で見られるよりもっと数多く存在します。しかし、アマランス３は「フロッピーディスクドライブ２台で動く」のが開発上の条件でしたから、どうしても容量的な制限を受けてしまうのです。２HDフロッピーディスク５枚組の製品（＝約６MB）ですが、それでも予定された全てのアニメーションを入れることはできなかったのです。アニメプロダクション（アニメアール）の方々には大変申し訳なかったのですが、多くのシーンをカットせざるを得ませんでした。残念！

　ヘルプシステム

【画面１３】ヘルプカーソル

【画面１４】ヘルプウィンドウ

　アマランス１や２では、表示されているアイテム名にカーソルを合わせた状態で左キーを押下したまま決定キーを押すと、そのアイテムのヘルプメッセージが表示されました。

　ところがアマランス３ではフルマウスオペレーションとなり、ゲーム中は一切のキー入力が無効になっています（キー入力割り込みのベクタを書き換えているので、本当に一切無効です）。このため、完全にマウスのみで操作を行わねばなりません。
　そこで考えられたのが、【画面１３】のようにショップや装備のアイテムメニュー表示時にマウスカーソルの移動範囲がメニュー内に制限されることを利用し、左端でカーソルが止まると形状を"HELP"に変えてヘルプモードに入るという手法です。この状態で左クリックすると【画面１４】のようなヘルプウィンドウが表示されます。アイテムの説明と装備の可否情報を見ることができます。
　実はこれはかなり自慢のシステムなのです。選択メニューが表示されているときであれば、ほぼいつでもヘルプが参照可能です。プレイ中のコマンドメニューも例外ではありません。よくある、ヘルプ表示用のボタンを設ける手法と比べるとその操作の「気持ちよさ」が実感できるでしょう。意外とこういうところが「技術」だったりするわけです。

　スクリプト制御

　アマランス２のスクリプト制御技法をさらに進めたのが、アマランス３のイベント制御スクリプトです。【リスト１】のサンプルソースをご覧になればおわかりのように、構造化された文法で専用の言語として記述されています。アマランス２ではアセンブラのマクロを利用してオブジェクトに変換していましたが、アマランス３では専用のコンパイラを作成し、エラーチェックもきっちり入るようになっています。

　ソースを簡単に説明します。
　SETWINDOWPOSコマンドは会話用の窓絵付きウィンドウの表示位置やサイズなどを定義するものです。そしてOPENSPEAKコマンドで実際に会話ウィンドウを表示、SPEAKで会話文を表示および変更、CLOSESPEAKでウィンドウを閉じます。SWITCH－CASE－ENDSWITCH文やIF－ELSE－ENDIF文はC言語やPASCALのそれに類似しています。ただし、C言語のようにBREAK文はありません。SPEAK文の中の会話文中の"^[5"と記述されている部分はテキストの色変更です。あらかじめ登録されているNo.5の色に変更するという意味になります。"^?"で初期状態に戻しています。このほか、文字サイズの変更、太字、字間変更などいろいろな指定ができます。
　MAIN_CNTや@CLOSEDは変数です。前者は整数変数、後者はフラグ変数で、定義さえしておけば予約語と重ならない限り自由に使用できます。当然ですがフラグ変数は１ビットサイズですので、０と１しか代入できません。

;　アマランス３イベントスクリプト例１

;●鉱山出口
;EVPOS(15, 56, 110, DOWN) - (15, 59, 110, DOWN)
START 2501
	SETWINDOW 0, 2, 17, 30, 12, 1, 16, 144
	SETWINDOW 3, 34, 223, 30, 12, 2, 16, 144

	SWITCH(MAIN_CNT)
		CASE 102		;タフォス島のクステゴ鉱山に入った！！！！
		OPENSPEAK 0, 13
		SETWINDOW 0, 2, 17, 30, 12, 1, 16, 144
		SPEAK 0, "ねぇリアン！そこは出口よ。ドラゴンの卵を見にきたんでしょ。",END
		SPEAK 0, "早く探しましょうよ！",END
		CLOSESPEAK 0

		CASE 103		;レクルスに会った
		IF(@CLOSED == 0)
			OPENSPEAK 0, 33
			SPEAK 0, "あれ！",END
			SPEAK 0, "大変だ！入り口がふさがれてる！！",END
			OPENSPEAK 3, 15
			SPEAK 3, "あの女のせいね！あいつがやったに決まってるわ！",END
			SPEAK 0, "あいつって……さっきの^[5レクルス^?とかいう？",END
			SPEAK 3, "そうよ。他に誰がいるのよ。",END
			CLOSESPEAK 3
			CLOSESPEAK 0
			@CLOSED = 1
		ELSE
			NOTICE "洞窟の出口は硬くとざされている",END
		ENDIF

		CASE 104		;ヴァルゾーン大佐に会った
		NOTICE "洞窟の出口は硬くとざされている",END

		DEFAULT
		NOTICE "洞窟の出口は硬くとざされている",END
	ENDSWITCH
PEND
END

【リスト１】

　もう少しコマンド類をご紹介しましょう。【リスト２】は製品版のスクリプトを解説用に変更したものです。簡単にコメントをつけてあるので、おおよその機能は推察してもらえると思います。制御文にWHILE－ENDWHILEがありますが、ご覧のように入れ子（実質無制限）が可能です。こちらはC言語のようにBREAKで抜けることができます。また、ローカル変数も使用できます。プロシジャ内でDEFINEにより定義された変数はローカル変数となります。
　MOVEは指定したキャラクタを移動させるコマンドです。キャラクタIDと移動方向とキャラクタの向き（後ずさりやカニ歩きなどを表現するため）を指定します。移動はDISPLAYコマンドで反映されます。DISKCHKは指定したドライブに指定したフロッピーディスクが入っているかチェックし、入っていなければ自動的にメッセージを表示して交換を促します。オーバーラップビジュアル用のデータはサイズが大きく使用頻度が低いため、ディスクの交換を前提としている場合が多くなっています。もちろん、ハードディスクにインストールされている場合は、このコマンドは何もしません。

;　アマランス３イベントスクリプト例２

;●ループ制御例、他
START　6542
	DEFINE MONEY, RC			；ローカル変数宣言

	CNT = 3
	WHILE(CNT)
		SCROLL 0		；０の方向に１ステップMAPをスクロール
		CCC = 1
		WHILE(CCC <= 9)
			MOVE CCC + 3, 8, 0	；キャラクタの移動
			CCC = CCC + 1
		ENDWHILE
		MOVE 0, 4, 0
		MOVE 1, 4, 0
		DISPLAY 1		；MAP再表示
		CNT = CNT - 1
	ENDWHILE

	DISKCHK 1, 2			；フロッピーディスクチェック（BドライブにBディスク）
	FADE 2, 4			；フラッシュアウト
	OVERLAP 10, 83, 34			；オーバーラップビジュアル表示
	FADE 0, 4			；ディフォルトパレットに復元
	SOUND 5			；効果音の発声
	CALL 6600			; No.6600イベントの呼び出し（サブルーチンコール）
	DISKCHK 1, 3			；フロッピーディスクチェック（BドライブにCディスク）

	GETMONEY MONEY			；所持金取得
	OPENSELECT 25, 89, BUYSEL, RC, 1			；選択ウィンドウ表示
	CLOSESELECT			；選択ウィンドウ閉じる
	IF((RC == 1) \| (RC == 65535))			；選択結果のチェック
		NOTICE "購入を思いとどまった"
	ELSE
		SETMONEY MONEY - 100		；所持金処理
		MAIN_CNT = 108
	ENDIF

	IF(MAIN_CNT == 108)
		MAPMASK 0		；MAPフィールドを黒でマスク
		MAP 84, 0, 35, 1		；MAP No.84に切り替え。初期座標は(35, 1)
		DISPLAY 0		；MAPを表示
		CHRLOAD 0, 7		；主人公キャラクタパターンセットをNo.7（車）に変更
		BLIND 6		；主人公キャラ以外を非表示に
		DISPLAY 0		；MAPを表示
		DISABLE 1		;；エルイン（セーブ）の禁止
		@CAR = 1
		MAPMASK 1		；MAPフィールドのマスクを解除
		MAIN_CNT = 109
	ENDIF
PEND
	LABEL BUYSEL			；データラベルの設定
	WIDTH 10, 2			；選択メニューの表示幅と項目数
	ELEMENT " 買う",CR			；選択メニュー項目１
	ELEMENT " 買わない",END			；選択メニュー項目２
END

【リスト２】

　ショップでの買い物や判断選択の際に表示される選択メニューウィンドウもスクリプトで記述されています。OPENSELECTで表示され、CLOSESELECTで閉じられます。OPENSELECTの引数は、ウィンドウを表示する座標、項目リストのラベル（LABEL文で設定）、戻り値格納変数名、キャンセル可否指定（０で禁止、１で可能）です。項目リストはリスト末のPENDとENDの間に記述します。LABEL文でラベルを付け、WIDTH文でウィンドウの幅と項目数を指定し、ELEMENT文で必要なだけ項目を設定します。もちろん、項目リストはひとつのプロシジャにいくつでも記述できます。ちなみにOPENSELECT－CLOSESELECTは６段までの入れ子が可能で、選択結果によってさらに別の選択メニューを表示させていくことができます。
　また、ラベルに０を指定すると、直前のMAKEELEMENTコマンドの結果を項目として表示させることができます。MAKEELEMENTは指定されたメンバーIDと種別からメニュー項目を作成してくれます。例えば、


	MAKEELEMENT　2, 1
	OPENSELECT 80, 100, 0, RC, 0

と記述すると、ディンが装備可能な武器の一覧項目が作成され、それが選択メニューとして表示されます。他、現在のパーティーのメンバー一覧や所持アイテム一覧なども作成できます。
　戻り値格納変数には選択された項目番号が（MAKEELEMENTで作成されたリストの場合は各ＩＤが）、キャンセルされた場合には65535が格納されます。これらの選択メニュー関連コマンドの開発により、ＲＰＧのイベント記述における大きな柔軟性を実現できました。この機能はWindows版アマランスのイベントスクリプトにも引き継がれ、より柔軟性に富んだイベントの実現に一役買っています。

　リアルタイムゲーム入り(^_^;)

【画面１５】強制二択アクションイベント

　アマランス３は戦闘シーンがタクティカルコンバット形式になったため、ハラハラドキドキの(*^^*ゞリアルタイムシーンが皆無になってしまいました。
　そこでひねり出されたのが【画面１５】のようなリアルタイムイベントです。パーティーで鉱山トロッコに乗り込むと、MAPの強制横スクロールが始まります。するとレールの切り替えポイントが迫ってくるので、「こっちだ！」と思う方向にマウスカーソルを合わせてクリックします。選択を誤るとレールが途切れていて全員死亡・・・リアンのツァイツの出番となります。はっきり言って、ここは勘任せです。連続で７回の二択に正解するとイベントクリアとなります。一発でクリアできる確率は2⁷=128分の1となりますね。ちょっとキツいかも・・・

　ミニゲーム入り(^_^;;;)

【画面１６】ミニゲームイベント

　スクリプト制御の項で紹介したように、アマランス３のイベント制御システムはコンパイル形式によってより高度に進化しました（以前はアセンブル形式）。それまでは複雑なイベント記述するには大変骨が折れたのですが、高級言語感覚でプログラムできるようになったことにより、一気に効率が上がったわけです。すると欲が出るのがプログラマの性というもの。アマランス３のイベントプログラムはうりぼうと杉之原名人（一部社長も）が担当していましたが、当時新人だったうりぼうが狂喜乱舞。アマランス２の３倍ともいわれたイベントプログラムの６割以上を書き上げました。杉之原名人は当然メインプログラムも担当していたので、涙を流して喜んだと伝えられています。
　うりぼうは量のみにあらず、この高級言語型イベントスクリプトを使いこなすべく、「だったらゲームの中でゲームを作れるじゃないか！」と発想。【画面１６】の博覧会場内のドッグレースイベントをミニゲームに仕立てたのでした。社内では「ここまでやるか？」と半ば白い目で見られたといいます。が、自ら言語仕様を作り、コンパイラ＆ドライバも作成した杉之原名人は、嬉しさの余り寝込んだ（なぜ？）と伝えられています。

　専用エディタ"UMED"

　アマランス３を制作するにあたり、当然ながらデータ作成のためのツール類が必要になります。先にお話ししたようにアマランス３のMAPフィールドは奇数ラインがないので、実質640×200ラインモードのグラフィックデータを作成しなければなりません。

【画面１７】呪術アニメーション例

　そこで作成されたのがアマランス２用に開発されたNMEDの改造版UMEDです。頭の"U"は単純に推測すると"Ultra"の頭文字かな？とも思われがちかもしれませんが、アマランス３制作で気を吐いた新人プログラマの「うりぼう（もちろんニックネーム-本名は塚原君）」をローマ字にしたときの頭文字だったりします。残念なことに、このUMEDの実行ファイルもソースファイルも消失してしまっていて、その画面イメージをお見せすることができません。バックアップしたはずのMOディスクがエラーを起こしたのが原因です。３年後にCD-Rに移そうとした際にそれが発覚し、必死の復旧努力も空しく帰らぬファイルとなってしまいました。まぁ、もっと倉庫をひっくり返して調べてみたらフロッピーディスクなんかに残っているかもしれませんので、そのときはこのページに画面イメージを追加することにしましょう。うりぼうは「バックアップ魔」だったので、その可能性は意外とありそうです。

　UMEDはNMED以上に万能のエディタで、MAP＆PCGとそのアニメーション、キャラクタの他、呪術アニメーションエディタの機能も持っていました（【画面１７】）。アマランス３の呪術はフィールド画面全体に合成される最大１６セルパターンのアニメーションで表現されているため、専用のツールが必要だったわけです。UMEDはアマランス３に必要な約１０種類のファイルを出力する機能を持つ、統合グラフィックツールでした。

　ちなみに、先に名前の出たうりぼうがどのくらいバックアップ魔だったかというと、その日の仕事が終わったら全環境をフロッピーディスクに二組バックアップし、一方を自宅に持って帰り、もう一方を私（杉之原名人）に渡して自宅に持って帰らせるのです。確かに、これなら会社と自宅が同時に火事で全焼しても、一組は残ります。普通はここまでやりませんよね？でも、それくらいに慎重だったのです。実は私も「三ヶ所バックアップ」をする人間なのです。今でも会社と自宅とWebサーバ上（大阪または東京）にプログラムソースをバックアップしています。プログラマにとってソースは仕事の要ですし、貴重な財産でもありますから。
　実際に私は友人にプログラムソースをしばらく預けていたときに、その友人宅が火事で全焼してソースが消滅したことがあります。そのときは個人的に作っていたゲームソフトだったのでまだよかったのですが、つくづく「世の中何が起こるかわからない」ということを学習しました。ま、この話をうりぼうにしたことがそもそも彼がバックアップ魔になる発端だったんでしょうけどね・・・・

　その他

【画面１８】パレットによる夜の表現

　PC9801シリーズは同時に１６色までしか表示することができません。（H98シリーズは拡張ボードで256色に、PC9821シリーズは標準で256色に対応していました。）そのため、カラーパレットを変更すると変えたくない色まで変わってしまい、デザイン的に大変苦労させられます。
　【画面１８】は夜のシーンをカラーパレットの変更で表現していますが、グラフィッカは試行錯誤を繰り返しながら大きな労力を払ってパレット値を決定しているのです。顔CGや数値類はちゃんと違和感なく見えないといけないので、これはもう職人技中の技といえるでしょう。

【画面１９】戦闘中の移動先指定モード

　【画面１９】は戦闘中、ディンの移動ターン時のスクリーンショットです。中央の赤っぽいキャラクタが敵、そのすぐ下のぼやっとしたキャラクタが「移動先指定カーソル」です。この場合はディンが移動しようとしているので、カーソルもディンの形をしています。これがマウスカーソルになっているので、リアルタイムに自由にフィールド内を移動させられます。実はこのカーソルも奇数ラインに表示させることによって高速になおかつ半透過に見えるようになっています。操作性の良さにこだわっている部分のひとつです。

【画面２０】フィールド内の敵の表現

　アマランス３の敵はフィールド内をうろうろしていますが、接触して実際に戦闘画面にならないと実の姿がわかりません（【画面２０】）。つまり、「敵の気配が見えている」状況を表しています。
　これはリアルさを考えたためで、決してメモリの節約などといった理由からではありません。ええ、決して。強いて言えば、「たまたまメインメモリの節約につながった」だけです。

　最後に

　アマランス３は１および２とは全く異なったシチュエーションのストーリーでしたし、戦闘は非リアルタイムタイプ、フルマウスオペレーション、などなどそれまでとはかなり雰囲気の違った「異色作」でもあります。このためユーザの評価もはっきりと二分される傾向があります。「シリーズ中、最低の駄作」と評する人がいる一方、「シリーズ中、最も好き」と言う人も大勢いらっしゃるのです。でも、正直にデータ（主にアンケート葉書）からいうと、前者の方が多いですね。特に１と２の大ファンという方は圧倒的に前者だったと記憶しています。やはりアマランス（ディン）の物語は「中世ドイツ風」がベストマッチなのでしょうか・・・・