⚡⚡⚡ Полезные ссылки ⚡⚡⚡ 🔎 yakovlevgamedev.ru - курс по архитектуре игр в Unity 🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал (тут розыгрыш и материалы для обучения со всеми полезными ссылками - искать в закрепленном сообщении) 🔎 dzen.ru/b/ZVthaYMiXVQbRmWa - статья про LinQ от Лавки разработчика 🔎 boosty.to/yakovlevgamedev - ссылка на бусти 🔎 ua-cam.com/channels/C-hfECZdghe_QNAJzztHEg.html - ссылка на канал моего младшего брата (подпишись если не сложно)
Мне лень проверять НО, 1:27 идея с заменой на свойство может быть опасна, поскольку Vector3 является структурой и будет создана копия, редактирование которой никак не изменит исходный объект
Я привык думать о лямбда выражениях такого типа как о сокращениях, или ссылках на что-либо. То есть под капотом свойство Position ничего не хранит. Это просто проводник, который за ручку нас ведет к другому полю или методу. В данном случае к transform.position
Более того, так как структура лишь копирует значение позиции при инициализации, его значение не будет обновляться, и, как следствие, это вообще не будет работать. Vector3 является структорой - это не класс, а значит доступ к нему осуществляется не по ссылке.
Свойства - это просто другая форма (синтетический сахар) вызова get и set методов, со всеми вытекающими. Не всегда происходит инлайн оптимизация, стоит обращать внимание на частоту вызовов, но в рамках игровой логики маловероятно, что где-то будете упираться в производительность. Насчет запрета исключений в конструкторе - эта проблема из плюсов, на си шарпе просто как правило хорошего тона. Linq имел проблемы с производительностью во времена четвертого юнити, сейчас там больших проблем нет, и тогда же я не рекомендовал его использовать так как не все понимали его (редко использовался), что тормозило задачи. Сейчас с этим проблем нет, в клиент-серверном это стандарт, а следить за выделением памяти так и так придется, всегда можно поправить.
Касательно второй ошибки: Как метод назовёшь, так его и будут использовать, назови нормально и переопределять не будут, но в целом практика действительно хорошая, абстрактные и виртуальные поля лучше не вызывать в конструкторах. Что касается ошибок в конструкторе, для такого лучше использовать статический метод Create, что тоже частично нарушает паттерны, но лучше ошибок в конструкторе. Есть ещё предложение создавать методы Init и подобные, чтобы этот метод вызывали при необходимости, и вот он может выкидывать ошибки, а конструктор пусть будет. Касательно 4-ой ошибки: Не считаю это ошибкой, ведь ты сам объяснил, почему это хорошо, иногда это рудимент. Хотя конечно лучше задуматься над тем, где какие интерфейсы нужны, а где они бесполезны. И если мы говорим про предметы, которые можно собирать, лучше сделать интерфейс типа IStorable, если есть предметы, которые можно со стакать, можно назвать ICollectable. В целом согласен с твоим тезисом.
@@FloatingGamesКурс кстати купил, скоро начнутся занятия. А что насчет вопроса, сам сервак на Ubuntu хостится, само собой использую Docker контейнер. Серверная логика игры на NakamaServer + TypeScript. Клиент очевидно Unity + C# ;3
@@FloatingGames Странно что у “всех” невменяемый ответ :3 Тогда постараюсь сказать в двух словах и максимально просто. Докер помогает "упаковать" приложение со всеми его настройками и зависимостями, чтобы оно могло легко и одинаково работать на любом компьютере или сервере. Это существенно упрощает развертывание и управление приложениями, делая разработку более гибкой и эффективной. Допустим теперь понятно вкратце чем хорош докер. Но теперь вы подумали “нафига оно мне???”. Без Докера: Если вы разрабатываете на Windows с C# (судя по комментарию), ваше приложение может не работать или работать по-разному на других системах (например, Linux), из-за различий в настройках и зависимостях. Если даже после этого ничего не понятно, то лучше глянуть отдельно материалы о том для чего нужен докер и чем он полезен. Так как я плохо объясняю :3
Про отказ от бессмысленных переусложнений -- лучший совет. Иногда открываешь код (допустим когда тестовое при приёме на работу проверяю), а там такие приколы... Интерфейсы и абстракции ради красоты ещё никому лучше не делали. Единственное чего придерживаюсь в плане, что не всегда оно нужно -- в каждом новом проекте создаю интерфейсы IInitializable { Initialize(); } и IConstructable { Construct(T param); } Как раз для решения проблемы с тем, что конструкторы только для инициализации полей. Можно писать по типу new ClassName(инициализируемые поля).Initilize(), а Construct использую для монобехов (awake и start только в бутстрапе или декоративных элементах не влияющих на логику игры). И сразу видно, если с классом после создания, перед выполнением его логики, нужно провести ещё какие-то подготовительные операции. Видео отличное и очень полезное! Спасибо С:
Вообще паттерны и всю эту херобору, вплоть до DI нужно использовать только когда это нужно. Я вообще со временем пришел к выводу что сначала лучше наебошить код в лоб, а уже потом, как только появляется такая необходимость переписать. Ибо эти пресловутые BP без надобности превращают код в кашу из кучи интерфейсов, мелких методов на пол строки и остальных приколюх. Я иногда даже юзаю простой инициализатор вместо Zenject.
@@opodlinok Ну нет, когда ты делаешь прототип как раз в команде самая лучшая стратегия - это фигачить как фигачится: сущностей мало, зависимостей тоже. Это уже когда прототип идет в работу и окончательно ясно чего и сколько будет уже можно писать как по учебнику. А сразу наращивать интерфейсы ради 2-ух с половиной калек - такое себе. Ну и офк, стоит упомянуть что я работают с мобилками в тиме из 4-7 человек.
То есть это просто интерфейсы для учёта инициализируемых классов? Какую это задачу решает? Можно без интерфейсов писать. И в Construct если несколько параметров - не создавать лишний объект. Нет лишнего объекта - не надо лишнего поддерживать. Наверное, если есть Initializable, то есть и Disposable?
@@vector7932 констракт вообще не используется при создании объекта. Это буквально функция для подготовки монобеха без awake/start к работе. Эти интерфейсы решают задачу унифицирования кода - ты, конечно, можешь просто прописывать в каждый класс функцию Initialize со своей логикой и без интерфейса, но смысл если можно одним кликом её реализовать, да и к тому же показать всем, кто работает с этим классом, что его мало просто создать, но и перед работой нужно что-то сделать, с первого взгляда
Лучше вообще выкрутить все ворнинги до ошибок. И отключать их локально или глобально, снабжая осознанным вменяемым комментарием, почему здесь такой код ОК. Тогда, например, и с виртуальным методом в конструкторе (2 ошибка) не накосячить. Еще, кстати, хорошо завести привычку объявлять классы как не наследуемые по умолчанию. Тут и IDE чуть быстрее работать будет, и глазкам сразу видно, что наследников у типа точно нет.
Постоянно тыкаю моих подопечных на проекте в подобные ошибки. Всё это нарабатывается только с опытом. Потом уже просто на автомате действуешь правильно. Советы на самом деле полезные! 👍
1. Это не ошибка, а более фича, что ли удобство. 2. Тоже фича и под конкретную задачу, нет смысла лишний раз делать переменные так-то. 3, 4 и 5 согласен полностью
Секундочку. На 1:50 ты же задаешь луч значением по умолчанию, т.е. он будет сгенерирован при создании объекта. А в апдейте ты рейкастишь всегда один и тот же луч! Некорректный пример же.
С первым интересно , остальные будут более мешать чем кодить . Когда ты хочешь описать механику и за одно думаешь как это лучше прописать ,чтоб на скрипте смотрелся лаконично, это во первых отбивает желание кодить, сбивает с толку, отнимает время, и возможно с большим процентом ты не сможешь выполнить задуманное. Я говорю механиках придуманной из головы (ответ который в инете не нашел), а не шаблонные механики(которые уже прописанны для тебя сотни раз) Вообще проще саздовать второй велосипед и гавнокодить просто надо учесть: Много ифов не добавляйте производительность жрет, говорят кейсом проще или ифелсом пользуйтесь если ра то пошло. P.S. YandereDev Делайте так чтобы коды можно было друг от друга отстыковавать, механики, чтобы по блокам по честям, можно было кодить или даже сносить и менять опрелеленную механику если это захочится
Всё круто, только плз давайте не будем называть это громким словом "архитектура". Это просто вопросы дизайна уровня чуть выше микро. Из-за того, что вот это называют архитектурой, потом на проекте куча архитекторов и ни одного кодера. Все только и делают, что языками чешут.
Я вот разве что первую ошибку совершаю... просто потому что все остальные ошибки я даже не смог бы совершить) Что за интерфейсы, что за виртуальные воиды, каво? Разве что хотел бы спросить Что означает вот это {get, set} после переменной? Возможно это что-то крутое, что мне стоило бы использовать Я только вчера узнал про "=>" и блин, это так удобно
Последняя ошибка не до конца раскрыта) Как назвать метод, в котором будет следующий код "if (IsWinning()) {ShowVictoryWindow(); ShowVictoryParticles(); ... }" ?
Заголовок "5 ошибок в архитектуре". Реальность: переименовываем переменные для лучшей читаемости...
11 місяців тому+1
Интересно узнать. У меня рогалик, уже 10 месяцев в разработке, через месяц финал. Персонаж состоит из кучи стат, айтемы улучшают их. Я реализовал это через Scriptable Object, создал массив где SO инстанциируется и получается новый SO, который при изменении не повлияет на оригинал. К его полям всегда есть доступ через эту датабазу на чтение и запись, они просто публичные. Это плохая реализация? Пока я не сталкивался с проблемами на всём пути разработки и удобно изменял значения, а где они делились или уходили в минус я делал проверки и задавал значение. Типа если МаксХП после айтема
Пока тебе удобно, игра не рушится и ты двигаешь к завершению - реализация хорошая) Но, объективно, я уже не раз говорил, что в SO писать ничего не надо (причина была в одном из видосов с советами по архитектуре как раз). Далее то, что ты молча клэмпишь значения, может быть опасно просто потому что ты даже не поймешь, если у тебя какие-то ошибки будут. В логике могут быть косяки, которые не вылезают при каких-то обстоятельствах, а когда вылезут, сложно будет их найти, т.к. вроде бы все работает частично и непонятно где нарушение может быть. Но, опять таки, если ты там просто при опускании ниже нуля хп их клэмпишь к нулю, то это нормально, ведь урона может нанестись больше чем осталось хп, так что тут все окей, это логично
11 місяців тому
@@-it394 А что за видео по архитектуре? Хотя лучше посмотрю все) В принципе, я тоже самое могу сделать и классами и получать доступ в ним, но это придётся работать больше) Для начала (да и я тогда вообще ничего не знал, а рекомендовали SO очень для стат, но не уточняли что их используют как конфиги) я считаю норм :D Всё равно я был уверен что в будущем буду переписывать всё красиво и нерушимо, насколько это возможно. Часто было такое что враг получал двойной урон, пофиксил временем неуязвимости, которое тоже может быть 0 и меня в принципе устраивает. Меня харило писать сначала SO, добавлять туда новую стату, потом добавлять её же в класс с ними, а ведь игрок должен свои данные засэтить из него, получается третий раз, аналогично с врагами, ибо им один SO не дашь. Вот что реально выстрел в ногу - я не могу таким образом добавить в будущем кооп, ибо всё через SO, а два таких сделать анриал, ибо всё сломается. Не думал что буду делать кооп, а он вписывается вообще. Так что убирать буду, теперь точно :D Спасибо за ответ и видосы
1:24 оочень вредный совет. Зачем нам три раза оди и тот же вектор копировать? И почему-то многие юнитисты в погоне за "чистым кодом" допускают такие ошибки А через пару секунд како-то мракобесие с форматированием в апдейте 2:40 можно просто рассказать про First class collection - очень полезный принцип в целом 4 ошибка - жизааааааааааа. Люди с гиперкежа ооочень любят клепать абстракции, которые вообще не нужны. Люди не умеют итерировать просто и их потом не перучить делать большие фичи в "больших" играх 5 - просто база
а меня например напрягают люди пишущие название полей через _ , считаю это ошибкой - не допускай этого. А если серьезно, в целом по делу тут мало чего, человек который смог написать большой и стабильно работающий проект (в данном случае игру) и с возможностью без проблем его дорабатывать - сделал все правильно. И нет такого понять "Не надо так делать", раз сделал - значит надо было
Делать надо правильно, чтобы другие потом (и ты через год после написания проекта) могли понять что ты сделал. Сейчас работаю сам разработчиком и много приходиться с чужим кодом возиться и ты не представляешь какой гемор пытаться разобраться в том, что написали пару лет назад по принципу "главное работает". Если хочешь это развивать только как хобби, твоё дело, но если хочешь чего-то большего, то по такому принципу будешь в пролете.
@@timothypsina я написал комментарий в окнтексте видео, а из того что сказано в видосе, это никак не вредит легкости и поддержанию проекта. Но громко заявляется как "Ошибка - которую не стоит допусткать"...
Второй пример: не могу понять, почему при создании дочернего класса у нас должна возникнуть ошибка? Ведь в конструкторе базового класса на 9-й строке создается и инициализируется список, а после уже вызывается виртуальный метод, который в этот же список кладет элемент. В каком месте оно должно сломаться на попытке записи в несуществующий список?
Я наверное неудачно сделал нейминг) И в родительском и в дочернем классе свой приватный список, который я назвал и там и там list. Поэтом в дочернем классе мы пишем в свой список, который ещё не проинициплизирован
Нет-нет, по неймингу всё понятно, вопрос немного в другом. В видео говорится, что при создании экземпляра дочки сначала вызывается конструктор родителя. А родитель в своём конструкторе обращается к СВОЕМУ виртуальному методу, в котором идет обращение к СВОЕМУ приватному списку, который уже проинициализирован. А если он проинициализирован, то почему должна возникнуть ошибка? Или виртуальный метод к моменту вызова уже перезаписан дочкой?
И свойствами толком не умею пользоваться (1-я ошибка), и в конструкторы всякую хрень пихаю (2-я ошибка). LINQ не пользуюсь, - как-то не возникало необходимости. 4-я и 5-я вроде ко мне не относятся 😅
Я не давно начал пользоваться unity и у меня всё скрипты в нём без пользования классов и листов , я просто не понимаю для чего они нужны и где их можно применять на практике
насчёт первой ошибки - мне кажется, в основном это только для себя упростит жизнь - в случае чего другому программисту будет только сначала визуально комфортно, но потом на каждое такое нажимать и разбираться что это (а это обычный transform.position) не очень удобно но в принципе если на такие банальные штучки не делать (ну или уж слишком часто оно встречается, то можно)
⚡⚡⚡ Полезные ссылки ⚡⚡⚡
🔎 yakovlevgamedev.ru - курс по архитектуре игр в Unity
🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал (тут розыгрыш и материалы для обучения со всеми полезными ссылками - искать в закрепленном сообщении)
🔎 dzen.ru/b/ZVthaYMiXVQbRmWa - статья про LinQ от Лавки разработчика
🔎 boosty.to/yakovlevgamedev - ссылка на бусти
🔎 ua-cam.com/channels/C-hfECZdghe_QNAJzztHEg.html - ссылка на канал моего младшего брата (подпишись если не сложно)
Кто ничего не пишет, тот не ошибается в коде☝️🧐
Это яндер дев так делает
Ауф
☝️🤓
Как следствие, тот кто пишет хоть что нибудь, заведомо пишет ошибочный код.
@@megammmarisnowflake8623зато миллионы бухает , в отличий от тебя и от меня тоже
Спасибо, за видео! Очень полезная информация!
Мне лень проверять НО, 1:27 идея с заменой на свойство может быть опасна, поскольку Vector3 является структурой и будет создана копия, редактирование которой никак не изменит исходный объект
Так я и не редактирую, а просто обращаюсь. Но, в целом да, замечание верное, за этим надо следить)
Я привык думать о лямбда выражениях такого типа как о сокращениях, или ссылках на что-либо. То есть под капотом свойство Position ничего не хранит. Это просто проводник, который за ручку нас ведет к другому полю или методу. В данном случае к transform.position
Более того, так как структура лишь копирует значение позиции при инициализации, его значение не будет обновляться, и, как следствие, это вообще не будет работать. Vector3 является структорой - это не класс, а значит доступ к нему осуществляется не по ссылке.
Свойства - это просто другая форма (синтетический сахар) вызова get и set методов, со всеми вытекающими. Не всегда происходит инлайн оптимизация, стоит обращать внимание на частоту вызовов, но в рамках игровой логики маловероятно, что где-то будете упираться в производительность.
Насчет запрета исключений в конструкторе - эта проблема из плюсов, на си шарпе просто как правило хорошего тона.
Linq имел проблемы с производительностью во времена четвертого юнити, сейчас там больших проблем нет, и тогда же я не рекомендовал его использовать так как не все понимали его (редко использовался), что тормозило задачи. Сейчас с этим проблем нет, в клиент-серверном это стандарт, а следить за выделением памяти так и так придется, всегда можно поправить.
Не синтетический, а синтаксический)
Касательно второй ошибки:
Как метод назовёшь, так его и будут использовать, назови нормально и переопределять не будут, но в целом практика действительно хорошая, абстрактные и виртуальные поля лучше не вызывать в конструкторах. Что касается ошибок в конструкторе, для такого лучше использовать статический метод Create, что тоже частично нарушает паттерны, но лучше ошибок в конструкторе. Есть ещё предложение создавать методы Init и подобные, чтобы этот метод вызывали при необходимости, и вот он может выкидывать ошибки, а конструктор пусть будет.
Касательно 4-ой ошибки:
Не считаю это ошибкой, ведь ты сам объяснил, почему это хорошо, иногда это рудимент. Хотя конечно лучше задуматься над тем, где какие интерфейсы нужны, а где они бесполезны. И если мы говорим про предметы, которые можно собирать, лучше сделать интерфейс типа IStorable, если есть предметы, которые можно со стакать, можно назвать ICollectable. В целом согласен с твоим тезисом.
Великолепный материал. 😅Все больше хочется купить курс. Но пока что на работе запара, осваиваю серверную часть для игры.
А на чем сервер? На сокетах?
@@FloatingGamesКурс кстати купил, скоро начнутся занятия. А что насчет вопроса, сам сервак на Ubuntu хостится, само собой использую Docker контейнер. Серверная логика игры на NakamaServer + TypeScript. Клиент очевидно Unity + C# ;3
@@RimuruDev я впервые такое слышу, у меня сервер на windows + c#, а зачем используют docker? Просто сколько не спрашивал у всех невменяемый ответ
@@FloatingGames Странно что у “всех” невменяемый ответ :3
Тогда постараюсь сказать в двух словах и максимально просто.
Докер помогает "упаковать" приложение со всеми его настройками и зависимостями, чтобы оно могло легко и одинаково работать на любом компьютере или сервере. Это существенно упрощает развертывание и управление приложениями, делая разработку более гибкой и эффективной.
Допустим теперь понятно вкратце чем хорош докер. Но теперь вы подумали “нафига оно мне???”.
Без Докера: Если вы разрабатываете на Windows с C# (судя по комментарию), ваше приложение может не работать или работать по-разному на других системах (например, Linux), из-за различий в настройках и зависимостях.
Если даже после этого ничего не понятно, то лучше глянуть отдельно материалы о том для чего нужен докер и чем он полезен. Так как я плохо объясняю :3
@@RimuruDev а вообще на Линукс можно скомпилировать c# проект, просто мы пытались это сделать но никак не получилось
Эти советы полезны в любом проекте, а не только при разработке игр.
Не советую удалять абстракцию "сделанную для красоты", если планируете в будущем систему модификации игры, иначе придётся дофига всего переписывать...
Последний совет про то, как лучше заменить Check - очень кстати, спасибо) Давно была мысль как-то симпатичнее организовывать этот момент.
Про отказ от бессмысленных переусложнений -- лучший совет. Иногда открываешь код (допустим когда тестовое при приёме на работу проверяю), а там такие приколы... Интерфейсы и абстракции ради красоты ещё никому лучше не делали.
Единственное чего придерживаюсь в плане, что не всегда оно нужно -- в каждом новом проекте создаю интерфейсы
IInitializable { Initialize(); } и
IConstructable { Construct(T param); }
Как раз для решения проблемы с тем, что конструкторы только для инициализации полей. Можно писать по типу new ClassName(инициализируемые поля).Initilize(), а Construct использую для монобехов (awake и start только в бутстрапе или декоративных элементах не влияющих на логику игры).
И сразу видно, если с классом после создания, перед выполнением его логики, нужно провести ещё какие-то подготовительные операции.
Видео отличное и очень полезное! Спасибо С:
Вообще паттерны и всю эту херобору, вплоть до DI нужно использовать только когда это нужно. Я вообще со временем пришел к выводу что сначала лучше наебошить код в лоб, а уже потом, как только появляется такая необходимость переписать. Ибо эти пресловутые BP без надобности превращают код в кашу из кучи интерфейсов, мелких методов на пол строки и остальных приколюх. Я иногда даже юзаю простой инициализатор вместо Zenject.
@@_Otets_ это если ты работаешь соло или не в коммерческой разработке и твоим кодом не будут заниматься другие люди
@@opodlinok Ну нет, когда ты делаешь прототип как раз в команде самая лучшая стратегия - это фигачить как фигачится: сущностей мало, зависимостей тоже. Это уже когда прототип идет в работу и окончательно ясно чего и сколько будет уже можно писать как по учебнику. А сразу наращивать интерфейсы ради 2-ух с половиной калек - такое себе. Ну и офк, стоит упомянуть что я работают с мобилками в тиме из 4-7 человек.
То есть это просто интерфейсы для учёта инициализируемых классов? Какую это задачу решает? Можно без интерфейсов писать. И в Construct если несколько параметров - не создавать лишний объект. Нет лишнего объекта - не надо лишнего поддерживать.
Наверное, если есть Initializable, то есть и Disposable?
@@vector7932 констракт вообще не используется при создании объекта. Это буквально функция для подготовки монобеха без awake/start к работе.
Эти интерфейсы решают задачу унифицирования кода - ты, конечно, можешь просто прописывать в каждый класс функцию Initialize со своей логикой и без интерфейса, но смысл если можно одним кликом её реализовать, да и к тому же показать всем, кто работает с этим классом, что его мало просто создать, но и перед работой нужно что-то сделать, с первого взгляда
Лучше вообще выкрутить все ворнинги до ошибок. И отключать их локально или глобально, снабжая осознанным вменяемым комментарием, почему здесь такой код ОК.
Тогда, например, и с виртуальным методом в конструкторе (2 ошибка) не накосячить.
Еще, кстати, хорошо завести привычку объявлять классы как не наследуемые по умолчанию. Тут и IDE чуть быстрее работать будет, и глазкам сразу видно, что наследников у типа точно нет.
Типа sealed?
@@FloatingGames угу
Постоянно тыкаю моих подопечных на проекте в подобные ошибки. Всё это нарабатывается только с опытом. Потом уже просто на автомате действуешь правильно. Советы на самом деле полезные! 👍
Весьма полезные советы даже для тех, кто не один год работает прогером. Лойс.
Мне понравился ролик про ошибки 👍. У меня с усложнением кода всегда проблема была, надеюсь исправлю. Я бы хотел вторую часть 😅
1. Это не ошибка, а более фича, что ли удобство.
2. Тоже фича и под конкретную задачу, нет смысла лишний раз делать переменные так-то.
3, 4 и 5 согласен полностью
Очень познавательно, требую еще)
нашёл 2 метода с check в начале, убирать не буду, мой код - мои правила ))
🤘🤘🤘
Секундочку. На 1:50 ты же задаешь луч значением по умолчанию, т.е. он будет сгенерирован при создании объекта. А в апдейте ты рейкастишь всегда один и тот же луч! Некорректный пример же.
Видео не соответствует своей теме. В нём вовсе нет ничего про архитектуру, зато есть короткий список из ошибок новичков в языке С#
С первым интересно , остальные будут более мешать чем кодить . Когда ты хочешь описать механику и за одно думаешь как это лучше прописать ,чтоб на скрипте смотрелся лаконично, это во первых отбивает желание кодить, сбивает с толку, отнимает время, и возможно с большим процентом ты не сможешь выполнить задуманное.
Я говорю механиках придуманной из головы (ответ который в инете не нашел), а не шаблонные механики(которые уже прописанны для тебя сотни раз)
Вообще проще саздовать второй велосипед и гавнокодить просто надо учесть:
Много ифов не добавляйте производительность жрет, говорят кейсом проще или ифелсом пользуйтесь если ра то пошло. P.S. YandereDev
Делайте так чтобы коды можно было друг от друга отстыковавать, механики, чтобы по блокам по честям, можно было кодить или даже сносить и менять опрелеленную механику если это захочится
Архитектура слишком сильное слово для таких ошибок уровня "первый раз открыл юнити"
По логике чем выше уровень программиста, чем меньше он ошибок совершает. Так что вряд ли существует понятие "ошибки профессионалов"
Всё круто, только плз давайте не будем называть это громким словом "архитектура". Это просто вопросы дизайна уровня чуть выше микро. Из-за того, что вот это называют архитектурой, потом на проекте куча архитекторов и ни одного кодера. Все только и делают, что языками чешут.
Ошибка номер 0: пихать лямба выражения в каждую строчку, что бы побольше в код насрать.
4 ошибка топ. Сам этим страдаю. Правдивая до жути
Я вот разве что первую ошибку совершаю... просто потому что все остальные ошибки я даже не смог бы совершить) Что за интерфейсы, что за виртуальные воиды, каво?
Разве что хотел бы спросить
Что означает вот это {get, set} после переменной? Возможно это что-то крутое, что мне стоило бы использовать
Я только вчера узнал про "=>" и блин, это так удобно
Последняя ошибка не до конца раскрыта)
Как назвать метод, в котором будет следующий код "if (IsWinning()) {ShowVictoryWindow(); ShowVictoryParticles(); ... }" ?
Все виконано на принципі чистого коду по суті, який архітектуру гри сповільнить як і всі інші аспекти коду.
Заголовок "5 ошибок в архитектуре".
Реальность: переименовываем переменные для лучшей читаемости...
Интересно узнать.
У меня рогалик, уже 10 месяцев в разработке, через месяц финал.
Персонаж состоит из кучи стат, айтемы улучшают их. Я реализовал это через Scriptable Object, создал массив где SO инстанциируется и получается новый SO, который при изменении не повлияет на оригинал. К его полям всегда есть доступ через эту датабазу на чтение и запись, они просто публичные.
Это плохая реализация?
Пока я не сталкивался с проблемами на всём пути разработки и удобно изменял значения, а где они делились или уходили в минус я делал проверки и задавал значение.
Типа если МаксХП после айтема
Пока тебе удобно, игра не рушится и ты двигаешь к завершению - реализация хорошая)
Но, объективно, я уже не раз говорил, что в SO писать ничего не надо (причина была в одном из видосов с советами по архитектуре как раз).
Далее то, что ты молча клэмпишь значения, может быть опасно просто потому что ты даже не поймешь, если у тебя какие-то ошибки будут. В логике могут быть косяки, которые не вылезают при каких-то обстоятельствах, а когда вылезут, сложно будет их найти, т.к. вроде бы все работает частично и непонятно где нарушение может быть. Но, опять таки, если ты там просто при опускании ниже нуля хп их клэмпишь к нулю, то это нормально, ведь урона может нанестись больше чем осталось хп, так что тут все окей, это логично
@@-it394 А что за видео по архитектуре? Хотя лучше посмотрю все)
В принципе, я тоже самое могу сделать и классами и получать доступ в ним, но это придётся работать больше)
Для начала (да и я тогда вообще ничего не знал, а рекомендовали SO очень для стат, но не уточняли что их используют как конфиги) я считаю норм :D Всё равно я был уверен что в будущем буду переписывать всё красиво и нерушимо, насколько это возможно.
Часто было такое что враг получал двойной урон, пофиксил временем неуязвимости, которое тоже может быть 0 и меня в принципе устраивает.
Меня харило писать сначала SO, добавлять туда новую стату, потом добавлять её же в класс с ними, а ведь игрок должен свои данные засэтить из него, получается третий раз, аналогично с врагами, ибо им один SO не дашь.
Вот что реально выстрел в ногу - я не могу таким образом добавить в будущем кооп, ибо всё через SO, а два таких сделать анриал, ибо всё сломается. Не думал что буду делать кооп, а он вписывается вообще.
Так что убирать буду, теперь точно :D
Спасибо за ответ и видосы
@разве so создавался для того чтобы записывать в него данные?
Я почти мегамозг )
Спасибо за видео
Прикольное видео наверно, жаль что я пока что далёк от понимания этого)..
1:24 оочень вредный совет. Зачем нам три раза оди и тот же вектор копировать? И почему-то многие юнитисты в погоне за "чистым кодом" допускают такие ошибки
А через пару секунд како-то мракобесие с форматированием в апдейте
2:40 можно просто рассказать про First class collection - очень полезный принцип в целом
4 ошибка - жизааааааааааа. Люди с гиперкежа ооочень любят клепать абстракции, которые вообще не нужны. Люди не умеют итерировать просто и их потом не перучить делать большие фичи в "больших" играх
5 - просто база
Абстракции для красоты( Нашел парочку
а меня например напрягают люди пишущие название полей через _ , считаю это ошибкой - не допускай этого. А если серьезно, в целом по делу тут мало чего, человек который смог написать большой и стабильно работающий проект (в данном случае игру) и с возможностью без проблем его дорабатывать - сделал все правильно. И нет такого понять "Не надо так делать", раз сделал - значит надо было
Делать надо правильно, чтобы другие потом (и ты через год после написания проекта) могли понять что ты сделал. Сейчас работаю сам разработчиком и много приходиться с чужим кодом возиться и ты не представляешь какой гемор пытаться разобраться в том, что написали пару лет назад по принципу "главное работает". Если хочешь это развивать только как хобби, твоё дело, но если хочешь чего-то большего, то по такому принципу будешь в пролете.
@@timothypsina я написал комментарий в окнтексте видео, а из того что сказано в видосе, это никак не вредит легкости и поддержанию проекта. Но громко заявляется как "Ошибка - которую не стоит допусткать"...
Второй пример: не могу понять, почему при создании дочернего класса у нас должна возникнуть ошибка? Ведь в конструкторе базового класса на 9-й строке создается и инициализируется список, а после уже вызывается виртуальный метод, который в этот же список кладет элемент. В каком месте оно должно сломаться на попытке записи в несуществующий список?
Я наверное неудачно сделал нейминг) И в родительском и в дочернем классе свой приватный список, который я назвал и там и там list. Поэтом в дочернем классе мы пишем в свой список, который ещё не проинициплизирован
Нет-нет, по неймингу всё понятно, вопрос немного в другом. В видео говорится, что при создании экземпляра дочки сначала вызывается конструктор родителя. А родитель в своём конструкторе обращается к СВОЕМУ виртуальному методу, в котором идет обращение к СВОЕМУ приватному списку, который уже проинициализирован. А если он проинициализирован, то почему должна возникнуть ошибка? Или виртуальный метод к моменту вызова уже перезаписан дочкой?
Уже перезаписан (сначала вызывается дочерний метод, потом через base. родительский)@@alsg00
Видео интересное, но от Чaracter ушкам больно
И свойствами толком не умею пользоваться (1-я ошибка), и в конструкторы всякую хрень пихаю (2-я ошибка). LINQ не пользуюсь, - как-то не возникало необходимости. 4-я и 5-я вроде ко мне не относятся 😅
Почитай начало статьи от Grammarly под названием Declarative Programming in .NET.
5:26 в конструкторе базового класса уже создаётся лист, о чём речь вообще?
Я не давно начал пользоваться unity и у меня всё скрипты в нём без пользования классов и листов , я просто не понимаю для чего они нужны и где их можно применять на практике
Тогда лучше будет сначала изучить теорию, говорю как разработчик 3года и особо ничего не знающий, буду после этой сессии жёстко учиться
без нормального кода, что-то сложнее раннера ничего не напишется
а что вот этот значок делает => почему нельзя просто = поставить
?
Это лямбда выражения
metanit.com/sharp/tutorial/3.16.php - вот тут можешь почитать)
Честно, понял меньше половины... Пойду книжки читать... Опять...
вкусовщина
Протектед же имеет те же уязвимости что и публичный уровень доступа?
Можно по подробнее к чему этот вопрос?)
Protected является рекомендацией по правилу SOLID "открыт к расширению, но закрыт к изменению", так этот модификатор доступа и работает.
спасибо
Хорошо, теперь куда выкладывать игры во время санкций в России?
насчёт первой ошибки - мне кажется, в основном это только для себя упростит жизнь - в случае чего другому программисту будет только сначала визуально комфортно, но потом на каждое такое нажимать и разбираться что это (а это обычный transform.position) не очень удобно
но в принципе если на такие банальные штучки не делать (ну или уж слишком часто оно встречается, то можно)
Это довольно простой пример, но если адекватно называть все и убирать что- то длинное в свойства, то жизнь упрощается всем)
Ты еще не забывай что такое свойство- это и кеширование.
Я бы сказал, что лучше это не в ствойства делать, а в переменные в методе кидать, если часто вызывается, лучше создать приватный метод GetSth
Потом юзинги по проекту собирать, ну уж нет)
Причем тут архитектура?))
Кек, ничего из этого не допускал хД
Можно я кота-яковлева в игру добавлю?)
Не знаю что за игра, но звучит забавно😂
@@-it394 , потом на скриншот сатурдей покажу
Кликнул из-за юнити, но тут базис по шарпу
полезный видос
Здравствуй, не интересна ли тебе идея снять ролик по кривым?
Чарактер. Ясно понятно. Зовите следующего...
Ваще нихуя не понял
Можно про ошибки в коде у новичков
за такие Awake методы надо руки отбивать
В плане?