|
|
|||||
Цитата:
Который примет id атакующего и атакуемого юнитов. Выполнит все проверки, посчитает модификаторы урона и т.д. Объект World содержит данные обо всех сущностях в игре. (В нём есть списки юнитов, бафов/дебафов, вся необходимая информация)
__________________
Дети не должны знать о своих родителях |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Tails, я ещё полюбопытствую. В твоём примере есть класс GameData, который, как я понял, затягивает из json все справочные данные игры: и юниты, и атаки, и типы атак. На больших проектах ты так же делаешь - один пухлый справочник всех статических данных, который хранит и выдаёт все списки, или уже как-то разделяешь?
__________________
Не сломано - не чини! |
|
|||||
Я выносил в GameData все статичные данные игры, не изменяемые во время выполнения. А если и делить, то как? И зачем? Динамические данные (изменяемые в ходе игры) у меня были в объекте World. Вообще, я думаю, что лучше хранить абсолютно все данные в одном месте и изменяемые и не изменяемые (В идеале).
__________________
Дети не должны знать о своих родителях |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Не знаю, поэтому и спрашиваю. Можно пофантазировать, что а) данный класс будет слишком раздутым, так что в нём будет тяжело ориентироваться, б) объём загружаемой и хранимой инфо будет слишком большим с т.з. ресурсов системы и, возможно, в) над различными аспектами игры трудятся разные люди в команде, поэтому им удобнее иметь свои справочники, а не делить один общий.
И если у тебя все справочники живут вместе, зачем тебе наследовать классы парсеров? Ты в одном из предыдущих сообщений писал, что по этой причине предпочитаешь не реализовывать парсер как "статический" класс. Я правильно понимаю, что парсер - это у тебя такая огромная простыня с кол-вом методов по кол-ву классов-листов?
__________________
Не сломано - не чини! |
|
||||||
Цитата:
Цитата:
Мой гоблин в рантайме: id, unitID, life - Не более 16 байт. (4 + 4 + 8) Гоблин по принципу - "объект сам себе режисёр": Содержит текущие данные, копию его статичных данных (Имя юнита, например) и данные всей цепочки наследования + EventDispatcher. Потребление памяти будет явно в несколько раз больше. Цитата:
Цитата:
Цитата:
__________________
Дети не должны знать о своих родителях |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Исчерпывающе, спасибо.
Будешь смеяться, но поскольку по мере развития своего проекта мои собственные познания очень активно развиваются и расширяются, я уже на сегодня имею массу разнообразных вариантов хранения справочных данных. В частности, у меня есть языковые XML файлы, несколько классов, в которых я создал и вручную заполнил такие же хэши, как у тебя из json считываются, плюс есть в порядке эксперимента вариант подгрузки и считывания из json в рантайме. В принципе все работают, то ясен пень, нужно с этим плюрализмом заканчивать. Кстати, намотал на ус твою мысль о рисках ошибиться, возникающих при обращении к данным json в рантайме. С другой стороны, я уже понимаю, что в полной мере реализовать описанную тобой модель работы со всеми данными игры проблематично, при всей красоте и заманчивости. Практическая проблема заключается в том, что мне приходится хранить в хэшах непосредственно классы. Так как зачастую создаваемые объекты - это разные наследники одного базового класса. Код в классе-хранителе справочной инфо выглядит так: А дальше прямо в конструкторе класса создаваемого экземпляра записан запуск переопределяемого в наследниках метода setInitialProps(), который ломится в тот же справочник и сам заполняет нужные данному наследнику поля.
__________________
Не сломано - не чини! |
Часовой пояс GMT +4, время: 04:58. |
|
« Предыдущая тема | Следующая тема » |
|
|