'Наследование vs композиция. Компонентная система Unity' - бесплатный вебинар. Яковлев Илья

⚡️⚡️⚡️ Полезные ссылки ⚡️⚡️⚡️

Что будет?

Впереди нас ждет 2 часа полезного материала и общения в ходе которых мы разберем непонятные для многих темы связанные с разработкой игр:

👉 Разберем такие подходы к реализации игровых модулей как наследование и композиция
👉 Посмотрим на их отличия в примерах и определим в каких случаях нужно использовать тот или иной вариант
👉 Рассмотрим компонентную систему Unity как реализацию композиционного подхода
👉 Посмотрим на плюсы компонентной системы
👉 Подумаем почему Unity компоненты могут быть небезопасны и неудобны при разработке
👉 Разберем несколько частых ошибок новичков при работе с компонентами
👉 И многое другое!

💎 И без крутых и полезных подарков я вас не отпущу!

💪 Все участники трансляции получат доступ к записи лекции по необходимым знаниям архитектуры игр
💪 А также у вас будет шанс получить скидку на 5 - месячный курс Unity adventure, запись на который откроется уже 30 июня!

#Unity#ЯковлевИлья#gamedev

[NewUser]

Вторая парадигма ООП (методология, стиль программирования, а хорош ли он?) - наследование противоречит первой - инкапсуляция. Что повышает связанность системы.
С увеличением связанности системы, увеличивается сложность системы и возрастает вероятность ошибки. В силу этого можно сказать, что наследование (ещё раз - это парадигма одного из стилей программирования, а хорош ли он? ведь есть и другие стили) также частично противоречит SOLID, нарушая первый и, возможно другие принципы.

В большинстве языков, наследование ограничено наследованием абстракций, реализаций и множественным наследование по цепочке (например, в C#). Что не исключает и часто порождает другие языковые конструкции, близкие к наследования (трейты в PHP).

Из своего 20+ лет опыта разработки скажу, наследование - это плохо. Ведь в большинстве случаев, разработчик принимает решение о наследовании единолично, без разработки блок схемы, анализа бизнес процессов, согласования архитектуры с системным архитектором. И (самое главное) под страхом - если не унаследуюсь, тимлид мне предъявит, засмеют, поругают - т.е. из своего рода страха, неуверенности, следовании общепринятым нормам (нигде не задокументированным).

Как типовой результат - избегание дублирования кода, без избегания дублирования идеи (анализа то не было), увеличение связанности системы, появление ошибки в цепочке наследования, головная боль архитектора, который бегает по цепочке наследования, пытаясь понять все связи и влияние кода на другой код (от недели до двух на исправление простой ошибки).

Можно сказать и проще. Орк не равно эльф. Они разные ) Как бы даже названия разные, на вид разные. )
И даже если построить систему с наследованием (ведь орк и эльф могут получать удар, верно? - что то общее), что вы будете делать, если появится 3 раса - нежить?
Сможете ли вы, в игре, в уже хорошо работающей игре с большим онлайном, монетизацией, в отлаженной системе, безошибочно дополнить класс, влияющий на множество других классов системы? Рискнете? ) Если у вас 10 игроков - легко. А если их сотни тысяч?
Сможете ли провести все тесты, учесть всё возможное взаимодействие кода?

Попробуйте, попрактикуйтесь. Напишите простой контроллер врага в 1000+ строк кода (с какой ни будь базовой машиной состояний) и вы поймете, что даже с хорошей структурой кода, комментариями, именованиями сущностей, вы уже будете не уверены в его работе, в силу большого количества взаимосвязей различных систем (методы ютини, ссылки, корутины, циклы, анимации, отслеживание событий, события аниматора Spine).

В результате, даже в топовых играх, интеллект моба (врага) весьма примитивен. А интеллект босса более продвинут и отличается от моба - хотя оба же монстры.
Не наследуют.

[PragmaGames]

@Albert Изначально может быть достаточно сложно, но если разберешься будет хороший опыт, во многих компаниях этот инструмент используют

[PragmaGames]

@Sergey Если скорость и качество твоей работы будет лучше чем использование нативного ui toolkit, то это только плюс

[PragmaGames]

@Paul Sugar Нужен конкретный пример. Взаимодействие между модулями обпеспечивается классами "прокладками"

[PragmaGames]

@TheEvilDuck Ну в разных компаниях по разному, есть очень сильные команды, етсь слабые, тут еще как повезет.

[sixdkcd]

На мой субъективный взгляд, эти подходы с наследованием лучшее, что можно делать при разработке игр. Например, мы можем создать базовый абстрактный класс Weapon, который будет представлять любое оружие с его общими свойствами и методами, например каждое оружие будет атаковать, что логично, у каждого оружия будет урон и скорость атаки. Абстрактный класс для того, чтобы мы не могли создать экземпляр этого самого класса, что весьма логично, ведь само по себе Weapon это лишь абстракция для наших будущих оружий со своей логикой. Абстрактные методы нам нужны в этом классе для того, чтобы мы их ТОЧНО переопреляли, например метод Attack(), котоовй будет у всех оружий, но работать по разному. Виртуальные методы использовать только в том случае, если у нас повторяется какая-нибудь логика у разных классов (оружий), чтобы у нас была возможность переопределять только при необходимости, если у нас какое-то оружие будет отличаться, или вызывать базовую его реализацию с помощью base. Так же можно вызывать встроенные в юнити методы Start(), Update() и другие в классах-наследниках. Но если эти методы определены в базовом, то мы можем в производном просто скрыть его с помощью new для того, чтобы он был как бы закрытым и не было конфликта имён. Так же мы можем наоборот запретить наследоваться от законченого оружия, которое не подразумевает быть базлвым класом для других наследниках, запечатать его с помощью sealed. И если мы какие-то оружие отправляем Классу Weapon weapon; то будет вызывать вся логика именно та, какое оружие мы ему передали (пример полиморфизма). Извините, что так много написал, но наследование в контексте юнити я обожаю

[VasiliyAzarov]

Немного не понятен пример с наследованием. Если ты наследуешь Башню от Врага, не значит ли, что твой класс Враг имеет поведение которое не свойственно всем Врагам, а каким-то конкретным (пример: у тебя в классе Врага только ближний бой, а есть еще и дальний) и значит нужно выносить не соответствую абстракции вещи в другие абстракции? То есть как будто бы пример выглядит так что мы пытаемся скрестить собак с котами и поэтому наследование надо избегать.

[DarkIllusoire]

Ролик не смотрел, но сама идея противопоставления этих парадигм - дурацкая. Кофе нужно пить или с сахаром, или с молоком