アルゴリズム

[アルゴリズム]移動の探索

出水洸太郎 — Tue, 25 Jan 2011 09:36:00 GMT

移動力にしたがってマップを移動していくタイプの
戦略シミュレーションゲームがあります。

昔だと大戦略といえば通用したのでしょうが、
最近だとスーパーロボット大戦とかファイアーエムブレムとか言えばいいんでしょうかね？

その移動アルゴリズムについて作成してみました。
普通に書くとこんな感じですかね？

class Board{
public:
  int mx, my;
  int *bd;

  Board(int mx, int my):mx(mx), my(my){
    bd = new int [mx * my];
  }
  ~Board(){
    delete [] bd;
  }

  int & operator()(int x, int y){return bd[mx * y + x];}
  int size()const{return mx * my;}

  void fill(int a){
    for(int i = 0; i < size(); i++){bd[i] = a;}
  }
};

bool range(int x, int y, Board &board){
  if (x < 0 || y < 0) return false;
  if (board.mx <= x || board.my <= y) return false;
  return true;
}
void check(Board &map, Board &out, int x, int y, int now = 0){
  // ボード範囲内かのチェック
  if (range(x, y, map) == false) return;

  int move = map(x, y);
  // 空白か移動力が大きい(遠回りしている)なら探索する
  if (out(x, y) == 0 || move + now < out(x, y)){
    out(x, y) = move + now;
    count++;
    check(map, out, x + 1, y, now + move);
    check(map, out, x - 1, y, now + move);
    check(map, out, x, y + 1, now + move);
    check(map, out, x, y - 1, now + move);
  }
}

int main(void){
  Board board(10, 10);
  Board idou(10, 10);

  board.fill(1);
  idou.fill(0);

  check(map, out, 7, 5);
}

Boardクラスは単なる二次元配列を作るためのクラスです。
boardがそのマスの地形(必要移動力)が入った変数、
idouがそのマスに移動するために必要な移動力を計算する変数となっています。
check関数を実行すると、idouに計算結果が帰ってきます。

さて、これは余り効率が良い方法とは言えません。

再帰を使っていますので、まず今回の場合は右、左、下、上の順で探索しています。
最初に右に移動した場合を全て探索した後、次は左、下、上、というふうに探索するわけです。
すると、以下のような状態が起こります。

A地点からB地点に行く場合、明らかに遠回りしています。
しかし、再帰を使った場合は、下→左というルートを探索する前に
右→下→左→左というルートを確認します。
実際は、これ以上の更なる無駄なルートを探索しています。

そこで、まずは１歩で移動できるマスすべてを探索した後、
２歩で移動できるマス、３歩で移動できるマス、という風に探索するとよいでしょう。

この方法を使うためにキューを使います。
check関数は以下のように変更します。

struct Data{
  int x, y, move;
  Data(int x, int y, int move):x(x), y(y), move(move){}
};

void check(Board &map, Board &out, int x, int y){
  std::deque<Data> queue;
  queue.push_back(Data(x, y, 0));

  while(!queue.empty()){
    Data &dat = queue.front();

    if (range(dat.x, dat.y, map)){
      int move = map(dat.x, dat.y);
      if (out(dat.x, dat.y) == 0 || move + dat.move < out(dat.x, dat.y)){
        out(dat.x, dat.y) = move + dat.move;
        count++;
        queue.push_back(Data(dat.x + 1, dat.y, dat.move + move));
        queue.push_back(Data(dat.x - 1, dat.y, dat.move + move));
        queue.push_back(Data(dat.x, dat.y + 1, dat.move + move));
        queue.push_back(Data(dat.x, dat.y - 1, dat.move + move));
      }
    }
    queue.pop_front();
  }
}

計算したい物をキューの後ろに入れ、先頭から計算していきます。
まず、スタート地点を登録して、その後１歩で移動できる４箇所がキューに入ります。
それらを順に計算し、２歩で移動できる場所が後ろに追加されます。
キューなので、１歩で移動できる場所がすべて探索された後、２歩目の探索が始まります。

