« 2008年1月 | トップページ | 2008年3月 »

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に続く。

|

2008/02/18

レトロゲーマー マドカ!(14) 「読書の秋」

レトロゲーマー マドカ!(14) 「読書の秋」
 第14話です。子供の頃ファミコン買ってもらえなかったという話は前にしたことあるような気がしますが、攻略本を買ってもらって読んでいたという記憶はあります。で、ゲームやってないけどエンディングは知っているとかそういう状態(笑)。あと、その本を見てドット絵を描き写して遊んでたりもしていた、そんな子供時代でした。

 時城いずみ

|

2008/02/16

R・SYSTEM

 わざわざ永久保存版に特集ページまで作ってもらったりしたうち開発のRPGコンストラクションツール”R・SYSTEM”、今まで投稿含めて100本以上のRPGが製作されたわけだけど、販売本数としては約4000本だから単純計算でいくと、40人に1人がゲーム作ったという、ツクール系としては異様に活用された計算になる。
 実際のところ、一人で何作も作った人が多いんだけどな。
 でも、ここ数年単位でみるとさっぱりさっぱり、なのですよ。MSXマガジン永久保存版#3であれだけページさいてもらって、Windowsで動くバージョンも配布されたけど、さっぱりさっぱり、なのであります。
 原因は至極簡単。
 クロス開発ができなかからだと。
 Windows上でできるとはいっても所詮は閉じた空間なので、「当時としては」イベント記述言語としての先進性はあっても、MSX2上での閉じた空間になっているのでファイルの差し替えすらも今みると面倒であります。

 次、新作RPGコンストラクションツールを作るなら・・・とかそんな大それたことは思っていないんですが、まけシュー5は作りたいなぁと。
 突然シューティングゲームの話になるんですが、「おまけシューティング」略してまけシューって、実は2の時から敵キャラの配置データって簡易スクリプト方式になっていたんです。開発段階でしか公開していないんですけれども。
 テキストファイルで記述された敵キャラ配置データ、マップ表示データをMSX1上でその場でコンバートしてシューティングゲームとして成立させるというのは、構想としてはあります。大丈夫、できます。

|

2008/02/11

レトロゲーマー マドカ!(13) 「スポーツの秋」

レトロゲーマー マドカ!(13) 「スポーツの秋」
 第13話です。掲載当時の感想に「1,500m走をやったのかな?」というのがありましたが、MSX版のハイパーオリンピックに1,500m走があったというのは描いた当時は知りませんでした(汗)。おそらくマドカはそれをやったに違いありません。

 時城いずみ

|

2008/02/05

WAVEって漫画にMSXが

0205_msx表紙にいきなしPC88とか、裏にもMSXの文字があったので買ってきた。MSX世代には熱いコミックですよ、これ。
http://wave.kudan.jp/

|

2008/02/04

レトロゲーマー マドカ!(12) 「アダプター」

レトロゲーマー マドカ!(12) 「アダプター」
第12話です。今のゲーム機ではこの形状のアダプターはあまり見なくなりましたね。やっぱり危険だからか?(笑)。

 時城いずみ

|

« 2008年1月 | トップページ | 2008年3月 »