…困ったものです。
全然ゲームを作る気が起こらないのです。
でも、ツールを作る気は満々にあるのです。
というわけで、現在私が製作中のマップエディタ(※1)について、宣伝も兼ねていろいろ語っていきたいと思います。
ゲームプログラマーなら誰しも（？）が持つ感情の中に、「あ〜、RPGつくりたいな〜」という想いがあります(※2)。しかし、実際にはRPGなんて一人で作れるもんじゃありませんし、一人でRPGを完成させられたならば、それは天才の成し得る技か人並みならぬ努力の結晶でしょう。そもそもRPGはやることが多すぎます。プログラム、キャラクタ、マップ、効果音、音楽、シナリオ、ストーリー、戦闘システム、…などなど、思いつくだけでこれだけあります。
さらに、データを用意するのもまた一苦労です。絵や音はともかく、マップやシナリオの記述などにテキストエディタやバイナリエディタを駆使することになるでしょう。しかし、バイナリエディタでの編集は何をやってるのかが一目でわからず、テキストエディタで編集されたデータは直接扱わず、何らかの変換を行って利用することがほとんどだと思われます。とすると、プログラマはそのための変換ツールを---RPG本体のプログラムとは別に---用意しなければなりません。そしてそのようなツールを作っているうちに、だんだんRPG本体のプログラムがおざなりになり結局制作をあきらめてしまったことがある人はプログラマの数の4分の1ぐらいは居るでしょう(※3)。
そこで私は考えました。
「そんなプログラマの手助けになろう」---と。
…とか書いてると、非常に聞こえがいいですが、どうも自分はあまりゲームを作るのに向かなくなったんじゃないかなぁと思ったのが本音でもあります(※4)。それならツールでも作ってサークルの人の役に立てればいいかなぁと、ツール作りをはじめたのです(※5)。
しかし、なぜ今更マップエディタなのか。
マップエディタと名のつくものなら既にフリーでいろいろ出回っているではないか。
…確かに、既にそのようなソフトは数多くあります。しかし、それらのマップエディタはいざ自分で使ってみようとすると、
等といった不満も少なからずあると思います。なかでもファイルフォーマットを自分で決められないのは、変換前後のデータファイル管理の点で圧倒的に不利になります。
そこで、私の作るマップエディタは既にあるようなマップエディタの模倣などではなく、「ファイルフォーマットを自由に決められるエディタにしよう」と考えたのです。もちろん、操作性も損なってはなりません。できれば、障害物の配置も行えるといいですよね。そのようなことを考えて、私の作ろうとするマップエディタの目標はだいたい次のようになっています。
現在一部の3年生を中心に、RPGを制作するプロジェクトが進んでいます。プロジェクトおよび制作ゲームについての説明は別ページを参照していただくとして、現在私の作っているマップエディタは最低でもそのプロジェクト向けにマップ編集ができるようになることが大きな目標です(※6)。
今回は、VS.NET2003(※7)でC\#言語を用いることに決めました。C\#言語を用いると、GUI周りの開発がVBライクに行えることと、オブジェクト指向を進化させたようなコンポーネント指向言語であり、C/C++言語以上に安全なプログラムが組めるものと判断したためです。もっとも、C\#言語を用いるということは、実行環境に.NET Frameworkが必須になるというデメリットがありますが、現行のOSなら対応しているはずですのでそんなに大きな問題ではないでしょう。
マップフォーマットを自由に決めるにはどうしたらよいか---その答えは「プラグイン」です。有名な画像ビューアにSusieというものがありますが、あれと似たような感じです。ただし、プラグインの作り方はおそらく大きく異なります。Susieプラグインはプログラムで決められた内部データ構造に合わせてデータを出力します(※8)。私の作るマップエディタのプラグインは編集するデータ構造自体を記述します。オブジェクト指向が多少わかる人向けに書くと、「エディタで用意してあるマップファイルを表したクラスを派生して、独自のマップファイルを扱えるようなクラスを自分で作れ」ということになります。
このようなプラグインを実現するためには、マップエディタで扱うデータ構造を抽象化する必要があります。この抽象化は、出来る限り多くのファイルフォーマットに対応できるようにしないといけないので、多くの時間を費やして慎重に構造を決めました。
快適操作のために絶対に必要なことは、マップ表示の高速化が重要な課題になります。そのために利用した技術として、「DIB(※9)とDDB(※10)の併用」および「マップイメージの再利用」をあげることが出来ます。
C\#上（正確にはGDI+上）での画面表示は、基本的にDIBを用いて描画を行います。が、このDIB、描画速度が遅すぎて使い物にならないのです。32×32の小さなイメージでXGA($1024\times768$)の画面を埋めるのに平気で数秒から数十秒時間を取られます(※11)。これでは快適操作など考えられないですね。というわけで、次に思いつくのはDDBを用いた描画です。しかし、DDBは高速ですが、その代わり半透明処理などの複雑な画像効果を得ることが出来ません。複雑な画像効果を得るならやはりDIBです。さあどうしましょう。
そういうわけで、画像効果はDIBで行い、画面表示はDDBを用いる方法を考えました。表示されるイメージに対して特殊な操作（例えば少し暗くするなど）はDIB上で行い、それをDDBに変換しておいていざ画面表示を行うときはDDBを用いればいいのです。ここでDIB→DDBへの変換が行われていますが、これは元となるDIBに変更があったときのみ行われますので、パフォーマンスの点では問題ありません(※12)。
複数レイヤーの重ねあわせ時に半透明処理が出来ると少しは便利になりそうですが、この際きっぱりとあきらめてしまいました(※13)。その代わりといってはなんですが、単色カラーキーつき転送(※14)はDDBでも速度を落とさず実現できますので、これを実装しました。
もう一つ、マップイメージの再利用については、まさにそのとおりで、 マップをいったんバッファに描画しておき、 画面に表示する時はバッファから切り出して表示する手法をとりました。 そして、画面がスクロールされると、 バッファの再利用可能な部分をバッファ内で転送して 余った部分にマップチップを描画するようにしました。 このため、マップのスクロールも非常に高速になり、 さらには画面のちらつきも隠すことが出来るようになりました。
で、現状はこんな感じです（上図参照）。とりあえずプラグインの管理、マップ表示、パレット表示、レイヤーの管理が大体出来るようになっています。まだマップチップをマップに置くという編集部分が未実装のままです。編集に関しては、アンドゥや矩形転送の処理がネックになりそうです。
正直マップエディタにはあまり時間を取れなくなってきているので、この本が皆様の目に触れる時にはまだ完成してない可能性のほうが大きいです。それでも無事に完成するといいなぁ…とこんなことを思ってこの文章をおしまいにします。最後までお読みいただきありがとうございました。
（2004/10/24 古川 史幸）