最初の再帰を使う方法を「深さ優先探索」、次のキューを使う方法を「幅優先探索」と言います。
どちらを使うか、というのは問題によって様々なのですが、
今回の場合は一歩目、二歩目という感じで順番に探索するほうが向いています。

次回はキューの大きさについて考えてみます。

[C++]ランダム大地に立つ

出水洸太郎 — Tue, 19 Jan 2010 22:35:00 GMT

標準のrand関数は余り使わない方がいい、というのは知っているでしょうか。
これは線形合同法に起因する問題で、乱数といいつつも、結構規則正しいという特徴があります。

それを改良した乱数と言うとメルセンヌ・ツイスタが有名ですが、これもちょっとした問題があります。
それは、メモリの消費がかなり多い！

周期が2^19937 - 1 ということは、19937ビットのデータが必要なのです。
その大きさは約2.5KBですが、いくら高品質とはいえ、ちょっと量が多いですね。

それに、2^19937 - 1って数は6000桁以上！
宇宙の果てまで数えられる数の周期が必要な場面はそんなにないでしょう。

そこで、今回紹介するお手頃な乱数が、xorshift。
ソースは以下の通り。

unsigned long xor128(){ 
  static unsigned long x=123456789,y=362436069,z=521288629,w=88675123; 
  unsigned long t; 
  t=(x^(x<<11));x=y;y=z;z=w; return( w=(w^(w>>19))^(t^(t>>8)) ); 
}

これだけのソースですが、2^128 - 1という周期をもつ乱数で、たった16バイトしか消費しません。
staticで確保しているx, y, z, wの4つの値を保存しておくだけで、前回の乱数の続きから生成できるため、
シリアライズ化するのも簡単というとてもお手軽かつ便利な乱数です。

なお、乱数の種(seed)ですが、x, y, z, wのすべてが0でなければどんな数でもいいです。
これは、128ビットの数値と見なすと、周期が2^128 - 1ということで、0以外の数値であれば、
循環する数列のどれかの要素になる、というわけです。

そういえば、メルセンヌ・ツイスタを改良したSFMTというものもあるみたいですね。
乱数は奥が深いです。

[アルゴリズム]とらいあんぐるはーど

出水洸太郎 — Sun, 28 Jun 2009 02:15:00 GMT

[アルゴリズム]六角対応の続きです。

前回ヘックスマップにおけるデータ表現を書きました。
ならば次はこれだ！！

正三角形を敷き詰めた形ですね。
やっぱりこの形をそのまま使うのは難しいので、これを正方形の形に変換します。

上の形を変換したのが下の形です。
見やすさのために四隅を切り落としています。

赤い線が目立ちますが、これは壁です。
黄色なら下、水色なら上側が壁になり、ここは通行できません。

三角形と見比べてみると、この赤い線は頂点になります。

1マスで移動できる領域です。
上三角と下三角の形の二種類があるので、移動できる場所が異なります。

前回同様、距離の図です。

これも、ややこしいですが、前回同様Xの移動量とYの移動量で分けてみます。

紫の領域は非常に素直で、X+Yがそのまま距離となります。
しかし、橙の領域はなんだか変なことになっています。
一番下の行を見ると、76767と交互に数字が並んでいる、ってのはわかるわけですが…。

まず、橙のマスの中で、偶数になっているものを見ましょう。
すると、必ず市松模様上に配置され、しかもその値はYの移動量の2倍です。

あとは、奇数のマスは偶数マスの+1か-1で、その法則も簡単に割り出せます。
それを踏まえて作ったソースがこちら。

/* 上方向に移動する場合、Yはマイナスになる */
/* IsUpperは、そのマスが上三角(△) ならばtrue */
int distanct(int x, int y, int dx, int dy){
  int ax = abs(dx);
  int ay = abs(dy);
  if (ax < ay){
    /* Yの移動量が多い場合 */
    if (IsUpper(x, y) == (0 < dy))
      /* 最初の移動方向に壁なし */
      return ay * 2 - (ax + ay) % 2;
    }else{
      /* 最初の移動方向に壁あり */
      return ay * 2 + (ax + ay) % 2;
    }
  }else{
    /* Xの移動量が多い場合 */
    return ax + ay;
  }
}

