旧ロボットのウディタぼやき

WOLF RPGエディター(通称ウディタ)に関して気づいたこととか、ぼやきとか、開発状況とかを書いています

明かりの実装&その他もろもろ

2010-04-10 17:45:19 | 開発

ウディタでローグライク開発第19弾。
まだまだ、ゲームをブラッシュアップ中です。
今回は、ミニマップとトラップの機能を強化&明かりを実装しました。

竜の迷宮ver1では、ダンジョンが広範囲に見渡せるようになっており、ミニマップも、地図が全表示+モンスターの位置がまるわかりの状態でした。
今回でそれらを修正。
プレイヤーの視界を制限して、視界内のモンスターやアイテムなどのみをミニマップに表示、歩いた位置から地図を描画していくようにしました。
また、トラップの機能も強化。
初めはトラップが見えない状態にしておき、プレイヤーがその上を通過しようとすると、トラップが現れて効果を発揮するように機能を追加。

↓こんな感じになりました(これは開発中のものです)
【開発動画】ウディタでローグライク【明かりの実装】


明かりの機能だけ補足します。
明かりは、プレイヤーが部屋にいる場合と通路にいる場合とで、表示方法を変えてます。
部屋にいる場合、タイルセットで★に設定したオートマップ用チップを使い、部屋を囲うようにマップチップを塗りつぶすことで、明かりを実現しました。
通路にいる場合は、真ん中に穴の開いた真っ黒の画像を、画面上に表示させるようにしています。


【お知らせ】
今年の4月から、私は社会人となりました。
そのため、今は週末くらいしか、ゲーム制作にまともな時間をあてられなくなっている状態です・・・。
ブログの更新頻度も、今後どんどん少なくなるかもしれません。
竜の迷宮ver2のテストバージョンを、ゴールデンウィーク中に公開しようと考えてますが、正直な話、この時期に公開できるかどうかの目処はまだたってません><
(こうなることが考えられたので、本当は3月中にバージョンアップしたかったのですが、間に合いませんでした・・・)
場合によっては、また公開時期を延ばしてしまうかもしれません。
まったりと、気長にお待ちいただければ幸いですm(_ _)m


キャラの移動

2010-03-26 00:22:37 | 開発
ウディタでローグライク開発第18弾。
現在、ゲームをブラッシュアップ中です。
3月中のアップデートは不可能になりました、ごめんなさい><
一通りの調整が完了したら、ver2のテストバージョンを公開する予定ですが、これはかなり先の話になりそうです・・・。

さて、本題へ。
今回は、キャラの移動処理を調整しました。


今までは動作指定でキャラを移動させていましたが、変数呼び出し値を使って移動させるように仕様を変更しました。
変数呼び出し値の9180000+Xなどを使用して、主人公やイベントの座標を変更すると、自動的に指定した位置へ主人公やイベントが移動してくれるという、隠し機能があるそうです。(教えてくれた方、ありがとうございます)
しかも、キャラに設定した移動速度をちゃんと反映し、すり抜けを無視して移動するので、ローグライクでのキャラ移動に近い動作を再現することができました。

しかし、ただ変数呼び出し値に値を代入するだけでは、キャラの移動に違和感が生じるので、やることがいくつかあります。

まず、移動方向にキャラの正面を向かせないといけません。
変数呼び出し値で移動させる場合、キャラの向きはそのままですので、座標を代入する前に、動作指定で向きを移動方向へ変更します。

次に、座標を代入する際、カウンタを1キャラに対して1つ用意します。
このカウンタは、0より大きい数値で初期化され、キャラが移動している間、1フレーム毎に1ずつ減っていきます。
そして、カウンタが0より大きい場合は、変数呼び出し値で座標を代入できないようにします。
なぜ、わざわざこのようにするかと言いますと、変数呼び出し値での移動は、移動の途中に別の座標を代入すると移動が中断され、新しい座標へ移動できてしまうためです。
特に主人公の移動の場合、方向キーの入力に応じて変数呼び出し値に座標を代入していると、方向キーで細かな動作をさせたときに、主人公の移動が不安定になってしまいます。
カウンタを設定することで、キャラの移動を安定させることができました。

