Привет. Расскажу про то, как устроен код в проекте, чего придерживался, что пришлось менять. Тут есть, о чем поговорить. Я поделюсь своим опытом.
Разграничения
Как уже писал в предыдущей статье, пространства имен – это отличный способ разграничить островки игровой логики в проекте в крупном масштабе. На более низком уровне идет разбиение на классы. Помните, Божественный объект – это антипаттерн. К слову, один заказчик немного разбирался в программировании и всерьез хотел, чтобы мы делали именно божественные объекты в играх.
Тогда еще совет. Вы – специалист своего дела, который знает технические подробности реализации проекта, и это ваша обязанность – настоять на правильном обоснованном техническом решении.
Альманах
Не забываем про абстракцию. Если того требует ситуация, сначала делаем абстрактный класс или интерфейс, потом более конкретную реализацию. Не беспокойтесь, никогда не поздно начать извлекать методы и выделять классы.
Интерфейс или абстрактный класс? Абстрактный класс уместней использовать при очевидной общности наследников, интерфейс же – лишь модель поведения, которую могут реализовать объекты, не имеющие ничего общего между собой.
Совет. Учи рефакторинг, это реально полезно. Учи горячие клавиши в среде программирования, это реально полезно. На новом месте работы я научился многому у старших коллег, и в то же время мне тоже было что рассказать и показать им.
Пример абстракции. Когда главный герой знакомится с новым видом противника, то игроку показывается описание нового врага и его особенности, характерные черты поведения. То же самое происходит с новыми подобранными игроком свитками. Логично сделать некую основу, в которой будут меняться детали. Поэтому данные о свитке и данные о новом противнике унаследованы от общего класса от ScriptableObject. Страница описания противника, и страница описания свитка тоже имеют сходство, но в описании противника мы еще показываем список характерных черт, а в свитках есть только описание.
Только спустя пару лет практики программирования начинаешь понимать принципы SOLID и ООП по-настоящему. Не просто так в каждом ролике, в каждой статье или интервью с разработчиками повторяется как мантра: каждая механика – это отдельный островок, который работает независимо от других; удаляя один компонент, другой не должен сломаться… Старайтесь придерживаться принципов программирования, это в любом случае дешевле обойдется, чем потом переделывать все, поправляя одно, ломая тем самым другое.
Совет. Не переставайте менять именование полей, методов и классов до тех пор, пока не станет максимально удовлетворять вас. Именование должно лаконично передавать суть и все. Классы именуются как имя существительное, методы как глагол. События привычно писать со слова On (OnHit, OnLoaded, OnError), но методы, которые на них подписываются, должны передавать свою суть (GetDamage, Unfade, SetDefaultValues). Помните, большую часть времени вы прежде всего читаете код, нежели непосредственно пишите его. Решиться на изменения в коде гораздо легче, если хорошо владеть IDE (например, переименование и извлечение метода).
Совет. Используйте ключевое слово field в атрибутах, оно позволяет воспринимать свойства как поля, отображая их в инспекторе, но все еще инкапсулировать данные. Не пренебрегайте ограничением доступа к данным. Этот трюк сокращает количество строчек в 2 раза, Карл! Этот десяток строк мог выглядеть как 20 строк.
Спаун противников
Тут вроде все просто. Враги появляются по волнам. Волны, количество противников и период их создания во время волны определяется в SpawnerData. Они могут появляться на протяжении всей волны, могут в начале волны или только в конце; по одному в секунду или сразу скопом.
С самого начала я не до конца продумал как именно будут появляться противники на арене, а я очень хотел внести какую-то оригинальность в моей игре. Поэтому мне пришлось переопределить архитектуру этой части кода. Теперь точка появления и логика этого события делегируются в отдельный класс SpawnDealer. Он стал отвечать за то, как именно и где появится противник. Например, арахниды появляются с помощью червя Нидуса, если такого нет на сцене, сначала появится червь, проиграется анимация, а уж потом появится противник из него. Духи появляются только в темных участках арены, а демоны в точках, где есть огонь (факел, костер, пожар). Некоторые противники появляются с помощью молний, только на участках арены под открытым небом.
Красными точками отмечены темные места для появления Духов, а белыми точки под открытым небом для создания молнии и спауна противников из них.
Урон и здоровье
Эту часть игры тоже пришлось переписывать после первых попыток. Итогом стали абстрактный класс Health и его наследники HealthPart и HealthParent. Предполагалось, что попадание в разные части тела (HealthPart) дает множитель на получаемый урон, передавая значения на HealthParent, который у противника есть в единственном экземпляре. Это решение из общей папки с кодовой базой, на самом деле в проекте используется только HealthParent.
Так как в игре есть стихийный урон и различные мета-данные нанесения урона (с какой стороны прилетел удар, точка удара, физическая сила удара, префабы попадания), я сделал структуру HitData, а также DamageDealer для удобства заполнения этих данных.
Совет. Старайтесь подписываться на события (если это не дочерние компоненты), нежели напрямую завязывать внешние объекты между собой. Это уменьшит связность проекта, позволит убирать или добавлять что-либо на сцену, не ломаю остальное.
Завершение
Понимаешь диаграммы классов? Что-то стоит поправить? Что думаешь? Есть польза от написанного? Критикуй, пиши, прочтем. Я очень надеюсь, что делаю какое-то полезное дело, в надежде повысить свою и вашу грамотность в написании кода.
Разработчик | Проект | YouTube | e-mail | Поддержка
Vkontakte
Twitter
Одноклассники