要は、最初の移動方向に壁があるかどうかでチェックすればいいわけです。
これで、三角形を敷き詰めるようなパターンを作りたい場合もある程度すっきりかけることになります。

[アルゴリズム]六角対応

出水洸太郎 — Fri, 26 Jun 2009 20:48:00 GMT

ウォーシミュレーションと呼ばれるジャンルで採用されるゲームでは六角形のマップを使うことが多いです。
こんなマップですね。

これをプログラムで実装するとして、どういう風にデータを持つかという問題があります。
ずれているのが厄介で、うまく表現することができません。

結局、この形が一番やりやすいだろうという結論に落ち着きました。

チェスのようなマップです。
白い部分だけを使って灰色の部分は使いません。

無駄なメモリが増えるように見えますが、座標の管理だけは上の図で行い、
実際にチップにデータはxの値を半分にして取得すれば問題ありません。
こんな感じですね。

int getData(int x, int y){
  return data[x / 2][y];
}

黒い部分か白い部分かの判定は、xとｙの座標を足し、奇数か偶数かでみればよいでしょう。
上の図の場合、偶数ならおける場所、奇数ならおけない場所です。

また、移動する場合もxとyの移動量を足して偶数になっていることをチェックすればいいでしょう。
奇数になっている場合は、上の図の黒い部分に入ってしまうため、移動できません。

さて、移動です。

このように6方向に進むことができます。
実際のヘックスも6方向に動けるので一致します。

そして、距離の求め方です。

距離はこのような図になります。
この図では結構複雑な式になりそうですが、実はそれほど難しくありません。

紫と橙の部分に分けています。
このとき、紫の領域はxとyの絶対値を足して2で割った値、
橙の部分は、単純にyの絶対値です。
ソースで書くとこうなります。

int distance(int dx, int dy){
  int ax = abs(dx);
  int ay = abs(dy);
  if (ax < ay){
    /* Yの移動量が多い場合 */
    return ay;
  }else{
    /* Xの移動量が多い場合 */
    return (ax + ay) / 2;
  }
}

こんな感じで、さっくり計算できます。

[アルゴリズム]突っ込みにも負けるな

出水洸太郎 — Wed, 17 Dec 2008 22:12:00 GMT

ここまで突っ込まれるとは…ということで、前回の「処理落ちに負けるな」の補足です。

前回のループでは17msと決め打ちで回していますが、
vsyncに合わす、という意味ではあまり良いとは言えません。
vsync割り込みを利用するとして書き直すと前回のソースはこうなります。

unsigned int vsynccount = 0;

// vsyncが発生するたびに呼ばれる関数
void callback(){ vsynccount++; }

while(1){
  while(0 < vsynccount){
    control();
    vsync--;
  }
  draw();
  waitvsync();
}

draw()の処理途中にcontrol()が呼ばれるのは良くありませんので、
vsync割り込みの中ではカウンタだけインクリメントしてその回数だけループを回します。

しかし、理想形まで行けばこんな感じでしょうか。

deque<Pad> queue;

// vsyncが発生するたびに呼ばれる関数
void callback(){ 
  queue.push_back(getPad());
}

while(1){
  while( !queue.empty() ){
    control( *queue.begin() );
    queue.pop_front();
  }
  draw();
  waitvsync();
}

vsyncの度にコントローラの状態をキューに貯めておき
その値を使いながらcontrol()を回す方法です。
これであれば、相手がシンクロ連射でも確実に連射状態になります。

ただ、前回に17msと決め打ったのは、vsyncが1/60秒でないことを考慮したためです。
PCならvsyncが1/60とは限りませんし、vsyncはブラウン管の名残です。
液晶が全盛となった今にvsyncに頼るのは果たしていいのか疑問が残ります。

凪瀬さんのコメントのように処理のみ120fpsで行うってのもありでしょう。
レースゲームでは大抵0.01秒まで出ますから、10ms以下の単位で処理をしたいところです。

ということで、描画と処理は必ずしも同期する必要はない、と考えた方が幅が広がるかと思います。

