|
ゲープロ講座セッション７：ちょっと違うＲＰＧ・準備編
- ユニークシステムのアプローチ |
こんにちは、鷹月ぐみなです。ＳＬＧ講座はどうしたの？と言われそうですね。別に止めたわけじゃないので安心してくださいね。今回はちょっとした息抜きがてら、ＲＰＧの事についてちょっとだけ触れてみようかなーと思います。 |
鷹月も含めて、いまだＲＰＧが好きな人が多いと思います。食傷気味だとか時間稼ぎに飽きたとか言われていても、ＲＰＧをプレイしている時のあの感覚を思い出して、ついつい遊んでしまう人もいるでしょう。そういうわけで、この講座でもそのうちＲＰＧプログラムについて取り上げようと考えています。もっともＲＰＧと言っても色んな形があるでしょうし、その全てを網羅するわけにもいきませんから、皆さんの中で、何か特別「ダンジョンＲＰＧで面白いものを作りたい！」とか、「戦闘システムが面白いＲＰＧを」とか希望があったら、その旨メールでいただきたいと思います。 ……と、こうアピールするのが本題だったので、今回の講義はお終い。と〆てしまうと悲しいので、今回はその準備編として、少し話を続ける事にしましょう。
|
ダンジョンＲＰＧをちょっと思い出してください。あれは、２Ｄのマップを擬似的に３Ｄ画面にして、主人公視点で進めるものです。私は正直、このダンジョンＲＰＧというものが苦手です。まず同じ地形ばっかり出てきてマップが覚えられない点、それと回りが見えないという不安です。前者は最近のポリゴン化のおかげで改善されてきましたが、問題は後者。プレイヤー視点とキャラクターの視点が一緒になった良いシステムである事は認めます。しかしちょっと考えてみてください。確かに前を向いている人間は後ろは見えません。しかし見ようと思えばすぐ見れるはずです。パーティーで歩いてて、「後ろから突然攻撃を受けた！」と言われたときに思わず言いたくなります。「誰か普通、後ろくらい気を配るだろ？！」そうでなくても、後ろを振り返るのは非常に面倒くさくて、おまけにあまりに切り替わりが早すぎて、後ろを見ている気になりません。 この辺の理由があって、鷹月は平面型ＲＰＧの方が好きなのですが、こちらはこちらで逆に視点が広すぎるのです。プレイヤーにしてみれば悪い事はないのですが、本来プレイヤーが見えるわけがないものが見えたり、なんとなく臨場感というものに欠けます。そこで考えたのが、平面型ＲＰＧに、ダンジョンＲＰＧのような視点を取り入れることはできないか？というものです。すなわち、プレイヤーが見えない部分を隠してしまう、という事です。後ろに関しては、「振り返ればすぐ見える」という事で特に考えない事にするか、もしくは若干後ろの視野を見にくくするか、どちらにしても実現できそうな感じですね。 とまぁ、こういうアイデアですが、もちろん過去のＲＰＧで既に実現されてはいます。ドラクエ１の洞窟やＡＲＰＧですがイースの洞窟など。周囲何マスしか見えない、というやつですね。 とはいえ、これは視界の幅が固定されていて、別に岩山があろうが湖があろうが平地だろうが、本来は遮蔽されるのにも関わらず、一定の範囲が見えてしまいます。「その角を曲がったとたんに……」という仕掛けで驚かす事ができず、要は単に見える範囲を狭めているに過ぎないのです。そんなこの問題点ですが、ＦＣウルティマ（明るい場所と暗い場所の分類） →ソードワールドＰＣ（角ポイントの設定、及び敵キャラの隠蔽）→ディアブロ（光源計算）の順に改善されていきました。前二つはプレイしていない人も多いでしょうから細かい説明は省きますが、動的に、回りの地形から視界を算出し、プレイヤーに提示するようになってきました。（まぁディアブロはＡＲＰＧですが） この視界計算の実装の仕方ですが、主に二つの方法が使われています。
Ａ） 全方位直線アンカー
Ｂ） 屈折型アンカー 論より証拠ということで、早速テストアプリケーションを作ってみましたので、ちょっと動かしてみてください。あいかわらずDelphi＋TGWコンポーネントによるものです。なお、処理的にかなり重いことをやっているので、推奨スペックはPentium233以上としておきます。（すんません、もう少し最適化させると、Pentium75でも快適になるはずなんですが…）
別に何をするアプリでもなく、ただフィールドをうろつくだけです（^^;)。なお、最初は可視範囲と不可視範囲がくっきり分けられていますが、リターンキーを押すことによって、「徐々に視界が暗くなっていく、１１段階光源モード」への切り替えが可能です（下図参照）。
割とハイテクな事をやっているように見えますが、実はセッション３で発表した移動アプリとほとんど同じです。移動可能地点を探索し、それぞれの場所に「そこへはどのように行けば到達できるか」という道順を記憶させているわけですが、この道順を格納する文字列の長さが、純粋に主人公からの距離数に等しくなるという事実を使い、その距離数に比例してフィルタを強くしているだけです。フィルタはマップチップで、単に上から配置しているだけなんです。メカニズム自体は、ソースを見ていただければ分かるとおり、とてもシンプルなんですが、DirectXも何も使わずに、こういった光源計算が実現できるんですね〜。 ここで言いたかったのは、移動システム一つを取ってみても、既存のパターンを踏襲すると言うより、それを活かしつつ自分のこだわりを入れることで「ちょっと違うシステム」が演出できること、それとＳＬＧのために考えた移動可能座標探索のルーチンが、こういう所に応用が効くという一つの実証です。なお、ソースの解説はしませんので、余力のある方は解析してみてください。一部不自然なコードもありますが（^^;)、ちょっとした小技も効いてますので。
|
ということで今日はここまで。いかがでしたか？ プログラムが分からない方でも、ソースファイルはちょっとだけ覗いておいて下さいね。この内容があれだけの行数で実現できるんだな、ということを感覚的にで良いですから理解しておいてください。次はＳＬＧ講座の続きかな？あっちはサンプルアプリ製作が結構大変なんだよな〜……とぼやきつつ、さようなら。感想お待ちしています。 - 鷹月 ぐみな |
□ Session８：戦術ＳＬＧの移動アルゴリズム（６） (2000/3/29)
|