プロフィール

Na-7

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


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
DATE: CATEGORY:三国志軍記開発
16方向ビルボード対応
開発中のメイン画面
ユニットの画像パターンを8方向から16方向に拡張し、カメラを移動した時の違和感を少なくした。



◎プログラム改修

前々回では、ビルボードのクォータニオンを取得し、頂点変換を行い、そこから角度を求めました。

その後yohさんからもっと簡単なやり方を教えて頂きましたので、プログラムを改修します。

まず、カメラの平面角度を求めます。
Vector3 tmpPos = mainMap.MapViewPos - billPos;
float viewPlaneRot = MathHelper.ToDegrees((float)Math.Atan2(tmpPos.Z * -1.0f, tmpPos.X));


次に、ユニットの向きはこれまでint型(=絵の番号)だったのですが、今後のことを考えてfloat型に変更します。また、絵の番号は真上(12時の方向)から時計周りに番号を振っていましたが、三角関数に合わせて右側(3時の方向)から反時計周りに振り直します。

最後に、カメラの平面角度とユニットの向きを差し引いた値(角度)から、絵の番号を判定します。



◎円周率の誤差?

ユニットの向きをint型からfloat型に変更し、

pos.X += ((timer / 5000) * moveSpeed) * (float)Math.Cos(MathHelper.ToRadians(rot));
pos.Z -= ((timer / 5000) * moveSpeed) * (float)Math.Sin(MathHelper.ToRadians(rot));


こんな感じでユニットのXZ座標をUpdateするようにしました。

一見すると狙い通りに動いてるようですが、座標値を確認すると微妙にずれているようです。例えば、rot=90として真上に向かってるつもりでも、X座標が徐々に変化します。円周率の誤差でしょうか?

このままだと、上下移動を繰り返しただけでも、微妙に左右にずれていくことになります。ゲーム性を考えると誤差の範囲と思いますが、テスト中の数値確認はやりにくいです。向きはintに戻した方がいいのかなぁ?うーん…。



◎アニメ画像取得

プログラムは一応できたようなので、槍兵のアニメ画像を取得します。

背景色はRokDeBone2で自由に指定できることに気が付いたので、わざわざGIMPで塗りかえる必要が無くなりました。これでかなり楽になりました。

それでも9方向分(左右反転すれば16方向分)のアニメ画像を取得するのに3時間近くかかりました。単純作業の繰り返しは精神的に疲れるなぁ…ブツブツ。



◎画像の反転

画像を左右反転して板ポリに貼り付けようとしましたが、それを一発で簡単にやる方法がわかりません。オプション設定とかで簡単に出来そうな気がしますが、ヘルプやネットで探しても見当たりません。何でかなぁ…。

わざわざ左右反転用カスタムエフェクトを作るのも面倒なので、UVを反転した板ポリゴンを作成して、左右反転したい場合はそちらのモデルに切り替えるようにしました。

こんな時、他のXNAユーザはどうしてるんでしょうか?



◎実行

ようやく画像が準備できたので、早速実行してみましょう。

うっ…画像読み込みが一気に遅くなりました。640×480の画像を720枚も読み込んでいるので、仕方ないですね。画像ファイルは圧縮されているので1枚あたり20KB以下ですが、メモリの方は結構やばいかもしれないなぁ…。



ほほう…モデルが静止してると、画像の切り替えが多少気になりますが、耐えられない程ではないかも?

面白いのは、アニメしながらの方がごまかしやすいってことですね。もともと切り替えアニメだし(笑)



◎総評

ビルボード&切替アニメで、カメラを近付けても3Dっぽく見えます。むしろ地形の方が2Dバレバレですね(^^;
地形については試したいことがあるので、後日やります。

今回は16方向×40コマでやりましたが、32方向×80コマでやると、もっと滑らかになるんでしょうね。でも今後ユニットの種類を増やした時の画像枚数を考えると、難しいかもしれません。そこら辺は後で調整ですね。

とりあえず、ユニットの表示方式はこれで確定しました。
yohさん、HOSSIEさん、どうもありがとうございました!



◎次回予告

次回は部隊ユニットの画像を取得します。以前の方法は大変なので、Softimageで簡単に作れないか試してみます。

スポンサーサイト

テーマ : モンスターハンター総合 - ジャンル : ゲーム

コメント

それっぽくなって来ましたね

DSのダビスタもこんな感じです。中割りアニメーションの数はもうちょっと多いかな。ユニットの数を多くして賑やかにすれば昔の合戦っぽくて楽しそうですね。 (^^) 昔お試し版で遊んだMSの『AGE OF EMPIRES』なんかも参考になると思います。

出来れば、XNAで中割りを自動的に作成するツールを作るとよいかも知れません。ツールは面倒でも一度作ってしまえばとことん修正に対応出来ますよ。

三角関数に誤差が、という件については
(float)Math.Cos
という記述が気になりました。変数に格納する直前までdoubleで計算して、最後にfloatに変換した方がよいのではないでしょうか。あとは、rotもラジアンで保持した方がいいです。

ありがとうございます

ユニットはなるべく増やして賑やかにしたいと思っています(^^)

>『AGE OF EMPIRES』
2と3をかなりやりました。あれも似たような作り方してるんですかね?陸戦数百ユニットが私のメインPCでまともに動くのはさすがMSです。ちなみに海戦で水しぶきが上がり始めると、1フレーム5分かかったりして全くゲームになりません(笑)

>XNAで中割りを自動的に作成するツール
できることなら作りたいのですが、XNAで3D表示した画面をファイルに保存する部分が自動化できず悩んでいます。

>変数に格納する直前までdoubleで計算して
実際に試したら、私のプログラムでは30%ぐらい変わりました。結構違うものなんですね。ありがとうございました。

>rotもラジアンで保持した方がいいです。
これは、誤差が減るからでしょうか?それとも、何かと都合が良い(計算がやりやすい)からでしょうか?

補足

>rotもラジアンで保持した方がいいです。
ええ、単に少しでも関数を通す回数を減らした方がいいということです。もともとほとんどの数学関数はラジアン向けなわけですし。

と言っても、doubleにしてしまえばそこまで誤差は出ないような気もしますし、もしゲーム中のユニットが必ず45度単位で8方向にしか動かないということであれば度の方がいいかも知れません(0~7の整数で保持する手もあり)。ゲーム内容で決めてください。

解説ありがとうございます

ユニットの移動は8方向を想定していたので整数で保持していましたが、絵のパターンは16~32方向とすることになったので、今回度に変更しました。

度はラジアンよりも直感的にわかりやすいのでデバッグには良いのですが、ご指摘のように関数を通す回数が増えます。度は中途半端な気がするので、最終的にはラジアンか整数にしようと思います。どうもありがとうございました!

コメントの投稿


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

トラックバック


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



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