ゲームエンジン作成記

smw @Shi_MeiWo

数年前から作っては壊し、作っては壊ししてきた、ゲームエンジンがある。ゲームループを採用してから、ようやく処理が見通せてきた。先は長いが、少しずつ進もう

smw @Shi_MeiWo

ちなみにゲームループとは、１フレーム（垂直同期周期である1/60秒が多い）の間に「情報の更新」と「画面描画」を行い、次のフレームが来るまでは待機する、というもの。各段階でやるべき事をきっちり分けるので、頑張り次第で込み入らないような構造にできる、はず。

smw @Shi_MeiWo

休憩時間中に。先日書いたゲームエンジンで、６角形の座標系を考えている。いわゆる「ヘクス」と呼ばれるアレね。だが、はたと行き詰まる・・・。それは「経路探索」 #AStar #heuristic

smw @Shi_MeiWo

経路探索は #A* ( #AStar ：「エー・スター」と読む) という方法が知られていて、仮の最短距離を得る関数（ヒューリスティック #heuristic 関数）を準備することで、あるマスからあるマスへの最短歩数を得ることができる。行き詰まったのは、このヒューリスティック。

smw @Shi_MeiWo

ヒューリスティック関数は、少なくとも確実に「２マス間の最短距離」を求められることが前提。なおかつなるべく現実に近い歩数を得られれば、精度が上がって、計算量も減らすことができるんだと。ヘクスでなくスクエア（FEやSRWと同じ四角）なら、マンハッタン法やピタゴラスの定理が使えるが・・

smw @Shi_MeiWo

というわけで昨日検索していて、こちらで素晴らしいヒントを得ることができた。 http://goo.gl/JrZyC なるほど、これなら最短距離どころかより確実な「最短歩数」を「確実に」得ることができる。ヒューリスティック関数にうってつけだ。アルゴリズムを考えつく人は尊敬する。

smw @Shi_MeiWo

ちなみにA*については http://goo.gl/h4fqT で紹介されているので、興味のある方はぜひ。

smw @Shi_MeiWo

ヘクスの座標系を悩み中。選択肢は２通り。X軸を水平に取る方式（よく解説されている方）は斜め方向の移動角が大きい（６０度）のでもっと平べったくなってほしいし、Y軸を水平に取る方法は角度は浅い（３０度）けど実装例の資料が少ない。６０度でヘクスを縦に潰す、てのは今回ナシの方向で。

smw @Shi_MeiWo

もうひとつ。座標管理をどうするか。現在は「座標変換クラス」をつくり、ヘクス座標を与えたら内部座標やマップチップの座標をgetterメソッドで取り出せるものを考えているが、それならクラスメソッドにまとめてもいいだろうし、いや、もっと効率のいい方法があるかも、と考えると迷ってしまう。

smw @Shi_MeiWo

座標変換がうまくいっている事を確認する意味も込めて、いよいよグリッドを実装しなくてはならん。過去の試作ではつくっていたのでそんなに難しくはないと思うが・・・今回は絶対座標との変換を常に行なってみたいので（実際には最短歩数を測るときにしか使わないが、まぁテストだしね）。

smw @Shi_MeiWo

グリッドの実装のためには、ダミーのマップデータを作って、カーソルをマップ上のグリッドに沿うように動かして、なおかつマップ座標と絶対座標を表示するようにすればよし、だな。マップデータのシステム反映と、移動コストについてはあとまわし。

smw @Shi_MeiWo

例えば、ジープに歩兵が随伴するとする。歩兵が取り残されないように、ジープは速度を落とす。つまり、移動力は歩兵並になる。さらに、歩兵だけなら森を抜けられるが、ジープに森は抜けられない。かくてこのユニットは、歩兵のノロマさとジープの小回りの悪さを合わせ持つことになる。

smw @Shi_MeiWo

少し話をすすめる。ポケモントレーナーとバスラオがユニットを組むとする。バスラオは魚だから、地上の移動コストが－２だとしよう。ポケトレ君はバスラオに合わせてゆっくり歩くことになる。だが、先のジープと歩兵の場合に比べ、ここには決定的な違いがある。

