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

H17/12/22記述

●アマランス４開発裏話

　前回の「アマランス３開発裏話」と同じノリでいきます。なるべく(?)技術的な話になるように努力してまいります。（あぁ・・・テクニカルエッセイのはずなのに・・・・・・orz）

　アマランスIV

　アマランス４にはリアンが登場しません（話題には上りますが）。代わりにリアンの子孫であるシュテラール王国の王子様ダイナスが主役のひとりとして登場します。もちろん、「アマランス」という名がついているので、ディンあるいはペールメール（二人ともアマランスの精）も登場するということです。

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

　【画面１】が起動画面です。「おや？どこかで見たことあるような・・・・」そう思われた方は気のせいではありません。他社の某有名シミュレーションゲームをパロッってますσ(^◇^;)。詳しくは申しませんので悪しからず。このあたりは風雅のノリということで。（この某シミュレーションを開発された会社とは親交もあり、新製品を出したときはお互いに送りあったりしたりしてました。親近感の表れなんです、ハイ。）
　この起動画面はこれだけで独立したプログラムになっていて、ゲームを起動するための環境設定のみを行います。そのため、BGMを演奏する音源やディスプレイ装置の選択を求めてきます。ここでアマランス３のときと異なるのが、MIDIの対応音源からＬＡ音源が無くなったということです。このころになるとMIDI音源モジュールもGS系が完全に主流となり、開発部としてはLA音源所有者の多くはGS音源も所有するようになったと判断したわけです。個人的にはアナログ風の音色のLA音源が好きだったのですが、これも時代の流れというヤツです。

　ハードディスク専用

【画面２】ゲームタイトル画面

　もしかするとこれがアマランス４の最大の特徴なのかもしれません。ついにアマランスシリーズもハードディスク（以降HDD）が必須になりました。
　風雅システムのゲーム製品はPC-9801対応製品処女作のビートバイスから（Aktieを除き）HDD対応を謳ってきましたが、同時にフロッピードライブ（以降FDD）のみでもプレイすることができました。それが事ここに至り、FDDのみでの動作を切り捨てたのです。
　理由は取りも直さず、FDDでの動作がゲーム制作の足枷になっていたからに他なりません。FDDでのプレイとHDDでのプレイの差は、(1)ディスク入れ替えの必要性の有無、(2)アクセス速度－特に読み込み時間、(3)インストールの必要性の有無、(4)標準搭載の有無です。
　(1)と(2)は利点、(3)と(4)は欠点となります。利点をもう少し具体的に解説すると、(1)は大容量化によるメリットです。1.2MBのフロッピーが２枚では収められるプログラムやCGの量は制限されるため、どうしても容量の大きなCGを表示するときはフロッピーディスクの入れ替えが必要になってしまいます。これはプレイヤー側にしてみれば「興ざめ」の一言に尽きるでしょう。「ディスクの入れ替え」という「現実」に引き戻されるわけですから。当然HDDであればあり得ない話です。ユーザにとって大きな利点となることは間違いありません。
　しかし、(1)の利点はそれだけではありません。データの振り分けが不必要となったり、デバッグ期間が短くなったりして、開発コストが下がるのです。そうやって節約できたコストをより完成度を高めるために費やせるので、製品の質も向上するわけです。実際、アマランス４は非常に完成度の高い製品になったと思っています。

【画面３】オープニングの１シーン

　最初はディン１人、次に左のリグラ、右のレスという順番で仲間が増えていきます。この３人が揃って一戦終わったところでオープニングの始まりです。

　(2)の利点は言わずもがな。ゲームの起動はもとより、プレイ中の待ち時間が皆無なことです。一度HDDでプレイしてしまうと二度とFDDではプレイできなくなると言われていたように、その快適さは絶大なものです。ですが、風雅システムはほとんどの製品がHDD対応ですから、「なぜHDD専用なのか」という問いの回答にはなりません。
　この問いの回答は「いろいろなシステム的要因」とせざるを得ません。例えば「同時に大量のデータを扱う必要があるため」とか「FDDのアクセス速度ではゲーム中の待ち時間が長くなりすぎる」とかが主要因といえるでしょう。アマランス４の仕様では、FDDだけでは荷が重すぎたのです。戦闘が発生する度にフロッピーディスクを何枚も入れ替えるなんて、とても現実的とは言えませんから・・・・。
　とにもかくにも、HDD専用化によってユーザに妥協の少ないゲーム提供することができたことは確かなのです。（でも、若干ですが、「根性でFDD対応にしろ！」とユーザからお叱りのお言葉をいただいたことも確かです。）

【画面４】ハードディスクインストーラ画面

　さて、ここからは欠点です。(3)の問題はパソコン初心者ユーザに対しては大変大きなものです。フロッピーディスクを挿入して電源を入れれば、ゲームでもワープロでも動くもの・・・・と思っていたユーザが多かったですから、「HDDを接続してインストールする」なんていうと、それだけで引かれてしまいます。
　そこで登場するのが【画面４】の"FUGA HD Installer"です。これはエルステディアの頃から使われていたものですが、HDD専用となって、俄然その存在感が大きくなりました。

