-- / --
--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

04 / 26
Sat

Ziphil です。

さて、 実は私、 大学 1 年です。 まあ、 活動内容に関わらず、 ハンドルネームは Ziphil で統一していますから、 私の Twitter やもう 1 つのホームページなどを見たことがある人なら、 もう知っていることかもしれませんが。 で、 なぜ突然よく分からないカミングアウトをしたかというと、 忙しいんです。 つまり、 趣味の時間があまり取れないんです。 主に数学とフランス語とロシア語のせいで。

というわけでですね、 膨大な時間がかかることが予想される 『Eminentia』 ですが、 おそらく開発は中止となります。 だからといってゲームを作らないわけではありません。 使える時間がそれなりでも作れるようなゲームを、 趣味として作っていこうかなと思っています。

正直、 私は工学部に進んだりゲーム会社に入社したりする気はありませんので、 ゲーム制作はあくまで趣味の範囲です。 ですから、 また開発が頓挫になる可能性は大いにあります。 まあ、 期待せずにこのブログを読んでくれると助かるなー、 という感じです。


スポンサーサイト
comment ×0
03 / 19
Wed

スマートフォンの画質に感動する Ziphil です。

RPG などで、 ゲームを進んでいるとよく完全上位互換の武器とかが手に入りますよね。 自分が今持っている武器より、 どのステータスから見ても強い武器のことです。 こういうのが頻発するゲームはあまり好きではありません。 これまでの武器を売って新しい武器を手に入れるだけで、 武器を選択する楽しみがなくなります。

私個人の意見ですが、 過去に用いた武器や防具を頻繁に売ることになる RPG は微妙です。 ゲームを進めると、 いろいろな武器が手に入り、 迫り来る敵にはどれが最も適切かを考えるのが楽しいんです。

ということで、 武器の設定は並列に行うようにしています。 いろいろな特徴をもった武器が何種類もあるみたいな感じです。 まあ、 データベースの設定はその分大変になりますけどね。


comment ×0
03 / 06
Thu

この欄に書くことが思いつかない Ziphil です。

さて、 これまで Temple 型, Wilderness 型, Cavern 型 の 3 つのランダムダンジョン生成アルゴリズムを作りました。 名前は今適当につけました。

3 種類あれば十分かもしれませんが、 もう 2 種類くらいほしいなー、 と思うわけです。 具体的に言えば、 部屋と通路ではなく迷路のようになっている Maze 型と、 Temple 型 を自然物化させたような空洞と通路で構成される Cave 型です。

Maze 型は有名なアルゴリズムがありますから良いんです、 穴堀り法とか。 問題は Cave 型です。 Temple 型における部屋と通路の生成を、 より自然物っぽく曲線を含ませたものに改良すれば、 それで終わりな気がしますが、 せっかくだし違う方法を採ってみたいです。

穴掘り法っぽい方法で作れそうかなー、 と思うんです。 つまり、 適当な位置から適当に通路を掘っていって、 適当な位置で空洞を作り、 また適当に通路を作る、 みたいな。 このとき、 その場に本当に作れるか調査しならが通路や空洞を作っていけば、 それっぽくなる気がします。

もしくは、 空洞を先に適当に配置して、 適当に通路をつなぐ方法です。 ただ、 この通路をつなぐ処理が、 意外と面倒なんです。 孤立した空洞ができては困りますし、 かえってつなぎすぎも良くありません。

調べてみてもいるんですが、 なかなか良い方法は見つかりませんし。 こう、 エレガントな方法はないんでしょうか。


comment ×0
03 / 03
Mon

Ziphil です。

アルゴリズム考察の続きです。 前回のエントリで、 曲線を使った方法を書きましたが、 もうちょっと具体的にしてみましょう。

