契約や能力調整の話をする前に、まず作業のファイルについて話します。
リリースバージョンでは選手が「まとめ」というファイルで同梱されましたが、作業中では１、２、３、JFL、地域と既存に分割された。最大の理由は、一つのファイルではデータがあまり多すぎてエディタが重くてまともに作業できなかったからです。
以前ではいろんな分割方法を考えましたが、整理しやすさと移籍面を考えると地域で分割することが一番という結論にたどり着いた。どの分割案でも、結局選手を別のファイルに移動することが必要であるので、移動を最低限に抑えつつ、選手のファイルをすぐ特定できるという条件で、所属先の地域分割に決めました。
だからとある選手が札幌から福岡に移籍すると、その選手を１から削除し、３に移す作業が必要です。
なぜエディタが重くなるのが嫌か、それはFMエディタの変更では単純に値の変更ではないからです。
以前でも話しましたが、FMエディタのデータ管理は変更数が単位です。例えば、とある選手のCAを65から75に調整し、その後また75から65に戻すと、値としては変わらなかったが、ファイルでは65→75と75→65という変更が保存された。なので、このような変更では数字上では意味がないが、ファイルサイズが増えた。
このような挙動を意識しないと、いつの間にかファイルがとんでもないサイズになってしまい、読み込みも遅くなる。しかも、実はかなりバグりしやすい。
例えば、AクラブはA監督を解雇し、B監督を雇った。もしエディタは単純にA監督の契約を消す、そしてB監督をAクラブの監督に調整すると、なぜかB監督はアシスタントコーチになったのです。
理由としてはA監督がAクラブの監督だったという変更が保存された。そして変更の順番によるが、A監督がAクラブの監督→B監督がAクラブの監督→A監督がフリーという順番で反映されると、FMでは同じクラブに2つ監督が存在できず、B監督は自動的にアシスタントコーチに調整されてしまう、そしてA監督はそのあとフリーで、Aクラブは逆に監督がないという状況です。
だから以上のシナリオで正当なやり方は、「Database Changes」でA監督の契約情報のChanges（変更）を削除する→「Reload Database And Apply Undeleted Changes」を押す（変更を削除すると、データベースをリロードしないとさらなる変更ができません）→B監督の契約ページでAクラブに設定。
そしてこの「Reload Database And Apply Undeleted Changes」の処理は、変更が多いほど処理が重くなるので、分割はどうしても必要であった。
ちなみに本当に選手を別ファイルに移動させる場合、自分のやり方は新選手を作成し、ページごと選手の情報をEdit→Copy、Edit→Pasteで選手を複製し、そしてその新しい作成された選手以前の変更を全部削除して新ファイルにセーブ、移動したいファイルにインポートします。もちろんインポート後では元のファイルからその選手を削除する。
なぜこのようなことか、それは変更項目は時間順で保存される。同じ選手の変更でも時間を立つと変更がバラバラになってしまい、その選手だけのファイルを作るのが大変難しくなる。だからいっそ同じ内容で新しく作成するほうがいいです。
ただし「Duplicate」機能は厳禁。FMエディタのDuplicate機能は複製元のIDを参考するから、Duplicateしてその新選手以前の記録を削除すると、参考先がなくなりバグります。逆にDetails、Contact、Person Dataなどページ一つ一つでEdit→Copy、Edit→Pasteでは変更がちゃんと記録されるから、そっちのほうが望ましいんです。
ちょっと理解しづらい話でもあるが、最初FMのJリーグパックを作成するときではいろいろな壁にぶつかったからの経験談です。もちろん、もっといい方法で選手の変更を管理するであれば、ぜひ教えてください。
