シミュレーションゲーム作成工房　戦術画面を作るにあたって

戦術画面を作るにあたって　戦略（ストラテジー）より戦術（タクティクス）のほうが作りやすい

作っていて（何度も言いますが、手探りです）感じたことだが、戦略画面より戦術画面のほうが作りやすい
気がする。やることが決まっているからではないだろうか？
もちろん、複雑にしようと思えば、いくらでも複雑にできる。
が、とりあえず動くものを作ろうとしても、戦略（ストラテジー）系シミュレーションは、何をいつ、どの程度やるか
といった問題に直面してしまうのに対して、戦術（タクティクス）系シミュレーションは、敵を追い詰め、殲滅せよ
の一言に尽きる。

何をやればよいか、はっきりしているわけだ。
相手に近づくための最短ルートを探し出し、移動し、打撃を与える。
基本的には上記の処理をプログラムしてしまえばよい。ここには思考ルーチンのかけらもない。
（逆に言えば、だからこそ作りやすいわけです。考えなくていいから。ひとまず、動けばよいことを目指します）
通行不可能な地域があるとか、相手に隣接しないでも攻撃できるとか（飛び道具・魔法などの使用）、土地の
高低差があるとかいったことは、後で実装できる。

道は平坦でどこにでも移動でき、一度に移動できる距離はどのユニット（部隊・キャラクター）も共通で、隣接
しないと攻撃できない。そんな簡単なルールから作っていこうと思う。
戦略シミュレーションだと、最初から判断を求められるので、のっけからしてつまづいてしまう。

ＶＢプログラムの構造


frmMap……フォーム上のオブジェクト・イベントに関するプログラムはここ
bas_API……API関数を記述
Bas_Base_File……ファイル入出力処理を記述
bas_Const……定数・変数宣言
basMain……メイン処理
basThink……思考ルーチン

となっているが、標準モジュールについては、プログラムを同一モジュール内に書いても動くだろう。
組みやすいように用途に応じて、モジュールを使い分けてもらえればよい。

さて、戦術画面を作るにあたって、頭の片隅に入れて欲しいことは、２画面間のデータ移動についである。
最終的には戦略画面と連結して、２画面間でデータのやり取りができるようにしたいものだ。

戦術画面を作るにあたって 戦略（ストラテジー）より戦術（タクティクス）のほうが作りやすい

戦術画面を作るにあたって　戦略（ストラテジー）より戦術（タクティクス）のほうが作りやすい