#пилимигру

[@grootkroot22]

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

[@МихаилЗайлогин]

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

[@whatareulookingat235]

Как всегда полезно! Хотелось бы также увидеть UI и Settings Menu в частности. Хотелось быть уточнить, в текущем подходе - настройки будут инициализироваться в GameEntryPoint? То есть достаём прокси настроек и сетим значения к примеру в аудио микшер.

[@gamedevlavka]

@@whatareulookingat235 скорее нужен какой-то биндер для настроек, который да цепляется на прокси и перекидывает значения в микшер, как только они обновляются

[@Magic__Man]

Круто! Смотрим!

[@AleksandrSknarin]

Кстати интересно как прикручивается логика MVVM если например я хочу использовать юнитевскую физику? Чем в данном случае будет физика - модель (потому что непосредственно влияет на логику) или вью (потому что юнити+монобех)?

[@gamedevlavka]

@@AleksandrSknarin физика как таковая не влияет на логику, влияет результат обработки физики. И этот результат обработки можно интерпретировать, как инпут. Персонаж наступил на монетку, коллайдеры пересеклись, сигнал полетел в модель "давай, добавляй монетку". Тоже самое можно представить в виде консольного приложения: пользователь пишет "я наступил на монетку", сигнал идёт в модель: "добавить монетку"

[@grootkroot22]

Допустим у меня есть скрипт с монобехом и публичным методом Initialization(SomeSystem someSystem), как мне в него передать эту систему, допустим в геймплейной сцене? У меня в голове только это: сделать сереализуемое поле в геймплейной точке входа, пробросить через инспектор и вызвать метод инитиалищации в этой точке входа. Как лучше сделать?

[@gamedevlavka]

Все правильно думаешь. Вся инициализация - через точку входа, где ты увидишь, как и из чего состоит сцена. Но есть один нюанс. Очень похоже на MVVM, только тогда скрипт с монобехом будет что-то вроде MyObjectBinder : Monobehaviour, система будет вьюмоделью MyObjectViewModel. И метод называться Bind(MyObjectViewModel viewModel) В случае MVVM ты можешь прокидывать зависимости в глубину. Условно у тебя есть некий WorldRootBinder - что является корневым баиндером, который и кидается в поле EntryPoint, как ты и написал. Но может быть внутри WorldRootBinder есть како-нибудь CharactersBinder, а внутри CharacterBinder - SomeSpecificCharacterBinder. И тогда зависимости спускаются соответственно через WorldViewModel дальше CharactersViewModel, дальше в SomeSpecificCharacterViewModel - как пример. Надеюсь понятно объяснил и не запутал. Мы будем это проходить чуть позже, в ближайшие 3 видео

[@binarchik039]

УРА

[@ВладимирАсланов-э3ш]

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

[@gamedevlavka]

@@ВладимирАсланов-э3ш да, можно подрубить uniTask, или ещё что, станет лучше конкретно в этом месте, но в остальном проекте они не понадобятся, так что оставлю пока так. Если прижмёт, то поменять - 5 минут

[@NewUser78654]

Мне кажется надо сделать 1 статический класс и 1 БД SQLite и не пихать всё что есть в языке туда, где это не надо. Люди, 2024 храните данные в БД - это же очевидно. Используйте всю мощь SQL - всё масштабируется, синхронизируется, да что угодно - недостатков нет. Опционально пойти на курсы программистов майкрософт, которые ведут сертифицированные преподаватели со стажем и внимательно посмотреть где используются те или иные языковые конструкции. За 20 лет уже надоело, что каждый программист из страха показаться не профессионалом показывает знания всех паттернов, языковых конструкций, всех встроенных возможностей языка в одном решении . Впихнуть всё. Доколе?

[@lDyamonagl]

У Васяна и Стасяна удалили подписьки....

[@nepochat]

👾💜

[@MrGolovewkin]

Cool!

[@AlexdV-Channel]

Вопрос что смотреть за обедом отпал сам собой)

[@MightyBlow]

Для чего вообще создается папку Root внутри какой-нибудь папки? Если рядом с Папкой Root лежат файл, это место и считается корнем. А мы зачем-то дополнительный "корень" создаем в котором вообще не понятно что тогда содержится. Надеюсь понятно объяснил своё непонимание/

[@boost_456]

Как с помощью R3 сделать публичное реактивное свойство, но чтобы у него был сеттер, ограничивающий Math.Clamp'ом подаваемые значения?