まずは、 マップ全体を形作る閉曲線はどうやって描くか? 初期地点を決めて適当に曲げながら線分を描いていく方法を考えましたが、 これでは閉曲線になる保障がありません。 そこで、 最初から閉曲線を作っておいて、 それを曲げていく手法を採ってみようと思います。

  • マップ全体より少し小さめの長方形を作り、 その頂点に時計回りに 0, 1, 2, 3 のデータ値をもったノードを置く。
  • 数値が隣り合っている 2 つのノードを選び、 その中点から少しずれた位置に新たなノードを作成する。このノードは、 選んだ 2 つのノードのデータ値の相加平均のデータ値をもつ。
  • 上の処理を適当な回数繰り返す。

適当な線分描画アルゴリズム (ブレゼンハムのアルゴリズム) を使って、 隣り合うデータ値をもつノード間の線分を描画し、 通過領域とすれば、 洞窟ダンジョンの輪郭が決まります。 このとき、 輪郭の内部の座標を記憶しておきましょうか。

次は、 この閉曲線内に適当に道を作ります。

  • 通過領域から適当に 1 点選び、 内部に向かって適当な長さの線分を引き、 通過領域に変える。
  • 線分の先の点から、 前回引いた線分とのなす角が 60° 未満になるように、 新たな線分を引き、 通過領域に変える。
  • 上の線分を引く処理を、 通過領域に衝突するまで続ける。
  • 最初の処理から順に同じ処理を適当な回数繰り返す。

これで、 輪郭がいくつかの領域に分けられるはずです。 後は、 部屋になる部分を決めます。

  • 輪郭の内部の通過不能領域である点を適当に選ぶ。
  • その点を含む領域を、 部屋として通過可能領域とする。
  • 以上の処理を適当な回数繰り返す。

これで部屋の完成し、 空洞つきの洞窟ダンジョンのマップが完成する・・・と思います。

このアルゴリズムの欠点ですが、 空洞の中央から通路が伸びるということがないことでしょうか。 まあ、 後から通路を追加すれば良いだけの話ですが。 詳しいことは、 実際にコードを書いて動かしてみないことには分かりませんね。 実装はまだ今度やろうと思います。


comment ×0
03 / 03
Mon

Ziphil です。

昨日はランダムダンジョンを自動生成するコードを書いたわけですが、 やっぱりあれを洞窟のダンジョンに使うには不自然。 ということで、 自然物のダンジョンをそれっぽく生成する方法を考えてみます。

昨日のアルゴリズムの何が不自然かと言うと、 一番は部屋の形でしょう。 長方形ですから、 自然物らしくありません。 そこで、 長方形の部屋の角や辺を少し削って、 部屋に丸みを帯びさせるというのが最も簡単です。

根本からアルゴリズムを見直してみましょう。 こんな生成方法が思いつきます。

  • 適当な位置を中心とし、 楕円状の通過領域を作る。
  • 適当な方向に移動し、 同じように楕円状の通過領域を作る。
  • 上の移動を何度か繰り返す。

楕円状の通過領域の形を毎回微妙に変えてやれば、 それっぽい洞窟の通路ができそうです。 まあ、 これだけでは一本道なので、 分岐を作ったりの処理も入れなければなりませんが。

こんな方法も思いつきました。

  • マップ全体に閉曲線の通過領域を描く。
  • 通過領域の適当な 2 点を結ぶ、 適当な曲線の通過領域を描く。
  • 上の曲線の描画を何回か繰り返す。
  • 閉曲線になっている部分をいくつか選び、 その内部を全て通過領域として部屋を作る。

直線要素がなくなるので自然物らしくはなりますが、 閉曲線を描くアルゴリズムが難しそうですね。

さて、 左上にミニマップそ表示するプログラムを追加したので、 昨日のアルゴリズムで生成したランダムダンジョンのサンプルを上げておきましょうか。 サイズは 80×80 です。

771_製作過程A

ちなみに、 変に細長い部屋が作られないように、 領域が縦長なら横に分割し、 領域が横長なら縦に分割するように、 昨日のプログラムを改良してあります。 また、 領域の最小の長さを、 5 から 10 に変更してあります。

上の画像ではよく分かりませんが、 実は FPS が設定値の 40 を下回っています。 やっぱり描画が遅いみたいで、 これは昔 StarRuby のときにやっていた軽量化処理を施さないといけないのでしょうか。


