УБЕРИ ЭТО из архитектуры игры! C# и Unity! 5 ошибок в построении архитектуры

Рет қаралды 27,940

Күн бұрын

Пікірлер: 106

@-it394 11 ай бұрын

⚡⚡⚡ Полезные ссылки ⚡⚡⚡ 🔎 yakovlevgamedev.ru - курс по архитектуре игр в Unity 🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал (тут розыгрыш и материалы для обучения со всеми полезными ссылками - искать в закрепленном сообщении) 🔎 dzen.ru/b/ZVthaYMiXVQbRmWa - статья про LinQ от Лавки разработчика 🔎 boosty.to/yakovlevgamedev - ссылка на бусти 🔎 kzbin.info/door/C-hfECZdghe_QNAJzztHEg - ссылка на канал моего младшего брата (подпишись если не сложно)

@flexmachine2280 11 ай бұрын

Кто ничего не пишет, тот не ошибается в коде☝️🧐

@megammmarisnowflake8623 11 ай бұрын

Это яндер дев так делает

@emeil1989 11 ай бұрын

Ауф

@Frogi02 11 ай бұрын

☝️🤓

@zeronim1965 10 ай бұрын

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

@ilhanilhanDev 10 ай бұрын

@@megammmarisnowflake8623зато миллионы бухает , в отличий от тебя и от меня тоже

@hordorsok 11 ай бұрын

Спасибо, за видео! Очень полезная информация!

@MrYuriyP 11 ай бұрын

Эти советы полезны в любом проекте, а не только при разработке игр.

@volodya185 11 ай бұрын

Касательно второй ошибки: Как метод назовёшь, так его и будут использовать, назови нормально и переопределять не будут, но в целом практика действительно хорошая, абстрактные и виртуальные поля лучше не вызывать в конструкторах. Что касается ошибок в конструкторе, для такого лучше использовать статический метод Create, что тоже частично нарушает паттерны, но лучше ошибок в конструкторе. Есть ещё предложение создавать методы Init и подобные, чтобы этот метод вызывали при необходимости, и вот он может выкидывать ошибки, а конструктор пусть будет. Касательно 4-ой ошибки: Не считаю это ошибкой, ведь ты сам объяснил, почему это хорошо, иногда это рудимент. Хотя конечно лучше задуматься над тем, где какие интерфейсы нужны, а где они бесполезны. И если мы говорим про предметы, которые можно собирать, лучше сделать интерфейс типа IStorable, если есть предметы, которые можно со стакать, можно назвать ICollectable. В целом согласен с твоим тезисом.

@argon9113 11 ай бұрын

Мне лень проверять НО, 1:27 идея с заменой на свойство может быть опасна, поскольку Vector3 является структурой и будет создана копия, редактирование которой никак не изменит исходный объект

@-it394 11 ай бұрын

Так я и не редактирую, а просто обращаюсь. Но, в целом да, замечание верное, за этим надо следить)

@dmitriytuchashvili8594 11 ай бұрын

Я привык думать о лямбда выражениях такого типа как о сокращениях, или ссылках на что-либо. То есть под капотом свойство Position ничего не хранит. Это просто проводник, который за ручку нас ведет к другому полю или методу. В данном случае к transform.position

@lit1041 11 ай бұрын

Более того, так как структура лишь копирует значение позиции при инициализации, его значение не будет обновляться, и, как следствие, это вообще не будет работать. Vector3 является структорой - это не класс, а значит доступ к нему осуществляется не по ссылке.

@xpoftik 11 ай бұрын

Постоянно тыкаю моих подопечных на проекте в подобные ошибки. Всё это нарабатывается только с опытом. Потом уже просто на автомате действуешь правильно. Советы на самом деле полезные! 👍

@ДмитрийГуляев-н5н 10 ай бұрын

Весьма полезные советы даже для тех, кто не один год работает прогером. Лойс.

@RimuruDev 11 ай бұрын

Великолепный материал. 😅Все больше хочется купить курс. Но пока что на работе запара, осваиваю серверную часть для игры.

@FloatingGames 10 ай бұрын

А на чем сервер? На сокетах?

@RimuruDev 10 ай бұрын

@@FloatingGamesКурс кстати купил, скоро начнутся занятия. А что насчет вопроса, сам сервак на Ubuntu хостится, само собой использую Docker контейнер. Серверная логика игры на NakamaServer + TypeScript. Клиент очевидно Unity + C# ;3

@FloatingGames 10 ай бұрын

