けろんゲーム作成ブログ

RPG制作7

気が付けば1月以上放置とか。
リアルで忙しかったのもあるけど、見た目に変更のある部分を作っていなかったもので。

次は戦闘を作ろうかな
↓
敵パーティのデータ作成ツールを作ろう
↓
戦闘開始のトリガーがないな
↓
スクリプト部分を少し作ろうか←いまここ

そして、昨年同様、6月頃までは仕事が忙しくて作業が進みそうになかったり。
まあ、のんびりやるさ。

RPG制作6

マップのレイヤーを複数にしていました。
キャラの下に2枚、上に1枚。
ついでにオートタイルにも対応。

マップチップが使い回しなので見た目がカオスだけど、機能の確認には問題ない。

オートタイルの実装はすべきかどうか悩んだ。
オートタイルを使うとプログラム的に負荷がかかるし、微妙なマップがかけなくなると思ったんだけど。
でも、マップチップ作成とマップ作製の手間を考えると、オートタイルがあった方が作業は早いよね。

しかし、オートタイルの参考にしようと思って調べていたら、最近のツクールでは色んな種類のオートタイルがあるんだな。
壁のオートタイルとかは便利そうだったけど、まあ、なくてもいいや。

……なんか、この辺りの機能を実装していると、ウディタでよかったじゃんという気分になってくる。
いや、戦闘とか、細かいシステム周りに手を入れ始めたら、きっと今の方が楽なはず。
多分。

RPG制作5

ちょっと仕事が忙しくなってきて、あんまり進まなかったけど。

結局データの保存形式は、シリアライズを使うのはやめて、自作のデータ形式にしましたさ。
車輪がうまく回らないのなら、自分で作ればいいじゃない。

シリアライズが有効なのは、きっと、もっとちゃんと設計をしてから作るようなデータ構造の場合。
趣味で作るいきばたで構造がぽこぽこ変わるようなプログラムには向いていないんでしょう。

RPG制作4

データ作成ツールまわりをいじっていました。
ゲーム本体は進展なし。

現在、データの保存形式で悩み中。

最初は、個々のデータごとにバイト配列にデータを放り込んで、ファイルに書き出しとかしていたんですよ。
読み込むときは逆で。
ただ、これが結構面倒くさいというか、時間がかかる。

なので、.NET Frameworkで用意されているシリアライズを使ってみることに変えたんですが。
確かに、短期的な開発時間は短くなります。
でも、変数の型や名前を変えるとデータが読めなくなります。

まあ、当り前なんですが。
読み書き部分を自作していた場合は、旧フォーマットからの変換は簡単にできたのに、シリアライズの場合はかなり面倒なことに。
できなくはないけど、むしろ手作業の場合よりも手間がかかってるんじゃないか？

シリアライズの長所と短所は、こんな感じか。

長所
・短期的な開発が早い。

短所
・データフォーマットの変更に弱い。＝結局総合的な開発時間は長くなる？
・データの中身を見てもわけわからん。XML形式のシリアライズもあるけど、制限が多くて使う気にならない。
・ファイルサイズが大きくなる。僕のスキルだと5～10倍くらい。

あれ。利点はどこだろう。
目先の便利さに惑わされただけだろうか。

このままシリアライズを使い続けるか、自作のデータ形式に戻すか。
判断するのは、まだデータが増えていない今のうちだなー。

RPG制作3

ステータス画面と、キャラクターのデータ周りの整備をしていました。

キャラデータの設定はやっぱり面倒くさいね。
戦闘処理作るくらいまでは、プログラム内に直打ちでテストデータを入れておくつもりだったけど、やっぱりデータ入力用のツールを先に作ろう。

そんなわけで、ツールの作成も並行して。
.NET Framework は見栄えにこだわらなければアプリを簡単に作れるので作業が早い。

RPG制作2

少し進展。

移動は、PCの足踏みアニメーションと、8方向向き変え、壁の当たり判定を実装。

メインメニューを呼び出せるようにもしたけど、こちらは呼び出しと消去のみ。
メニューの階層を掘り下げたり、ステータスを表示したりするのはまだ未実装。

まあ、順調に進んでいるんじゃないかな。

RPG制作

えー。かなり放ったらかしだったんですが。

ウディタで一からシステムを構築するのって、大変ですね。
データベースの形はもとより、イベント作成が大変です。
元からあるものを修正する分にはさほど気にならなかったんですが、一から構築しようとするとちょっと不便かなぁ、と。