comment ×0
12 / 29
Sun

Computer Modern フォントの美しさに気づき始めた Ziphil です。

最近プログラミングの話題ばっかりですねー。 ということで、 久々にドット絵を描いてみました! ・・・ではなく、 データベース設定の話です。

RPG を作るのは大変で、 多くの人が挫折するっていうのはよく聞く話で、 RPG ツクールとか買って最初は意気込んで作り始めても、 結局完成しないなんてことも、 よくあるみたいですね。 何で挫折するかって、 設定すべきデータベースが多いことでしょうね。 作ってみて始めてわかるものですが、 RPG のデータベースが多いこと多いこと。 ステータスやら、 状態異常やら、 武器やら、 防具やら・・・。 でも、 こういうデータベースを作るのも、 また楽しいんですよねぇ。

さて、 このごろプログラミングばかりでしたが、 実はゲーム製作は進んでいません! なぜかというと、 次にプログラミングすべき部分が、 敵キャラとのバトルに関する処理だからです。 実は、 敵キャラのデータベースをまだ何も設定してないんです。

で、 困ってるのが、 敵モンスターってどういう風にプレイヤーに攻撃して、 どういう風に防御するのかなー、ということです。 プレイヤーは武器を持ってますから、 武器で攻撃するじゃないですか。 じゃ、 モンスターは何で攻撃するんでしょう。 剣とか持ってるんですかね、 それとも素手? じゃ、 モンスターの防御は? プレイヤーと同じように、 鎧とか着ているのか、 それとも防御は屈強な体だけ?

私の RPG にはペットシステムを導入して、 モンスターを仲間にできるようにしようと思っているので、 プレイヤー自身と、 NPC の人間の仲間と、 ペットにしたモンスターという、 3 つの要素を同等に扱いたいんです。 そうすると、 もちろん、 ペットにも武器を持たせ防具を着せることができるということになります。 でも、 野生で出てくるモンスターが武器を持ってるってのも、 何か不自然・・・。 かといって、 野生のモンスターが素っ裸だとすると、 野生が弱すぎるか、 武装したペットが強すぎるか、 どちらかになってしまいます。 それに、 野生のモンスターが武器や防具を持つと、 その武器や防具によって、 モンスターの強さにかなり差が出ます。 序盤に出てくるスライムみたいな敵でも、 エクスカリバーみたいな最強武器を身につけていれば、 かなりの強さになりますからね。

さて、 どうしましょうか。 今のところ、 モンスターも最初はいくつか武器や防具を持っていて、 その武器や防具はモンスターごとに定まっている、 ということにしようと思っています。 まあ、 その分、 それぞれのモンスターがもつ武器とか防具の分だけ、 データベース量が増えて、 ただでさえ量が多いデータベースをさらに増やすことになりますが。 まあ、 楽しいんで問題ないですけどねー。


comment ×0
12 / 20
Fri

インフルエンザの予防接種で肩が痛い Ziphil です。

せっかく Kotlin 慣れてきたー、 なのに、 Ceylon という新しい JVM 言語をやり始めています。 RPG を作る言語を選ぶときに、 JVM 言語を 10 個くらい試したんですが、 そのときにこの Ceylon もかじってました。 概略とかを見た第一印象が 「複雑そう」 だったので、 Ceylon はやめて Kotlin にしたわけです。 ・・・が、 最近 Ceylon についていろいろ調べてみると、 結構良い感じだったんですよ。

ということで、 Ceylon 環境を構築しているところです。 IntelliJ IDEA のプラグインはないみたいなので、 Eclipse を入れています。 でも私は IDEA の方が好きです。

あー、 新しい環境にするとセットアップが面倒なんですよねー。 私の場合、 細かいところが気になってこだわっちゃうので、 環境構築だけに 2 時間くらいかかるんですよねー。 主にコードの配色の設定とか。

まあ、 環境が整ったら、 しばらく Ceylon と戯れて、 今後の RPG 開発で使うかどうか決めます。


comment ×0
back-to-top
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。