@@RimuruDev я впервые такое слышу, у меня сервер на windows + c#, а зачем используют docker? Просто сколько не спрашивал у всех невменяемый ответ

@RimuruDev 10 ай бұрын

@@FloatingGames Странно что у “всех” невменяемый ответ :3 Тогда постараюсь сказать в двух словах и максимально просто. Докер помогает "упаковать" приложение со всеми его настройками и зависимостями, чтобы оно могло легко и одинаково работать на любом компьютере или сервере. Это существенно упрощает развертывание и управление приложениями, делая разработку более гибкой и эффективной. Допустим теперь понятно вкратце чем хорош докер. Но теперь вы подумали “нафига оно мне???”. Без Докера: Если вы разрабатываете на Windows с C# (судя по комментарию), ваше приложение может не работать или работать по-разному на других системах (например, Linux), из-за различий в настройках и зависимостях. Если даже после этого ничего не понятно, то лучше глянуть отдельно материалы о том для чего нужен докер и чем он полезен. Так как я плохо объясняю :3

@FloatingGames 10 ай бұрын

@@RimuruDev а вообще на Линукс можно скомпилировать c# проект, просто мы пытались это сделать но никак не получилось

@ИгорьФилатов-и1к 11 ай бұрын

Свойства - это просто другая форма (синтетический сахар) вызова get и set методов, со всеми вытекающими. Не всегда происходит инлайн оптимизация, стоит обращать внимание на частоту вызовов, но в рамках игровой логики маловероятно, что где-то будете упираться в производительность. Насчет запрета исключений в конструкторе - эта проблема из плюсов, на си шарпе просто как правило хорошего тона. Linq имел проблемы с производительностью во времена четвертого юнити, сейчас там больших проблем нет, и тогда же я не рекомендовал его использовать так как не все понимали его (редко использовался), что тормозило задачи. Сейчас с этим проблем нет, в клиент-серверном это стандарт, а следить за выделением памяти так и так придется, всегда можно поправить.

@ravenempty3562 3 ай бұрын

Не синтетический, а синтаксический)

@petrpal330 10 ай бұрын

Последний совет про то, как лучше заменить Check - очень кстати, спасибо) Давно была мысль как-то симпатичнее организовывать этот момент.

@tugoshow2049 11 ай бұрын

Мне понравился ролик про ошибки 👍. У меня с усложнением кода всегда проблема была, надеюсь исправлю. Я бы хотел вторую часть 😅

@dicony3427 11 ай бұрын

Очень познавательно, требую еще)

@ИванИсайков-я5с 11 ай бұрын

Не советую удалять абстракцию "сделанную для красоты", если планируете в будущем систему модификации игры, иначе придётся дофига всего переписывать...

@opodlinok 11 ай бұрын

Про отказ от бессмысленных переусложнений -- лучший совет. Иногда открываешь код (допустим когда тестовое при приёме на работу проверяю), а там такие приколы... Интерфейсы и абстракции ради красоты ещё никому лучше не делали. Единственное чего придерживаюсь в плане, что не всегда оно нужно -- в каждом новом проекте создаю интерфейсы IInitializable { Initialize(); } и IConstructable { Construct(T param); } Как раз для решения проблемы с тем, что конструкторы только для инициализации полей. Можно писать по типу new ClassName(инициализируемые поля).Initilize(), а Construct использую для монобехов (awake и start только в бутстрапе или декоративных элементах не влияющих на логику игры). И сразу видно, если с классом после создания, перед выполнением его логики, нужно провести ещё какие-то подготовительные операции. Видео отличное и очень полезное! Спасибо С:

@_Otets_ 11 ай бұрын

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

@opodlinok 11 ай бұрын

@@_Otets_ это если ты работаешь соло или не в коммерческой разработке и твоим кодом не будут заниматься другие люди

@_Otets_ 11 ай бұрын

@@opodlinok Ну нет, когда ты делаешь прототип как раз в команде самая лучшая стратегия - это фигачить как фигачится: сущностей мало, зависимостей тоже. Это уже когда прототип идет в работу и окончательно ясно чего и сколько будет уже можно писать как по учебнику. А сразу наращивать интерфейсы ради 2-ух с половиной калек - такое себе. Ну и офк, стоит упомянуть что я работают с мобилками в тиме из 4-7 человек.

@vector7932 11 ай бұрын

