前回、ゲームブックのシステムをモジュール化する方法について質問したところ、意外にも？Grok3が一番ソリが合うって感じだったので、本日はGrok3で色々と聞いてみようと。
まず、Interfaceってのが分かってないんですよね。ザックリ操作性を統一させる入力系の定義みたいなものか？
ほほう・・動的型付けを実現する。これは全く考えてなかったな。でも、言ってみればデータに対して同じ操作で勝手に型を考えて処理してくれるってそういうことだな。
それと、Interfaceに定義されたメソッドを全部実装してたらOKって話か、なるほどね。
ふんふん、定義はメソッド名と引数、返り値の型のみで良いと
どんな型でも？うーん？
Speakerインターフェイスの要件は引数無しで返り値String型のSpeakメソッドだと
出たよType cat struct{}って奴。このコードを見てみると・・
・Dogは構造体（空でも良い）の宣言みたいなもの？
・Func (c Cat) Speak() string { ...は構造体Catをcとして.表記するための引数無しのSpeakメソッド定義である？
・実際の使い方はSpeakerインターフェイス型であるspeaker変数を定義、そこにCat構造体を代入。この状態で変数speakerでSpeakメソッドを呼び出すとCat構造体が入ってるのでCatの場合のメソッドとなると。
便利そう？だけど、上の例ではInterfaceの実装方法が書かれてないし今は無視で
じゃあ早速書いていく？と思って先日書いてもらったコードを見たら、いきなりType LoneWolfSystem struct { //必要なフィールド
となってて、途方に暮れたので具体的には？と聞いてみる。上のCat{}はフィールドがない場合ってだけで普通はあるってことか
なるほど？
これはCRTフィールドの前提条件になってるから定義されてるんだな
Grokの判断ではCRTとRandだけで良いと（他の2つは外部からTOMLデータにアクセスするためのパスを文字列で保持してるっぽい）。正直、たったこんだけで良いの？って感じがするのだが
なるほど・・つまり、LoneWolfに特有の・・うーん、なんて表現したら良いんだ？外部に依存してるシステムって感じ？ちょっと違うか？
そしてこちらは取り込み用のデータの置き場所を渡すためのパスを文字列にしてるわけだから、やっぱり外部データ（システム）って事かなぁ。ややこしいことにLoneWolfSystemに必要なシステムってことらしいな？
うーんまあ、なんとなく納得
うーん、スキルなんかはTOMLにするには向いてないと思うんだけどなぁ。
前にも出してくれたけど、とりあえず右も左も分からないしコレの通りに整理してみるか・・
これは分かる
ところで全く別のシステムを導入するのに提示されてる方法で大丈夫なんだろうか？例えばLWでは出来ない「いつでも回復」とか「任意でアイテムの使用」とか。というわけで書き始める前に質問しておこう
あ、なるほど。Playerの状態を変化させるメソッドを書けばアイテム取得とかトラップとかも解決するか・・
PlayerはGameStateで管理するってなってたけど、あらかじめ考えられるあらゆるステータスを定義しておいて、不要なのはNilなりしておけばいいって事だものな。
なるほどね！これは知りたかった事。ところでメソッドの正常な返り値にNilを返してるのはどういうことなんだろうか・・
あ、なるほど・・初期値や能力値スロットはハードコーディングするしか思いつかなかったけど、TOMLで書いておいてPlayerの能力値や状態をマップで定義、そこに足していくってことか・・確かにこれは、よりデータとシステムが分離されててイイね！
なるほど・・マップ大活躍だな。
うーん、最後のExtra map[string]interface{}がよく分からんが・・文字列をキーにしてInterfaceを呼び出してどうしよってんだ？次回聞くか、忘れてなければ
というわけでアップデートされた構造。これを参考に次回から書いていくか！
最後にFF用に書いてくれたTOML（Grokはかなりしつこい・・ありがたいが）。なるほど、シナリオファイルの先頭にPlayerの初期装備とかを記述しておくってことか。OK、なんか疲れたんでまた今度(-_-;)
