RPGエンジン/基本仕様 - HSPでオープンソースRPG共同開発 @ ウィキ

RPGエンジン/基本仕様

• とりあえずは「ツクール」のような感じで良いかと思います。
• 早い段階で、「DQ・FF」タイプか「ポケモン」タイプかそれ以外かなども決めていきましょう！

エンジン内で使用できる変数データ仕様など

• とりあえず、プレイヤーのセーブデータとマップデータ、アイテムデータ、敵キャラデータは必須だと思いますが、どうでしょう？
• 他に必要なデータがあればコメントへお願いします。

• 変数名はある一定の規則で名づけると、後々の管理も楽になると思います。
• 例えばこんな感じで。

マップの最大サイズ
DT_map_xmax = 256
DT_map_ymax = 256

実際のマップ（地形）データ
dimtype DT_map, vartype("int"), DT_map_xmax, DT_map_ymax, 4

マップファイル仕様など

• マップエディタ本体に関する議論はこちらへ

• 一度に読み込むマップのサイズは固定か可変か、固定なら最大？×？か（例えば最大256×256とか）
• できれば2の乗数だとバイナリ的にも扱いやすいかと思います。

• マップはマップチップから逐次マップデータを自動で生成するタイプだと、

マップデータと少ないマップチップだけで済み、メモリ消費も少なくなると思います。

• rpgvar_map.as

rpgvar_map.as

////////////////////////////////////////////////////////////
; 
; マップデータ定義スクリプト
; 2008/06/25 修正（196 ◆RGuhLsdBoc）
; 
; ※ 追加や修正すべき点などあったら適宜変更していってください
; 
////////////////////////////////////////////////////////////
 
; マップの最大サイズ
DT_map_xmax = 256
DT_map_ymax = 256
 
; 実際のマップ（地形）データ
dimtype DT_map, vartype("int"), DT_map_xmax, DT_map_ymax, 4
 
; DT_map のデータの説明
; 
; 配列的にはこんな感じでしょうか．．．？
; ⇒ DT_map ( x, y, info )
; 
; x と y はマップ中のX座標とY座標で、info はそれぞれ．．．
; 
; 0 : 下層レイヤチップのX座標
; 1 : 下層レイヤチップのY座標
; 2 : 上層レイヤチップのX座標
; 3 : 上層レイヤチップのY座標
; 
; 今のところこんな感じです
; 
; 管理の面などから、地形属性フラグやチップアニメーションなどは
; 「チップデータ」として分離したほうがいいかもと思います
 
 

2007/07/01までに挙がっている案のまとめ

324 ：196 ◆RGuhLsdBoc ：2008/07/01(火) 12:35:23 ID:73rRIxDI
ちょっと時間ができたのでまとめてみます。

とりあえず現在までに出ているマップデータファイルのフォーマットは．．．

• XML形式（>>303◆GbVHcPwvTA氏の案）
• BMPフラグ形式（>>310氏の案）
• ローグライク形式（>>323氏の案）
• バイナリ形式（個人的な案、ARCSでも使っている）

※BMPフラグ形式については>>322氏が実際にサンプルを作成されています。
http://gamdev3.hp.infoseek.co.jp/cgi-bin/up/No_0298zip.html

※バイナリ形式については196◆RGuhLsdBocが作成したデモがあります。
※要望があればARCSで使っているマップエディタ（未完成ですが）もうｐってみます。
ttp://www.nintendo-fan.com/hspgamedev/arcs-rpg/arcsrpg.lzh

．．．現在までに挙がっている主な意見をまとめてみました。

チップセットファイル仕様など

• 最初にツクールのチップセット仕様に準拠するかしないかを決めておいたほうが良いのかな．．．

• チップセット画像のサイズと、チップ自体のサイズ（16*16など）も決めなければいけないと思います。

• チップ自体のサイズについては「16*16」か「32*32」あたりが無難でしょう。
• 個人的には「16*16」を推したいですが．．．反論があればどうぞ。

• 基本的に各チップの属性フラグの他、通行可不可フラグなどが必要だと思います。

チップセットファイルに必要なデータは

• 地形属性フラグ
• 通行可不可フラグ
• アニメーションの設定データ
• ．．．

くらいでしょうか。

画面・サウンド仕様など

• まだ決まっていません。
• とりあえず今は保留でも良いかと思います。

入力インターフェイス仕様など

• まだ決まっていません。
• とりあえず今は保留でも良いかと思います。

イベント関連の仕様など

• しばらくの間はこちらで議論していきましょう。
• 狭くなったらRPGエンジン/イベントへ移動する予定です。

• イベント関連を簡易的なスクリプトで実装すると、いろいろ汎用的な気がします。
• 参考サイト：イベントアクションスクリプトについて

ＨＳＰでＲＰＧ作ろうぜスレの286氏の案

286 ：名前は開発中のものです。：2008/06/21(土) 13:50:29 ID:wBHItpg7
(´･ω･｀)なんか気合の入ったスレだな。
面白そうだから、参加させてくれ。