さらに、このカウンタは少し長めに設定するのがミソです。
1マスの移動が完了してから、1フレーム時間くらい(正確にはわかりませんが・・・)の余裕を持たせます。
こうすることで、1マスの移動が完了するたびに、システム変数35番「主人公移動中?」が0になります。
変数呼び出し値に座標を代入する方法だと、キャラの位置を直接書き換えるので、イベントコマンドや変数呼び出し値のキャラ位置を取得する操作では、移動が完了したかどうかの判断が難しくなってしましました。
そのため、このシステム変数35番が0かどうかを判定することで、キャラの移動完了を判断するようにします。


動作指定を利用する場合よりも、調整がかなり面倒ですが、キャラ移動の挙動が本場のローグライクゲームに近くなりました。
さらに、モンスターの移動AIも少し賢くなったので、まさに一石二鳥でした^^

例によって、文章での説明だけではわかりにくいと思いますので、私が実験用に作成したゲームをアップします。
これは、以前にアップした「動作指定での主人公移動サンプルゲーム」を改造したものです。
変数呼び出し値を使用した移動のサンプルゲーム

ダンジョンの店

2010-03-14 16:38:33 | 開発
ウディタでローグライク開発第17弾。
今回、ダンジョン内で買い物ができるようにしました。
私が絶対に実装したいと思っていたシステムの1つなので、楽しみながら作成しました^^

イメージ的には、トルネコ2で登場するものと同等です。
ある1つの部屋をまるまる店にし、部屋の入り口のそばに店主が待機しているという形式です。
店の中に落ちているアイテムが商品となっており、それを拾って店主に話しかけることで、その商品を買うことができます。
また、手持ちのアイテムを店の適当な位置に置いた後、店主に話しかければ、そのアイテムを売ることも可能です。
このような感じになります。
(これは開発中のものです。内容は変更される可能性もあります。)
【開発動画】ウディタでローグライク【ダンジョンのお店】


ただ、店を実装するにあたって、2つの大きな問題がありました。
それは、
・アイテムの売買をどのようにするか?
・店主のAIをどうするか?
です。
これらをどのようにして実装したかを、簡単に説明します。
ここで、「店をどのようにしてダンジョン内に作るか?」
も問題になりますが、これは前回実装した、モンスターハウスを作る処理を流用することで簡単に実現できました。

1.アイテム売買
まず、買うアイテムを保持するリスト・売るアイテムを保持するリストを用意します。
次に、アイテムが「地面→手持ち」または、「手持ち→地面」に移動するタイミングを監視。
店の商品が拾われたら、買うアイテムリストへ追加し、店にアイテムが置かれたら、売るアイテムリストへ追加。
そして、店主に話しかけると、買うアイテムリスト・売るアイテムリストにデータがあるかどうかを確認し、データがあればアイテムの売買を行います。
アイテムの売買が終了したら、買うアイテムリスト・売るアイテムリストを初期化。

2.店主AI
AIといっても、大したものは作ってません。
店主となるモンスターを、状態異常のシステムを使って「店主状態」にします。
そして、モンスターのAIを処理するときに、モンスターが「店主状態」になっていれば、店主独自の行動をさせます。
具体的には、先程出てきた買うアイテムリストにデータがある場合は、部屋の入り口をふさぐように移動する。
買うアイテムリストのデータがなくなったら、元の位置に戻るように移動します。