[アルゴリズム]処理落ちに負けるな

出水洸太郎 — Wed, 17 Dec 2008 06:17:00 GMT

ゲームには垂直同期信号というのにしばしば悩まされます。

1フレームという単位があって、約1/60秒を差します。
大体のゲームは1秒に60回画面を書き換える事が出来ることができます。
それ以上の速度で処理をしても基本的に無意味ですから
これを一単位として使う事がおおいわけです。

1/60秒は約17ミリ秒です。
1回の処理に20ミリ秒かかると、次の垂直同期信号を待たないといけません。
ちょうど電車が出た途端に駅に着く、って感じですね。

つまり、17ミリ秒を超えた瞬間、いきなり速度が半分になります。
いわゆる処理落ちです。
一部のゲームではこの処理落ちをゲーム性に組み込んでいるものもありますが、
望ましい結果とは言えません。

そこで、処理落ちが発生した場合は描画処理を飛ばして
なるべくゲーム速度を保つ方法を考えてみます。
で、いろいろ考えた結果が以下のソースになります。

timeGetTime()は1ミリ秒単位で現在時間を取得する関数で、
waitvsync()が垂直同期信号を待つ関数です。

unsigned int befour t = timeGetTime();
unsigned int ctrltime = 0;
while(1){
  unsigned int now = timeGetTime();
  unsigned int dttime = befour - now;
  befour = now;

  for (ctrltime += dttime; 0 < ctrltime; ctrltime -= 17){
    control();
  }
  draw();
  waitvsync();
}

処理と描画の完全分離です。
control()を一度呼び出すたびに1フレームの動作をします。
draw()は描画処理に特化し、control()を呼び出さなければ
全く同じ画面が描画されます。

XNAなんかはこの考えが浸透している感じですね。

なお、draw()はボトルネックになっていても、
control()は無視できる速度で処理が終わることを前提としています。
どちらが足を引っ張っているのかは確認してください。

あと問題は、コントローラの入力を不定期に取ってしまう事です。
独歩頂膝がでねーぞ！！って事になりかねません。
そんな人にはPC買い換えろとやさしい言葉をかけて解決としましょう。

[アルゴリズム]クイックソートの広さ

出水洸太郎 — Thu, 13 Nov 2008 23:04:00 GMT

ネタ元>再帰をループに変換

クイックソートとは以下の順序でソートを行うものです。
(1)ある要素を取り出し、その要素より小さいグループと大きいグループで分類する
(2)それぞれのグループに対し、要素の数が1個になるまで(1)を繰り返す
このクイックソートが必要とするメモリ量、すなわち空間計算量を考えてみましょう。

要素を2つに分割した後、両方を同時に処理することはできません。
ですから、一方はいったん置いて他方を処理します。
その処理中にまた2つに分割されるため、いったん置いたうえにさらに置くことになります。
図で表現するとこんな感じですね。

このようにうまく二等分できれば一時領域は10段もあれば十分です。
この一時領域をスタックサイズと呼びます。

別の場合のスタックサイズを考えてみます。
こんな場合はどうでしょうか。

先ほどと違い、うまく分割することが出ていません。
そして、このペースだとスタックサイズは500段必要です。

一体スタックサイズは何段用意しておけばいいのでしょうか。
出来るだけスタックサイズを小さくする方法を考えてみます。

このスタックは処理中のものが終了するまで積まれ続けるわけです。
いつ終了するんでしょうか。
それは、処理中の要素数が2個以下になるまでです。

それならば、早く処理中の要素数を減らせばよいわけです。
2つに分割したとき、どちらをスタックに積み、どちらを処理中にするかは
自由に決められるため、要素が多い方をスタックに積んでしまえばいいのです。

それを図示しました。

いずれも4:1のグループに分かれていますが、左の方はもうすぐ処理が終わりそうです。
このように、アンバランスに別れた方がスタックに積む量が減るため、
最もスタックが必要なパターンは二等分されるパターンです。
そして、二等分された場合、スタックサイズはlog2(N)必要です。

よって、クイックソートの空間計算量は最悪の場合でもO(logN)です。

