3 ОШИБКИ В АРХИТЕКТУРЕ ТВОЕЙ ИГРЫ! C# и Unity! Советы для улучшения архитектуры

[@-it394]

⚡⚡⚡ Полезные ссылки ⚡⚡⚡ 🔎 yakovlevgamedev.ru/unity_adventure - обучение разработке игр с нуля до создания полноценного проекта 🔎 t.me/yakovlev_advanced_bot - бот для регистрации на вебинар (подарок тут же)

[@TWITexe]

признаюсь честно, я удивлен качеством информации и подачей. Это один из лучших каналов по Unity, продолжай в том же духе!

[@STIGRADOR]

Занимаюсь разработкой около четырех лет. Могу смело заявить, что автор лучший из всех на ютубе в своем направлении. Нет никаких глупостей и базу дает очень правильно и верно. Лавка Разработчика и Яковлев Илья - это то, что вам нужно для понимания разработки на юнити. Илья, продолжай плиз в том же духе! Даже я иногда нахожу очень полезные вещи в твоих видосах!

[@Tera-h7e]

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

[@lev431]

Лавка разработчика больше немного для продвинутых, чтоб закрепить какой то материал по новой теме и может узнать какие то подробности где ты не узнал в прошлом источнике информации​@@Tera-h7e

[@STIGRADOR]

​​@@Tera-h7e В части лавки разработчика поясню - там канал, который направлен уже на продвинутых типов. Предполагается, что зритель уже хорошенько прошарен и понимает базовые принципы основных паттернов и архитектуры. В пояснение к стилистики добавлю - я так понимаю ты смотрел старые видосы, где он постоянно "this" лепил. Мы его за это зисменом прозвали с ребятами знакомыми, но исключительно любя :)

[@Tera-h7e]

@@STIGRADOR это понятно, но насчёт "продвинутых" это неверно. Какие продвинутые? Он базовую базу рассказывает, слишком поверхностно да и к тому же нормально объяснить не может, примеры плохие показывает. Я сразу понял что либо он сам не знает темы либо обучать не умеет. Например тема про евенты, он рассказал как они вызываются и всё, а зачем это нужно и как работает это под капотом - нет. Не рассказал про делегаты и взаимодействие с ними, например, GetInvList, DynamicInvoke, что такое просто Invoke, а просто сказать: "Ну типа так вызывается событие и тд". А как же про то, как подписаться? Нужна ссылка на объект, но это нарушает 1 и 5 принципы SOLID, другой класс должен отвечать только за свою работу и не знать о других объектах, а так же твой класс должен зависеть от абстракции (5 принцип), т.е. прокинуть в него зависимость в конструктор или в сеттер, например, сделать интерфейс только с событием и текущем значением IHealthNotifier, в котором будет описано событие изменения здоровья и текущее здоровье с помощью свойства гет, и с помощью этого интерфейса мы можем работать с любым объектом, который реализует его для того, чтобы не нарушать эти принципы SOLID. Я бы ещё написал много всего об этом и о другом, ну мне кажется что итак много.

[@myownchannellol]

Занимаюсь разработкой 8 лет. Лавка Разработчика - очень плохой пример. Сам не понимает тот материал, который пытается на аудиторию раскатать.

[@darkcitizen]

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

[@ilteeeee]

этому каналу точно есть место в зале легендарных каналов по юнити

[@vomiann6770]

Жду новое видео на тему АСИНХРОННОСЬ В UNITY!

[@ivan-_-8577]

Кажется что твоя мечта сбылась

[@giogall6229]

Очень крутой выпуск! Всё понятно, и, главное, приятно слушать.

[@VISHNEVSKY69]

Бро, теперь жду видосик про архитектуру игр для поддержки моддинга

[@AntonGorbachevDev]

Плюсую, очень интересная тема

[@divizitin4462]

Отличное видео бро, как и предыдущее и все предыдущие. Жду следующие.

[@Екатерина-о5л3ч]

Советы реально классные, ждем еще :)

[@Slayser_so2]

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

[@kruservinsar1075]

Попробуй все текстуры под dxt формат сделать, у меня так 35 мб при билде убралось

[@bonbad612]

Глянь статью на хабре от Дядиченко, должна помочь

[@pressF-d9j]

Смотрю на это и думаю как же хорошо что я начинал с js. Взял оболочку от tauri юзаещь библиотеки thre js для реакта и кайфуешь - теперь проблема только в нужных 3д моделях - подучив блендер могу делать только примитивную геометрию - стены, полы, двери, щас смотрю видосы китайцев как они делают 3д модели - это прям искуство

[@evgeniy_a7363]

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

[@andrewalexart]

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

[@_gonga]

Ждем гайдики по облочкам :D

[@ivan-_-8577]

Привет от анрильщика-крестовика который пробует своими кривыми лапками нормальный движок. Отличный канал.

[@stingerfingerr1599]

Отличное видео бро, как и все остальные на твоем канале

[@deniskarter7088]

Всё отлично! Благодарю за полезное видео :) Пока только переживаю за цену курса :D

[@Veles017]

Отличные рекомендации!

