05/08/05 02:34:08 dkIepTJP.net
続き。
移動先定義は
1文字目＝右上から来た時に次に進める方角を数字で書く
2文字目＝上から来た時に・・・
...
5文字目＝転換状態の時に次に進める方角・・・
...
9文字目＝左下から来た時に・・・
で構成。「5」だった場合、次は来た方向以外の好きな方向に移動できると扱います。
（例：アメリカ大陸の本州・カジノの上の左空港マスなら「000455040」となります）
離れ小島のように方向転換が無効になるマスの場合、９文字全てを同じ移動方向に定義すればOK。ハワイのチャンスマスは左しか進めないので「444444444」です。
移動処理法は順にこんな風。１歩目は前ターン最後に変数更新ができている為、ＡＢを省略。サラリーなどの処理はＢの直後に。
Ａ方向Pボタンを押して移動しマスに到達。到達したマスの移動先定義を読み込む。
Ｂ読んだ定義のP文字目の文字を読み、新たな「次の移動方向」とする。「直前にいたマス」を更新。
Ｃ次の１歩は、次の移動方向が5以外（1～9）ならばその方向だけ。
5ならば分岐点なので、８方向のうちマスが存在する方向に移動できる。
ただし、「アメリカ大陸のラッキーなど、物理的に移動できない斜め方向にもマスがあるマス」に対応する為、チェック法は以下の通り。このチェックの中で「直前にいたマス」に進む方向を弾く。
１ まず上下左右４方向に隣り合うマスを調べる。あれば移動可。
２ 続けて斜めの方向をチェック。マスAが存在しても、Aに隣り合い、かつ現在いるマスにも隣り合うマスがある場合は移動不可とする。条件外なら移動可。
（方向1にあるマスは、方向4と方向2にマスがない場合のみ移動可）
こんな風に処理すれば、移動関連を全て数字で管理できるので、楽になるのでは（数値←→文字列の型変換が必要かも？）？
・・・役立たないかもしれない参考資料、いります？