То есть это просто интерфейсы для учёта инициализируемых классов? Какую это задачу решает? Можно без интерфейсов писать. И в Construct если несколько параметров - не создавать лишний объект. Нет лишнего объекта - не надо лишнего поддерживать. Наверное, если есть Initializable, то есть и Disposable?

@opodlinok 11 ай бұрын

@@vector7932 констракт вообще не используется при создании объекта. Это буквально функция для подготовки монобеха без awake/start к работе. Эти интерфейсы решают задачу унифицирования кода - ты, конечно, можешь просто прописывать в каждый класс функцию Initialize со своей логикой и без интерфейса, но смысл если можно одним кликом её реализовать, да и к тому же показать всем, кто работает с этим классом, что его мало просто создать, но и перед работой нужно что-то сделать, с первого взгляда

11 ай бұрын

Интересно узнать. У меня рогалик, уже 10 месяцев в разработке, через месяц финал. Персонаж состоит из кучи стат, айтемы улучшают их. Я реализовал это через Scriptable Object, создал массив где SO инстанциируется и получается новый SO, который при изменении не повлияет на оригинал. К его полям всегда есть доступ через эту датабазу на чтение и запись, они просто публичные. Это плохая реализация? Пока я не сталкивался с проблемами на всём пути разработки и удобно изменял значения, а где они делились или уходили в минус я делал проверки и задавал значение. Типа если МаксХП после айтема

@-it394 11 ай бұрын

Пока тебе удобно, игра не рушится и ты двигаешь к завершению - реализация хорошая) Но, объективно, я уже не раз говорил, что в SO писать ничего не надо (причина была в одном из видосов с советами по архитектуре как раз). Далее то, что ты молча клэмпишь значения, может быть опасно просто потому что ты даже не поймешь, если у тебя какие-то ошибки будут. В логике могут быть косяки, которые не вылезают при каких-то обстоятельствах, а когда вылезут, сложно будет их найти, т.к. вроде бы все работает частично и непонятно где нарушение может быть. Но, опять таки, если ты там просто при опускании ниже нуля хп их клэмпишь к нулю, то это нормально, ведь урона может нанестись больше чем осталось хп, так что тут все окей, это логично

11 ай бұрын

@@-it394 А что за видео по архитектуре? Хотя лучше посмотрю все) В принципе, я тоже самое могу сделать и классами и получать доступ в ним, но это придётся работать больше) Для начала (да и я тогда вообще ничего не знал, а рекомендовали SO очень для стат, но не уточняли что их используют как конфиги) я считаю норм :D Всё равно я был уверен что в будущем буду переписывать всё красиво и нерушимо, насколько это возможно. Часто было такое что враг получал двойной урон, пофиксил временем неуязвимости, которое тоже может быть 0 и меня в принципе устраивает. Меня харило писать сначала SO, добавлять туда новую стату, потом добавлять её же в класс с ними, а ведь игрок должен свои данные засэтить из него, получается третий раз, аналогично с врагами, ибо им один SO не дашь. Вот что реально выстрел в ногу - я не могу таким образом добавить в будущем кооп, ибо всё через SO, а два таких сделать анриал, ибо всё сломается. Не думал что буду делать кооп, а он вписывается вообще. Так что убирать буду, теперь точно :D Спасибо за ответ и видосы

@FloatingGames 10 ай бұрын

@разве so создавался для того чтобы записывать в него данные?

@skalse_456 11 ай бұрын

1. Это не ошибка, а более фича, что ли удобство. 2. Тоже фича и под конкретную задачу, нет смысла лишний раз делать переменные так-то. 3, 4 и 5 согласен полностью

@mrgates231 11 ай бұрын

Архитектура слишком сильное слово для таких ошибок уровня "первый раз открыл юнити"

@zjcom-bb7ek 2 ай бұрын

По логике чем выше уровень программиста, чем меньше он ошибок совершает. Так что вряд ли существует понятие "ошибки профессионалов"

@craftgameworld 5 ай бұрын

Последняя ошибка не до конца раскрыта) Как назвать метод, в котором будет следующий код "if (IsWinning()) {ShowVictoryWindow(); ShowVictoryParticles(); ... }" ?

@johnwheel2591 11 ай бұрын

4 ошибка топ. Сам этим страдаю. Правдивая до жути

@cimweed18 11 ай бұрын

Абстракции для красоты( Нашел парочку

@omegakrakengames 11 ай бұрын

Я почти мегамозг ) Спасибо за видео

@alsg00 10 ай бұрын

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

@-it394 10 ай бұрын

