シミュレーションのマップについて考える
ヽ(´ー`)ノ 久々の更新ー！！！
(￣∀￣) やっと就職もきまったしぃー
少しは暇になるかと思っていたが，学会の準備だの中間発表だのゼミの準備だの，
集中してプログラミングをする暇ねぇー！！！！
(;´Д｀) ソフトウェアの研究がしたかったなぁ…入る研究室間違えた，アイタタタ…
さて，今回は，シミュレーションゲームのマップについて考えてきました．(鉄拳風に)
で，やりたいのは「クォータービュー」とか「Isometric View」とかいうタイプのヤツです．
３Ｄでやれば簡単なんだろうど，２Ｄでやってみよーっと．
(TдT) だって，ワシには３Ｄはまだ敷居が高いんじゃよぉぉぉ・・・
とりあえず，マップの仕様はこんな感じで…
・クォータービューである．
・地形に高度がある．
・高度があるが立体交差は無い．
立体交差があると，マップを作ることができてもゲーム中の戦闘のときのルーチンが複雑そうになるので，今回はパスします．(-_-;)
ただ，立体交差は無いですが，奥行きを表現するためにグラフィックが重なったりするので，レイヤー自体は２層構造にします．
イメージ的にはこんな感じのチップを並べてマップを作ります．
■レイヤについて■
レイヤは２層構造で作ります．各レイヤは性質の違いで分けられてみました．
●レイヤ１
・必ずキャラクタの下にくるようなチップで構成される．
いいかえると，レイヤ１がキャラクタを上書することは無い．
●レイヤ２
・キャラクタより手前にくる場合があるチップで構成される．
(レイヤ２のブロックは，キャラの下に来る場合もあるし，キャラを上書する場合もある)
次のイメージで，上のイメージがレイヤ１だけを表示した場合．下のイメージがレイヤ２も表示した場合です．
一番手前のブロックがキャラの一部を上書しています
■表示アルゴリズムについて■
さーてと，どうやって表示するかなー．
とりあえず，奥から表示しないといけないっすね．
キャラクタのいる位置を（X,Y）と高さ（H）で管理することにします．
このとき，奥にある座標は（X+Y）の値が小さく，手前にある座標は（X+Y）の値が大きくなります．
だから，基本的には（X+Y）の値が小さい順に描いていけばOKっす．
あと，（X+Y）の値が同じ場合は（H）の小さい順に描かないといけません．
━ 表示のアルゴリズム ━
１．レイヤ１のチップを全て表示する．
２．レイヤ２を（X+Y）値でソーティングする．（実際にはマップ作成時の１回だけでOK）
キャラクタも（X+Y）値でソーティングしておく．
３．レイヤ２に関して，最も奥（X+Y値が最小）のチップを全て表示する．
４．最も奥のキャラクタを全て表示する．
５．レイヤ２に関して，１つ手前のチップを全て表示する．
６．１つ手前のキャラクタを全て表示する．
７．最も手前のキャラを描き終わるまで５．６．を繰り返す．
とりあえず，このアルゴリズムで「立体交差無し」という条件なら表示されるハズです．
(まだ実装はしてないからホントになるのかは謎)
■データ構造について■
ふーむ，しかし，チップの管理単位はコレでいいのだろうか？
なにしろ管理しづらい…(;´Д｀) マップエディタも作りにくそうだ…
そのうえ，表示時に，結局重なってしまうので，塗りなおされる部分が多すぎる…
例えば，２個のブロックが横に隣接する場合でも，
赤い部分が塗りなおされるし，縦に重なる場合だって，
こんなに重なりがある！！
(-＿-;) うーん，実はチップをブロック単位で管理しようとしていたのがそもそもの間違いかも．
いっそのこと，こんな風にブロックを分割して管理する方法について考えてみよう．
●メリット
・表示時に塗りなおしが無くなるので無駄が無い気がする．
・レイヤ１に関しては完全に(画面の)縦方向と横方向の２次元で管理できるので，マップエディタが作りやすい．
●デメリット
・パーツ数が多くなる．（組み合わせパターンが増えるので）
・チップが多いので表示の時にループがでかくなる→速度低下につながる．
デメリットの「パーツ数が多くなる」については，ブロック単位で管理しても多くなるときは多くなりそうだし，
逆に細かくわけてるほうがパーツ数が少なくなるかも知れないなー．
「ループがでかくなる」も，もしかするとブロック単位での「塗りなおし」にかかる時間のほうが大きいかもしれないし．
ふーむぅ，どうもメリットの方が大きいかも知れませんねぇ．
(-＿-;) あとは，マップを作るのが面倒になるだけか・・・
さっさとマップエディタを作ってしまって検証せなあかんな・・・
うーん，タブレットのプログラムも途中やった…，さっさと完成させねば…
<< Back to Diary...