« レトロゲーマー マドカ!(14) 「読書の秋」 | トップページ | レトロゲーマー マドカ!(15) 「果てなき挑戦?」 »

2008/02/26

RPGコンストラクションシステムの概念。

従来市販されていたRPGコンストラクションツールは、例えば
・ 宝箱には何ゴールド入っていて
・ このキャラはこのセリフを喋って
・ ここに道具屋を配置
 そんなベースとなる枠組みがあった上でのRPGコンストラクションツールが多勢を占めていたわけなんですが、そういった概念をつき進めていくと
・ 宝箱にアイテムを入れれるようにしよう
・ このキャラはイベントキャラ
 そんな「設定の多様化」によってツールを進化させられるわけなんですが、そういった方法をMSX2でとりいれるには現実的に問題があったんです。

 例えば、MSX-BASIC上であればマシン語を多用していても、4人パーティのRPGを作るというのはメモリー的に厳しいんです。できなくはないけど厳しい。マシン語を組み入れたりして、ブログラムを分割させたり途中で読み込ませたりすれば別なんですけれども、RPGの基本的な部分、例えば「フィールド処理」、「武器の装備」、「戦闘シーン」、「イベントシーン」といったものを一括のブログラムで処理するには厳しいメモリ領域なんです。
 MSX・FAN ファンダムやMSXマガジンプログラムコンテスト等で、RPGの投稿作品は多くても、パーティシステムを採用した作品となると結構数が限られてきます。
 MSX2のRAMが64KB(キロバイト)といっても、MSX-BASICだけでは前半の32KBは使えないし、DE40H以降はバッファやらなにやらの領域なので使えないという制約があるので、マシン語を多用するか、戦闘シーンは別ブログラムをロードする、とかしないといけないわけだったんですが、フロッピー全盛時でしたので後者はありえないだろう、ということでマシン語を多用しつつ別の方法を探るという形で試行錯誤を続けていました。
 RAMが少ないなら、VRAMってプログラム領域に使えないかなぁ?
 というのが RPGコンストラクションツールの最初の発想だったように思います。
 RAMとVRAM似たようなものでVRAMのほうが128KBと容量が大きいのですが、例えばVRAMに直接プログラムを置いて動かすといったことはできません。
 VRAMにマシン語などのブログラムを一時的に退避させて、必要な部分だけをVRAMから読み込むといったことはわりとよくある芸当の1つでR・SYSTEM等でも多用していますが(そのおかげで、後からの大改造がしにくかったんですが)。
 イベントの表示方法によくある、
・ メッセージを表示する
・ キャラクターを表示する
・ アイテムが手に入る
 といった処理をデータ化して、そのデータをVRAM上に配置すればRAMを圧迫せずに複雑なイベントを少ないメモリーで処理できるんじゃね? ってのがそもそもの発想点です。
 最初のうちは イベントのメッセージの文章データやマップデータ、ステータスといったものをVRAM上に置いて、RAM上にはできるだけデータ類を置かないといったことからとりかかります。
 それでいくつか作っているうちに、RPGに必要な要素を全部VRAMにデータとして配置して、イベントデータだけでなく、戦闘シーンや道具を使った時の処理も共通化すれば、圧倒的に少ないメモリでRPGの基本ブログラムが作れるのではないだろうか、
 というのが、SyntaxにおけるRPGコンストラクションツールのはじまりです。
 この時点ですでに イベントシーンと戦闘シーンと道具等の処理を同列に扱うというR・SYSTEMの基本構想はあがっていました。
 イベント記述の方式と同じ方式で道具の設定ができる、同じ方式で敵キャラの行動パターンを設定できるというのは当時としてはなかなか画期的なことではなかったかと思います。
 そうこうして、共通の96命令による「実行コマンド」(あぁ、もうちょっとちゃんとした名前にしておけば)方式による、RPGのシナリオの記述方法が模索されていったわけですが。
 命令数こそ96命令でRPGで必要なものに限られてはいましたが、「ビジュアル簡易言語」としての必要最低限のものはあったような気がしないでもない。
 このビジュアル簡易言語をもう一歩薦めたのが 3.2より導入された「マクロ命令」。
 あらかじめ登録しておいた「パターン」をいつでもどの状態でも呼び出せるので、複雑な処理をする道具や敵キャラが設定できるようになりました。

 ここまでが既に発表されたものですが、これをさらに推し進めた考えとしてRPGに必要な
・ フィールド画面の描画
・ 戦闘シーンへの画面の書き換え
・ 戦闘シーンが終わった時の処理
 そういったゲームシステムの基幹に関わるこれまでだったらブログラムであらかじめ処理していた部分も、VRAMにデータを置いた形でのビジュアル簡易言語で設定することで2つのメリットがあるんですよ。
1 データとメモリを節約できる
2 ユーザーが自由に設定ができる
 これで、自由度もあがるし、開発効率も良くなる・・・と。

その2に続く。

|

« レトロゲーマー マドカ!(14) 「読書の秋」 | トップページ | レトロゲーマー マドカ!(15) 「果てなき挑戦?」 »