Я наверное неудачно сделал нейминг) И в родительском и в дочернем классе свой приватный список, который я назвал и там и там list. Поэтом в дочернем классе мы пишем в свой список, который ещё не проинициплизирован

@alsg00 10 ай бұрын

Нет-нет, по неймингу всё понятно, вопрос немного в другом. В видео говорится, что при создании экземпляра дочки сначала вызывается конструктор родителя. А родитель в своём конструкторе обращается к СВОЕМУ виртуальному методу, в котором идет обращение к СВОЕМУ приватному списку, который уже проинициализирован. А если он проинициализирован, то почему должна возникнуть ошибка? Или виртуальный метод к моменту вызова уже перезаписан дочкой?

@-it394 10 ай бұрын

Уже перезаписан (сначала вызывается дочерний метод, потом через base. родительский)@@alsg00

@JamesListener 11 ай бұрын

Секундочку. На 1:50 ты же задаешь луч значением по умолчанию, т.е. он будет сгенерирован при создании объекта. А в апдейте ты рейкастишь всегда один и тот же луч! Некорректный пример же.

@VoroninPavel 11 ай бұрын

Лучше вообще выкрутить все ворнинги до ошибок. И отключать их локально или глобально, снабжая осознанным вменяемым комментарием, почему здесь такой код ОК. Тогда, например, и с виртуальным методом в конструкторе (2 ошибка) не накосячить. Еще, кстати, хорошо завести привычку объявлять классы как не наследуемые по умолчанию. Тут и IDE чуть быстрее работать будет, и глазкам сразу видно, что наследников у типа точно нет.

@FloatingGames 10 ай бұрын

Типа sealed?

@VoroninPavel 10 ай бұрын

@@FloatingGames угу

@apogee... 11 ай бұрын

Я вот разве что первую ошибку совершаю... просто потому что все остальные ошибки я даже не смог бы совершить) Что за интерфейсы, что за виртуальные воиды, каво? Разве что хотел бы спросить Что означает вот это {get, set} после переменной? Возможно это что-то крутое, что мне стоило бы использовать Я только вчера узнал про "=>" и блин, это так удобно

@ilhanilhanDev 10 ай бұрын

С первым интересно , остальные будут более мешать чем кодить . Когда ты хочешь описать механику и за одно думаешь как это лучше прописать ,чтоб на скрипте смотрелся лаконично, это во первых отбивает желание кодить, сбивает с толку, отнимает время, и возможно с большим процентом ты не сможешь выполнить задуманное. Я говорю механиках придуманной из головы (ответ который в инете не нашел), а не шаблонные механики(которые уже прописанны для тебя сотни раз) Вообще проще саздовать второй велосипед и гавнокодить просто надо учесть: Много ифов не добавляйте производительность жрет, говорят кейсом проще или ифелсом пользуйтесь если ра то пошло. P.S. YandereDev Делайте так чтобы коды можно было друг от друга отстыковавать, механики, чтобы по блокам по честям, можно было кодить или даже сносить и менять опрелеленную механику если это захочится

@hackermann99 10 ай бұрын

Видео не соответствует своей теме. В нём вовсе нет ничего про архитектуру, зато есть короткий список из ошибок новичков в языке С#

@questprom 11 ай бұрын

нашёл 2 метода с check в начале, убирать не буду, мой код - мои правила ))

@-it394 11 ай бұрын

🤘🤘🤘

@Kompreso 11 ай бұрын

5:26 в конструкторе базового класса уже создаётся лист, о чём речь вообще?

@Иван-д2ф6ш 11 ай бұрын

а что вот этот значок делает => почему нельзя просто = поставить ?

@-it394 11 ай бұрын

Это лямбда выражения metanit.com/sharp/tutorial/3.16.php - вот тут можешь почитать)

@uuuummm9 10 ай бұрын

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

@urod7149 11 ай бұрын

спасибо

@ilya.drone.moments 10 ай бұрын

а меня например напрягают люди пишущие название полей через _ , считаю это ошибкой - не допускай этого. А если серьезно, в целом по делу тут мало чего, человек который смог написать большой и стабильно работающий проект (в данном случае игру) и с возможностью без проблем его дорабатывать - сделал все правильно. И нет такого понять "Не надо так делать", раз сделал - значит надо было

@timothypsina 10 ай бұрын