　このころのハードディスクインストーラというと、インストール先のディレクトリが固定であったり、ドライブまでＡドライブ固定のものがありましたから、痒いところに手が届かないどころか、痒いところだらけでどこを掻いていいのかわからない状態のもの珍しくなかったのです。つまり、HDDインストールは「サポート外のおまけ」だったのです。（もちろんそうでないものもありましたが。）

【画面５】オープニングより

　おなじみシュテラールの都町に到着した３人。ご覧の通り、アナログ１６色の限界を超えてるでしょ？

　HDDインストールゲーム元祖を自負する風雅システムとしては、ここで黙っている(?)わけにはいきません。結果作られたのが汎用の高機能インストーラだったのです。'93～'94発売の風雅システムのゲームソフトをお持ちの方はご存じのように、ファイル操作専用ソフトの感覚でインストールディレクトリを自由に視覚的に決定することができます。HDDを何台も接続しているヘビーユーザにも対応できるように配慮されています。
　また、初心者のために、エラーメッセージも数多く、わかりやすいものをわかりやすく表示するように工夫してあります。一言で言うと「ビジュアルインストーラ」ですね。(3)の欠点を少しでも小さくするため、できることを積極的に行った結果といえるでしょう。　

　残るは(4)ですが、これはHDDの価格の低下が進み、一般化するのを待つしかありません。標準搭載機では問題ありませんが、非搭載機の場合は外付けのHDDをユーザに購入してもらう必要があります。安い買い物ではありません（当時で数万円～）から、それに見合うだけの利点があることを啓蒙していく以外に方法はありませんでした。ゲーム開発会社としては、「ゲームの質の高さ」をアピールすることに徹しました。

　実はHDD専用化はアマランス３のときも○之原名人が社長に懇願していたのですが、「甘えるな！」の一言で却下されていたのです(^_^;)。事実、微妙な時期ではありました。それが一年半経過することで、情勢が変わり、今度は社長も、「お゛お゛？もういいがんないが？（富山弁：訳＝うん？もういいんじゃないの？）」と許可を下してくれたのです。

　クオータービュースクロール

【画面６】クオータービューMAP１

　シュテラール城下町を歩く主人公キャラクタ（ディン）

【画面６】がアマランス４のプレイ画面です。シュテラール城下町がご覧の通りクオータービューで描かれています。ゲームの世界にも流行廃りがあることは皆さんご存じの通り。当時はまさにクオータービューばやりだったのです。
　もちろんクオータービューが流行ったのにもそれなりにわけがあります。パソコンのCPU性能が高くなってきて、負荷の高いスクロールを実行させても十分に高速になったのです。実際にアマランス４のスクロールルーチンはアマランス２と比べると平均で２倍以上重くなっています。もちろん、最適化されたアセンブラで組んであってもです。
　理由はいくつかありますが、最も大きいのが「描き換え不要ケースが皆無」という点でしょう。アマランス１～３までのハーフトップビューのスクロールの場合は、MAPの最小構成単位であるPCG(16×16pixel)が移動方向に隣り合わせかひとつ飛びに配置されていると、描き換える必要がないために高速化できました。ところがクオータービューになると実質的にそのようなケースが全くありません。アマランス４はPCGが16×16pixelで構成されていますが、視覚的な縦横比が１：３になっているので、横は16ドット単位、縦は1ドット単位でスクロールできるようになっています。実際にプレイされたことのある方は、主人公キャラクタが障害物に当たったときに上下方向にヌルヌルとスムースにスクロールして、その障害物を自動的に避けようとするのを憶えていらっしゃるでしょう。これからもわかるようにスクロールごとに全面描き換えが必要になるのは明らかです。つまり、描画処理の軽減が全くできないのです。

【画面７】クオータービューMAP２

　シュテラール城３階にて。戦闘モードに入る前の導入イベントシーンより。

　次いで処理が重くなる要因は、よりMAPの表現力を上げるための描画機能拡張にあります。クオータービューの場合、使用するPCGの数がハーフトップビューに比べて多くなる傾向があるため、アマランス３と同じく最大で512個まで同時に表示できるようになっています。ただし、アマランス３のように奇数ラインを抜いたりしていませんから、PCGの必要とするメモリサイズはその倍になります。すると64KBのセグメントの壁を越えることになるので、PCGをひとつ描画するごとにセグメントの切り替えが発生する場合が多く出てきます（実際には256個づつ2バンク構成になっているので、上位バンクに登録されたPCGを描画するときだけセグメントが切り替えられます）。
　さらに、それでもPCGが不足しがちになるため、PCGごとに左右、および上下に反転して描画できるようにもなっているのです。もちろん、この機能を有効に利用するにはグラフィッカの工夫と努力が必要になりますが。
　このように、PCGひとつを描画するために必要なCPUパワーが多くなっているのです。

　その他にも、MAP上のプレイヤーキャラクタをはじめとしたオブジェクトのサイズが大きくなっていることや、MAPスクロールフィールド自体が広くなっていることも大きな要因と言えます。しかし、アマランス４発売当時は、さすがのV30マシンも現役を退き、80386やi486CPU搭載機が主流となり、Peintiumも登場していた時代でしたので、スクロール速度の不満を指摘するアンケート葉書は幸いにも皆無でした。

