プロフィール

Na-7

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


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
ソーサリーフォース
ソーサリーフォース
3Dアニメーションソフト「エルフレイナ」をはじめ、ツール、ゲーム、プログラミングなどのコンテンツが充実している。



◎スクリーン座標変換

今回は、城の上にネームプレートを掲げて、城名称がわかるようにします。

最初は板ポリゴンを配置して城名を記述するつもりでしたが、よく考えると遠くの文字は小さくなったり歪んだりして読み辛くなりそうです。

通常の2D文字の方が、大きさや角度が均等で読みやすそうですが、その場合はネームプレートの位置を特定するために、城の3D座標を2D座標に変換する必要があります。

座標変換はソーサリーフォースの「3次元座標からスクリーンへの座標変換」を参考とさせて頂きました。ここでいうスクリーン座標とは、元の3次元空間をカメラ視点に置き換えた3次元空間座標で、そのX、Y座標が2D座標に相当します。

それにしてもソーサリーフォースのプログラミングTipsは大したものですね。初心者向けに丁寧に解説されたTipsがサンプル付きで体系的にまとめられています。XNAを始めた頃に一通りチェックしたのですが、いつの間にか増えてました。



◎ネームプレートの表示

スクリーン座標から表示位置を特定し、3Dテストプログラムで作成した漢字表示方式を流用して城のネームプレートを表示しました。理由があって位置ズレはまだ修正していませんが、先に画面の雰囲気を確認しておきましょう。

城ネームプレート表示01   城ネームプレート表示02

ゲームっぽい雰囲気は少し向上したような気がしますが、城が集中する所はゴチャゴチャしてわかりにくいですね。

位置ズレを修正すればもう少しマシになると思いますが、他にも工夫した方が良さそうです。遠方の城のネームプレートは表示しないとか、重なった部分だけ表示しないとか…。



◎また来年!

というわけで、今年はこれでおしまいです。ご来場ありがとうございました。来年もよろしくお願いします。

それでは皆さん、よいお年を!

スポンサーサイト

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
エイジオブエンパイア3の高度管理
エイジオブエンパイア3の高度管理
見た目の高低はあるが、移動速度や射程距離、戦闘修正等には影響せず、ゲーム要素としての高度は無視している。



◎ゲーム要素としての高度

ゲームに高度(マップ上の高低差)の要素を導入し、移動や戦闘に影響させると、作戦の幅が広がります。
ゲームの高度に関する案は、以下の2種類の組み合わせになります。

A案:高度は無視する(侵入可否は存在する)
B案:高地と低地だけ区別する
C案:5~10段階程度で高度管理する
D案:3D座標で高度管理する(無限段階)

1案:影響なし
2案:移動速度に影響する
3案:移動速度と射程距離に影響する
4案:戦闘修正に影響する
5案:移動速度と戦闘修正に影響する
6案:移動速度、射程距離、戦闘修正に影響する

当初はC6案にしようと考えていましたが、3DCGを採用したためD6案まで可能になりました。

一般論として、シミュレーションゲームのパラメータ要素は、より多く細かい方がリアルになり、作戦の幅も広がります。その点だけを考慮すると、D6案が一番良いはずです。

但し、パラメータの違いが簡単に把握できる(一目で分かる)状態になっていないと、プレイヤーにとってパラメータチェックが面倒なウザいゲームになってしまいます。

実際にマップ画面を作成して気付いたのですが、全体マップを上空から表示すると、地面の高低差は殆どわかりません。
この状態でC案やD案を採用しても良いのでしょうか?



◎既存ゲームの高低管理

既存ゲームを参考に検討を進めます。


○三国志10(C3案)
三国志10の高度
ぱっと見で高低差がある程度分かるような角度に視点が固定されています。
それでも高度がよくわからない時は、マウスカーソルをその位置に移動して高度をチェックします。

いちいちチェックするのは面倒と言えば面倒かもしれませんが、私の主観では殆ど気になりません。
チェックの頻度や簡便性、ゲーム性、ボリューム量(マップの広さやユニット数)などを総合的に評価すると、チェックのウザさよりもゲーム性向上要素の方が強く、成功していると思います。


○シヴィライゼーション4(B5案)
シヴィライゼーション4の高度
高地と低地の2種類しか無く、CGを描き分けているため、大体ぱっと見で判別できます。
それでもよくわからない時は、やはりマウスカーソルをその位置に移動してチェックします。

このゲームのメインテーマは「文明の進化」です。
高地と低地の差は、移動速度や戦闘修正に影響しますが、それよりも文明進化の基本となる生産性に大きく影響するため、大変重要な要素です。
B案が効果的に導入された例と言えます。


○三国志11、信長の野望革新、エイジオブエンパイア (A1案)
信長の野望革新の高度
リアルタイム性重視のエイジオブエンパイアなどで、高低差要素は初めから無視するというのはよくわかります。
しかし三国志11や信長の野望革新のような、リアルタイム性の低いゲームでも、最近は高低差を無視する傾向が強いようです。



◎結論

既存ゲームを改めて見ると、年々高度差の要素が薄れているのがわかります。3D表示技術が発達し、見た目は立体的なのに…皮肉なものですね。
これはゲームが複雑化して若い世代のゲーム離れが進んだ反省によるものでしょう。それはそれで良いことだと思います。

ですが、既存ゲームの多くがその方向に進むなら、私はあえて逆の方向を目指したいのです。同じようなゲームばかり作ってもあまり意味がないので。

但し下手にこだわりすぎてチェックがウザいだけのゲームになったら最悪です。少なくとも、高度差が分かりにくい画面のまま高度差の導入は出来ません。
カメラの角度や地形の変更、チェック方式、ゲームバランスなどを総合的に考慮しながら、最終判断を下す必要がありそうです。

…というわけでまたまた結論は保留ですが、結論の単なる先送りではなく、熟考の上「今は決定を下すタイミングではない」という判断なので、悪くないと思います。



◎次回予告

マップ上の城の位置はズレたままですが、とりあえず先に城の名称や属性を城モデルの上に表示します。
調子が上向いてきたので、ガンガンいきましょ~!

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
都市の位置ズレ01
城を配置した画面
カシミール3Dの地名座標データをXNAで読み込んで城を表示した画面。白マルの位置と城の位置がズレまくっている。



◎最近ハマった問題

カシミール3Dで地名表示する際に、地名アイコンの座標はテキストデータとして渡しています。その座標データをXNAで読み込んで城を表示したら、冒頭の画面になりました。
…何じゃこりゃ?

試しに5つだけ表示したら、ズレの方向と距離がばらばらでした。

都市の位置ズレ02

普通は縮尺(倍率)と座標軸(差分)を修正すれば一致するはずなんですけど、これではどう修正してもズレてしまいます。何でこうなるの??



◎プログラム上の問題か?

修正値やプログラムが悪いのかと思っていろいろ試したのですが、そういうわけでもなさそうです。

都市の位置ズレ03

上記の画面は、カシミール3Dで一部の地域を拡大したものです。ここで3つの都市の座標データは以下の通りです。

魯陽(112.55, 33.44)
シュウ(113.10, 33.39)
葉(113.18, 33.30)

X座標に注目すると、

魯陽~シュウ間:113.10 - 112.55 = 0.55
シュウ~葉間:113.18 - 113.10 = 0.08

上記の数値を比較すると、魯陽~シュウ間は、シュウ~葉間の6倍以上もあります。しかし、カシミール3Dの画面表示上は、せいぜい2倍程度です。

以上のことから、座標データ上に城を配置しても、カシミール3Dの画面表示と一致しない(位置ズレが発生する)のは当然であり、修正値やプログラムの問題ではないと思います。



◎結論

…で、位置ズレの原因は何かと言うと、

座標値は緯度経度っぽい→地球が丸いから?
カシミール3Dは標高データと連動表示しているから?
カシミール3DとXNAでカメラの位置が違うから?

などが考えられますが、位置のズレ方がバラバラすぎるので、どれも違う気がします。結局原因不明です。


で、改めて考えてみると、原因不明であることよりも、この程度のことで延々とハマったことの方が問題ですね。
データはテキストファイルで数値化されているんだから、いざとなったら手作業で修正しちゃえば済む話なのに…。
プログラムが原因ではないと気付くまでに時間かかりすぎだし、(体調不良ではなくスランプの意味で)最近どうも調子が悪いな~、と感じてました。



◎お疲れさまでした!

調子が悪いのは、最近人と会話してないから脳が不活性になってるんじゃないか?と思い始めた矢先、昔の職場仲間としばらくぶりに会う機会があり、良い気分転換になりました。麻雀は完敗でしたけど(笑)

会社勤めの方は、昨日で仕事納めだった所が多いようですね。学生の方もそうかな?皆さん一年間お疲れさまでした!

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
Wikipediaクリスマス
クリスマス - Wikipedia
クリスマスが何の日か改めて見てみると、歴史も習慣も日付さえもバラバラで意味不明だったりする。楽しんだ者勝ち?



◎景気のいい話?

最近は金融不安や雇用不安など不景気な話ばかりでしたが、折角のクリスマスなので少しでも景気のいい話をすべく「CGモデル調達計画書」を作成しました。今回はその内容を簡単に説明します。



◎目的

「CG品質を向上させて、ゲームに対する注目度や期待感を高める」というのが主目的です。
私のお粗末なCGでは見向きもされないことは最初から承知してますので、金を投資してまともなCGに置き換えようという計画です。

ちなみに「ゲーム第一弾はフリーソフトとして無料配布し、気に入った人に第二弾を購入してもらう」という販売戦略が根底にあります。



◎対象と発注範囲

今回の対象は、武将モデルです。有力武将を10~20人程度選抜して個別モデルを作成します。非選抜武将は、ザコ武将モデルを1~2体作成して使い回します。
目標は20人程度ですが、場合によっては10人以下になる可能性もあります。

発注範囲は、デザインからモデリング、モーション作成まで。先方が一括で請けてくれればベストですが、交渉により別々のパターンも考慮します。



◎期間と予算

不景気が深刻化するであろう2月頃から発注の打診を開始します。製作期間は3~4か月程度を見込んでいます。

そして肝心の予算規模ですが、サラリーマンの給料数か月分を考えています。作業を細分化して細かい試算を出した上での結論ですが、その辺はヒミツです。(笑)

個人がフリーゲームに投入する額としてはデカイ!…と思いますが、作業量や専門性を考慮して時給換算すると、割の良いバイトと言いきれないのが苦しい所です。断られた場合も想定して、発注先候補は複数考えておかないといけませんね。



◎今後の課題

発注するにあたり、有力武将の一覧表を用意する必要があります。ということは、武将が登場するシナリオ概要を決めておかねばなりません。

また、モーション作成の前に、演出概要を確定させてモーション一覧表を作成する必要があります。事前に作成するのは難しそうですけど…。