[@gamedevlavka]

Никак, реактивные свойства для этого не созданы, они как уведомлялки

[@boost_456]

@@gamedevlavka решил эту проблему, создав подписку на реактивное свойство внутри этого же класса

[@KontAin]

сможешь помочь мне с ошибкой при билде на андроид?

[@gamedevlavka]

Залетай, тут помогают: t.me/gamedevtavern/18991

[@lazybee6969]

Вот смотрю я уже 6 ролик и у меня возникает стойкое чувство "А это вообще все нужно?". Сейчас я объясню, что имею ввиду. Мы пишем код, код безусловно красивый и умный, расширяемый и гибкий, и вообще просто вах вах, в плане архитектуры. (мне и самому нравится как это все выглядит) НО тут возникает главный вопрос "Зачем?". 80% зрителей этого канала это инди-разработчики, которые не будут писать такие монструозные проекты, которые будут поддерживать на протяжении нескольких лет. Так зачем закладывать фундамент, на котором будет построен шалаш. Не проще ли создать рабочий (кривенький, косенький, в некоторых местах сильно связанный) проект и вообще посмотреть выстрелит ли он. А после, когда пройдет год, и проект все еще будет актуальный, то просто полностью переписать его (или вообще создать 2 часть 😄). Как по мне главное не уходить вообще в абсолютный говнокод, думать "Тут у меня данные, тут бизнес логика , тут ui, тут контроллер, которое все связывает, да контроллер скорее всего разрастётся до огромных масштабов, но к тому времени я уже закончу проект", даже наверное не надо это все делить на уровне архитектуры, просто поделить на отдельный классы. Стараться придерживается принципов solid (хотя как по мне 3 принцип, какая то фигня убивающая наследование) использовать некоторые удобные паттерны и все. Может я чего-то не понимаю или еще не дорос, не знаю.

[@gamedevlavka]

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

[@nightkot4917]

Тут весь фокус в том, что 80 процентов Разработчиков не пишут средние и большие игры. Для мелких типа Одноразовый "Тетрис" и Одноразовый "Три в Ряд" - Архитектура не нужна. Достаточно просто опрятно написать. "Все ЭТО" нужно, когда собираешься создавать что то долгоиграющее, типо Stardew Valley, WorldOfWarCraft или FalloutShellter... И все в таком духе.

[@nightyonetwothree]

@@nightkot4917 я вот диаблоид думаю написать. И геймплейный код меня не интересует - имел опыт в модмейкерстве. А вот архитектура для меня более важный вопрос. Я конечно и сам могу додуматься за 5 лет, но лучше посмотрю, полайкаю, а сделаю для себя чуть попроще.

[@NewUser78654]

Все очень печально. Автору стоит серьезно подумать над тем, что он делает и почему для простейших решений (которые уже есть у более опытных разработчиков) он строит такого вот "монстра". Смотрю на всё это и мне страшно. Страшно - мы не знаем что это такое, если бы мы знали что это такое - мы не знаем что это такое. Если честно, у меня даже есть мысль, что автор троллит. Статический класс и БД SQLite. Всё. Без подписок, отписок, абстракций...они не для этого были созданы. Не надо показывать знания всего и толкать это всё туда, где ему не место. Не надо. Решение просто ужасно. И это выяснится на большом и реальном проекте. Это когда вы будете работать со стим и 100500 пользователями. Так сказать небольшая ответственность. И вам надо будет контролировать, загружать, изменять кучу ресурсов, обновления игры, модифицировать структуру сохранений. И вот с этим, что на видео, вы хлебнете горя.

[@gamedevlavka]

@@NewUser78654 Окей, засуну опыт работы над крупными проектами со Scopely (~200 человек на проекте, из них 40 программистов), откуда и взялся мой опыт работы с MVVM, реактивностью и клиент-серверным взаимодействием куда подальше. А если серьезно, то как раз такие решения используются на крупных проектах, и меня сложно будет переубедить, т.к. я имею немалый опыт работы с крупными проектами. Но ради справедливости скажу, что строить такого монстра я и не заставляю, я просто делюсь знаниями, использовать их или нет - дело ваше. Не стоит расписаться по поводу статики и базы данных, эта комбинация смертельна для мультиплатформенный проектов сложнее гиперказуалки (в долгосроке, конечно же). А простую игру можно на коленке написать часов за 8-16 без визуала