Phaser - полезные советы

Часть 45: Логика Построения Кода Игры

Работа в Робин Гуде идет полным ходом. За несколько дней перенес весь код из прототипа в проект. Для себя сделал заключение, что не стоит делать прототипы на чистом JS, а лучше уже прямо в Phaser-е. Это существенно облегчает построение логики игры и передачу данных между классами.

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

Именно в этой игре я заметил пользу от инкапсуляции (скрытие кода). Кстати, я попробовал скрывать методы класса через ключевое слово private (в JS6 оно уже внедрено), но что-то оно ни на что не повлияло. После компиляции, я по прежнему без труда обращался к таким членам объекта извне 🙂 Даже PhpStorm не скрывал из подсказки эти свойства и методы. В результате, я воспользовался самым простым решением: добавил символ подчеркивания перед такими свойствами и классами.

За мою практику, у меня было всего несколько случаев, когда обращение к свойствам через get/set методы оправдывали громоздкость генерируемого кода. Игра Робин Гуд заставила меня еще раз задуматься, не использовать ли такие методы ВСЕГДА. Практический пример: благодаря тому, что значения времени рейда и размер добытых ресурсов можно было получить через методы, в определенный момент программирования, мне довольно легко удалось изменить правило добычи ресурсов. А если быть конкретней:

Все числа у меня были рассчитаны исходя из того, что рейд будет проходить раз в секунду, что на практике слишком быстро и не зрелищно… по этому изменил время на 4 секунды. Из за этого, доход и другие параметры увеличивались соответсвенно. А так как другие классы получали данные через методы, мне достаточно было поменять логику в одном месте (самом классе точки облавы), что бы изменения вступили в силу вдруг х местах.

Даже когда вся работа была закончена, пришлось потратить еще одни сутки на рефакторинг. Стало понятно, что не смотря на то, что логика управления точками облавы и есть вся игра, все же стоит ее отделить от кода управления интерфейсом (который тоже постепенно разрозся). По этому я создал дополнительный класс и назвал его «Шервудский Лес». Вообще, надо взять за правило не халтурить и делить код на логические классы (правда можно и переусердствовать в этом плане).

в своей жизни НИКОГДА не рисовал, это последние несколько рисунков

Ждите продолжение с первыми реальными скринами и как я начал учиться рисовать =)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *