ゲームプログラミング相談室【Part6】

**名前は開発中のものです。** · 04/03/06 01:25

ゲームプログラミング全般の質問スレッド。
扱う話題のダイナミックレンジはやや広め。包容力高め。
他の初心者質問スレとの棲み分けを探りつつ
これからもマターリと活用しておくれ。
　
■過去スレ
【Part2】http://pc.2ch.net/tech/kako/985/985540361.html
【Part3】http://pc.2ch.net/tech/kako/1002/10028/1002894129.html
【Part4】http://game.2ch.net/gamedev/kako/1005/10050/1005040025.html
【Part5】http://pc2.2ch.net/test/read.cgi/gamedev/1036410116/
■関連スレなど
>>2-5

**名前は開発中のものです。** · 2006/01/27(金) 17:05:37

>>724-725
ごめん、本当に初心者です
バッファリング用のint二次元配列と当たり判定用のint二次元配列を一緒にしようと思ってたので頭がこんがらがってしまって
別々に作ってみます
ありがとうございました

**名前は開発中のものです。** · 2006/01/27(金) 17:10:51

レイヤ使わないなら、判定用に分けなくてもいい気がする。

**名前は開発中のものです。** · 2006/01/27(金) 18:16:19

BMP読み込み
マップデータ(ブロック種類記述)読み込み
マップデータからマップデータ配列
struct MapData{
　　POINT pt;
　　int type)

**名前は開発中のものです。** · 2006/01/27(金) 18:16:51

うっわ恥ずかしミス

**名前は開発中のものです。** · 2006/01/27(金) 20:46:59

可愛いよ>>729
その恥じらう姿がたまらなく可愛いよ>>729

**名前は開発中のものです。** · 2006/01/27(金) 21:24:04

>>728
書きかけだし、ミスならアレだけど、
なんで POINT が必要なのかな・・・かな？

**名前は開発中のものです。** · 2006/01/27(金) 21:48:01

0とか1とかが並んだマップデータファイルからデータを読み込んでtypeに格納、その際POINT型のptに座標(開始0,0)も格納
座標は1チップ読み込む度に座標+=1チップのサイズ
これを100チップx100チップの仮想BMP(マップファイル)に書き出す
キャラクターの座標はクライアント領域内の座標じゃなくマップ内の座標にする
・・ってのをやってみたいと思ってる
マップ作っちゃうと重くなるかな？

**名前は開発中のものです。** · 2006/01/27(金) 22:41:59

おｋ、把握した。チップ画像の座標てことね。

そんなんでいいと思うよ。

**名前は開発中のものです。** · 2006/01/27(金) 22:43:08

良かった
がんばってみる

**名前は開発中のものです。** · 2006/01/27(金) 22:44:24

参考までに
http://gamdev.org/w/?%5B%5B%A5%DE%A5%C3%A5%D7%A5%A8%A5%C7%A5%A3%A5%BF%5D%5D

**名前は開発中のものです。** · 2006/01/27(金) 22:48:15

ありがとう
今エディタ探してたところ

**名前は開発中のものです。** · 2006/01/28(土) 05:38:41

>732
今のPCパワーなら何ら問題無い
メモリの有効利用がキーになるけど
それよりもマップの画像データを
作るほうが大変

**名前は開発中のものです。** · 2006/01/28(土) 10:21:30

ttp://ian-albert.com/misc/gamemaps.php

有名どころのマップ集。デザインの参考にはなるんでない？

**736** · 2006/01/28(土) 20:54:31

ttp://dream.my-sv.net/upload/src/up0124.zip
ここまでやってみた。画像はマップ作成ツールのサンプル
ただスクロールがなんかおかしい
当たり判定はuser構造体内のPOINT型mptとmapdata構造体配列でやりたいと思ってるけど実装の仕方がわからなくてグダグダ
マップとか画像はセンスが無いからどうにも･･･

**名前は開発中のものです。** · 2006/01/29(日) 01:48:00

ざっとソース見させてもらったけど、気になる点がいくつか。
仮想BMP、まさか本当にマップファイルの大きさのBMPを用意するのはさすがにまずいと思う。
それからマップチップの画像は一枚にまとめておいたほうが扱いやすいと思う。

struct MapChipData {
POINT src; // マップチップ「「画像」」の開始座標を格納
int type;
}

int MapData[MAP_HEIGHT][MAP_WIDTH]; // ここにマップデータをそのまま読んで番号を格納していく

こういうの用意して、例えば0,0からマップを画面に書きたかったら

for (int y = 0; y < 20; y++) { for (int x = 0; x < 15; x++) {
POINT src = MapChipData[ MapData[y][x] ].src; // これでチップの座標取って
// ここらでsrcを使って裏画面にマップを描画。ソースは省略
}}

あと、初心者で普通のRPGのように滑らかな移動を初めから実装するのは無謀だと思う。
まずは、チップサイズ（この場合32ドット）毎にキャラが移動するように作って
それで、仕組みを理解してから滑らかにスクロールするところを作りこんだほうがいいと思う。

当たり判定については、キャラを実座標で扱っているからごちゃごちゃしてるんだと思う。
例えば右に移動するのを+10ドットとするのではなく、右に+1とする。
そのとき、一緒に当たり判定するとか。

// 右に移動したとき呼ばれたとして、typeで判定かな
if ( MapChipData[ MapData[自キャラのY座標][自キャラのX座標 + 1] ].type == 1 )
{ 自キャラのX座標 ++ }

当たり判定用のマップ作りたい場合はマップデータをintじゃなくて構造体にして詰め込めばいい。と思う(´･ω･`)

**名前は開発中のものです。** · 2006/01/29(日) 15:34:49

Direct Graphics の描画時の同期(Present()の終了待ち)をタイマーの代わりにしていたけど、
それだと、ウインドウモードでFPSが変わると速度の変化があるよね。

60Hzと75Hzで同じような処理を行うには、75のときに5回に一回飛ばせばいいだけなの？
それだとカクカクしない？

**名前は開発中のものです。** · 2006/01/29(日) 16:01:50

カクカクする。
でもそれは仕方の無いことだとあきらめてる。
解決策教えてエロい人。

速度を一定に保ちたいなら、１秒間でどのくらい動くかということを考えて
フレームごとの移動量を足していくようにすればいい。

**名前は開発中のものです。** · 2006/01/29(日) 16:16:20

>>740
はじめに数枚のマップチップを張り合わせたbmp画像を読み込んでおき、
struct MapChipData {
　POINT src; // マップチップ「「画像」」の開始座標を格納
　int type;
}mapchipdata[読み込むチップ数]
にマップチッブを張り合わせたbmp内の目的チップの座標とタイプを格納して
マップの再描画が必要になったとき(スクロール時等)にマップチップをメモリデバイスに貼り付け
ということでしょうか？

あと当たり判定の
if ( MapChipData[ MapData[自キャラのY座標][自キャラのX座標 + 1] ].type == 1 )
はMapData[自キャラのY座標/チップサイズ][自キャラのX座標/チップサイズ + 1]ですか？

そろそろGDI卒業してDirectGraphic使いと思って本屋で探したけど2Dからの入門書探しても3Dしかない・・

**名前は開発中のものです。** · 2006/01/29(日) 16:48:30

自キャラの位置をマップ座標で持ってるなら、32で割る必要なしだと思うが。
そのところは好きに実装すればいいんじゃね？

単にキャラの座標を32倍して保持するか、しないかの差だろ。
歩くたびに割り算するのはあんまり好きじゃないけど、今時のPCならどうでもいいことだろうし。

要は短形で判定する必要はないってことじゃないかね。
1ピクセルが一歩なら別の方法取らなければならんが。

**名前は開発中のものです。** · 2006/01/29(日) 17:05:54

MapData[40][40];に自キャラ座標のmapdata[120][130+1]を要求するとおかしくなると思ったので
キャラの1歩を32ドットとして当たり判定は移動先の座標にブロックがあるかないかで判断すると
キャラ移動時のアニメーションが必要になりますね
その辺りも勉強しておかないと

**名前は開発中のものです。** · 2006/01/29(日) 17:34:55

判定方法と、移動時のアニメーションの必要性の有無に因果関係はない。

**724** · 2006/01/29(日) 17:36:03

俺は740のソースしか見ていないから違ってるかもしれんが
「自キャラの座標」は適当に直して使えということではないかな？
俺だったら32倍して持たないけど。

745の二行目以降はよく意味が解らん。アニメーション関係あるか？？

**名前は開発中のものです。** · 2006/01/29(日) 17:50:53

>>746-747
ポケモンとかのゲームは1歩が1マスで移動時にアニメーション
同じように1歩を1マスにするとアニメーション使わないと見栄えが悪くなるかなと思って
まだまだそんなこと言ってられるレベルじゃないけど
>「自キャラの座標」は適当に直して使えということではないかな？
なるほど。自キャラの座標は実座標で扱ってたのでマスとして扱ってみます

**名前は開発中のものです。** · 2006/01/29(日) 17:53:21

勘違いしてほしくないので補足。

/ 32 自体が間違ってるから不要と言ってるのではなくて
まぁ初心者だから、好きなようにやってみるといいんじゃね？
あとから仕組みがわかるだろうさ、という意味。

**名前は開発中のものです。** · 2006/01/29(日) 18:12:51

なんかRPG作りたくなってｷﾀｰよ

**名前は開発中のものです。** · 2006/01/29(日) 19:33:33

>>750
http://hobby-const.bbs.thebbs.jp/1126798622/
こんな感じのか？

**名前は開発中のものです。** · 2006/01/29(日) 20:27:43

便乗質問ですが、ウィザードリィやＭ＆Ｍ、女神転生などの
３Ｄダンジョンはどのように作れば良いでしょう。

**名前は開発中のものです。** · 2006/01/29(日) 20:42:43

>>752
「どのように」って質問されてもな。何答えろって言うんだろうな。
大工さんに頼めという答えを期待しているのだろうか？

1,データをどのように持つのか？
　　　→　自分が作りたいものを内部的にどう表現するのか？
2,準備したデータをどのように表示するのか？
　　　→　自分の場所と方向を変化させても通用するように一般化させてコードに落とす

の2段階を考えれば、全体の流れは明確だと思うのだが。

まず着手してもらえるかい。
その中で個別に問題が出てきたら、ここで質問するといいよ。

**名前は開発中のものです。** · 2006/01/30(月) 14:41:03

>>752
状態に応じた画像を用意しておきそれを組み合わせて表示する。

**名前は開発中のものです。** · 2006/01/30(月) 20:49:25

ttp://dream.my-sv.net/upload/src/up0126.zip
マップ間のリンクなんとかならないだろうか
いちいち位置を指定するのは面倒

>>749
いろいろやってみてるけどやっぱり難しいね
前作った物はキャラ移動の度に全てのチップに大して当たり判定してたから酷かった

**名前は開発中のものです。** · 2006/01/31(火) 11:37:06

>>755
ソースをアップするのは自由だが文面から察するに
「誰かソース見て添削してくれ」と言わんばかりだな。
そのスタンスは歓迎されないし自分の為にならない。
僕らは君の先生じゃない。だが焦点を絞って質問すればその限りではない。

>マップ間のリンクなんとかならないだろうか
>いちいち位置を指定するのは面倒
マップを増やすたびにコンパイルが必要と言うのはあまりよくない。
どのマップからどのマップへ移動というデータは外部で持つべき。
そのトリガはマップチップの番号なのは言うまでもない。
とにかくアルゴリズム以外は外部ファイルに追いやる事が慣用。

**名前は開発中のものです。** · 2006/01/31(火) 21:00:44

なんだかんだ言ってソースを見てる>>756に萌え。

**名前は開発中のものです。** · 2006/01/31(火) 23:47:03

…ななな何言ってんのよ！！ふっ、ふざけないでよ！
私だって、す、好きでやってるわけじゃないからね！
べ、別にあんたなんか困っててもかまわないんだから！

バカーーーーーーーーー！！！

**名前は開発中のものです。** · 2006/02/01(水) 02:12:15

つんでれワロス

**名前は開発中のものです。** · 2006/02/02(木) 16:47:09

マリオ風アクションゲーム作りたくて設計を考えてるんだけど、マップ内の移動と描画はいいとして
敵とかのプレイヤーが動かすことのできないオブジェクトはどうやって表現するの？
出現条件とかもわからないし

**名前は開発中のものです。** · 2006/02/02(木) 16:59:17

>>760
>敵とかのプレイヤーが動かすことのできないオブジェクトはどうやって表現するの？
まぁ基本はこんな感じか。
for (i = 0; i < キャラクタの数; i++)
{
obj[i]->Move();// 移動処理&マリオとの当たり判定など
}

>出現条件とかもわからないし
出現条件はマリオの居る現在位置から割り出し、
画面に出現する直前にキャラクタの登録をしてるんじゃないかな？
それかマップのロード時に一括して登録して移動処理はしないで画面で出そうになったら
移動処理を開始するとか。いろいろ方法はあるな。

**名前は開発中のものです。** · 2006/02/02(木) 17:47:28

>>761
なるほど。
やっぱり専用のスレッドを作った方がいいでしょうか？

**名前は開発中のものです。** · 2006/02/02(木) 18:00:45

スレッドを作るほどのことではない。

**名前は開発中のものです。** · 2006/02/02(木) 18:26:05

というよりスレッドなんか作ったらいかん。

**名前は開発中のものです。** · 2006/02/02(木) 19:59:29

>>763-765
勘違いしてるかもしれないので一応
_beginthread()で生成して_endthread()で破棄するスレッドのことです
現在メッセージループメイン関数(描画処理をプロージャのWM_PAINT内で行う)のほかに
キャラクター表示座標、マップ内表示座標調整スレッドがあります

**名前は開発中のものです。** · 2006/02/02(木) 20:00:39

ありますと言うか予定してます

**名前は開発中のものです。** · 2006/02/02(木) 20:34:10

>>765
いやたぶん>>763-764は勘違いしてないと思うよ。
メッセージループとゲーム処理用のスレッドは分けてもいいけど、
ゲームでは仕事ごとにスレッドなんぞ作ったりしない。
マルチスレッドなんぞそれが絶対に必要な状況でなければしないほうがいい。

細かい事だが・・・
>プロージャ
プロシージャな。

**名前は開発中のものです。** · 2006/02/02(木) 20:37:45

>>767
そうでしたか
スレッド重くなりますかね
>プロシージャ
今までずっとプロージャプロージャ(ry

ありがとうございました

**名前は開発中のものです。** · 2006/02/03(金) 17:39:09

ゲーム作りたいけど何をどうすればいいか分からない
まぁゲーム以前にDirectXの扱い方知らないわけですが

**名前は開発中のものです。** · 2006/02/03(金) 17:42:45

チュートリアルなぞって、コードを入力しながら動作を確実に確認する。
途中で絶対飛ばさず最後までやる。
これだけである程度は使えるようになる。

**名前は開発中のものです。** · 2006/02/03(金) 18:24:26

何も分からないあなたに

　Ｈ　　　Ｓ　　　Ｐ

**名前は開発中のものです。** · 2006/02/03(金) 18:30:17

>>771
C言語とWindowsAPIは分かってるかもしれない。

**名前は開発中のものです。** · 2006/02/07(火) 15:21:25

チュートリアルってどこにあるん？

**名前は開発中のものです。** · 2006/02/07(火) 15:42:19

SDKのなか

**名前は開発中のものです。** · 2006/02/09(木) 00:16:23

d3dでｘファイル表示して動き回るところまでは行けたんだが、
肝心のキャラクターのモデリングが全く進まん・・・
というより、どういうキャラを作れば良いか全く不明orz
ゲームの趣旨考えてなかったツケがこんなに早く回ってきた・・・

**名前は開発中のものです。** · 2006/02/09(木) 00:46:35

初期化やらライティングやらマトリックスでコンパイルエラーしまくって鬱状態の俺の前でそんなこと言うか
万死に値する

**名前は開発中のものです。** · 2006/02/09(木) 00:48:24

matrix・・・orz
それ聞くと鬱になる・・・

**名前は開発中のものです。** · 2006/02/09(木) 01:21:47

>コンパイルエラーしまくって

さすがにそれはプギャー

**名前は開発中のものです。** · 2006/02/11(土) 20:44:09

>>777
そんな君に
つQuaternion

>>778
コンパイルエラーならどこが悪いか箇所教えてくれるだけまし

**名前は開発中のものです。** · 2006/02/11(土) 21:09:44

3Dゲームについて聞きたいんだけど
テクスチャマッピング機能ってどうやって使うの？
VertexBufferに入れた物体には適応できるけど
Xファイルには適応できないような・・

**名前は開発中のものです。** · 2006/02/11(土) 21:57:41

>>780
最近のD3Dはわからんのだが、
基本的にXファイル自体はマテリアルやテクスチャを内部で持っている。
読み込むときに自前でテクスチャをロードし、
描画時にデバイスにSetTexture()する。

**名前は開発中のものです。** · 2006/02/11(土) 22:34:00

yaneSDK3のフレームスキップの部分なんですが/**/のところが意味がわかりません。
なぜ2フレームと書いてあるのにdwWait*3なのでしょうか？

void CFPSTimer::WaitFrame(){ // (C)yaneurao 1998-1999
DWORD t = timeGetTime();
m_dwFPSWaitTT = (m_dwFPSWaitTT & 0xffff) + m_dwFPSWait; // 今回の待ち時間を計算
// m_dwFPSWaitは、待ち時間の小数以下を１６ビットの精度で持っていると考えよ
// これにより、double型を持ち出す必要がなくなる。
DWORD dwWait = m_dwFPSWaitTT >> 16; // 結局のところ、今回は何ms待つねん？
DWORD dwElp = (DWORD)(t - m_dwLastDraw); // 前回描画からいくら経過しとんねん？
if (dwElp>=dwWait) { // 過ぎてるやん！過ぎてる分、250msまでやったら次回に持ち越すで！
DWORD dwDelay = dwElp-dwWait;
//250以上遅れていたら、フレームスキップしない（初期化のため）
//そして、遅れ時間は0として扱う
if (dwDelay >= 250) dwDelay = 0;
/**///２フレームの描画時間以上ならば次フレームをスキップする
m_bFrameSkip =(dwDelay >= dwWait*3);
if (m_bFrameSkip) m_dwFrameSkipCounterN++;
t -= dwDelay;
// 今回の描画時刻を偽ることで、次回の描画開始時刻を早める
m_dwLastDraw = t;
m_dwElapseTime[m_nDrawCount & 31] = 0;
return ;
}
// ほな、時間を潰すとすっか！
m_dwElapsedTime += dwElp; // 時間待ちした分として計上
m_dwElapseTime[m_nDrawCount & 31] = dwElp;
m_bFrameSkip = false;//次はフレームスキップしない
::Sleep(dwWait-dwElp);
m_dwLastDraw += dwWait; // ぴったりで描画が完了した仮定する。（端数を持ち込まないため）
}

**名前は開発中のものです。** · 2006/02/11(土) 22:39:19

>>781
なるほど。
全てXファイルを使用するなら必要のない機能ということですね

**名前は開発中のものです。** · 2006/02/11(土) 22:45:31

そりゃあんた、一周の待ち時間が*1だからじゃよ。
（余計にかかった時間が）2フレームの描画時間以上なら…
と読み替えればよろし。

つか、キモいコメントだね。
関西人ってみんなこうなの

**名前は開発中のものです。** · 2006/02/11(土) 22:54:06

関東だろうが関西だろうが、キモい奴はキモいんだよ。
関西人と一括りにするのは失礼。

**名前は開発中のものです。** · 2006/02/12(日) 01:38:10

関西人だけど確かに>>780はキモイ希ガス

**名前は開発中のものです。** · 2006/02/12(日) 01:39:35

ちなみにコイツはﾁｭﾝだな

**名前は開発中のものです。** · 2006/02/12(日) 01:43:36

初心者の俺をキモい呼ばわりですか

**782** · 2006/02/12(日) 03:40:55

>>784
実をいうと２フレームというところからして理解できないので
m_bFrameSkip = dwDelay > 0;
としました。

**名前は開発中のものです。** · 2006/02/12(日) 11:39:09

>>782
コメントもコードもキモすぎると思ったら
あの偏執狂やねうらおか

**名前は開発中のものです。** · 2006/02/14(火) 03:36:39

また大阪か

**名前は開発中のものです。** · 2006/02/14(火) 03:47:35

テクスチャのお勉強にDirect3Dを使って2Dのゲームを作りたいのですが、
薄い面だけのポリゴンを複数画面に並べ、そこにマップチップ等のテクスチャを貼り付ければいいのですか？
自キャラの描画もキャラ用の薄い面にアルファ値を設定したテクスチャを貼れば大丈夫ですよね？

**名前は開発中のものです。** · 2006/02/14(火) 04:05:40

>792
日本語で（ｒｙ

マジで薄い面って何だよ

**名前は開発中のものです。** · 2006/02/14(火) 04:11:34

三次元のポリゴンでなくて頂点が4つしかない普通の四角形
日本語は苦手

**名前は開発中のものです。** · 2006/02/14(火) 08:19:24

ポリゴンはそもそもただの三角形。

**名前は開発中のものです。** · 2006/02/14(火) 08:51:04

>>795
それは言い過ぎ。
「ポリゴン」とだけ言った場合は「多角形」という意味。

>>792-794
マジエスパーすると、いわゆる矩形スプライトのことだろう。

**名前は開発中のものです。** · 2006/02/14(火) 10:49:04

もうちっと3Dグラフィックに関する勉強が必要なんじゃないか

**名前は開発中のものです。** · 2006/02/14(火) 14:00:53

>>796
それっぽいです
ポリゴンに貼り付けないと2Dは描画できないと思っていたので

>>797
参考書と睨めっことか嫌いだから
いろいろ作りながら覚えていこうと思ってる

いってくる

**名前は開発中のものです。** · 2006/02/14(火) 21:01:27

「ビルボード」でいいんでない？

**名前は開発中のものです。** · 2006/02/15(水) 13:57:58

SDKだと「スプライト」が座標変換無しの2D画像で
「ビルボード」は爆発とかに使う座標変換ありの1枚板だな

**名前は開発中のものです。** · 2006/02/15(水) 18:51:04

>>80
ゼノギアスの戦闘シーンのキャラとか、FFTのキャラとかがビルボードですな。
爆発にも使えるけど。

どちらかといえば2Dの描画というより、3Dの背景の中に
2D絵をなじませるための技術だと思っていたが、その理解でいいのかな？

**名前は開発中のものです。** · 2006/02/18(土) 19:38:52

3Dゲームは描画用マップとコリジョンマップに分けると聞いたのですが、
描画用マップとコリジョンマップは1ステージ全て1つのXファイルで作るんですか？

**名前は開発中のものです。** · 2006/02/18(土) 20:10:32

キャラクターと衝突判定する部分だけに特化したデータを作ってもらうといいじょー。
例えば天井に衝突しないゲームなら、デザイナーさんに天井無しにしてもらうとか。
描画用ではカーブでも衝突用のは多少ごつごつしてても平気っす。
描画用もヒットチェック用もXファイルじゃなくってもいいけど、基本別々です。

**８０３** · 2006/02/18(土) 20:13:53

×カーブ　○滑らかなカーブ

**名前は開発中のものです。** · 2006/02/18(土) 21:07:24

>>803
なるほど、描画用マップはテクスチャ情報の付いたXファイルなど、
コリジョンマップは壁や各オブジェクトの位置を表したデータファイル・・・であってますか？

>作ってもらうといいじょー。
業界人ではないので誰にも作ってもらえないですorz
コリジョンマップエディタとかあるらしいのですが有料でしょうか

**名前は開発中のものです。** · 2006/02/18(土) 21:28:28

逆にコリジョンマップを含めたステージの論理的なデータから
風景を生成するっていう考え方もあるが、まぁ普通は別々に作るんだろうな

**８０３** · 2006/02/18(土) 21:51:17

>>805
そそ、描画データが大体、x,y,z,nx,ny,nz,u,v,面情報,マテリアル情報などなど～、とかだけど
コリジョン用は、x,y,z,面情報、で十分なので。

>コリジョンマップエディタ
オラにはわかりませんです。

>>806
風景データの完成後、それをコピって別レイヤーで
がすがす頂点削ってく作業なので結構すぐ作ってくれます。
２～３週間で作るデータでも、１・２日でコリジョンデータは出来てくるっす。

**名前は開発中のものです。** · 2006/02/18(土) 23:15:29

gtkradiantだっけ？
そういうのもあるらしい。

**名前は開発中のものです。** · 2006/02/19(日) 00:17:34

FF７～９のように一枚の２Ｄ絵に描かれた３Ｄ世界の中を３Ｄのポリゴンキャラが動き回るゲームって
どうやって実現しているんでしょう？
特に、スクロールとかやった時にどうして遠近感や空間関係が破綻しないのか不思議です。
なんたって、キャラは３Ｄで背景は２Ｄですからね。作るの難しいですかね？

**名前は開発中のものです。** · 2006/02/19(日) 01:57:03

あれは一枚のように見えるけど一枚じゃないぞ

**名前は開発中のものです。** · 2006/02/19(日) 09:01:11

>>809
フィールドは、全部３Ｄでおおまかなブロックにわけてスクロール。ＦＦ７で時々読み込み失敗する；；（飛空挺？とかで）
ダンジョンは、カメラの視点・注視点が動かないシーンは背景を２Ｄでプレイヤーの前面にくるオブジェを
３Ｄ計算で（これは２Ｄ計算（描画順序のみ）のままでもいけるところもあるかも）。
ムービーへ切り替えするときは、背景をムービーとして、カメラワークとプレイヤーの前面にくるオブジェだけ３Ｄ計算。

**名前は開発中のものです。** · 2006/02/19(日) 14:15:08

注視点が動かないシーンなら分かるんです。コンポジションソフトと同じ要領でしょ？
問題はカメラがキャラを追って大きくパン（背景絵もスクロール）するような広いダンジョンの場合は？
空間関係を保持出来ませんよねぇ？

**名前は開発中のものです。** · 2006/02/19(日) 15:12:31

コツとしては絵の中の道は実際の３Ｄデータとして考えて、
カメラワークをキャラクターの位置から背景２Ｄ絵に対して平行にすべらせるとＦＦ７～９のようにできます。
（道がキャラクターより前面にくる時は当然３Ｄオブジェとして描画します。
というかＦＦ７～９の背景データは３Ｄデータから２Ｄにおとしてる？）

背景データが３Ｄじゃないと表現できないのはカメラ視点が平行移動せず奥へ向かって行く場合っす。
ＦＦ７～９ではそういう時、ムービーを使用しています。
そういえばバイオハザードとかも同じっすね。

**名前は開発中のものです。** · 2006/02/19(日) 15:14:58

FFに視点・注視点が動くような場面あったかな
単純にスクロールしてるだけだと思ったが
http://gamdev.org/up/img/4707.jpg

**８１３** · 2006/02/19(日) 15:41:30

×奥へ　○奥や手前へ

>>814
そう思います。プレステ１だし風景まで３Ｄってわけにはいかなかったのかも。

**名前は開発中のものです。** · 2006/02/20(月) 00:21:23

理解しました。つまりカメラがキャラの移動に対して常に平行移動する限り、カメラアングルに「角度」的変化は無いので背景絵と矛盾しなかったんですね。
しかしその場合でも、ｽｸﾘｰﾝ何個分もスクロールするような長い道などの場合ﾏｯﾌﾟ絵の読み込みだけで相当なメモリを消費するんじゃないかと思うんですが。
それに3D処理とマップ描きは別の工程での作業になると思うんですが、
実際プログラム上で実行した時に3D処理上の当り判定とマップ絵上の壁とが
寸分違わず一致してますよね～。一体どうやってるんでしょう？

**名前は開発中のものです。** · 2006/02/20(月) 00:22:51

寸分違わず一致しない理由がわからん。

**名前は開発中のものです。** · 2006/02/20(月) 01:44:52

だってだって、普通少しくらいズレたって良さそうじゃん？
3D処理用の簡易モデル・シーン情報→マップ描く人のツールに移す→細かいパーツとか付け足し、テクスチャ貼り→プリレンダ絵完成
この工程のどこかでズレそうじゃん、どこかでマウスがブレたりして。またはカメラの設定トチったりして。

**名前は開発中のものです。** · 2006/02/20(月) 01:52:21

製品レベルではズレることは許されない

**名前は開発中のものです。** · 2006/02/20(月) 02:14:38

じゃあ慎重な作業と根性でズレないようにしていると理解してよろしいですか？

ちなみにこういったシステム（FF7･8･9/初期ﾊﾞｲｵﾊｻﾞｰﾄﾞ）のゲームを作るにはどの程度のプログラムの技術が必要になりますか？
自分はプログラムは組めないので、出来る人を探さなければいけないんですが。
例えばこのスレにいる皆さんなら作れます？キャラモデルやマップ等は全部こっちで用意すると仮定して。

**名前は開発中のものです。** · 2006/02/20(月) 02:33:26

>>820
出来る人は結構いるけど、あんたに付き合っている暇がある人はいないと思われ。

**名前は開発中のものです。** · 2006/02/20(月) 04:31:14

割と大変な方。

**名前は開発中のものです。** · NG

>>820
技術もさることながら、単純にマンパワーが必要になるよ
ＦＦ７～クオリティ・量のグラフィックデータを自前で全部作れるのならそんな心配無いのかもしれんけど

**名前は開発中のものです。** · 2006/02/20(月) 12:13:27

上司「高速化がご飯作ってくれるの！？」
オラ「でもスクエ二君の家は・・・」
上司「スクエニ君の家はスクエニ君の家！！うちはうち！！」

**名前は開発中のものです。** · 2006/02/20(月) 13:24:47

プロの作品って技術もさることながらマンパワーが凄まじいよなぁ