[@АнатолийКарпенко-п9ъ]

просто оставлю это тут для продвижения видео)

[@SleepyRaccoon-k]

Спасибо за видео! =)

[@nuclear-decline]

Добрый день. Спасибо за видео. Очень помогла идея с Bootstrap. Возник вопрос. У меня есть машина состояний, которая управляет состоянием игры (загрузка игры, главное меню, сама игра, окончание игры и т. п). Каждое состояние выполняет какие-либо действия с обьектами на сцене, например включает нужные панельки. Стейт не наследуется от монобеха и не висит на обьекте на сцене. Как в таком случае прокинуть в стейт нужные ссылки? Только через FindObjectsByType?

[@ДмитрийМатюшенко-т2э]

Есть видео на эту тему на канале Code Craft: Unity Edition, называется "Игровой цикл на Zenject", так что если с Zenject'ом дружишь, то можешь оттуда идею взять

[@Filimon_enc]

надеюсь в будущем будет по Unity Dots урок)

[@-it394]

С dots не работал, но по leoEcs или entitas вполне возможно контент подъедет в следующем году)

[@urod7149]

Хочу еще одно такое видео (только с другими ошибками)

[@TheFenix717]

Спасибо за урок! 8:04 на 12 строке зачем нужен return??

[@ВикторВорогушин-з4й]

В данном случае скорее просто признак хорошего кода А в других случаях чтобы при вызове извне получать сразу игрока или что-то что создалось

[@bad_tutor_Nik]

Привет! Этот метод должен возвращать нам MainCharacter, поэтому мы его и возвращаем :)

[@Olavr_UA]

Метод возвращает Героя, который заспавнился, то есть, можна из другого скрипта дать значение героя который был заспавнен только что, по факту это метод который отсылает на метод спавна но при этом в нем можно добавить некие стартовые методы.

[@mr.nobody4152]

Так автор же создаёт врагов вокруг игрока и вообще передаёт ссылку на трансформ, чтобы они перемещались к игроку.

[@tomasgonsales483]

Вовремя ролик я глянул) Я токо кумекал как бы по уму отвязать настройки уровня от сущностей. Спасибо)

[@Fessoid]

Создаю игру с заделом на модостроение игроками. Какую архитектуру посоветуешь? Видел такую: в папке Mods всё, что лежит - заменяет намтройки оригинала. Помню в Warhammer 40k таким образом заменил 1 lua-файл и хаоситы начали жечь фиолетовым огнём.

[@serafimr.3648]

А для более крупных проектов, как используется bootstrap? Создаётся bootstrap с bootstrap'ами?

[@-it394]

В целом что-то в таком духе. Суть остается та же, что надо контролировать как старт всего приложения, так и каждой отдельной сцены/контекста

[@Tera-h7e]

​@@-it394Да, по сути та же EntryPoint

[@tortik22]

А есть видео по работе с облаком или адресаблами чтобы хранить там хотябы те же конфиги?

[@-it394]

В планах на следующий год:)

[@tortik22]

​@@-it394 у адресаблов есть баг или фича, что при работе с теми же самыми скриптбл объектами, что они создают разные копии этих so :) Допустим если записать чето в скриптбл на сцене которая в билде и попробовать прочитать этот скриптбл в адресбл сцене, то там не будет этих изменений :) Возможно не так выразился, но думаю понятно, что нет обратной совместимости или что-то типа того

[@-it394]

@@tortik22 С таким не сталкивался, т.к. настройки какие-то никогда в сценах не держали (мне кажется в целом таких ситуаций не должно быть). Т.е. отдельно настройки - отдельно сцены

[@tortik22]

​@@-it394 Например в стартовой сцене авторизуется игрок и какие-то данные профиля записывались в so. Потом в игре оттуда брались при необходимости в разных сценах. В итоге где-то использовали статику где то so. В целом адресеблы глючная технология. При билде могут тупо выдаваться ошибки и пакеты не грузятся, при повторном билде ничего не меняя все работает хорошо. Еще несколько проблем было сейчас и не вспомнить

[@Maymazl]

не лучше было бы использовать "addressables" для загрузки сцен !? Ведь в показанном подходе она и так всё хранить в оперативке.

[@hpr895]

01:11 - диздок Алайфа 2.0

[@nathankoteev6355]

Никто не понял отсылки

[@arturkadirov9280]

Делаю игру в Годо. Но смотрю Яковлева, потому что много базы. В Годо пока базированных блогеров мало.

[@ДмитрийМатюшенко-т2э]

Не очень понятно в 3 совете как разбить конфиг, то есть префаб и позицию спавна раздельно? А как тогда связать определенный префаб с определенными данными, например, есть куча файликов с разными конфигами от ScriptableObject, и как тогда к каждому из них подвязать свой префаб?

[@-it394]

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

[@_meyko_]

Очень круто

[@Mister_14438]

А можно такое видео,но про архитектуру в годот?

[@fear_ctpax]