なお、ピボットに使われた要素は処理済みにするのが好ましいため、
1000個は499個＋1個＋500個のように3つに分けられますが
今回は分かりやすくするため、それを無視しています。

[アルゴリズム]マルチコア

出水洸太郎 — Thu, 30 Oct 2008 06:33:00 GMT

ネタ元＞WindowsとC++：高性能アルゴリズムについて調べる

上記の記事を読むと、マルチコアで動作する時、
同じコアで実行するメモリは近くに配置し、
違うコアで実行するメモリは遠くに配置するべき、と書いています。

さて、以前書いたシェアソートの並列動作なのですが、
横ソートにおいては上記のマルチコア動作に向くメモリ配置になっています。

しかし、縦ソートに至っては並列動作に向かないパターンです。
良くないパターンとして紹介されている物と全く同じです。

今回の場合は”#pragma omp parallel for”を使ったものなので
自分でカリカリ内部動作を書いた場合とは違うのかもしれません。
ただ、キャッシュの読み直しという単語がちらほら見えるので、
ハードウェアの仕様のような感じで、ソフトウェア側でどうにかならない気がします。

シェアソートの縦ソートが遅いとなるといよいよ出番もないですね…。

#ということで、教えて詳しい人！

[アルゴリズム]等号は続くよどこまでも

出水洸太郎 — Thu, 23 Oct 2008 01:02:00 GMT

ネタ元：同じ値であること（その２）

aとbとcがすべて等しいという条件式を作ろうとして
数学のようにa=b=cと書いてしまう人はよくいます。

昔のBASICだと、if文の外でこのように書くとaに-1が代入されたりします。
a=(b=c)と解釈され、(b=c)がtrueを意味する-1になるからです。

そして、こんな書式も生まれました。

I$=INKEY$
x=x+(I$="4")-(I$="6")
y=y+(I$="8")-(I$="2")

I$は変数名で、INKEY$とは入力された文字を取得する関数です。
つまり、4が入力されればxは-1され、6が入っていればxは+1されます。
要はキャラクターやカーソルを動かす部分です。

さらに、a=b=c=dはどうなるでしょうか。
普通に解釈されるならa=(b=(c=d))ですね。

しかし、(a=b)=(c=d)と捕えてみましょう。

a=bがtrue 、c=dがtrue で全体がtrue
a=bがtrue 、c=dがfalseで全体がfalse
a=bがfalse、c=dがtrue で全体がfalse
a=bがfalse、c=dがfalseで全体がtrue

これは、排他的論理和(XOR)の否定を意味します。

排他的論理和の演算子を用意していない言語でも、
中央の等号をnot equalの記号にすれば排他的論理和を使うことができます。

[アルゴリズム]はみだしシェアソート6

出水洸太郎 — Sun, 28 Sep 2008 20:03:00 GMT

前回で終わりのような気がしていたが別にそんなことはなかったぜ！

今まで紹介したシェアソートは要素の数が平方数でした。
サンプルなので奇麗に正方形に並べられる個数ばかり選んでたわけです。

シェアソートは矩形(長方形)に並べられれば良いのですが、
要素の数が素数だった場合はそれすら適いません。

ということでそんな半端の状態のシェアソートです。

39個の要素でシェアソートを行おうとすると、以下のようになります。

実は、この形でも以下のように分割してシェアソートを行えば問題がありません。

豆知識として、縦ソートをするときに40以上の位置を差したら終端としておくと、
どこで数が変わったかというのを意識しないで済みます。

ですが、折り返しで終わった場合はちょっと工夫が必要です。
以下のような場合ですね。

空白に最大値を入れてソートでも良いのですが、スマートではないです。
そこで、1行6個ではなく7個で作りなおしてみます。

うまく行きました。

ちょうどいい一行の数の求め方ですが、今回はこうやっています。

　44 ÷ 6 = 7 余り 2

1行6個で並べれば7行と2個と読めますが、
逆に1行7個で並べれば6行と2個という読み方をします。
適当な偶数で割ってやってその商を1行の個数とすれば
必ず都合のいい配置になってくれるわけです。