>>280に便乗するけれど…。
今までRPG作成の経験は無いんだが、以前マップエディタを作った時に
必要だと思ったものと、データ形式について。

マップデータ
　├　チップの並び(チップ番号を格納した２次元配列)
　├　マップの付加情報
　│　　├　マップ名
　│　　├　使用するチップデータ名
　│　　├　マップのサイズ(レイヤ枚数、チップの大きさも含む)
　│　　└　読み込むオブジェクトデータ名
　■

287 ：名前は開発中のものです。：2008/06/21(土) 13:50:58 ID:wBHItpg7
チップデータ
　├　チップ番号(主キー)
　├　チップ画像名
　├　画像内のチップの座標
　├　チップの高さ(描画順)
　├　属性(壁など、毒沼とか作るときの為の複合選択可能にしとくべき)
　├　アニメーション情報　(これは独自に作ってもらったほうが……)
　│　　├　アニメーションのON、OFF
　│　　├　アニメーションの次の番号(チップ番号)
　│　　└　次のアニメーションにうつるまでの時間
　■

(※これは作ったこと無いから、どうなってるかワカランが空想)
オブジェクト情報
　├　オブジェクト番号(主キー)
　├　オブジェクト区分(人やアイテムなど付加できるとラク)
　├　オブジェクト名(あったほうが、メンテがラク)
　│　　　└　コメント(これもあった方が多分ラク)
　├　発現条件(どうしたらマップに登場するのか)
　├　発動条件(どうしたらイベントが発生するのか)
　├　発生するイベント番号(これによりイベントデータや処理にアクセスするという考え)
　■

ＨＳＰでＲＰＧ作ろうぜスレの289◆R7XM18kUMQ氏の案

293 ：289 ◆R7XM18kUMQ ：2008/06/24(火) 19:00:23 ID:pR31r7+7
>>292
ちょっと考えてみた。
前提1:マップには下層、上層、イベントのレイヤがあると仮定。
前提2:チップ画像は配列として持ってる。

• 下層レイヤ

湖、滝等アニメーションはこっち。
[チップNo]
[アニメ有無フラグ]
の2アイテムが必要。

• 上層レイヤ

樹木、立て札等。
[チップNo]のみ。

• イベントレイヤ

[イベント有無フラグ]
の2アイテム。

294 ：289 ◆R7XM18kUMQ ：2008/06/24(火) 19:01:04 ID:pR31r7+7
>>293の続き
別途イベントテーブルを定義。
[マップNo]
[マップX座標]
[マップY座標]
[チップNo]
[イベントNo](マップ座標単位に管理)
[イベント種別]
[イベント情報]
の6アイテム。

1プレイヤが移動する
2イベントレイヤのイベント有無を見る
3イベント有りならイベントテーブルからマップNo、X座標、Y座標をキーにイベントを取り出す。
4描画、壁の判定などなど。
壁とか毒沼みたいな下層、上層レイヤに影響されるイベントとゲーム作者が作るイベントを[イベント種別]で区別して、
マップエディタでは前者は非表示で自動定義、後者はエディタで編集可能。

長文失礼。自分のイメージはこんな感じかな。

ＨＳＰでＲＰＧ作ろうぜスレの 286◆GbVHcPwvTAの案、その2

さて、クソッタレ暇なので、>>286で書いた奴を元に
適当に書いてみるぞーっと。

[マップファイル]
　 ├ ファイルタイプ＆バージョン
　 ├ マップID
　 ├ マップ名
　 ├ 使用するチップセットファイル名
　 ├ マップの幅
　 ├ マップの奥行き
　 ├ マップのレイヤ枚数
　 └ チップの羅列データ
　　　　│
　　　　├ レイヤ１
　　　　│　チップ番号....チップ番号
　　　　│　チップ番号....チップ番号
　　　　│　チップ番号....チップ番号
　　　　│
　　　　├ レイヤ2
　　　　│　チップ番号....チップ番号
　　　　│　チップ番号....チップ番号
　　　　│　チップ番号....チップ番号
　　　　・
　　　　・
　　　　・
　　　　└ レイヤn

[チップセットファイル]
　 ├ ファイルタイプ＆バージョン
　 ├ チップセットファイルID
　 ├ チップセットファイル名
　 ├ 使用するチップ画像名
　 ├ チップの大きさX
　 ├ チップの大きさY
　 ├ チップの詳細情報の羅列
　 │　　│
　 │　　├ チップ１
　 │　　│　├ チップ番号
　 │　　│　├ 画像内の位置X
　 │　　│　├ 画像内の位置Y
　 │　　│　├ 描画順(プライオリティ)
　 │　　│　└ 属性
　 │　　│
　 │　　├ チップ２
　 │　　├ チップ３
　 │　　├ チップ４
　 │　　・
　 │　　・
　 │　　・
　 │　　└ チップn
　 │　　
　 └ アニメーション情報の羅列
　　　　　├ アニメ１
　　　　　│　├ チップ番号
　　　　　│　├ 次のチップ番号
　　　　　│　└ 次にチップにうつるまでの時間
　　　　　│　
　　　　　├ アニメ２
　　　　　│　
　　　　　・　
　　　　　・　
　　　　　・　
　　　　　└ アニメn

