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

📝Всем шарп! Сегодня я расскажу вам о 5 частых ошибках, которые мешают улучшать архитектуру твоей игры. Такие ошибки допускают многие и важно проработать их, чтобы избавиться от переусложненного кода, лишних багов и неразборчивой архитектуры. Разберем простые советы, которые в разы прокачают тебя как разработчика! Если ты увидел себя в каких-то из ошибок, то пиши в комментариях, будет интересно услышать твое мнение по этому поводу. А также не забывайте ставить лайки и подписываться, если хотите, чтобы я по быстрее выпустил следующую часть!) Приятного просмотра:)

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

🕒Тайм-коды:
➜ 00:00 - Вступление
➜ 00:31 - 1 ошибка
➜ 03:13 - НОВОГОДНИЕ ПОДАРКИ
➜ 04:17 - 2 ошибка
➜ 06:28 - 3 ошибка
➜ 07:25 - 4 ошибка
➜ 08:59 - 5 ошибка
➜ 10:51 - Заключение:)

🔥🔥🔥 На этом канале вы найдете множество уроков по Unity и C#, а так же различных видео на тему разработки игр, так что не стесняйтесь, заглядывайте на канал и вы обязательно найдете что-то по душе!🔥🔥🔥

#Unity#ЯковлевИлья#архитектура#architecture

[flexmachine]

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

[hordorsok]

Спасибо, за видео! Очень полезная информация! <3 С неймингом все время проблема, хотелось бы отдельный эпизод про это)

[tugoshow]

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

[petrpal]

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

[MrYuriyP]

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

[xxwsqkv]

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

[mqzpiqg]

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

[RimuruDev]

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

[argon]

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

[inijcsz]

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

[volodya]

Касательно второй ошибки:
Как метод назовёшь, так его и будут использовать, назови нормально и переопределять не будут, но в целом практика действительно хорошая, абстрактные и виртуальные поля лучше не вызывать в конструкторах. Что касается ошибок в конструкторе, для такого лучше использовать статический метод Create, что тоже частично нарушает паттерны, но лучше ошибок в конструкторе. Есть ещё предложение создавать методы Init и подобные, чтобы этот метод вызывали при необходимости, и вот он может выкидывать ошибки, а конструктор пусть будет.

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

[xpoftik]

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

[mrgates]

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

[skalse]

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

Интересно узнать.

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

Это плохая реализация?
Пока я не сталкивался с проблемами на всём пути разработки и удобно изменял значения, а где они делились или уходили в минус я делал проверки и задавал значение.
Типа если МаксХП после айтема <= 0 то оно возвращается на 1, а дальше обновлялся UI. UI я как раз сделал таким что там никогда ошибки не прилетали, помнится тоже благодаря тебе.

Какие могут быть негативные аспекты подобного решения?

[holo]

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

[opodlinok]

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

Единственное чего придерживаюсь в плане, что не всегда оно нужно -- в каждом новом проекте создаю интерфейсы
IInitializable { Initialize(); } и
IConstructable<T> { Construct(T param); }

Как раз для решения проблемы с тем, что конструкторы только для инициализации полей. Можно писать по типу new ClassName(инициализируемые поля).Initilize(), а Construct использую для монобехов (awake и start только в бутстрапе или декоративных элементах не влияющих на логику игры).

И сразу видно, если с классом после создания, перед выполнением его логики, нужно провести ещё какие-то подготовительные операции.

Видео отличное и очень полезное! Спасибо С:

[craftgameworld]

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

[questprom]

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

[jxlizbh]

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