Я уже сказал, в моём примере всё взаимодействие с миром происходит через апи объекта World. У этого класса будет, в том числе метод:
Который примет id атакующего и атакуемого юнитов. Выполнит все проверки, посчитает модификаторы урона и т.д. Объект World содержит данные обо всех сущностях в игре. (В нём есть списки юнитов, бафов/дебафов, вся необходимая информация)

Tails, я ещё полюбопытствую. В твоём примере есть класс GameData, который, как я понял, затягивает из json все справочные данные игры: и юниты, и атаки, и типы атак. На больших проектах ты так же делаешь - один пухлый справочник всех статических данных, который хранит и выдаёт все списки, или уже как-то разделяешь?

Я выносил в GameData все статичные данные игры, не изменяемые во время выполнения. А если и делить, то как? И зачем? Динамические данные (изменяемые в ходе игры) у меня были в объекте World. Вообще, я думаю, что лучше хранить абсолютно все данные в одном месте и изменяемые и не изменяемые (В идеале).

Не знаю, поэтому и спрашиваю. :) Можно пофантазировать, что а) данный класс будет слишком раздутым, так что в нём будет тяжело ориентироваться, б) объём загружаемой и хранимой инфо будет слишком большим с т.з. ресурсов системы и, возможно, в) над различными аспектами игры трудятся разные люди в команде, поэтому им удобнее иметь свои справочники, а не делить один общий.

И если у тебя все справочники живут вместе, зачем тебе наследовать классы парсеров? Ты в одном из предыдущих сообщений писал, что по этой причине предпочитаешь не реализовывать парсер как "статический" класс. Я правильно понимаю, что парсер - это у тебя такая огромная простыня с кол-вом методов по кол-ву классов-листов?

Количество строк кода не так страшно, как его запутанность. Даже если в классе будет более 2к строк, это не проблема, в любой нормальной иде есть "сворачивалки кода", закладки, различные способы навигаций и т.д. Главное, что-бы один класс выполнял строго одну задачу, тогда всё будет по красоте. Когда класс решает более одной задачи, тогда можно и в 200 строчках намутить такого, что чёрт ноги сломит. В данном случае, это просто справочник и в нём не будет много строчек, он будет иметь только список переменных.

Я думаю, напротив, это - самый минималистичный способ представления данных. Только чистые данные, без чего либо лишнего. Как уже писал выше, для сравнения:
Мой гоблин в рантайме:
id, unitID, life - Не более 16 байт. (4 + 4 + 8)

Гоблин по принципу - "объект сам себе режисёр":
Содержит текущие данные, копию его статичных данных (Имя юнита, например) и данные всей цепочки наследования + EventDispatcher. Потребление памяти будет явно в несколько раз больше.

Наврядли приветствуется такой подход. Скорее, в командах есть главный архитектор, который раздаёт всем остальным реализацию составленного им дизайна апи того или иного модуля программы. То-есть, формат у всех единый. В моём опыте я пересекался с другими программистами только в способах коммуникаций и передачи данных. (Я писал клиент, другой человек - сервер и т.п.)

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

У меня да. Вы можете как угодно сделать :) Никто не запрещает вам разбить парсер на составные, которые будут читать конкретные списки данных. Но нужно ли это? Парсер и так выполняет очень примитивную задачу. Его суть - в отделений модели данных от чтения конкретного формата. Этим со мной когда-то поделился Dimarik на этом форуме. Респект ему.

Исчерпывающе, спасибо.

Будешь смеяться, но поскольку по мере развития своего проекта мои собственные познания очень активно развиваются и расширяются, я уже на сегодня имею массу разнообразных вариантов хранения справочных данных. В частности, у меня есть языковые XML файлы, несколько классов, в которых я создал и вручную заполнил такие же хэши, как у тебя из json считываются, плюс есть в порядке эксперимента вариант подгрузки и считывания из json в рантайме. В принципе все работают, то ясен пень, нужно с этим плюрализмом заканчивать.

Кстати, намотал на ус твою мысль о рисках ошибиться, возникающих при обращении к данным json в рантайме.

С другой стороны, я уже понимаю, что в полной мере реализовать описанную тобой модель работы со всеми данными игры проблематично, при всей красоте и заманчивости. Практическая проблема заключается в том, что мне приходится хранить в хэшах непосредственно классы. Так как зачастую создаваемые объекты - это разные наследники одного базового класса. Код в классе-хранителе справочной инфо выглядит так:

А дальше прямо в конструкторе класса создаваемого экземпляра записан запуск переопределяемого в наследниках метода setInitialProps(), который ломится в тот же справочник и сам заполняет нужные данному наследнику поля.