※ 補 足 説 明 ※

[マップID] や [チップセットファイルID] は作者が任意につける整数とする。
マップファイルの各マップの大きさは、チップ(レイヤ)の枚数で表す。(ドット数ではない事に注意)
レイヤは、レイヤの番号が小さい方が一番下で、番号が上がるごとに上へ上へとなる。
レイヤには、チップ番号が羅列(2次元配列と考えると分かりやすい)されており、その番号からチップセットを参照する。

[ファイルタイプ＆バージョン]については、今後、スレの発展と共にこの形態からファイルの形式が変化する事を見越して
バージョン情報のようなものを付加させて、仕様変更に対応する。(古いバージョンをコンバートしたり、うんたらかんたら)
このへんは正直決まってませんサーセン。
[チップの属性]については、後で説明する。

んで、ここまでざっと書いたが、これをバイナリファイル(bsaveで作る奴な)で作成すると
仕様が変わった時に大変だったり、目視で何が入ってるのか分からなかったり、
メンテナンス効率から鑑みてもよろしくないので、テキストベースで作るとするね。

XML分からないが、マークアップ言語のような記述で書いてみる。

↓マップファイル

<MAPFILE>

<FILETYPE>Ver.0.01 / 286original</FILETYPE>
<ID>1000</ID>
<TITLE>マップＡ</TITLE>
<TIPSET>チップセット草原.hst</TIPSET>
<WIDTH>64</WIDTH>
<HEIGHT>64</HEIGHT>
<LAYER>3</LAYER>
<MAPDATA>
 <TABLE>
  1,1,1,1, …… 1,1,1,1
  1,2,2,2, …… 2,2,2,1
  1,2,3,1, …… 3,1,2,1
  1,2,3,3, …… 3,1,1,1
  1,1,1,1, …… 1,1,1,1
 </TABLE>
 <TABLE>
  8,8,8,8, …… 8,8,8,8
  8,0,0,0, …… 0,0,0,8
  8,0,0,0, …… 0,0,0,8
  8,0,0,0, …… 0,0,0,8
  8,8,8,8, …… 8,8,8,8
 </TABLE>
 <TABLE>
  0,0,0,0, …… 0,0,0,0
  0,0,0,0, …… 0,9,9,0
  0,9,0,0, …… 0,0,9,0
  0,9,9,0, …… 0,0,0,0
  0,0,0,0, …… 0,0,0,0
 </TABLE>
</MAPDATA>

</MAPFILE>

↓次、チップセットファイル

<TIPFILE>

<FILETYPE>Ver.0.01 / 286original</FILETYPE>
<ID>20</ID>
<TITLE>チップセット草原</TITLE>
<BMPFILE>kusamura.bmp</BMPFILE>
<WIDTH>32</WIDTH>
<HEIGHT>32</HEIGHT>

<TIPDATA> 0,   0,   0,   0,   0 </TIPDATA>　　　　　←　チップの詳細情報を[チップ番号, 座標X, 座標Y, プライオリティ, 属性]
<TIPDATA> 1,  32,   0,   0,   0 </TIPDATA>　　　　　　　の形式で書いている。
<TIPDATA> 2,  64,   0,   0,   0 </TIPDATA>
<TIPDATA> 3,  96,   0,   0,   0 </TIPDATA>
<TIPDATA> 4, 128,   0,   0,   0 </TIPDATA>
<TIPDATA> 5,   0,  32,   0,   0 </TIPDATA>
<TIPDATA> 6,  32,  32,   0,   0 </TIPDATA>
<TIPDATA> 7,  64,  32,   0,   0 </TIPDATA>
<TIPDATA> 8,  96,  32,   5,   1 </TIPDATA>
<TIPDATA> 9, 128,  32,   0,   0 </TIPDATA>

<ANIME> 7,  9,  50, </ANIME>
<ANIME> 9,  7,  50, </ANIME>

</TIPFILE>

属性についての勝手な考え。
正直、この部分は、ユーザーが自由にデータを入れれるのが理想だと思う。
しかし、自由にデータが入れれるとなると、データの共有が難しくなる。
とするなら、4バイト分の領域を一応作っておく。
下8ビットまでは、固定の属性を割り当てて、残り24ビットはユーザー定義によるものとする。
┏━━━━┳━━━━┳━━━━┳━━━━┓
┃00000000　00000000　00000000　11010101┃
┗━━━━┻━━━━┻━━━━┻━━━━┛
　　　　　　　　　　　　　　　　↑この部分だけ固定、他はユーザーが自由に使っていい。
もしくは、属性って項目を二つ作って、一つは固定定義
もう一つはユーザー定義とするってのが簡潔かもしれない。

---