迷走中。

　未だにプロットの書き方に悩んでいまして、
その最大の問題が「データを一括して扱いたい」という願いがあります。

　データを一つにすれば容量は減りますし、
管理も改良も楽にできますし。

　今はtxt、pdf,draw.io,パワポと様々なアプリを使っている関係で、
かなり面倒くさい事になっています。

　ある意味一括できるのはdraw.ioですけど。

　なんとかならんかと考えている中、
ちょっと検討しているのがqosoです。

　一括化できそうな気がしないでもないですが、
今はプロットを１から練る状況ではない（多忙ではなく既に内容が確定しているという意味で）ので、
使用するのは当面後かもです。

　後は何気にpro版が月額５５０円はちと高いです。
　３００円くらいなら使えそうですが、
企業が破綻しますよね？

　貧乏だからうかつに手が出せないのは仕方ないです。
　でも検討はしておきます。

　さて、
gladiabotsですが、
最大の壁に来ています。

　これ以上レートが上がらない位置＝自身の限界点に来ています。
　限界点に来ると、
他人と対戦するより己自身との戦いになっていくのですが、
ここで課題がいくつか見えてきました。



　コレクション。



　ドミネーション。

　上はリソースと呼ばれる玉を指定したエリアに運ぶ競技、
下は陣地を確保してポイントを得る競技です。

　どちらも共通している問題として、
「どこを先に取るか」という処理が曖昧になっています。

　今は単純に、
「近い場所」「敵がいない場所」を取るようにしていますが、
上ですと敵がいない場所＝遠い場所なので時間を食いやすく、
後者だと相手が分散している＝すべての陣地に向かっているとなれば、
敵が全ている陣地＝移動できないとなり、
動きにむらが出てきます。
（但し動けないのではなく、
優先処理しているだけなので最優先処理である「近い陣地に向かう」のプログラムが実行されます）

　この辺の処理をどうするか、
今でも模索しているのですが答えが出ません。

　かつては「中央に近い場所」としていまして、
ついで「自身の領地に近い場所」としていましたが、
これも一長一短でした。

　結局は状況判断で決めざるを得ないのかなと思いまして、
複雑なプログラムを組む以外にないのか？と考えています。

　今は試行錯誤中ですが、
５日答えは出したいですね。