ゲーム開発

2008年3月 7日 (金)

RPGコンストラクションツールの話 2

「3バイト」
 1バイト=半角1文字。0〜255までの数値。3バイトとなると半角3文字か漢字1文字半ですね。
 1つの「実行コマンド」を3バイトで表現していました。1バイト目がコマンドの種類、残りの2バイトをデータ1、データ2。
例えば
・ パーティの座標を移動させる場合は
「移動させる」「X座標」「Y座標」
・ 文章表示の場合は
「文字表示」「表示させる文字列その1」「表示させる文字列その2」

 でもちょっと困ったのが、どこどこのマップパーツを何に書き換えるか、でした。
「マップを書き換える」「X座標」「Y座標」
 これだと、どこを書き換えるかは指定できても、どこを「何に」書き換えるかの指定ができません。
 4バイト必要になってくるのですが、そうなると必要となるバイト数が単純計算で33%増、同じメモリー内で表現できることも減ってしまいます。
 当時の思想としてはそれはさけたかったので、3バイトで4バイト分を表現できる方法にしたので結果として拡張性が犠牲になってしまいました。
 実行コマンドの命令を96種類以上増やせないんです。
 R・SYSTEM実行中は128KB(半角131072文字分)のうち殆どがデータで埋まっているので、空いているメモリーは1000文字分もありませんでした。
 その1000文字の中に入っているのが、R・SYSTEM3.2より追加されたマクロ命令です。
 1000文字あれば、1命令あたり3文字分のデータを必要とする「実行コマンド」が300命令ぐらい詰め込むことができます。その領域をマクロ用に開放してイベント中や道具の処理からいつでも呼び出せるようにしました。
 そんな感じで結構メモリはがちがちに組まれています。

その3に続く。

2008年2月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年2月16日 (土)

R・SYSTEM

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

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

2007年3月18日 (日)

MSXソフト開発環境その1

0317labo Syntax開発室のimahiブースでのMSX関連の開発環境です。
 MSXターボR(A1-ST)にMEGA-SCSIと外付けフロッピーディスクドライブを接続、MEGA-SCSIには230MのMO2台とSCSIでコンパクトフラッシュにアクセスできるドライブを増設しています。
・ 外付けディスクドライブ
・ MOドライブ 通常の状態であればMSX+SCSIでは32メガ単位しかアクセスすることができないわけですが、MOだとディスクを入れ替えれば済むのでMSX用の接続機器としてはMOを使用しています。
 1台がMSX用の先頭32メガがMSXになっている物、もう1台は通常のMS-DOS用のMOになっています。以前にMOのドライブ自体が壊れて厄介なことになったので安全のため全く同じ機種を用意して、万が一の予備としての役割も兼ねています。
・ SCSIでコンパクトフラッシュにアクセスできるドライブ このドライブにコンパクトフラッシュとSDカードのアダプタをつけることでMSX実機でもSDカードにアクセスすることができるので1チップMSXとのデータのやりとりが容易になります。
・ モニター 貴重なMSX用RGBディスプレイはグラフィック担当スタッフに配分して、imahiブースではPSoneコンボをMSX用モニターとして使っています。画面は小さめですが液晶の質はいいですし、何よりMSXの電源を入れると自動的にPSoneの液晶の電源も入るのがいいですね。
・ ジョイパッド MSX用のATARI端子コネクタにPS用ジョイパッドを接続するアダプターを使って、いらなくなったPSone用ジョイパッドを使っています。
・ 台所用食器棚 アルミ製の台所用の食器棚にちょうどターボRの横幅とぴったりのものがあったので、それを
MSXに装着して、その棚の上にMSX関連の周辺機器を置いています。
・ 拡張スロット クォースが4本ささっています。特に開発とは関係無いです。