どんばのデータ
更新日付 1998-07-15
バスケのゲーム「どんば」で扱うデータ構造をまとめました。
ここではまだ紹介していませんが、音楽はX68000のMDXを使いました。
ゲームはプレイヤ一人が自由自在に動くようになりました。
ディフェンス側はまだ登場するだけですが、音楽や効果音も鳴っています。
・作業の分担
取り掛かる作業を洗い出してみます。
絵がなければプログラムには取りかかれません。
まずは手足などの各キャラを描きます。
これはパソコン通信などで手に入るフリーウエアで、
気に入ったグラフィックツールで描きます。
PC-98でのおすすめはEXLOUPE、マルチペイントのルーペとしておなじみです。
ここの「他人の道具箱」にも登録されています。
X68000だとLOUPE(ここには未登録)です。
並行してポーズデータも作ります。
描いたキャラをポーズデータとして並べるために、
専用のエディタを作った方がいいでしょう。
それから、背景となるコートなどを、
BGデータとしてマップエディタのようなもので描かないといけません。
作業は余っているPC-98互換機で行なうことにしました。
DOS環境でしか使えないPC-98なんて、ゲーム1本より安く買えます。
狙い目は、Windows3.1が出た頃のPC-98でしょうか。
PC-98互換機であるPC-486MUなら、
メモリ16MB、HDD、CD-ROM付きで\30,000ほどで買えるでしょう。
知人や彼女など、周りに優秀なこびとさんがいれば、
開発環境を貸し出して半月ほどでできると思います。
もしあなたがコンテストに入賞する自信があるなら、
対価を払ってでもいいキャラを手に入れるべきです。
・ツールいろいろ
ゲームを作るには、ゲームで使うデータを作らなければなりません。
そのデータを作るためのプログラムも必要です。
ここでは、これをツールと呼びます。
プログラム能力が低い人は、ツールを作るだけで力尽きるでしょう。
力尽きたとしてもプログラム能力は確実に上がりますから、
むだにはなりません。安心してください。
ところで、ツールも満足に作れないなら、
なるべくデータの少ないゲームを設計すべきです。
いきなり、スト2みたいなゲームなんて漠然と考える人は、
いっぺん死んだ方がいいでしょう。
そしてなるべくなら生き返らないでください。
・ポーズエディタ
ゲームに登場するプレイヤを表示するには、
OBJ(スプライト)が適しています。
プレイヤは複数のOBJを組み合わせて表示するので、
今回は専用のポーズエディタを作りました。
マップエディタを作った経験があったので、
比較的さくさくと作ることができました。
圧縮されていないグラフィックデータを扱うのは面倒です。
そこでPi形式で描いたデータを扱います。
X68000やPC-98で描いた16色のグラフィックを
Pi形式でセーブします。
Piファイルを読み込み、左上128×256ドットを、
16×16ドットのOBJ(スプライト)として考えます。
すると、OBJ(スプライト)番号は$000,$002,$004,$006,...となり、
次の行では$020,$022,$024,$026...と考えることができます。
$1eeまでが使えるので、全部で128個のOBJが使えます。
これをPC-98で扱いやすいように加工します。
PC-98はゲーム機に比べて解像度が高いので、
そのままのドット数で表示すると小さくて不便です。
そこで縦横共に2倍して表示することにしました。
表示の際に処理すると重くなるので、
あらかじめデータを横2倍にして持つことにします。
縦は表示する時に拡大するのでそのままです。
それからキャラクタの重ね合わせを見やすくするため、
輪郭だけを表示することにしました。
という考えで、ポーズエディタPEDITを作ってみました。
データ形式は別に解説します。
・マップエディタ
コートを描くにはBG画面が適しています。
マップエディタを作って、それでコートを描くことにしましょう。
Piファイルを読み込み、左上128×256ドットを、
8×8ドットのBGキャラとして考えます。
BGキャラ番号は$00〜$ffとなります。
SFCのBGキャラは最大1024個まで使えますが、
貴重なV-RAMをムダに使わないよう、256個までを扱うことにします。
つまり、$00〜$ffとしいうことですね。
こうして作ったBGキャラを横ではなく、
なぜか縦(すまん)に並べます。
この前は横スクロールのゲームを作ったのですが、
マップエディタはそのときに作ったやつなんです。
・データの構造
データの構造について説明します。
ソースプログラムのように記述してありますが、
ツールが吐き出すのはバイナリファイルです。
バイナリファイルとしてリンクしてください。
ツールがあってもそのデータ構造がわからないと、
プログラムでは利用できません。
アスキーから発売になっているキャラクターツクールも、
データ構造がマニュアルに載っていないので使い物になりません。
・ポーズデータの構造
関節のあるキャラを動かす場合、
腕や足といった個々のスプライトが、
どのようにつながっているのかを管理しなければなりません。
その情報をポーズデータと呼びます。
------------------------------------------------------------
ポーズデータはこのように設計しました。
pose00:
db x,y,sp,atr ;頭
db x,y,sp,atr ;胴体
db x,y,sp,atr ;腰
db x,y,sp,atr ;左肩
db x,y,sp,atr ;左手
db x,y,sp,atr ;左腿
db x,y,sp,atr ;左足
db x,y,sp,atr ;右肩
db x,y,sp,atr ;右手
db x,y,sp,atr ;右腿
db x,y,sp,atr ;右足
db x,y,sp,atr ;ボール
------------------------------------------------------------
一つのキャラは、
x座標、y座標、キャラ番号(スプライト番号)、属性で表され、
各1バイトづつで計4バイト、これが手足の1パーツとなります。
この手足12パーツ一組で、ポーズデータとするので、
1ポーズは4×12=48バイトとなります。
これを状態ごとに何パターンも用意します。
状態というのは、ドリブル、チェンジ、シュートなどです。
状態それぞれに何ポーズも必要ですから、
膨大な量のポーズをモデリングしなければなりません。
プログラムでは、今どんな状態なのかを表すために、
今、どんな動作をしているのかという情報と、
その動作の何ポーズ目なのかという情報が必要です。
・マップデータの構造
マップデータは画面を縦にスライスした状態で並んでいます。
1バイト目は左上キャラ、2バイト目はその一つ下のキャラです。
左下のキャラは32バイト目ということですね。
このようにBGキャラを32個づつ並べたものを、
32本並べると1画面ができあがります。
よって、1画面は32キャラ×32列=$400バイトです。
なお、マップエディタ自体は、上下左右反転の属性情報も、
別ファイルで吐き出すようになっています。
これを使うと左右対称の背景を描く場合に便利です。
DMAでさくっと転送するわけにもいかないし、
横方向に並んだマップデータの転送とくらべて面倒です。
以下に転送の例を示すので、参考にしてください。
------------------------------------------------------------
MAPE形式のマップを描く例
disp_map:
off16a
sep #$20
lda #$81 ;address +1 at $2119
sta $2115 ;VMINC
on16a
on16i
rep #$30
ldx #$0000
ldy #BG1SC0
_loop:
sty $2116 ;VMADDL/H
; jsr wait_vblank ;必要ならVブランクを待つ
_put:
lda map_data,x
and #$00ff
sta $2118 ;VMDATAL/H
inx
txa
and #32-1
bne _put
iny
cpy #BG1SC0+32
bne _loop
rts
------------------------------------------------------------
質問には答えます...
koh@inetmie.or.jp