プロフィール

Na-7

Author:Na-7
SE(システムエンジニア)として約15年間システム系ソフト会社を勤めあげ、2008年3月退社。現在、ゲーム制作会社設立を目指して活動中。


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
DATE: CATEGORY:三国志軍記開発
諸葛亮
諸葛亮
蜀の軍政家。劉備に三顧の礼で迎えられ、天下三分の計を献策する。放浪中の劉備を助けて荊州と蜀を抑え、漢中王に祀り上げるが、関羽北上の失敗により荊州を失う。劉備没後にその志を継いで北伐を敢行するが、漢王朝再興は果たせなかった。演義後半の主人公。



◎正射影マップ画像の取得

ラスタースクロールに挑む前に、まず正射影マップ画像を取得したいのですが、XNAではどうやれば良いのでしょうか?

試しに、Projection行列の視野角を極端に小さく…1度や5度に設定したら、地面の1部が極端に拡大されました。

視野角5度

正射影は遠近感が無くなるそうですが…目的のイメージとは全く違います。ぐむむ。


…ちゃんと調べたら、正射影行列を作成するメソッドがMatrixにありました。
Matrix.CreateOrthographicOffCenter()

正射影マップ

おお、これです!目的の正射影マップ画像が取得できました!

別にわざわざラスタースクロールさせなくても、このままで十分な気もするなぁ…予想より綺麗だし、疑似3Dと相性が良いし、奥のユニットを選択しやすいというメリットもありますね。

でも、距離感はありませんし、奥側ユニットのサイズや移動速度も不自然になりそうです。やはりラスタースクロールが成功するに越したことはないか。



◎ラスタースクロール描画テスト

マップ画像は準備出来ましたが、これをラスタースクロールさせると、本当に3Dっぽく見えるのでしょうか?

まぁ、とりあえずやってみましょう…エイッ!

ラスタースクロールのサンプルコード

ラスタースクロール01

おお~!ちゃんと3Dに見えますね!

昔はマシン語必須で憧れの技法だったのですが、spriteBatch.Drawだけで実装できるとは…XNAやっぱ凄いかも(笑)



◎酔っぱらいスクロール

ここまで来れば、勝ったも同然!