　イベント発生型タクティカル戦闘

【画面８】クオータービューによる戦闘シーン

　アマランス４がそれまでのアマランスシリーズと決定的に異なる点が、イベント形式で発生する戦闘シーンです。アマランス１はエンカウント方式、２と３はリアルタイム接触方式でしたが、４では戦闘が発生する場所とタイミングが完全に固定となっています。
　これはアマランス４の戦闘が本格的なタクティカル（戦術型）シミュレーション形式になっていることに起因します。つまり、じっくりと戦闘を楽しんでもらうためなのです。はっきり言って、アマランス４は戦闘シーンだけでも一本の製品として発売できるレベルにあります。（【画面８】）
　RPG部分と戦闘部分を分けることによって、それぞれを集中して楽しめるようにしたわけです。

【画面９】対ボスキャラ戦闘シーン

　戦闘モードは独立した個別プログラムになっていますが、見た目はフィールド移動時と変わりません。このあたりのシームレスな所が開発者としてはアピールポイントです。同じゲームをプレイ中なのですから、できるかぎり画面の印象は変わらない方が良いと考えました。フィールド移動中は主人公キャラ（ディンまたはダイナス）のみが表示されていますが、戦闘モードになるとパーティー全員が表示されるため、臨場感が出てきます。
　戦闘モードにおいて、マウスオペレーションは強力な追い風となりました。直感的にスピーティーに指令を出すことができます。キー操作のことを考えると、クオータビューは本当に厄介だろうなぁと推測していただけると思います(^^ゞ。

【画面１０】ギザブリツ炸裂！

　戦闘はデカキャラ有り、呪術アニメーション有り、会話イベント有り、アイテム有り、トラップ有り、どこでもSAVE有りと、機能盛りだくさんです。アマランス４はこの戦闘を楽しむためにフィールドを移動するゲームといっても良いのかもしれません（もちろんストーリーを楽しむのはフィールド移動中がメインですけど）。
　

　進化したマウスオペレーション

　アマランス４もアマランス３と同様にフルマウスオペレーションのゲームソフトです。当時はWindows3.1～95の時代でしたので、アイコンによるマウスオペレーションがトレンディーでした。そこで、アマランス３では文字中心だった表示系をアイコン中心の表示系に変更しました。これはHDD専用としたことによって仮想メモリ的な処理ができるようになり、メモリに余裕ができたことが実現を助けています。

【画面１１】ショップでの買い物画面

　【画面１１】はショップ（武防具屋）での買い物シーンです。商品はすべてアイコン表示となり、大きな「指カーソル」で操作するようになっています。今見てみると、誤操作を防ぐために確認のクリックなどが必要となっており、若干の煩わしさは拭いきれません。ドラグ＆ドロップを使えばもう少し良かったのかもしれませんが、アマランス４では敢えて採用を見送っています。処理が重くなるのが大きな要因なのですが、次回はWindows版になるとわかっていたので、そちらで実現することにしたのです。事実、「サイレントNOVA」でドラグ＆ドロップによる装備の着脱や授受を実現しています（それはそれでかなり苦労しているのですが・・・・）。

　フィールドの移動に関してはアマランス３に準じています。異なるのは８方向移動から４方向移動になったことくらいでしょうか。おっと、それからマウスカーソルの表示形態も異なっていますね。アマランス３のマウスカーソルはマウスドライバに登録されているカーソルパターンを変更して表示していますが、アマランス４の場合は風雅お得意(?)の外字定義を利用したテキスト画面にマウスカーソルを表示しています。「なぜ？」って思われますよね。実は「マウスカーソルを大きく、かつ軽くするため」なんです。

【画面１２】フィールド移動カーソル

　風雅システムのマウスドライバは、もちろん(?)自社開発のオリジナルドライバです。特に風雅セレクション１の「カルカッタ」には16カラー32×32dotの任意カーソルパターンが登録できる優れもののマウスドライバが使用されています。作者しんばる前川自慢の一品です。ところがこれには欠点もあり、動作が「重い」のです。これはやむを得ないことでもあります。マウスカーソルはX方向にも１ドット単位で高速に移動しなければならないのですから。もちろん、背景との合成・復元という作業も必要です。
　アマランス３のフィールドカーソルは16×16dotの標準的なモノクロカーソルでした。でも、これでは「見にくい」という意見が多かったのです。マウスドライバはモノクロ32×32dotのパターンもサポートしていましたが、これではチラツキが気になったのです。
　そこで採られたのが外字定義（PCG)を利用したものなのです（【画面】）。テキスト画面ですから、カーソルの移動はX方向８ドット、Y方向１６ドット単位です。しかし、実際にプレイしてみるとわかりますが、移動の荒さはほとんど気になりません。それどころか軽快に動くカーソルが小気味よく感じられるはずです。これも私たちは「技術」と考えています。