このようにすることで、ダンジョン内で買い物ができるようになりました。
そして、ダンジョン内の店ならお馴染みの、ドロボー行為も可能です。
商品の位置、プレイヤーの位置は常に監視しており、
商品が店の外に出た場合や、買うアイテムリストのデータが残っている状態で、プレイヤーが店の外に出ると、ドロボー状態になります。
ドロボー状態になった場合、店主が凶暴化し、襲い掛かってきます。
どのようにして店主を凶暴化させるかといいますと、実は「店主状態」を外すだけで済みます。
店主をわざわざ状態異常で実装したのは、このためでした。
そして、通常のモンスターは自動生成されず、代わりに店主のみが生成されるようになり、その頻度も通常より多くなります。
このドロボー状態は、階段を下りるまで続きます。
以下に、ドロボー状態になったときの動画を用意しました。
ズルをして、プレイヤーが壁を通れるようにしています。
(これは、開発中のものです)
【開発動画】ウディタでローグライク【ドロボー!】


これで、竜の迷宮ver2に実装する予定だったシステムは全て作成しました。
これからは、データ入力、難易度設定、ゲームバランスの調整の段階に入っていきます。
いままでに実装したシステムも、まだまだ不安定な部分があるので、この段階でブラッシュアップさせる予定です。

実は、アイテム鑑定システムも作成したいのですが、これは2作目ローグライクで実装します。
とりあえず、3月中には竜の迷宮をバージョンアップさせたいと思っているので、それに間に合うようであれば、アイテム鑑定システムも竜の迷宮ver2へ実装しようと考えています。

モンスターハウス

2010-03-05 14:35:04 | 開発
ウディタでローグライク開発第16弾。
今回は、モンスターハウスの実装をしました。
竜の迷宮ver2では、ちょっと変わった方式のモンスターハウスを導入します。


トルネコ等において、モンスターハウスのモンスターは、あらかじめ1つの部屋にギュウギュウに押し込められ、眠った状態で待機しています。
その部屋に突入すると、「モンスターハウスだ!」というメッセージとともに、寝ていたモンスターが一斉に起き出し、冒険者に襲い掛かってくる、というものでした。
ですが、別バージョンのモンスターハウスもあります。
ポケモン不思議のダンジョンシリーズでは、はじめからモンスターは存在しません。
部屋に突入すると同時に、大量のモンスターがその部屋に召喚され、主人公チームに襲い掛かる、という形式をとっています。
(以降は、前者のモンスターハウスを「眠らせ式」、後者を「召喚式」と呼びます)


竜の迷宮ver2では、「召喚式」のモンスターハウスを採用します。
なぜかといいますと、1番は動作の問題です。
現段階の仕様だと、モンスターの数に比例してゲームの動作が重くなります。
試してはいないのですが、「眠らせ式」だとモンスターが大量に存在するためにゲームの動作が悪くなり、そのために「モンスターハウスがあるな」と判断される可能性が考えられました。(トルネコ3〔GBA版〕ではそうでした)
それではおもしろくありませんし、動作の関係上、いろいろ都合が良かったので、この方式にしています。

もう1つの理由は、難易度の問題です。
「眠らせ式」では、モンスターハウスの存在がわかれば、寝ているモンスターを部屋に入る前に倒してしまう、ということができました。
しかし、「召喚式」では部屋に入らないとモンスターが登場しないので、そのようなことはできません。
モンスターハウスを通るためには必ず、大量のモンスターを相手にしなければならない、という仕様にしました。
こうすることで、ダンジョンの難易度が上がります。
ver1はコンテスト用ということもあり、難易度をかなり下げてしまいましたので、ver2は難易度を高めに設定しようと考えています。
ですが、初心者の方のために、「EASY」「NORMAL」「HARD」と難易度の選択ができるようにする予定です。

この2つの理由で「召喚式」を採用した結果、こんな感じになります。
(これは開発動画です。内容は変わる可能性もあるので注意!)



難易度選択に関する話がでましたので、あくまで「現段階の予定」ですが、ここでちょこっと各難易度の紹介をしたいと思います。

「EASY」はver1とほぼ同じです。
敵を弱く設定し、「モンスターハウス」や「店」などの要素は排除。
ローグライク初心者向けに、初見クリア可能な難易度にしようと考えています。

「NORMAL」は敵を「EASY」よりは強く、「モンスターハウス」や「店」といった特殊部屋の要素を、控えめに取り込む予定です。
「EASY」ではもの足りない、またはローグライクに少し慣れている人向けにします。

