dunazavrTD

Проблема: в игре есть сотни параметров, которые возможно нужно будет подкручивать. Искать их по всем файлам неудобно.
Усложняется всё тем, что одновременно нужны несколько наборов таких параметров. В моём случае три: один будет актуален на случай новой игры, второй будет актуален для данного игрового сохранения и третий будет актуален для данной битвы, т.е. для текущего момента времени.
Например есть базовый урон башни, есть урон этой башни с учётом купленных навыков данного игрока, есть он ещё и с учётом построенных в данной битве зданий и вообще говоря он ещё есть для каждой конкретной построенной башни с учётом её апгрейдов, но эту уже информация надо хранить в конкретном экземпляре башни.
Ещё более всё усложняется тем, что некоторые параметры никак не изменяются с течением игры, а некоторые наоборот просто не существуют на момент начала новой игры и высчитываются из остальных на момент начала битвы к примеру. А потом изменяются.

Сейчас я решаю это так:
все параметры выведены в XML, читаются оттуда классом GameStats. Те параметры, которые могут в теории подлежать изменению в процессе игры, записываются в класс State, который ещё хранит производные параметры, появляющиеся только в момент начала битвы.
State и GameStats полностью статические.

Недостатки этого метода:
один уровень параметров попросту отсутствует
Не сразу понятно где искать нужный параметр, нужно оценить мог ли я расчитывать, что этот параметр будет меняться.
Добавление нового параметра требует много усилий: добавить в xml, добавить переменную GameStats, добавить для неё геттер, написать строчку считывания в GameStats из xml, потом ещё возможно добавить переменную, геттер, сеттер и строчку в функцию инициализации State если параметр может меняться.

Учитывая что GameStats и State разрослись на много страниц, каждая из этих операция убивает всё желание когда либо менять данный параметр.

Как нужно было сделать:
Один класс со всеми параметрами, от xml отказаться. На нужное количество уровней параметров создаётся соответствующее количество объектов. При начале действия, требующего перехода на один уровень параметров вверх создаётся объект, инициализируется от последнего уровня и используется он для всех возможных параметров, независимо от того когда они появились и могут ли они меняться.

А ещё лучше:
Создать класс который сам следит за тем какой из объектов представляет какой уровень параметров и кого от кого и когда надо инициализировать. Он же эти параметры и хранит.
У каждого изменения параметра, притендующего на продолжительность, должно быть указано какой уровень он хочет изменить и изменения вносятся во все объекты начиная от данного уровня и старше.
Если во время битвы взять ачивку (+10% к радиусу всех зданий), то проапдейтятся радиусы зданий второго и третьего уровней.
Правда чтоб проапдейтились уже построенные здания нужно вызвать отдельную проверку. Но может это и к лучшему? Может это фича?


Ещё нужно заметить, что радиус башни также можно расчитывать изходя из информации о взятых апгрейдах, так что информации всегда будет избыточно.
А можно наоборот полностью положиться на информацию от апгрейдах. И у каждой башни будет recalculateStats() в которой параметры башни будут пепересчитаны по формулам, учитывающим все виды всех бонусов.
Во время взятия апгрейда или ачивки или навыка должна вызываться эта функция для всех причастных.
Только сейчас сложно сказать можно ли будет вычлинить этих причастных. Не создаст ли это ещё больше проблем.