　これはマウスオペレーションとは直接関係ないのですが、操作上、アマランス３と異なる点としてキーボードのサポートがあります。マウス操作と並行して、フィールドの移動にテンキーが使用できるようになっているのです。しかし、[1][3][7][9]という一般的には使用されていないキーを割り振ったためか、「テンキーでも操作できるようにしとけっ！」というお叱りのアンケート葉書も何通かいただきました。全くお気づきになっていらっしゃらなかったようでしたので、正直ちょっとショックでした。確かに、マニュアルにもテンキーで操作できるとは一言もかいてありませんでしたので、間違いなく非はこちらです。でも、迷ったんですよ。[2][4][6][8]キーをそれぞれ同時に２つづつ押すようにするか、キーボードを斜め４５°に置いてもらって、[2][4][6][8]キーで操作するか、そしてあるいは実際に採用されている斜め方向キーを使うか・・・・。今にして思えば、オプションでそれらが選択できるようにしておけばよかったんですけどね（当時はまたそれすらできない理由もあったんですがf(^ー^;）。

　オブジェクト指向プログラミング

　アマランス４はC言語とアセンブラで組まれています。MAPやキャラクタの表示などの画面処理はすべてアセンブラで、それ以外はCコンパイラ（ちなみにBorland C++ 3.1）です。
　アマランス４の仕様が決まったとき、その仕事量の多さに開発チームは人割りに悩みました。特にメインプログラムはRPG部分と戦闘部分がそれぞれ従来の製品１本分に匹敵するほどの仕事量です。1人が半年間で組み上げるには無理が有りすぎます。しかし、２人あるいは３人でメインプログラムを分割して開発すると、開発中および最終的な結合時のオーバーヘッドやリスクが非常に大きくなってしまいます。
　そこで採られた方法がビートバイス開発時に倣った「実行ファイル分割方式」でした。これは例えば２人で開発する場合、メインプログラムを２本の実行ファイルに分けて作成するのです。こうすることによって、それぞれが独立してコンパイル（アセンブル）＆デバッグができるわけです。アマランス４では見たまんまですが、フィールド移動部分と戦闘部分で別プログラムファイルになっています。戦闘が開始されるときと戦闘が終了したときにお互いのプログラムが起動し合っているのです。ちなみにフィールド移動部分（RPG部分）は杉之原名人が、戦闘部分（SLG部分）はうりぼう塚原が、そして起動モジュールはしんばる前川が、専用ツール類はバトラー田丸担当しました。

　さて、表題に「オブジェクト指向」とあるくらいですから、アマランス４はC++の機能を使ってソースプログラムが書かれていると多くの方は推測されるでしょう。ところがそうではないのです。アマランス４は標準C言語の機能だけで記述されています。

【画面１３】杉之原名人作・「プリティーインベーダ」

　名人がC++練習用として作成したゲームのタイトル画面。遊びではなく、あくまでも「実践の練習として」作成されたものです。(^_^;)

　　開発当時はちょうどC++言語が話題になって盛り上がっていた頃でした。当然(?)、杉之原名人もうりぼう塚原もご多分に漏れずC++言語に興味を持ち、それなりに習得もしていました。うりぼうはテンプレートライブラリにハマり、自分が使用する標準入出力型ツール類をC++で開発していたのです。また、杉之原名人は実践練習と称してC++の特徴である継承や多態性の威力を味わうべく、オリジナルのインベーダーゲームを作っていました。
　ところが・・・・当時のC++コンパイラにはいろいろと弱点があったのです。まず第一の弱点はオブジェクトの実行速度が遅いこと。特にテンプレートライブラリを多用すると信じられないくらいに遅いのです。うりぼうの作ったC++製ツールは、結果表示の速度が異様に遅く、とても時間のかかる処理ではないにもかかわらず、描かれていく文字を追えるほどでした(CPU=i486-66MHz)。設計に多少問題があったのかもしれませんが、それにしても遅すぎです。名人のインベーダーゲームは、テンプレートライブラリもほとんど使用せず、モノクロ１プレーンのみのせいもあってか、違和感なく動作はしているようでしたが。
　このころのC++コンパイラは完全にソースレベルコンパイラ（トランスレータ）になっており、C++言語で書かれたソースプログラムを一度C言語のソースプログラムに変換してからCコンパイルするようになっていました。試しに中間ソースを覗いてみると、異常に可読性の悪い、長々としたプログラムになっています。当然、オブジェクトのサイズも大きくなりがちで、何よりコンパイル時間が長いのです。実感としてはC言語のみに比べて３倍くらいかかったように記憶しています。

【画面１４】プレイ画面一部

ちなみにキャラデザも名人自身。

　これらからわかることは、「実際の開発に使用するには、最低でもC++コンパイラの癖を見抜く必要がある」ということ。つまり新しいノウハウが必要ということです。短い開発期間のうちに、これを並行して行うことはリスクが高すぎます。でも、クラスを使ったカプセル化などの機能はとても魅力的です。開発にも大きく寄与するでしょう。
　そこで考えられたのが「C言語だけでオブジェクト指向プログラミング」という方法です。C++という言語はオブジェクト指向でプログラムを作りやすくするための仕様ですから、他の言語ではオブジェクト指向ができないというわけではないのです。

　特に実現したいのがクラスによるカプセル化でした。「謎のバグ」を減らす特効薬と思えたからです。でもC言語ではクラスを使えません。そこで採った方法が、「ひとつのソースモジュールをクラスオブジェクトに見立てる」というものでした。
　アマランス４のような市販用RPGともなるとC言語で記述されたソースプログラムだけで４万ステップを軽く超えます。当然ながら、こんな大きなプログラムを１本のテキストファイルにするなどバカげています。そこで機能単位でプログラムを分割してせいぜい１千ステップ程度のモジュールとし、別々のプログラムテキストファイルとするわけです。こうしておけば、モジュールごとにコンパイルしてオブジェクトを作成しておき、実行ファイルを作成するときのみリンカでモジュールオブジェクトを結合すると効率的だからです。
　そのようなモジュールをクラスとして扱うことができれば、バグ軽減に寄与するはずです。そこで、原則グローバル変数はモジュール内でのみ使用可とし、すべてstatic宣言（外部からの参照不可指定）することを徹底して行いました。つまり、モジュール内の変数を外部からアクセスするには、そのモジュール内の専用のアクセス関数（メンバ関数に相当）を必ず使うしかないのです。もちろん、おかしなアクセスができないように、そのアクセス関数ではチェックを行います（例えば０～９９９までの数値しかとらないのにマイナスの値を書き込もうとしたとか）。
　他にもいろいろと取り決めを行い、モジュール単位のカプセル化を徹底した結果、原因究明に手間取るバグは従来に比べてグンと減少し、オブジェクト指向の優位性を体感する結果となりました。

　シリーズ最大量のイベントプログラム

【画面１５】イベント言語よるイベントシーン

　後に詳しく説明しますが、アマランス４のイベント記述言語はひとまずの完成を見ています。また、前作でもほぼ同様の形式でイベントプログラムを記述しているため、ある程度のノウハウも蓄積されていました。当時はすでに、アマランスシリーズといえばストーリー主導型RPGの典型という認識も一般ユーザの中に浸透してきており、その期待に応えるべく(?)ストーリーはより濃厚に、会話などのイベント量もそれに追従して膨れあがりました。
　アマランス４は比較的サクサク進むので、実際にプレイされた方はそれほどのイベント量を感じられないかもしれません。ところが登場人物も多く、それぞれがよくしゃべるので、アマランス３を凌駕するイベント量（イベント制御データサイズ）を誇っています。

【画面１６】戦闘モード中の会話イベント例

　また、戦闘中でもフィールド移動中と同じように窓絵による会話イベントが適宜発生します。もちろんアイテムゲットなどのイベントやトラップイベントも発生します（【画面１６】）。原則、戦闘中もフィールド移動中とほとんど同様のイベントを発生させることができます（共通のスクリプトとコンパイラを使っています）。アマランス４のイベントデータサイズが大きいというのは、実はこの戦闘モード時用のイベントがかなりあることも大きな要因なのです。
　

　シリーズ最大量のＣＧデータ

　アマランス４は1.2MBフロッピーディスク７枚組の製品でした。メディアの価格も大分下がってはいましたが、それでも製品原価は上がってしまいます。アマランス４は定価が11,800円と、いい値段がしました。枚数が増えた最も大きな要因はなんと言ってもCGの容量でしょう。会話イベント用の顔CGだけで軽く１００枚を超えています。ビジュアルシーン用のCG枚数もアニメーションパターンを含めるとかなりの枚数になります。

【画面１７】会話用顔CG

　【画面１７】は初期パーティーメンバーのレス・ペリオデの顔CG一覧です。彼だけで１８枚用意されています。ディンに至っては３０枚近く用意されています。１６色CGのノウハウが蓄積されているとはいえ、グラフィッカの労力も大変なものでした。
　ストーリーとその演出にこだわるためには、いろいろな表情の大量のCGが必要だったのです。それゆえに、心情描写が微妙なレスやディン、そしてメーヴェ（両親を殺された14歳少女）やファイルヒェン（主人公ダイナスの年上の恋人なんだけど盗賊の娘）などの顔CGはそれぞれ２０枚近く描かれました。

【画面１８】オープニング用CG

【画面１９】エンディング用CG

　どこでもSAVE

【画面２０】 SAVEウィンドウ

　実は風雅システムが昔から結構こだわっている点であったりします。RPGであれSLGであれ、いつでもどこでもSAVEができるということは大きなメリットであることは異論のないところでしょう。風雅システム開発部では、プログラムの設計をするときは「どこでもSAVE」が可能なように、まずSAVEデータのデザインを行います。あらかじめこれを決めておかないと、汚いプログラムになってバグの温床になりかねないからです。
　アマランス４ではRPG部分とSLG部分が完全に別プログラムになっていますから、SAVEデータの設計はより一層重要です。いたずらにSAVEデータが大きくてもユーザは迷惑ですから、必要最低限のデータのみがSAVEされるように熟考してあります。その結果、フィールド移動中でも戦闘中でも、まったく同じようにSAVEとLOADが可能になっているのです。
　ちなみに、SAVE/LOADウィンドウ（【画面２０】）では、移動中か戦闘中かでSAVEデータ名の文字色のみが異なっています。言い換えれば、それ以外は何の違いもないということです。結構すごいでしょ？

　専用統合MAPエディタシステム"AMA4MED"

【画面２１】 MEDの最終形態「AMA4MED」
の中の"FIGHMAP.EXE"

　MEDもついにここまできました。今度のMEDは“トータルシステム”になっています。それまでの“オールインワンタイプ”では、メモリサイズ的にも限界がきていたからです。そのためアマランス４用のMEDは、全部で７本の実行ファイルからなるシステムとなりました。
　【画面２１】はその中の戦闘モード用のMAPをデザインするときに使用するFIGHMAP.EXEの画面です。これは地形の属性を設定しているところ。ちなみに表示されているMAPはチェック用のプロトタイプのシュテラールの街です。
　アマランス４の仕様に合わせてあることもあり、従来のMEDとは全くイメージが異なっています。これは作者（プログラマ）が異なっているのが最も大きな要因かもしれません。AMA4MEDシステムのプログラマは、杉之原名人でもうりぼうでもなく、当時比較的新人だったバトラー・加賀福・田丸です。情報処理技術者第一種の資格を引っ提げて入社後、短期間のうちにメキメキと実力をつけ、次期メインプログラマと目されていました（実際にエバーブルームを作りましたが）。
　AMA4MEDシステムは、XMS（エクステンドメモリ＝拡張メモリシステム）が必須環境となっていて、当時としては膨大だった１MB超のメモリを利用して始めて動作するほど大規模なプログラムでした。

【画面２２】ＮＰＣの動きやＭＡＰ上のイベントを設定する
"EVSET_EXE"

　右の【画面２２】はフィールド上のイベントやNPCの動きを設定するEVSET.EXEです。MAPMAKE.EXEで作成されたMAPデータを読み込んで、イベント全般をプログラムすることができます。
　この画面はNPCの移動ルートを設定しているところです。指定したNPCがどれくらいの速度でどういったルートを移動するのかをビジュアルに設定できる優れものです。そしてそのNPCにプレイヤーキャラクタがぶつかったときに発生するイベントもそのまま記述できるようになっています。【リスト１】を見てください。これはひとりのNPCのイベントスクリプトですが、1行目から8行目と26・27行目はEVSET.EXEが自動出力したスクリプトです。そして、9行目から25行目まではEVSET.EXE上から起動されたテキストエディタで追加記述したプログラムになっています。もう、コメントがなくてもこのシリーズをご覧の方でしたら見ただけで内容は理解していただけますよね？このシンプルさが強みとなります。

EVSET.EXEが出力したイベントスクリプト例

0001	START "町の爺さん"
0002		CHRNAME　"OLDMAN0"
0003		CHRDIR　3
0004		CHRPOS　14, 276, 3, 88, 1, 46
0005		CHRPOS　7, 20, 5, 22, 7, 68
0006		CHRPOS　5, 24
0007		SPEED　6
0008		ACTIVE　1
0009		DEFINE　RND
0010		RANDOM　RND, 6
0011		SWITCH(RND)
0012			CASE 0
0013				SPEAK2 "んん？ああ、いい天気じゃのぅ。", END
0014			CASE 1
0015				SPEAK2 "すまんがもうちょっと大きな声で話してくれんか？", NEXT
0016				SPEAK2 "どうも耳が遠くてのぅ。", END
0017			CASE 2
0018				SPEAK2 "ごきげんよろしゅう。", END
0019			CASE 3
0020				SPEAK2 "最近物忘れがひどうてのぅ……お前さんがた、誰じゃったっけ？", END
0021			CASE 4
0022				SPEAK2 "そうじゃ、お前さんがたにわしの初恋の話を聞かせて進ぜようか？", END
0023			DEFAULT
0024				SPEAK2 "はて………？わしゃ、どこへ行くんじゃったっけ？", END
0025		ENDSWITCH
0026	PEND
0027	END

【リスト１】

　その他、MAPのアニメーション機能や属性の設定機能などは過去の集大成といえるだけの使いやすさがあります………が、AMA4MEDについてまともに解説するとNMED以上に長くなりますのでこれくらいにします。本当はすべての画面と機能をお見せしたくてしょうがないのですが、我慢×２です。今後、ご紹介する機会があったときにでも。

　進化型制御スクリプト

　アマランス４のイベント制御スクリプトは、基本的にアマランス３のものを踏襲しています（【リスト２】）。当然ながら、より洗練され、進化したものになっています。最も大きな特徴は２バイトコード、つまりスクリプト中にコメント以外でも漢字が使用できるようになっていることでしょう。ダブルクォーテーションで括ることによって、ラベルやターゲット名に使えるようになりました。やはり、開発チームは皆日本人ですから、アルファベットよりも仮名や漢字の方が認識しやすいのは当たり前です。引いてはデバッグ効率の向上に繋がります。
　また、イベントの発生位置や条件、NPC用であればその動きの情報など（【リスト１】参照）もスクリプト内にまとめられています。それまでは別にスクリプトを書き、別データファイルとして処理していましたから、それが一本のソースファイルにまとめられるというメリットは大きいものです。これもイベント関連のシステムを見直した結果です。

　もう一点、コンパイラがプリプロセッサを内蔵するようになりました。定数の置き換えが主な機能なのですが、C言語のenum（イニューム）のように、自動で連番数値を割り振る機能なども持っています。【リスト２】の20行～のSPEAK文の第１パラメータに指定されているのは、会話イベントで表示される顔CGなのですが、従来は数値であったものが定数のエイリアスになっています。ちなみにマイナスを付加すると左右反転されたCGが表示されるようになっています。また、ADD文やMEMBER文などの第１パラメータも同様にメンバーIDのエイリアスです。
　より直感的にスクリプトを記述できるようになったことで、アマランス４ではイベント中のバグもかなり少なくなりました。良い製品作りには良いツールが必要であるという風雅の社訓（ちょっと大袈裟ですが）が生きています。

AMA4イベントスクリプト例

0001	START　"リグラ登場"
0002		EVPOS　66, 306, 73, 308				; イベント発生位置
0003		EVCOND　ALWAYS				; イベント発生条件
0004		DEFINE　COUNT　DIRECTION				; 局所変数定義
0005		IF(CHAPTER == 1)
0006			BORN　"リグラ"			; NPCリグラ発生
0007			COUNT = 0
0008			WHILE(COUNT < 35)
0009				IF(COUNT < 10)
0010					DIRECTION = 3
0011				ELSE
0012					DIRECTION = 1
0013				ENDIF
0014				MOVE　"リグラ", DIRECTION, DIRECTION		; NPCリグラ移動
0015				DISPLAY
0016				COUNT = COUNT + 1
0017			ENDWHILE
0018			MOVE　"リグラ", 7, 7
0019			DISPLAY
0020			SPEAK9　LIG_SH, "^｢6ディンテンプロール^[?ですね？", NEXT
0021			SPEAK1　DIN_BU, "そおだけど、あなた誰？", NEXT
0022			SPEAK9　LIG_NO, "私の名前は^[6リグラ^[?。ドーハの都から来ました。", NEXT
0023			SPEAK1　DIN_RE, "ドーハの都……", NEXT
0024			SPEAK1　DIN_AM, "じゃあ、^[6モノディ^[?さんから？", NEXT
0025			SPEAK9 　"あなたの護衛にと遣わされました。",END
0026			SPEAK1　-DIN_CH,"わかったわ。これからよろしくね。", END
0027			NOTICE　"^[6リグラ^[?が仲間になった", END			; メッセージ表示
0028			ADD　Ligul, "ブローミル"			; ブローミル１個
0029			EQUIP　Ligul, 0, 31, -1, -1			; ダガーとクロースアーマー
0030			SETPARAM　Ligul, 1, 88, 0, 20, 20, 24, 9			; リグラの各パラメータ設定
0031			MEMBER　Ligul, -1			; パーティーにリグラを追加
0032			@LIGUL_LIVE = ON			; フラグON
0033			KILL　"リグラ"			; NPCリグラ消去
0034			DISPLAY
0035			CHAPTER = 2			; 大域変数代入
0036		ENDIF
0037	PEND
0038	END

【リスト２】

【画面２３】ミュージックモード

　実は隠しイベントのひとつである「ミュージックモード」も通常のイベントとして記述してあります（【画面２３】）。アマランス３のときと同様に、ELEMENTコマンドとLABEL文を使って簡単に曲目ニューを作成できますし、実際に曲を鳴らすのもSWITCH-CASE-ENDSWITCH文を使えば一発です。
　

　その他

【画面２４】アニメーションドライバによる
ビジュアルシーンのひとつ

　ビートバイスのために制作されたアニメーションドライバですが、時を経るにつれて改良が重ねられいました。それがアマランス４のときには一応の完成を見ており、すでにバージョンアップがなくなっていました。
　文法的な変更は当初よりほとんどなく、新コマンドの追加やシステム変数の追加などが主なバージョンアップ内容となっていました。アマランス４はこのアニメーションドライバが使用された最後の製品となりました。
　アニメーションドライバはPC9801VMの頃に仕様が策定されたものでしたから、高速性に主眼が置かれていました。そのため、文法もできるだけそれに寄与するようになっています。構造化プログラミングがしにくいというのもその弊害と言えます。また、コンパイラとしてもシンプルなもので、式のたたみ込みができないとか、多次元配列が使えないとか、未完成な部分も多々あります。
　ゲームソフトもWindowsに移行していくと、アニメーションは動画として扱うようになり、CD-ROMの大容量と相まってそれが標準的になっていきました。現在ではFLASHのアクションスクリプトも一般化しはじめているので、アニメーションドライバのようなシステムはほとんど必要なくなってきました。嬉しいような寂しいような・・・・ちょっとだけ複雑な気もします。

【画面２５】エングの公衆浴場にて

　また、アマランスシリーズといえば、もうお約束(?)になってしまっているのがお風呂シーンでしょう。アマランス４では、女湯をのぞくイベントなどはないのですが、その代わりといっては何ですが、女湯でのイベントシーンが計３回出てきます。エングの公衆浴場→シュテラール城の大浴場→エングの露天風呂、といった具合です。
　中世ドイツに湯船式の風呂があったのか？とツッコまれると、ちょっと自信のないところですが、とりあえずアマランス世界ではあるのです。富める者、貧しき者、力のある者、ない者、皆平等に裸になって、大地の恵みである温泉に浸ることは、平和な世の中を形成するためにも有効な方法です（日本的な考え方ですが・・・）。そんなわけでRPGにも取り入れてみました。シリーズを通して、お風呂イベントはなんとなく平和的でほのぼのしてるでしょ？プレイ中でもぽっと一息つけると思います。開発チームからプレイヤーの皆さんへのほんの気持ちです。ちなみにアマランス４のお風呂イベントはすべて女湯が舞台になっています。

【画面２６】シュテラール城大浴場にて

【画面２７】エングの大露天風呂にて

　PC-9821

　結果的にアマランス４は、風雅システムが開発・販売した最後のPC-9801シリーズ用ゲームソフトとなりました。PC-9801のノウハウが結集された製品と言っても良いでしょう。この頃になると、PC-9821シリーズがメインストリームとなっていましたから、1677色中の256色を同時発色できるようになり、解像度もDOS/V機に合わせて640×480dotモードを持つようになりました。ゲーム制作側としては、256色モードでパックトピクセル形式でV-RAMをアクセスできるようなった点が大きなメリットでした。

　しかし、大きな問題もありました。PC-9801/21シリーズの生みの親であるNECさんは、従来通りのV-RAMスペックしか持たないPC-9801シリーズの新型も発売し続けていたのです。256色を必要としない用途にはより安い価格でユーザに提供するという親切心だったのでしょう。でも、これではソフト開発者たちは256色モードに全力投球することができません。せめて、新PC-9801シリーズのV-RAMを9821相当に拡張する純正ボードを廉価で発売してほしかったですね。PC-9801VM/VF用の16色カラーボードのように・・・。（ただしPC-9801BX4だけは256色モードが使えました）

【画面２８】アマ４のビザムの滝はこんな感じ。

　そしてもう一点、DOS/V用ソフトでは一般的だったDOSエクステンダーが標準でなかったことです（DOS/V用のMS-DOSでも標準ではないのですが）。これがあれば、MS-DOSから１MBを超えるメモリ空間を自由に利用できるプロテクトモードのプログラムで高速なソフトを開発できたのです（80386以降のCPU）。頑張ってNEC製のMS-DOS6.2あたりに、標準で含めてほしかった・・・・DOS/V対抗の大きな力になったはずなのに・・・・。9821シリーズの256色パックトピクセル形式のV-RAMは１ドットが１バイトですから、640×480≒300KB となり、１セグメント(64KB)では足りないなんてもんじゃありません。9821では、リアルモード（8086互換モード＝16bitモード）のMS-DOSからこの300KBものV-RAMにアクセスするため、画面に32KBの「窓」を設けていました。この窓のメインメモリ上の位置（アドレス）は固定ではなく、ほぼ自由に設定できましたが、画面の描画を行う際に常に窓に反映される画面の位置を変更せねばならず、非常に使いにくい仕様です（苦肉の策なんでしょうけどね）。はっきり言って、まともな高速ゲームを作れるとは思えません。
　しかし、DOSエクステンダーを使って80386の32bitネイティブモードのプログラムを走らせることができれば事態は一変します。なぜなら、256色モードのV-RAMは１M超のアドレス空間にはリニアにマッピングされているからなのです。これなら３Dゲームだってバリバリ動かせます。実際、杉之原名人は32bitモードで動作するPC-9821の256色モード用のグラフィックライブラリを完成させています。ところがDOSエクステンダーを市販ソフトに組み込むには高額なライセンスが必要でしたから、自前の16bitモード←→32bitモード切り替えルーチンを使ってこのライブラリ（FGEライブラリという名称がついていました）を使用するようになっていました。が、市場がまだまだ小さいという点とWindowsの動向を見ようという理由から、結局256色モード用のソフト開発には到りませんでした。このFGEライブラリについては、別の機会にお話しすることにいたしましょう。

　Windowsの急速な普及に伴い、PC-9821シリーズは廉価なDOS/V機によって徐々に駆逐され、最終的にはNEC自らDOS/V機を発売するに到りました。風雅システム社内で培われたPC-9801シリーズに関するノウハウもほとんど意味を成さなくなりました。非常にもったいないような気もしますが、技術の世界というのはそういうもののようです。

　そして風雅システムはプラットフォームをWindowsに切り替え（当時はWindows3.1）、新たなノウハウの蓄積を開始し、現在に至ります。ただ、PC-9801時代は高速化のための技術がメインであったの対し、Windowsでは「安定性」「互換性」「保守性」などがキーワードとなります（いち早くMMXテクノロジに対応するなど、もちろん高速性にも留意していますけど）。
　Windows対応製品関連の技術公開はもうちょっと時間が経ってから。Tips形式でご紹介できればと思います。