…と勇んで簡易デモに組み込もうとしたのですが、やってみるとなかなか思い通りにいかず、結局丸1日かかってしまいました。落ち着いて考えれば、難しいプログラムじゃないはずなんですが(^_^;

で、実際に画面をスクロールさせてみると、横方向は綺麗にスクロールしますが、縦方向はどこか違和感を感じます。
アスペクト比の問題かもしれないと思い、縦横の拡大縮小率の調整を図りましたが、違和感を完全にぬぐい去ることはできませんでした。

滑らかなのに不自然なスクロールを見ていると…走行中の電車や車から至近距離を長時間見て、乗り物酔いしたような感じになります(ー_ー;

昔「ラスタースクロールは酔う」と聞いた気がしますが、これのこと?いゃでも、気分が悪くなる縦スクロールシューティングなんて無いよねぇ?しかし、3D系のモデリングやプログラミングをしていると、たまに違和感感じることもあるしなぁ…。

どうもよくわからないので、ユニットも同時にスクロールさせることにしました。一緒に流れる画面を見れば、はっきり判るかもしれないし、プログラミングの途中で何か気付くかも。



◎地形とユニットの同期スクロール

というわけで、地形スクロールに疑念を残したままユニットスクロールの実装に入りました。実際にやってみると、全然合わない…しかも単純なズレじゃなさそう。ヤなかんじ~!


結論から言うと、2日がかりでようやく同期するようになりました。同期がズレていた原因は、

:地形スクロールが間違っていた
:ユニットスクロールは地形と異なるプログラムが必要
:ユニット画像の原点を中央に合わせる必要がある

の修正中にの問題に気付いたため、の修正は後廻しとしたのですが、この順番は結果的に失敗でした。
の修正はspriteBatch.Drawの引数に指定するだけなので、先に直しておけば混乱要因を減らすことができたのですが…まぁ今となってはどうでもいいことですね。



◎拡大縮小機能の実装

マップ画像は現在1600×900×1枚を使用していますが、最大8000×8000の画像を使用したり、複数画像の組み合わせも(技術的に)可能です。現在のユニット画像は844×555なので、カメラをアップにしても十分耐えられるはずです。

但し、画像ファイルがデカいとネット配信が厳しくなりますし、カメラの角度を変えられないので、凝った演出は出来ないという欠点があります。マップとユニットの画像サイズは後日調整するとして、とりあえず拡大縮小機能を実装しましょう。


しかしいざ始めると、地形とユニットのスクロールがズレたり、画面左上を基準に画面が拡大縮小したりで予想外に大変でした。

ラスタースクロールで画面が歪んでいるので、画面中央を基準に拡大縮小させるだけで半日以上かかりました。実はまだちょっとズレます。頭がパンクしそうです(>_<)



◎簡易デモ

というわけで、以前の簡易デモにスクロールを実装しました。



いかがでしょう?
ユニット移動は前回と一緒ですが、画面がスクロールするとゲームっぽくなった気がしませんか?



◎今後の課題

作り始めたら、課題がいろいろ出てきました。

・拡大縮小すると、兵士の表示位置が微妙にずれる

・特定の倍率にすると、画面に黒い横線が一本入る

・描画範囲の右端が表示スケールによって変動する

・大きなマップ画像を取得する

・マップ画像の複数化対応

・ユニットの移動切り替えをスムーズにする
 →方向を切り替える際に、途中のコマを入れる



◎次回予告

ラスタースクロールの座標計算は予想以上にややこしいものでしたが、とりあえず形になって良かったです(^^)

ゲームの基本システムは、これでほぼ確定ですね。次回は「今後の課題」を順次対応していく予定です。

スポンサーサイト

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

コメント

疲れが…(汗)

小さいのがたくさんわらわら動くのがいい感じですね。(^^) 完成品ではユニットの種類が増えるでしょうから、より味が出そうです。

ところで、この画面構成ならラスタスクロールやら位置あわせやらで苦労するより、内部的にちゃんと3Dにしてしまってユニットだけいわゆるビルボード(3次元座標を持っているが、常にこちらを向いたテクスチャ1枚絵。昔のセガの体感ゲームの背景オブジェクトに近い)にした方がかえって楽じゃないでしょうか? 過去の経験上、下手に近似的に位置合わせして2Dを3Dっぽく見せるより、いっそ3Dで作ってしまった方が簡単だったもので。色々言って済みませんが、ご参考までに。


こっちは先週一週間でスキンシェーダまで作る予定が、keynoteプラグインからスキン重みとアニメを読み込むパイプラインに凝り過ぎて時間を食ってました。不要なところに力を注ぎ過ぎるのはよくないですね…。

どこまでやるべきでしょう?

>小さいのがたくさんわらわら動くのがいい感じですね。(^^)
ありがとうございます。ユニットの種類はできれば20種類ぐらいにしたいと思っています。

>いわゆるビルボード
なるほど、その方が楽かもしれませんね。そちらの方式も検討させて頂きます。どうもありがとうございました!

>不要なところに力を注ぎ過ぎるのはよくないですね…。
ビジネスシステムは優先順位を付けやすいのですが、ゲームシステムは明確な判断基準が無いので難しいですね。つい頑張りすぎちゃったり、逆にいい加減すぎて失敗したり…。
経験を積めば見切れるようになるのでしょうか?

どうでしょうね

>経験を積めば見切れるようになるのでしょうか?
他人のは客観的に見られるので見切ることが出来るのですが、自分で組んでいるものはついつい趣味に走ってしまうんですよ…。自分の場合、特に後々まで使い回せるであろうライブラリ的な部分について、ついつい凝ってしまうことが多いようです。

長年やっていて、自分が自分のやっていることを客観視できないということをようやく客観視出来るようになりました(笑)。

ビルボードの前段階です

>ライブラリ的な部分について
わかります。つい必要以上に凝ってしまいますね~

>ようやく客観視出来るようになりました(笑)。
やっぱり、自分のことはよくわからないものなんですね(笑)


とりあえず、オブジェクトを平面ポリゴンにしたら、プログラムが凄くシンプルになりました。どうもありがとうございました!_O_

コメントの投稿


管理者にだけ表示を許可する

トラックバック


この記事にトラックバックする(FC2ブログユーザー)



copyright © ゲーム制作の舞台裏 all rights reserved.Powered by FC2ブログ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。