それから、顔CGの調達方針はまだ未定ですが、顔CGと3Dモデルの整合性をどうするかも考えておく必要があります。さらに、顔CGと武将モデル以外にどんなCGが必要か、どうやって調達するか…考えることは山のようにありますね(^^;



◎次回予告

プログラムの方は、ある問題でハマってしまい、そこから全く進んでません。まいったな~。一人でプログラムしてると、ちょっとした問題に思いっきりハマって時間を潰してしまいますね。さっさと見切り付けるべきなんだろうなぁ。

というわけで、次回は多分その辺の話になると思います。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
3D-CHAYA
3D CHAYA
姫路城や銀閣寺などの建築物をはじめ、武器、道具、人物等の和風フリーモデル素材が多数公開されている。



◎作業報告

川や湖の追加修正は完了しました。

マップテスト08

微妙な位置ズレを修正したら、山間の谷間に川が流れるようになりました。



◎城モデルを作ろう!

マップ上に川や道を追加したので、今度は城を追加することにしました。

日本では城と町が別々に存在していましたが、中国や欧州は城塞都市が主流で、町全体が城壁で囲まれていました。というわけで、三国志軍記では町(都市)=城になります。

臨漢門

モデリングの参考とさせて頂いた写真です。(入手元はこちら
二千年前の城壁が今でも残ってるみたいですね~。しかも観光地というより生活感が漂ってる所が中国っぽい(笑)



◎モデリング

今回の資料は写真一枚だけでしたが、概観イメージはすぐに固まりました。また、直線的で単純な構造のためか、モデリングは結構簡単でした。積み木で遊ぶようなものです。
いきなり馬とか人とか作らずに、最初は建築物から始めるべきだったんでしょうね(笑)

とは言え、屋根の角の曲線と、城壁上部のゴツゴツパターンには少し悩みました。



◎モデルの精度

屋根の角の曲線を綺麗に作るため、冒頭の「3D CHAYA」の唐招提寺モデルを参考用にダウンしたのですが、開けてビックリ「うわーマジっすか~?」

何と木材の一本一本から再現してます。まるでCADですね。こんな緻密なデータをフリーで公開するとは太っ腹だな~。まぁ使い道は限定されますけど…格闘ゲームの背景とか?但し他のシーンの背景レベルをこれに合わせるのはキツそうです(笑)

結局、精度が違いすぎて参考にならなかったので、適当に作りました(^^;



◎パターン作成

城壁上部のゴツゴツパターンは、作るだけなら超簡単なんですが、数が多いので「手間をかけずに作る方法はないか?」という点で悩みました。
結局私が出した結論は「シンプルなパターンを1つ作り、複製していく」という、ありがちな方法です。

1.複製
2.位置変更
3.両端の頂点を繋げる

1~3を何度も繰り返して、倍々に増やします。単純に作るより遥かに手間は省けますが、細かい操作を要するので、他にもっと効率の良い方法がありそうな気もします。

パターン作成は今後も時々やるでしょうから、今後追及したいテーマの1つですね。



◎仕上げ

仕上げとは、細部を修正したり色を塗ったりテクスチャを貼る作業のことです。ちなみに、これが仕上げ後の完成品です。(ホームページからダウンロードできます)

城モデル01   城モデル02

二階に廊下や手擦りを付けたので、概観は悪くないと思いますが、色や模様や細部がお粗末すぎますね。モデリング技術は毎回少しずつ向上している気がしますが、仕上げについては全く進歩していない気がします(;_;)



◎次回予告

槍兵などのサンプルユニットは、実はこれまで適当な座標に配置してました。今回城モデル(=都市)を作成したので、マップオブジェクトの座標はデータファイルから読み込んで配置するようにします。

また、今後の課題として、マップ上の高度管理(高い場所と低い場所)や、森の表現方法の検討などを予定しています。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
呉書見聞
呉書見聞
三国志の呉の人物を独自の視点で考察したサイト。荊州争奪戦も呉の視点から捉え、独自の解釈を展開している。



◎川や湖を加えよう!

3Dマップは作ったものの、川や湖が無いといまいち物足りません。今回はマップに川や湖を追加します。

GIMP(フリーのCGツール)を用いてネット上の地図から河川と湖を抽出修正し、元のマップ画像と合成しました。

南陽郡地域図川湖付加01   南陽郡地域図川湖付加02



◎苦行の始まり

襄陽付近を見ていて気付いたのですが、地形と川の位置が微妙にズレています。
三国志の主戦場の1つである樊城と襄陽城は、河を挟んだ向かい合わせにあるので、襄陽の位置に川が無いとよろしくないですね~。

そもそも樊城と襄陽城の正確な位置ってどこら辺なんだろうと、ネット上のマップを拡大したら…ゲゲッ!ある縮尺から急に川が表示され始めました!それも半端な数じゃないぞ!

荊州は水郷地帯と聞いてましたが、まさかこれほどとは思いませんでした。これだけの川があるのと無いのでは違いすぎるので、これは無視できません。作り直しですね…。



◎というわけで

まだ修正中です。完成度は80%ぐらい。

この際なので、マップを拡大表示しても耐えられるように、高解像度で作り直していますが、元データの欠落が激しくて、修正に時間かかってます。最後はドット単位ですよ~(涙)

南陽郡地域図川湖付加03   南陽郡地域図川湖付加04

さすが当時中国最大の人口を誇る南陽郡です。稲作が盛んだったのでしょうが、今でもこれだけの河川があるのにはビックリしました。網の目のように広がってますね。

ついでに道も追加しました。現在の国道や高速道路をベースに、当時から残っているのではないかと思われるルートを適当に選別して修正しました。宛や襄陽は東西南北に繋がる交通の要所なので、こんな感じじゃないですかね?

部隊表示の大きさも改めました。上のマップは戦場の全体マップに相当するので、部隊を小さく表示しています。


南陽郡地域図川湖付加05   南陽郡地域図川湖付加06

拡大するとこんな感じ。実際にはこれぐらいの画面で操作することになると思います。
拡大しても、そんなにおかしくないですよね?



◎次回予告

すみません。まだ考えてません(^^;
とりあえず残り20%仕上げてから考えよう…。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
スーパーロボット大戦F
スーパーロボット大戦Fのユニット移動
ユニットはマス目の単位で移動する。縦横に比べて斜めの移動が遅いのは暗黙の了解となっている。



◎マップ座標の管理方式

今回は、ユニットや地形の位置情報をどのように管理するか検討します。


A案:四角形や六角形のマス目で区切る

A案表示イメージ   A案管理イメージ

オーソドックスな方式で、ターン制のゲームの多くに採用されています。

ユニットの移動や攻撃の範囲が明確であるため、マス目を数えて「敵の攻撃がギリギリ届かない所まで近付く」といったことが多くなります。近年は画面上の境界線をデフォルト表示せずに、オプションで選択可能としたものが多いようです。

個々のユニットに細かく指示しやすい反面、ゲーム全体のバランス(マップの大きさ、ユニット数、プレイ時間など)が悪いと、いちいち細かく指示するのが面倒に感じることもあるようです。



B案:A案をさらに細かく区切る

B案表示イメージ   B案管理イメージ

A案は1ユニットの位置を1マスで表現しますが、B案は1ユニットの位置を複数マスで表現します。

これにより、マップ上の距離感はA案より緻密になりますが、プレイヤーはマス目を意識しなくなるため、ゲームのプレイ感覚は逆に大雑把になります。

問題は、斜めに移動する場合の移動量です。
A案の場合、プレイヤーは予めマス目を意識しているので、斜め移動が速かったり遅かったりしても「そういうものだ」と暗黙の了解が成立します。
しかしB案の場合、プレイヤーはマス目を意識していないので、斜め移動が速くても遅くても不自然に感じます。

この問題は、リアルタイム制ゲームの場合、ゲーム時間によって解決できます。例えば、斜め移動は上下左右の1.4倍時間かかるようにすると違和感がなくなります。



C案:ピクセル座標やワールド座標で管理する

C案表示イメージ

マス目などの疑似的な座標を用いず、グラフィカルな座標だけで管理する方式です。

ユニットの向きや距離感はB案よりもさらに緻密でリアルになりますが、境界の概念が完全になくなるので、「このユニットは草原にいるのか森にいるのか?」が曖昧になります。

このため、地形種別は移動量にのみ影響し、攻撃力や防御力には影響しないのが一般的です。ちょっとズレただけで戦闘の勝敗が変わるということは、プレイヤーに神経質な操作を要求することになりますからね。



◎どの案が良いか?

上記A~C案のどれにするかで、プレイヤーがゲームに抱く先入観や、プレイした時の感触は、大きく異なるでしょう。

私自身はどのタイプでも抵抗なく遊んでしまいますが、マス目を意識するタイプのゲームを敬遠する人もいるようです。三国志軍記はターン制ではなくセミリアルタイム制なので、マス目を数えたりする必要は無いのですが、見た目で敬遠されるのは避けたいですね。

また、見た目という点ではC案が一番良さそうなので結構悩みましたが、今回は採用しないことにします。
地形種別による防御効果を無視することも考えましたが、三国志の場合、地形は計略にも影響するので、ユニットの地形が曖昧すぎるのは問題です。

というわけで、結局B案が良いだろうとの結論に達しました。
今の所、マス目の大きさは1ユニットの半分とし、向きは8方向とする予定です。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
マップテスト03   マップテスト04
開発中の3Dマップ画面
三国志軍記開発中のマップ画面。スペースシャトル地形データをベースに立体化したら、中国の山はこんな形らしい。



◎前回の続き

中国地図を作成したものの、ゲームのマップとして使い物になるかどうかピンとこないので、サンプルユニットを配置して確認します。

まず、地図を斜めに傾けてユニットを配置してみました。

(川や湖、道、森などは後日追加します。また、白マルは城モデルに置き換えます。そのつもりで見てくださいね!(^^;)

マップテスト01

ふむ…。
ボードゲームで遊んでるような雰囲気ですね。これはこれでアリかも。

ただ、インパクトと言うか、アクセントのようなものが無いと、ちょっと寂しいですね。
というわけで、マップの3D化にチャレンジしてみました。



◎GRを使ってみた

マップのネタを探していた時に、GRという3次元地形画像レンダラを発見しました。

3次元地形画像レンダラGR

これは2つの画像ファイルから3次元地形を生成するフリーツールで、モデルデータ形式(.DXF)への出力が可能です。

このツールを利用すると、以下の手順で3次元地形の.Xファイルを作成できます。

1.カシミールの表示設定を調整して、
  表面テクスチャとバンプテクスチャを取得する。

2.2つのテクスチャをGRで読み込み、
  3次元地形を生成して.DXFファイルを出力する。

3..DXFファイルをメタセコイアで読み込んで調整し、
  .Xファイルを出力する。

問題はバンプテクスチャとGRの相性です。やたら細かくデコボコになったりするので、カシミールやメタセコイアなど他のソフトで調整する必要があります。

GR失敗例2



◎意外な展開

数時間にわたって調整していたら、メタセコイアにデコボコ地形を作成する機能があることに気が付きました。ガーン!
(注:この機能はシェアウェア版のみ使用可能です)

結局、この機能を使用したら、一発で好感触の地形が作成できました。今までの苦労は一体?(爆)



◎3Dマップ

で、最終的に出来上がったのが、冒頭や以下の画面です。

マップテスト02   マップテスト05

シミュレーションゲームの場合、全体を把握する必要があるので、マップ表示(視点角度)は上方から見下ろすのが一般的です。斜めの角度はアニメーション等の演出や、上級者ルールで用いると思います。(上級者ルールの場合、視界外は見えない)

また、抽象化ユニットと具象化ユニットをそれぞれ表示してみましたが、抽象化ユニットの方が鮮やかで見栄えが良い気がします(;_;)



◎ユニットの表示について

抽象化ユニットと具象化ユニットを比較しました。

○抽象化ユニット
・現時点では見栄えが良い
・敵味方が一目でわかる
・部隊の向きがわかりやすい

○具象化ユニット
・武将や部隊の種類が一目でわかる
・色分けや旗などで敵味方を判別しやすくする必要がある
・かっこいい武将モデルが用意できれば見栄えが良くなる?

今の所、表示オプションで選択可能とする予定ですが、心配なのは「かっこいい武将モデルが用意できるか?」ってことですね。



◎オマケ

こんなのも試してみました。

マップテスト06   マップテスト07

う~む…微妙ですね。
大きさを調整して、抽象化ユニットを半透明にすれば、使えるかなぁ?



◎次回予告

ようやくゲームっぽい画面が表示できましたね。サンプルモデル作成に時間かかったからなぁ…。

次回は、マップやユニット情報の管理について検討します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
中国全域図01
3D地図ナビゲータ「カシミール3D」
三国志地図の作り方」を参考に作成した地図をカシミール3Dで表示した。同様に、日本地図を作成することもできる。



◎欲しいマップ

三国志軍記でまず必要なマップは以下の3種類です。

・中国全域図:荊州がどの辺かを示すために使う
・荊州全域図:戦闘地域を確定する(戦略マップ)
・戦闘地域図:戦闘を行う(戦術マップ)



◎入手できるか?

中国全域図や中国の白地図は、探せば簡単に見つかるので問題ありません。


戦闘地域図は、もし荊州各地域のマップが入手できるならそれに越したことはありませんが、無くても構いません。

地域マップが入手できた場合は、その上にユニットを配置してそのままゲームできるか試したいのですが、無ければ適当に作ります。地域マップはリアルさよりもゲームとしての面白さを重視したいので、実際と異なっていても構いません。


残る課題は荊州全域図です。できれば標高や川の地形に、当時の地名や道などもあればベストなんですが、全然見つかりません。赤壁の場所さえはっきりしないのに、荊州全域図など当時でさえ無かったかも…。



◎地図を作る

無いなら作ろう!というわけで、スペースシャトル地形データで地図を作ってみました。(冒頭図参照)

標高と、当時の地名があるのが良いですね。道は自分で加えるしかないでしょうが、川や湖もありません。また、荊州は中国中央部で海岸線が無い上に、平坦な平地ばかりなので、この地図と相性がよくないですね。

実際に荊州全域を表示しても、全くピンときません。川や湖を加えると、面白くなるかなぁ?

荊州全域図01

荊州ってこんなに南北に長かったんですね。北部と南部の2マップに分けるか後日検討しましょう。


さらに、荊州の中心である南陽郡をアップにしてみました。
これに川、湖、道、森などを追加したものが実際に戦う戦術マップになりそうです。

南陽郡地域図01

劉備が駐留した新野や、曹仁が関羽と対峙した樊城などがあります。(樊城は南郡に属しますが、ゲーム上は南陽郡マップに含めてしまいます)

当時全国でもっとも人口の多かった郡だけあって、領城が37もあるとのこと。多いですね~。
これだけの城を期間内に全て制圧するのは大変そうです。戦略が問われますね。



◎次回予告

今回は地図を作ってみましたが、これをゲームに使うとどんな感じになるのでしょう?
というわけで、次回はサンプルユニットを配置してみます。

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

| BLOG TOP |
DATE: CATEGORY:3Dテストプログラム開発
森のくまさんラストシーン
森のくまさんラストシーン
3Dテストプログラムのデモは、BGMとアニメーションの同期が1秒でもズレると台無しになる。



◎移行完了しました

前回の記事で、コンテントパイプライン系に問題が発生したと記述しましたが、解決しました。

それらのプログラムは別のプロジェクトに独立していたので、そのプロジェクトもXNA3.0に移行したら、あっさり動きました。

結局、ソースは何もいじらずに、ウィザードで変換してDLLを上書きしただけで移行できました。XNA先駆者達の報告では、移行に苦心した人の方が多そうだったので意外ですね。



◎タイミングがずれる問題

移行したプログラムを動かしてみると、BGMとアニメーションのタイミングがずれるのが気になりました。実行する度にズレの程度が変わるのですが、酷い時は2~3秒ずれます。

最初はXNA3.0の問題かと思いましたが、XNA2.0でも同じ現象が再現しました。そこでいろいろ試してみたのですが、実行する度にズレたりズレなかったり、ズレの幅もまちまちなので、同じテストを何度も行うはめになりました。

・XNA2.0の体操服化前のバージョンでも再現する
 →体操服化が原因ではない

・EXEを実行しても再現する
 →デバッグモードが原因ではない

・サブマシンでは再現しない
 →メインマシンの環境の問題

・ネットワーク回線切断時に再現率が高い
 →たまたま?

・全画面表示時に再現率が高い
 →窓枠表示(非全画面表示)ではほぼ再現しない



◎原因判明

CPU使用率を確認したら、窓枠表示時は15~20%ぐらいで、全画面表示時はほぼ100%でした。結論としては「全画面表示時に処理落ちしてタイミングがずれる」ということですね。

尚、、メインマシンのCPUはCore2Duo-2.6GHzで、XNAプログラムはその片方のCPUで動作します。もう片方があるのでPC全体は余力があり、CGも綺麗で滑らかに表示されているので、処理落ちしてるとは気付きませんでした。

考えてみれば、表示処理がオーバーしてるのにフレームを落とさないからタイミングがずれるんでしょうね。ドライバ設定を調整すれば直るかもしれませんが…とりあえず原因判明したからいいや。


ちなみに、サブマシンの方はPentium4-1.6GHzですが、グラフィックボードGeForce5200FXを増設してます。古くて安いボードですが、結構役に立ってたんですね。

メインマシンはグラボ増設してません。XNAがオンボードで動くだけ儲けものですが、全画面表示がこんなにCPU負荷かかるとは知りませんでした。



◎気になること

開発時はここまで気にならなかったんだけど、以前からこんなにズレてたかなぁ?う~む…。

それと、起動時のデフォルトは全画面表示やめて窓枠表示にした方が良かったかなぁ?でもXNAゲームプレイヤーの大半はグラボ増設してそうだし…。

あと、タイミングを合わせる時間として、ゲーム時間(GameTime)はやめた方がいいのかなぁ?でも実時間から取得すると、途中の処理が飛ばされて変な現象やバグが出そうなんだよね…。

例:XNAプログラムは、タイトルバーを押すとゲーム時間がストップします。但し、BGMは非同期に演奏されます。今はゲーム時間を取得してるので、BGMとアニメのタイミングはズレますが、バグは発生しません(多分)。

ここを押すと時間が止まる!



◎次回予告

変なところで時間を喰ってしまいましたが、原因は判明したので良しとしましょう。

次回からXNA3.0環境でプログラム開発をスタートします。
まずはマップですかね~。

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

| BLOG TOP |
DATE: CATEGORY:3Dテストプログラム開発
XNA3.0でスキンアニメーション
XNA3.0上で実行した画面。ACL2.0と全く同じ手順でスキンアニメーションができる。詳細はコチラ



◎XNA3.0に移行すべきか?

元SEの性(?)なのか、私は特に必要がない場合はソフトウェアのバージョンアップをしないタイプです。
手間がかかるし、不具合が発生すると嫌なので、安定環境のまま延々と引っ張ります。

XNA3.0はZune対応をウリとしていますが、私はZune対応する予定はありません。そのためXNA3.0は私にとって魅力が少ないように感じます。

しかし今は三国志軍記のプログラム開発を始める所です。移行には絶好のタイミングと言えるでしょう。そこで今回は移行するメリットとデメリットを整理し、移行可否を検証します。



◎メリットとデメリット

私がXNA2.0からXNA3.0に移行するメリットを記述します。

A:コンテンツが圧縮されてファイルサイズが小さくなる
B:マイクロソフト社のサポートを長く受けられる
C:将来XNAをさらにVersionUPする時のリスクが少なくなる

また、デメリットは以下の通りです。

a:移行に手間がかかる
b:不具合が発生する可能性がある
c:ヘルプやサポート情報が日本語化されてないものが多い
d:アニメーションライブラリ(ACL2.0)が動かない可能性が高い

…正直あまりメリットは感じませんね~。直接的なメリットはAだけですか?

まぁ、既存の資産は少ないので、aとbはちょっと頑張れば何とかなるでしょう。cは時間が解決すると思うので、それまで耐えるだけの話ですが、dが解決できないと致命的ですね。



◎XNA2.0からXNA3.0への移行

マイクロソフト社のHPを確認すると、XNA2.0とXNA3.0は同居可能とありました。これはありがたいですね!昔の資産は無理に移行せずに済みますし、移行する場合でもそれぞれの環境で試しながら移行できます。
ちょっと意欲が湧いてきましたよ!というわけで検証開始!

・念のため既存ファイルをバックアップ
・Visual C# 2008 Express Edition と XNA3.0 をインストール
・Visual C# 2008 で XNA2.0 のソースを開くと、VisualStudio変換ウィザードが自動起動する(バックアップも行われる)

で、変換後のプログラムをビルドすると、ACL2.0関連でエラーになりました。予想通りですね~。

プロジェクトに「参照の追加」でACL2.0を登録しても、ContentProcessorの候補一覧にACL2.0が追加されません。やはりXNA3.0でACL2.0は使えないようです。



◎アニメーションライブラリの移行

私は今回XNA3.0+XNAnimation(ACLとは別のアニメーションライブラリ)を試そうと思っていたのですが、その前にACLのホームページを確認すると…あれっ?11/26にACL3.0らしきものがUPされてるじゃないですか!
これはタイミング的にかなりラッキーかも…早速検証開始!

例によってDwarfTutorial 3.0があったので、これをゲットして解凍すると、プロジェクトファイル名は「DwarfTutorial 2.0.sln」となっています。
とりあえずXNA3.0上で実行すると…XNA3.0上で問題なく動きました。ファイル名は昔のままですが、DLLはちゃんとXNA3.0に対応しているようですね。

新規プロジェクトを作成して「XNA2.0でスキンアニメーション」の手順に従ってやってみると…おおっ動きました!手順もソースも全くそのままで動きましたよ!(冒頭図参照)

XNA2.0からXNA3.0にコンバートした既存プロジェクトのDLLを上書きコピーすると…ソース一切変更無しで動きました!DLL作者さんありがと~!(^^)



◎3Dテストプログラムの移行

これだけ手軽に移行できると、どこまで出来るか試してみたくなりました。というわけで、既存プログラムの中で最も複雑な3Dテストプログラムの移行にチャレンジ!

…エラーになりました。アニメーション系ではなく、漢字表示を実装しているコンテントパイプライン系のようです。
はぅ~!

コンテントパイプライン系ってちょっと苦手なんですよね~。もっと単純な実装にすれば良かったかなぁ…ブツブツ…。

まぁXNA2.0と3.0は同居できるので無理に移行する必要は無いんですけど、勉強がてら少し調べてみますかね…。



◎最後に

今回はXNA3.0+XNAnimationの検証になると思っていたのですが、話は意外な方向に進んできましたね~。
一応簡単にまとめると

・ACLの移行は、DLLを上書きコピーするだけ
・コンテントパイプライン系で問題あり?(調査は後日)

尚、ACL3.0にはXBOX360用のDLLも同梱されていますが、私はXBOX360不所持のため動作検証していません。
もし誰か検証したら、結果を教えてください。よろしく~。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
馬01 槍兵01 槍騎兵01
馬、槍兵、槍騎兵の3Dモデルデータ
ホームページからフリー素材としてダウンロードできるようになった。モーションデータも付属している。



◎UPしました

馬、槍兵、槍騎兵モデルをフリー素材としてUPしました。
人型モデルのフリー素材は多数ありますが、馬や騎兵のフリー素材は珍しいと思います。

少ないですけど、モーションデータも付けてあります。
RokDeBone2を使っている人は、兵士モデルを差し替えて走らせることも可能です。

初めて作った3Dモデルですので稚拙ではありますが、これを叩き台として改造するなり差し替えるなりしてください。



◎テクスチャ変えました

絵が描けないので写真を加工することにしたのですが、ネタ探しや加工に苦労しました。

顔写真のフリー素材はありそうで意外と少なく、しかも正面向きで3Dモデルに貼り付けられそうなものとなるとなかなか見つかりません。手配写真も探してみましたが、これも見当たらず。肖像権の問題ですかね?

何とか1枚候補を見つけたものの、メガネしてるわ正面からずれてるわ胸元が開いてないわで加工が大変なことに…windowsのオマケのペイントツールじゃ限界ッス!(爆)



◎手をスキャニング

顔ほどではありませんが、手も少し苦労しました。手の写真素材は大量にあるのですが、手の平(掌)ばかりで手の甲は格段に少なかったのです。大量の写真画像から手の平と甲のセットを探し出すのは容易ではなく、諦めて自作に切り替えました。

自分の手のイメージを取得する場合に、カメラかスキャナかちょっと悩みましたが、平面に近いものはスキャナの方が綺麗に撮れそうなので、スキャナを使うことにしました。

今年買ったばかりの複合機で初めてスキャニングしてみましたが、扱いは非常に簡単だし、スキャンは早いし、驚くほど緻密で綺麗でした。昔のDOSやNTの頃とは比較になりません。時代は進化してるのね…。

手の平は簡単にスキャンできましたが、問題は手の甲。ちょっと膨らんでてなかなか綺麗にスキャンできなかったのですが、本を持ったり手を併せたりして何とかそれなりのイメージを取得できました。
何度も撮り直したお陰で、腕が痺れてきましたよ(笑)


手のひら
手のひらのスキャン画像
拡大して見ると、細かいシワや血管まではっきり見えます。これで低解像度モードとは驚きですね~!



◎調整は各自で

ペイントやメタセコイアで修正している時はあまり気にならなかったのですが、XNAまで持ってくると明暗が強調されて、頬の白さや手の平の暗さが気になります。手の平の方はこれでも修正したのですが、まだ暗いですね。頬の方はちょっと無理っぽいです。

まともなペイントツールを使うか、XNAでエフェクト制御できればもう少しマシになるかもしれないんですけど、今はどちらもできません。今後の技術課題ですね。


3Dモデル全体としては、他にもお粗末な所ばかりなのでいちいち挙げません。データは自由に改編して構いませんので、気に入らない所は各自で調整してください。



◎次回予告

サンプルモデルがとりあえず一段落したので、ようやくプログラム系に入ります。

まずはプログラム環境の見直しということで、XNA3.0とアニメーションライブラリを検証します。

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

| BLOG TOP |

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