Делать надо правильно, чтобы другие потом (и ты через год после написания проекта) могли понять что ты сделал. Сейчас работаю сам разработчиком и много приходиться с чужим кодом возиться и ты не представляешь какой гемор пытаться разобраться в том, что написали пару лет назад по принципу "главное работает". Если хочешь это развивать только как хобби, твоё дело, но если хочешь чего-то большего, то по такому принципу будешь в пролете.

@ilya.drone.moments 10 ай бұрын

@@timothypsina я написал комментарий в окнтексте видео, а из того что сказано в видосе, это никак не вредит легкости и поддержанию проекта. Но громко заявляется как "Ошибка - которую не стоит допусткать"...

@gladiko2364 10 ай бұрын

Ошибка номер 0: пихать лямба выражения в каждую строчку, что бы побольше в код насрать.

@psix2006 11 ай бұрын

Я не давно начал пользоваться unity и у меня всё скрипты в нём без пользования классов и листов , я просто не понимаю для чего они нужны и где их можно применять на практике

@FloatingGames 10 ай бұрын

Тогда лучше будет сначала изучить теорию, говорю как разработчик 3года и особо ничего не знающий, буду после этой сессии жёстко учиться

@ilya.drone.moments 10 ай бұрын

без нормального кода, что-то сложнее раннера ничего не напишется

@АлександрСериков-ч5ю 4 ай бұрын

Заголовок "5 ошибок в архитектуре". Реальность: переименовываем переменные для лучшей читаемости...

@cristalGamer5100 11 ай бұрын

Протектед же имеет те же уязвимости что и публичный уровень доступа?

@-it394 11 ай бұрын

Можно по подробнее к чему этот вопрос?)

@timothypsina 10 ай бұрын

Protected является рекомендацией по правилу SOLID "открыт к расширению, но закрыт к изменению", так этот модификатор доступа и работает.

@holo2028 11 ай бұрын

Прикольное видео наверно, жаль что я пока что далёк от понимания этого)..

@весёлыйджек-у4щ 11 ай бұрын

Хорошо, теперь куда выкладывать игры во время санкций в России?

@ivanfilatov5482 7 ай бұрын

вкусовщина

@kirillsviderski4739 11 ай бұрын

1:24 оочень вредный совет. Зачем нам три раза оди и тот же вектор копировать? И почему-то многие юнитисты в погоне за "чистым кодом" допускают такие ошибки А через пару секунд како-то мракобесие с форматированием в апдейте 2:40 можно просто рассказать про First class collection - очень полезный принцип в целом 4 ошибка - жизааааааааааа. Люди с гиперкежа ооочень любят клепать абстракции, которые вообще не нужны. Люди не умеют итерировать просто и их потом не перучить делать большие фичи в "больших" играх 5 - просто база

@igor_mutny 11 ай бұрын

И свойствами толком не умею пользоваться (1-я ошибка), и в конструкторы всякую хрень пихаю (2-я ошибка). LINQ не пользуюсь, - как-то не возникало необходимости. 4-я и 5-я вроде ко мне не относятся 😅

@kirillsviderski4739 11 ай бұрын

Почитай начало статьи от Grammarly под названием Declarative Programming in .NET.

@KingDragon_Channel 11 ай бұрын

Здравствуй, не интересна ли тебе идея снять ролик по кривым?

@Максим-ъ6о6п 5 ай бұрын

Все виконано на принципі чистого коду по суті, який архітектуру гри сповільнить як і всі інші аспекти коду.

@prototypelq8574 10 ай бұрын

Видео интересное, но от Чaracter ушкам больно

@fisashgames6704 11 ай бұрын

полезный видос

@arturkadirov9280 11 ай бұрын

Честно, понял меньше половины... Пойду книжки читать... Опять...

@daniilsamodurov5423 11 ай бұрын

насчёт первой ошибки - мне кажется, в основном это только для себя упростит жизнь - в случае чего другому программисту будет только сначала визуально комфортно, но потом на каждое такое нажимать и разбираться что это (а это обычный transform.position) не очень удобно но в принципе если на такие банальные штучки не делать (ну или уж слишком часто оно встречается, то можно)

@-it394 11 ай бұрын

Это довольно простой пример, но если адекватно называть все и убирать что- то длинное в свойства, то жизнь упрощается всем)

@_Otets_ 11 ай бұрын

Ты еще не забывай что такое свойство- это и кеширование.

@volodya185 11 ай бұрын

Я бы сказал, что лучше это не в ствойства делать, а в переменные в методе кидать, если часто вызывается, лучше создать приватный метод GetSth

@vector7932 11 ай бұрын

Потом юзинги по проекту собирать, ну уж нет)