Это больше канал по Unity, но там на что на Gdscript, что на C# работают идентичные правила. Например я делаю так: сделай сцену "GameRoot, в которую вложи Bootstrap (должен быть выше всех, чтобы запустилс первым), что запускает менеджер состояния игры (пауза, в игре, загрузка, главное меню итд). Он в свою очередь использует разные отдельные сервисы (например сервис сохранения, спавна уровня). Сервисы получает через сервис-локатор. Причём ничего из вышеперечисленного, кроме BootstrapА не наследовать от (Node/MonoBehavour). Это один из вариантов, он спокойно применим к годо, хотя его я узнал из курса по Unity.

[@-it394]

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

[@alfarabius]

Зачем нам PlayerSpawner, а не Player на сцене? Если для респавна игрока, то все равно всем врагам нужно прописывать логику, что делать когда Player исчез со сцены. А если у них есть логика действий на отсутствие, появление и присутствие Player, то порядок инициализации не будет вызывать ошибок.

[@tanksdefense]

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

[@oneprogofficial]

Для мультиплеера, например

[@-it394]

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

[@alfarabius]

@@tanksdefense так буквально, если мы врагу пропишем логику на отсутствие игрока, то он отлично будет себя чувствовать в вакууме и порядок появления будет неважен.

[@argotroll8811]

Я конечно все понимаю, но делать пример где ты выносишь в so точку спауна персонажа как vector3 и говоришь что это удобно. Это прям ад.

[@-it394]

ну камон)) Ты же не хочешь точку спавна как трансформ хранить? Просто как это удобно настраивать в конфигах другой вопрос. Либо пишешь тулзу, чтобы подтягивать со сцены нужные данные, либо вообще тебе эти данные будут приходить json'ом с сервера (и про какой вообще трансформ речь идет тогда?). Просто в таком случае можно докопаться до того, что префабы лежат прямо в конфиге (что в целом может пол проекта за собой потащить) - их тоже лучше отдельно подгружать по ключам. Тут основной посыл был в том, что надо отделять настройки необходимые для объектов (опять же не всегда - я это тоже упомянул), что дает больше гибкости в плане менеджмента. Просто в 15 минут всего не уместишь

[@argotroll8811]

@-it394 а нахрена ее хранить где-то кроме сцены? Спавнеры всю жизнь на сцене расставляли их никто в здравом уме не будет переносить координатами. Про помыл уж более реалистичными были бы параметры персонажа. С ними все понятно и как их в таблицы на облоко кидать и как гейм дизайнерам не лазить по префабам. Но точку спавна они 1 хрен будут руками на сцене двигать и это норма.

[@Tera-h7e]

​@@argotroll8811отвечу на твой вопрос. Монобехи - это зло, точка.

[@belxsi]

Ну база че

[@Сэр-Коффе]

ни о чем, 2 совет по сути для разработки большого проекта, в это видео заходят кубики 1 совет все и так знают, рассказал бы лучше и больше про ассинхронщину, ООП ипро сущности

[@krivodeling7925]

+++

[@denisshevchenko7397]

Ошибки 1 - Использовать Zenject и прочее дерьмо мамонта 2 - Перебор и использованием интерфейсов, вместо DamageHandler использовать IDamagable и т.д 3 - Сильная связанность. Пытайтесь делать большие системы как можно более независимыми и модульными, идеально когда систему пришите отдельно и потом просто внедряете ее 4- Перегибать палку не стоит, и найти компромисс между качеством и скоростью разработки

[@volodyaDikiy]

Молодец, а теперь поясни почему 1 и 2 пункт являются ошибками

[@yedil-sama5851]

@@volodyaDikiy для новичков, она, наверное, имеет введу.

[@имяможноменять]

​@@volodyaDikiy зенжект/экстенжект тянет вместе с di контейнером посторонний функционал (ивент бас, насколько я помню), что порождает излишнюю зависимость от зенжекта для проекта; потворствует дурным практикам (например, ZenAutoInjecter) и в целом раздутый. Если нужен di в юнити, то уж лучше будет взять более быстрый и минималистичный vcontainer, с которым, тоже при особом желании можно будет выстрелить себе в ногу, но это будет уже немного сложнее.

[@heavyviolence9280]

@@volodyaDikiy Zenject старый, медленный и не обновляется. Лучше VContainer. Он быстрее на порядок, обновления выходят регулярно, да и просто структура API там приятнее как по мне.

[@denisshevchenko7397]

@@volodyaDikiy 1) - мода на Zenject прошла, он слишком "перегруженный" и старый, его функционал не используют на полную(DI можно самому реализовать или использовать уже готовые маленькие решения). Если в вакансии он есть, значит это древнущий легаси проект 2) Если у тебя автоатака и к примеру урон наносится всем врагам в радиусе с IDamagable, если враг уничтожен IDamagable будет все равно находится в списке и тебе нужно либо маппинг к какому то монобеху делать(условно есть Enemy скрипт), либо вводить bool в интерфейс, что бы проверять должен ли он быть на сцене либо нет и потом все это вручную проверять и очищать , и еще ест кучка проблем которая может возникнуть. IDamagable это как раз самый яркий пример, когда интерфейс не к месту использован

[@alexsklyarov6792]

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