そんなわけで、新しい環境を色々と探していました。

Windows でゲームを作るとなると DirectX を使うことが一般的なわけですが、どうやってこれを手軽に済まそうか、ということが問題でした。
DirectX の利用を簡単に済ませようとすると、一般的には Microsoft が用意している Managed DirectX や XNA を使うことになります。
しかし、この2つはプレイヤーにランタイムをダウンロードさせる必要があるのですね。
特に Managed DirectX の環境を整えるのは面倒臭い。

で、結局どうしようかというと、DXライブラリを使わせてもらおうと考えています。
DXライブラリはこちら。
ウディタでも使われているライブラリですが、僕はC#対応版を使わせてもらいます。

ただ、用意されているソースは、機械的に変換しただけのもののようで、ちょっとそのまま使うのは問題ありそう。
飽く迄参考にしつつ、DLLだけを使わせてもらう感じで。

# C/C++ って、関数の引数にポインタを渡す場合と配列を渡す場合の区別ないもんなぁ。
# 機械的に変換しただけじゃあ、混ざっちゃうよね。

そんな感じで、現状、2Dスクロールと、メッセージ用ウィンドウをなんとなく表示するところまでできました。

素材に悠久の迷宮で使用したものを流用しているので、見た目ウディタと区別つきませんね。

ゲームの仕様について悩むところは結構残っているのですよ。

現在は、1マス16×16ドットを2倍表示しています。
32×32ドットでもできるんですが、そうすると素材を作る時間がバカにならないので、どうしようかなぁ、と。

また、マップのスクロールは現在1枚しかありません。
最低でも2枚、キャラを挟んで上と下のマップが欲しいです。
理想としては、小物配置用のマップが1枚と、一番上にフォグをかけられるといいんですが。

現状はスクロールはしても、マスごとの侵入可否判定すらついてないんですけどね。

まあ、こんな感じでちまちまと形にしていきたいと思います。

以下、DXライブラリを導入するまでに調べた環境。

●SlimDX
Managed DirectX は Microsoft に見捨てられたのですが、後継の XNA には不満も多い。
そんな人に最適な、Managed DirectX と同様の感覚で使用できるフリーのライブラリがあります。
それが SlimDX です。

開発での使い勝手は結構良さそうだったんですが。
プレイヤーに環境を用意させるのは、やや面倒そうなんですよね。

インストーラを再配布できるらしいので、ゲーム本体と一緒に配布すればいいんでしょうが、サイズがでかいのも気になります。

●Flash (Action Script)
配布することを考えた場合、Flash は非常に強力です。
なんですが、Flash で RPG 作るのってどうなのかなーって。

もちろん、Flash 制の RPG はそれなりの数があるんですけど。
規模の大きいものになると、どうなんだろう？

それ以前に、文法的に気に入らない点もあったり。
# for 文のイテレータとして中で宣言した変数の寿命が for ブロックの外まであるとか。

ところで、Flash はもっさりとして重いというイメージを持っている人が多いかもしれませんが、それは間違いですね。
最近の Flash プレイヤーなら、普通に 60 FPS 出るようです。(環境によりますが)

悠久の迷宮27

悠久の迷宮がとりあえずの完成を迎えました。
形にするまで、思ったよりも時間がかかりました。リアルで忙しかったことが原因ですが。

DLページはこちら。keron.tuzigiri.com/dl/index.html
公開したところで宣伝していないから誰がDLするのかわからんけど。

さて、次は、基本システムを使わずに、システムも一から構築したいな。
ウディタのデータベースは仕様の変更に弱そうなので、可能な限り設計してから取りかからないと見た目が大変なことになりそうだ。

悠久の迷宮26

今週中とかいって、一か月放置してしまったわけですが。
数値設定そのものは確かに一週間だったんですが、戦闘してみるのって時間かかるね。

でもまあ、一通りの数値調整は終わったつもりで、現在は通しプレイをしながら細かい修正をしているところです。
次の週末には公開できるようになっているといいな。

さて、一か月前の話なんですが、ウディタのバージョン1.3が出ました。
Windows7(64bit)環境でイベントが見難かった点が改善されています。
これで僕の環境でも楽に編集できるようになりました。よかったよかった。

悠久の迷宮25

うぶ。
敵のデータ設定するのって、結構時間かかるね……。

でも、この調子なら、今週中には設定だけは終わりそう。
あとは、どのくらいテストプレイするかだけど。