smw @Shi_MeiWo

その違いは、同地形における「消費コスト」。ポケトレとバスラオの移動力がともに６で、バスラオは地上にいるばかりに１歩あたり３のコストを掛けてしまい、結果２歩しか歩けない。これはそもそもの移動力の異なる歩兵とジープの場合と比べ、かなり複雑な問題をはらんでいる。

smw @Shi_MeiWo

極端な例として、歩兵とイカ娘がユニットを組んだとする。イカ娘は水中では素早く動ける（例：８マス）が、地上でもそこそこ動ける（例：４マス）。これを、「本来の移動力は８で、地上で－２のコスト」と表現したくなる。が、コストペナルティをユニット共用にしたとき、歩兵も同じペナルティを受ける

smw @Shi_MeiWo

つまり、歩兵の移動力を仮に６とすれば、なぜか移動力が３になってしまうわけだ。「イカちゃん地上じゃ遅いし」なんて言い訳が通用するわけがない。歩兵がイカちゃんに合わせるどころか、あべこべに移動力４のイカちゃんが「地上の軍人はのろまでゲソ」と悪態をつくハメになってしまう。っべー超っべー

smw @Shi_MeiWo

とうぜん、これを避けるためには「ユニット構成員ごとに移動範囲を測定し、重なったマスだけをユニットの移動範囲にする」という方法が一般的だろう。だが、それだと構成員が４人や５人になったとき、重たい移動力計算を４回、５回と繰り返すハメになる。やはりユニット移動力を用いて一回で計算したい

smw @Shi_MeiWo

そこで考えた。１）すべてのユニット移動コストは、地上の場合を基準にする。２）地上以外のほうが早く動ける場合は、歩数ごとの消費コストを0.5なりの少数にする。つまり「荒地では-1のペナルティで消費は２」ではなく「荒地のコストは平地×２で消費は２」とするのである。イカ娘なら水＝0.5

smw @Shi_MeiWo

検証。イカ娘移動力４、水のコスト係数0.5。・１歩目：残移動力3.5。・２歩目：残3.0。・３歩目：残2.5。・４歩目：残2.0。・５歩目：残1.5。・６歩目：残1.0。・７歩目：残0.5。・８歩目：残0。途中で地上を挟んだ場合は、0未満になった時点で進入不可とする。

smw @Shi_MeiWo

ここで問題に気づいた。船のように、地上を移動できないものはどうする？地上の移動力0、海では10で動かしたい。水減衰の係数は「10/0」・・・0除算。ナイスアイデアは一瞬でついえたのでありました。クソッ！クソッ！クソッ！

smw @Shi_MeiWo

あ、地上の移動力を１０にして、水の減衰を無くして、別途「地上は進入不可」のフラグをつければいいのか。移動力と地形のコストは別管理だからな。ああ、ほっとした。

smw @Shi_MeiWo

でも、やっぱり不安だな・・・。移動領域というカテゴリを作って、陸の移動力、水の移動力、空中の移動力的なものを作るか？いやーそれもめんどくさいぞ。仕方ない、先にダメだしした「いちいち全員分の移動範囲を計算する」方法にするか。

smw @Shi_MeiWo

@Shi_MeiWo コスト実装以外は、土日のタスクはフルフィル。なんとヒューリスティックは「対角線法」を実装したぜヘイヘイ。今後はいったんA*から離れて、「移動範囲表示」を行いたい。その過程で、コスト管理も入ってくるだろう。

smw @Shi_MeiWo

あ、考えてみたら内部でいくらスクエアにしたとしても、移動コストの掛かり方が縦と横でてんでバラバラなら意味ないか・・・しかたない、実歩数計測のメソッドもあるから、あとで比較してみよっと。

smw @Shi_MeiWo

ネクタリスのサイトを見て、やる気を復活させる。もともとはASでネクタリスをやりたい！というところから始まったんだよね。あれはシンプルでいいゲームだった。