戦闘部分がほぼ出来上がったので、次は条件付きChoice。具体的には選択肢の中にKai Disciplineを持ってるかどうかで選べるものがあるんだけど、そのチェック。
構造はこういう感じになってるので・・
この通常のChoice部分に追加するわけだな。上の場合は技能もアイテムも不要で選択肢を選べる場合。
Else if で技能が必要な場合を追加していけば良いんだけど・・ここでハタと気づいた。条件はTomlからStringで与えられてるとして、それを動的に取り出して
KaiDiscipline構造体の同名フィールドをBoolチェック・・ってどうすりゃイイの？
僕の要求通り、構造体を活かすとなると、Reflectなるライブラリを新たに導入しないといけないらしい。確かにメソッドの.以降に変数を使ってるところなんてみたことないもんな〜。でも、出来ればライブラリじゃなくて標準機能でやりたいところ。
ハッ！？マップ！サンプルで文字列を直接入れてるけど、ここに変数が使えるなら構造改革もやむ無し！
出来るじゃない！
ふんふん、型定義の時点ではこんだけで良いのか
これこれ、この形がやりたかった
実際の技能名とBoolは初期化の時点で作ると。
なるほどな〜。これはRequiredItemも同様の仕組みにするべきだな。コレの素晴らしいところは、プログラム設計時に用意してなくてもTOMLからデータを持ってくる時にDisciplineマップとかItemマップに追加してやれば済むし、ゲーム中でもデータ駆動（使い方合ってるかな？）で追加出来るところだな。というか、この方式しか無いだろｗ。
そう考えると最初に考えてたこの設計が猛烈に愚かに見えるなｗ
初期化時点でマップに追加に変更
VSCODEを使ってると明らかに間違ってないのに波線が出てSyntaxエラーが出たりする。どういうこっちゃと思ってたけど
そこまで強制されんの！？マジか〜・・まあ、統一感があった方が読みやすいとは思いますけど(-_-;)
というわけで、スキルとアイテムが必要な場合を追加してみた。ではテスト！
SixthSenseをFalseでは・・駄目、OK
Trueにしてみたところ・・なんとパニック発生
どういうこっちゃ？と思ったけど、RequiredDisciplineなどから文字列を取得する時にNilだった場合にも行おうとしてるが原因だという。
解決策は変数に束縛する時にNilチェックをして、Nilって無い場合にのみ束縛吸うようにと。これでパニックが起きるからサンプルではいちいちNilチェックしてたのかぁ。とにかくGoはNilチェックにうるさいっすね
修正の結果・・無事にスキルチェックで選択肢が選べるようになったダス！いや〜・・AI無かったら何度詰んでるか分からんでマジで
次回はアイテムチェックを作って、ランダムチェックを実装や！