「HARD」はローグライクに慣れている人でないとクリア不可。
「EASY」と同じ感覚でプレイしたら軽く死ねるレベルにしようと考えています。
「モンスターハウス」等はもちろんのこと、初見殺しの固定マップも用意しようかと検討中です。

難易度は初めから全て選択可能にし、自分の力量に合わせて選択できるようにしたいと考えています。

アイテム投げ2

2010-03-01 14:47:43 | 開発

ウディタでローグライク開発第15弾。
前回の続きで、アイテム投げの処理を調整しました。

前の段階では、アイテムを連続して投げた場合、落ちたアイテムが壁をまたいでしまうことがありました。
そして、アイテムを落とす位置を検索する際に、すでに検索した位置を再び検索してしまうという無駄処理も・・・。
今回でこれらを改善、よりそれらしい処理になりました。

まず、アイテムが壁をまたいでしまうことへの対応です。
実は、私と同じくウディタでローグライクを作成している他の方のブログで、このことへの対処法が載っていました。
アイデアを頂いてしまおうか?とも考えましたが、私なりの方法で実現したいと思います。
アイテムを落とす地点と、最初にアイテムを落とそうとした地点との間に直線を引き、その線上に壁があった場合は、その位置にアイテムを落とさないようにしました。
こうすることで、壁をまたぐことがなくなるのはもちろん、
障害物が壁ではなく、例えば小さな岩だった場合でも、少し回り込んでアイテムが落ちていきます。
これで、前回よりは違和感が軽減されました。

次に、無駄な検索をする場合への対処です。
最初のアイテムドロップ予定地点を中心にして、放射状に検索していくのは同じですが、方法をまるっきり変更しました。
前回のものは、参考にしたアルゴリズムの影響もあり、再帰処理っぽくしていました。
ただ、今回はそんな無駄に難しい処理をせずに、最初の地点から同心円状に1つ1つ丁寧に検索するようにしました。
どのような処理にしたかといいますと、以下の図をご覧ください。

図における数値は、最初のドロップ予定地点からの相対位置を表してます。
マスの中の左の数値がX座標、右の数値がY座標です。
つまり、中心の 0 0 のマスが最初のドロップ予定地点を表していることがわかると思います。
そして、X座標、Y座標の絶対値の和が同じになるマスを、赤い線でむすんでいます。
この赤い線でむすばれたひし形状のマスを、ドロップ予定地点からひし形の小さい順に検索していくことで、無駄なく検索することができました。
(まあ、最初に同心円状と言いましたが、ひし形状になっちゃいましたね^^;)
このおかげで、アイテムを落とす地点を探し当てるまでの時間が大幅に減っています。

ただ今回、アイテムを検索する範囲に制限を加えました。
ひし形の直径が40マスになるまで検索しても、適切なアイテムドロップ位置が見つからなかった場合は、最初に説明した「壁をまたいでしまう場合」への対処をしないで、もう一度初めから検索しなおします。
そして、2度目の検索でも適切な位置が見つからなかった場合は、その時点で検索をやめてしまいます。
この処理は、処理時間軽減のために加えました。
私の作成したランダムダンジョンでは、100×100の大きさまでダンジョンを生成可能です。
そのくらいの範囲まで検索するようにしてもいいのですが、そこまで検索しないと空き位置が見つからないくらいに、アイテムがたくさんダンジョン内に落ちている状況にはならないと考えています。
そのため、処理軽減を優先して検索範囲に制限を設けました。
万が一、検索しても適切な位置が見つからなかった場合は、ドロップアイテムを別の場所へワープさせるか、消してしまうとかして、対応しようと考えています。

今回も、ブログでの説明だけではわかりづらいと思うので(というか、ちゃんと説明できているか心配なので)、サンプルのゲームをアップしておきます。
適当な位置で決定キーを連打してみてください。
アイテムを避ける処理のサンプルゲーム2