Такую жизу в конце сказал 🤣 Разработка реально роскошь, которую не каждый может себе позволить. Если точнее, свободное время - это наша роскошь. Когда мы подростки, у нас много времени - но нет осознанности, когда взрослее - осознанность есть, но нет времени
Добавлю и от себя: Обязательно, обводите и подписывайте свой код ! (Не ленитесь. ) Через пару месяцев, открывая "функцию или макрос", созданную ещё в начале работы над проектом. Будете смотреть на свои "спагетти", не понимая что это такое и кто всё это это сделал ?... 😅
1.Структура проэкта 2.Весь проэкт в отдельной папке в Content 3.Импорт ассетов в промежуточный проэкт 4.область видимости переменных и функций: Private Protected Public 5.Git. Таски
Еще добавлю: 6) Хорошая практика делать все переменные закрытыми и к тем, которые нужны извне давать доступ только через get- и set-функции. Это упростит переписывание внутренней логики блупринов без вероятности что-то сломать в других местах. 7) Постараться как можно реже использовать касты к конкретным классам. Это очень усложняет дальнейшее переписывание. Условно говоря, сделал ты везде касты на MyMegaCharacter и всё... С другим Character уже работать не будет, и в другой проект просто так не перенесешь. Решается это через интерфейсы часто. И наследование не панацея. 8) Реализовывать логику в компонентах.
@@gcomsu5819 Каст, встроенный в UE, это не тот dynamic_cast, если что. То есть, не такой тяжелый в плане производительности, как нативная реализация в C++.
Дополню про приватность. Сходу это не очень удобно смотреть. В секции MyBlueprint, где показанны наши переменные и функции можно в "глазике" поставить галку "Show access specifier in the My Blueprint View". Оно добавит перед каждой функцией и переменной подпись.
Ничего нового не услышал, но это очень очень важные базовые вещи! Приятно для себя недавно нашел твой канал, особенно как ТА послушать за оптимизацию просто приятно:)
Всё в точку. Единственное не проговорил в чем польза отдельной корневой папки, в моем случае я был вынужден её создать после того как мои собственные файлы смешивались с файлами которые мигрируешь с других проектов, часто из-за зависимостей поттягивается куча лишних папок даже если переносишь какой-нибудь партикл и твой проект который ты аккуратно вымащивал забивается левым мусором, становится тяжело находить то, что действительно важно.
Совет - не нужно делать все переменные Private и вообще «обращаться к классу из других мест», если классы у вас общаются через интерфейсы. Жесткие ссылки в блупринтах это не всегда (почти никогда) хорошая идея.
@@UNREALRUSSIA так ты бы делал, а то говоришь до фига, а смысл не ясен. Зачем мне делать папку с названием проекта в корневой папке? Почему не привести примеры и показать, что это даёт в итоге? Мне проще кликать на контент и видеть весь контент сразу, не нажимая ещё один раз на папку. Зачем делать приватные переменные? Не понятно. Это размер изменит? Скорость загрузки? Это повышает фпс? Зачем это? Непонятно. Нужны были примеры. Таски для инди это тетрадь. Никаких отвлечений на другие программы и интернет браузер. Работаешь, пишешь, читаешь, все под рукой. Твои видео вроде и нужные, но без примеров они бесполезны. Приходится смотреть американцев
@@TheMycomaриватные переменные не влияют ни на что в плане производительности. Это нужно с точки зрения код стайла Самая Крутая аналогия. Представьте, что вы садитесь за руль машины, а там кнопок как в кабине самолета. Любому пользователю понадобиться лишь несколько, но разработчик предоставил вообще все, включая флаги работы подушек безопасности. И вот вы мискликнув можете спокойно либо запустить их сразу и ввести в ступор вашу команду, либо отключить их неявно и вообще подвергнуть опасности пассажиров. А зачем вам вообще эти кнопки дали? И представьте насколько больше усилий нужно в большом проекте, чтоб разбираться, предназначена ли эта кнопка для работы, или разработчик просто не спрятал ее Или, в два слова, это говнокод
Я бы ещё шестой добавил. Всё документировать. В Ворде, Екселе или ручкой в блокноте. Со временем проект разрастётся и какие бы понятные названия переменным и функциям ни давали, придётся сидеть и вспоминать, что за BP_melee и чем stoneroad отличается от brickroad
По мне самое хорошее объяснение "привычке 2" - если не создавать подпапку проекта и начать закидывать ассеты с маркетплейса, то 4-5 ассетов и уже будет каша)))
Во первых, не будут в общей куче с файлами движка - стартер киты и прочее. Во вторых, при импорте ассетов можно их закидывать сначала в другую папку, на потестить (в юнити авторы ассетов частенько держат их в корневом каталоге и при импорте все разбрасывается по папкам движка так, что замучаешься вылавливать, еще и перепишут шейдера и т.п.). В третьих, для удобства исключения неиспользуемого из билда.
1:12 Есть один момент: есть некоторые группы ассетов, которые ОБЯЗАНЫ быть в папке Content, а не в дополнительной папке. Мне точно известно, что карты уровней (umap) обязаны лежать в Content/Levels, а видеоролики в Content/Movies, иначе они не будут включены в запакованный проект (то есть в саму игру) для использования через Level Streaming и Media Texture соответственно. Возможно есть что-то ещё, о чём я не в курсе, но на всякий случай держу папку Content/Music отдельно.
Вот с Movies согласен, а вот чтоб уровни не запаковывались если они не в спец папке, такого еще не видел, хотя те же видеоролики можно настроить чтоб они запаковывались из любой папки
К большей части озвученного пришёл самостоятельно, и про тесты в отдельном проекте и создании папки с названием проекта и к наименованию ассетов, опыт однако.
Да уж. С пунктами 2 и 3 на себе ощутил. Использовал кучу ништяков из маркетплейса, и как и сказано, зачастую далеко не весь пак, а кусочек от туда, пару ассетов от сюда. В итоге крохотная игруля в запакованом виде 3-4 гига и геймплеем на полчаса-час раздула папку проекта аж до 80-и гигов... О_о Ну и понятно дело все это дело в одной куче. :)
Пользуюсь Trello. Хорошая вещь. Можно работать как с веб-версией, так и с приложения на телефоне. Создание отдельной папки для проекта и область видимости - хорошие советы. Даже не задумывался о них
@@UNREALRUSSIA Аналогично, но вместо Excel пользуюсь Google Docs. Он автоматически сохраняет изменения, к тому же доступ к нужным файлам можно получить откуда угодно
У меня при создании всегда есть черновик: проект со всеми механиками и основными объектами, без карты. Там я в первую очередь отрабатываю новый код, новые объекты, взаимодействия и т.д. И если все успешно - повторяю в чистовике, основном проекте. А вот то, что переносить не весь пак, а лишь то, что надо.. А как? Идея замечательная, но вот объект из пака, у него бп, меш, материалы, все это надо вычленить и перенести точечно?
Тут не сложно - можно использовать мигрейт на объекте конкретном и всё то, что связано с ним склонируется в новый проект. С той же иерархией папок. Отчего важно правило 2 очень важно
Спасибо, очень полезно. Было бы интересно послушать про настройку среды разработки. Visual Studio или Visual Studio Code, или еще что-то? Меня просто если честно уже добивает это отвратный intellisence в 2019 VS. Пробовал ставить VS Assistant вроде лучше но пока дороговато, мб есть какие-то альтернативы?
Такую жизу в конце сказал 🤣 Разработка реально роскошь, которую не каждый может себе позволить. Если точнее, свободное время - это наша роскошь. Когда мы подростки, у нас много времени - но нет осознанности, когда взрослее - осознанность есть, но нет времени
где ты был 5 лет назад с этим видосом. Мега полезное видео для начинающих!!!!
Единственный кто такие неочевидные вещи для новичков рассказывает. Спасибо, продолжай в том же духе.
Добавлю и от себя:
Обязательно, обводите и подписывайте свой код ! (Не ленитесь. )
Через пару месяцев, открывая "функцию или макрос", созданную ещё в начале работы над проектом.
Будете смотреть на свои "спагетти", не понимая что это такое и кто всё это это сделал ?... 😅
Очень полезная информация, про приватность переменных банально не знал
1.Структура проэкта
2.Весь проэкт в отдельной папке в Content
3.Импорт ассетов в промежуточный проэкт
4.область видимости переменных и функций: Private Protected Public
5.Git. Таски
1. Единое правило именования.
Кто ты? Где ты был? Просто нереально спасибо огромное. Пожалуйста, продолжай дальше выпускать видео! Особенно про паттеры
Еще добавлю:
6) Хорошая практика делать все переменные закрытыми и к тем, которые нужны извне давать доступ только через get- и set-функции. Это упростит переписывание внутренней логики блупринов без вероятности что-то сломать в других местах.
7) Постараться как можно реже использовать касты к конкретным классам. Это очень усложняет дальнейшее переписывание. Условно говоря, сделал ты везде касты на MyMegaCharacter и всё... С другим Character уже работать не будет, и в другой проект просто так не перенесешь. Решается это через интерфейсы часто. И наследование не панацея.
8) Реализовывать логику в компонентах.
Спасибо за дополнение! P. S. По компонентам как раз надо будет как-нибудь пройтись :)
Да и касты снижают производительность, т.к. при касте идет подгрузка всего того что ты кастишь, а это ох как много ресурсов жрет!!!
@@gcomsu5819 Каст, встроенный в UE, это не тот dynamic_cast, если что. То есть, не такой тяжелый в плане производительности, как нативная реализация в C++.
@@f.artemenkov Я про блюпринты говорил, в них от кастов нужно по возможности совсем отказаться.
Дополню про приватность. Сходу это не очень удобно смотреть. В секции MyBlueprint, где показанны наши переменные и функции можно в "глазике" поставить галку "Show access specifier in the My Blueprint View". Оно добавит перед каждой функцией и переменной подпись.
Спасибо большое! "Show access specifier in the My Blueprint View" - это суперское дополнение!
Про таска очень полезная фича
Ничего нового не услышал, но это очень очень важные базовые вещи! Приятно для себя недавно нашел твой канал, особенно как ТА послушать за оптимизацию просто приятно:)
Очень качественно
СПАСИБО!!!!
Всё в точку. Единственное не проговорил в чем польза отдельной корневой папки, в моем случае я был вынужден её создать после того как мои собственные файлы смешивались с файлами которые мигрируешь с других проектов, часто из-за зависимостей поттягивается куча лишних папок даже если переносишь какой-нибудь партикл и твой проект который ты аккуратно вымащивал забивается левым мусором, становится тяжело находить то, что действительно важно.
Полностью согласен, спасибо за дополнение!
Гайд по стилю очень полезен, раньше его не видел, благодарю! Помимо самого стиля именования, там еще немало полезных советов дают.
Стоит пересмотреть позже, после первых пунктов немного непонятно из-за отсутствия понимания движка.
Благодарю, буду следить за вашими туториалами с огромным удовольствием
все так и делаю, кроме импорта. Про импорт в отдельный проект это интересная придумка. Нужно ее потестить.
Кратко !!! КРУТО и ПО ТЕМЕ !!!!
Мне стыдно за себя. Но за видео спасибо)
Спасибо, очень полезно!
Шик развивай канал
еще
Спасибо, очень полезно! А будет подробный ролик про настройку ассетов (к Правилу 3)?
Как программист - полностью со всем согласен!
Ещё очень важная штука это Get и Set методы, надо было и про них рассказать
Совет - не нужно делать все переменные Private и вообще «обращаться к классу из других мест», если классы у вас общаются через интерфейсы. Жесткие ссылки в блупринтах это не всегда (почти никогда) хорошая идея.
это оч.хорошая тема, на которую как-нибудь стоит сделать отдельный ролик :)
@@UNREALRUSSIA так ты бы делал, а то говоришь до фига, а смысл не ясен. Зачем мне делать папку с названием проекта в корневой папке?
Почему не привести примеры и показать, что это даёт в итоге?
Мне проще кликать на контент и видеть весь контент сразу, не нажимая ещё один раз на папку.
Зачем делать приватные переменные? Не понятно. Это размер изменит? Скорость загрузки? Это повышает фпс?
Зачем это? Непонятно. Нужны были примеры.
Таски для инди это тетрадь. Никаких отвлечений на другие программы и интернет браузер. Работаешь, пишешь, читаешь, все под рукой.
Твои видео вроде и нужные, но без примеров они бесполезны. Приходится смотреть американцев
@@TheMycomaриватные переменные не влияют ни на что в плане производительности. Это нужно с точки зрения код стайла
Самая Крутая аналогия. Представьте, что вы садитесь за руль машины, а там кнопок как в кабине самолета. Любому пользователю понадобиться лишь несколько, но разработчик предоставил вообще все, включая флаги работы подушек безопасности. И вот вы мискликнув можете спокойно либо запустить их сразу и ввести в ступор вашу команду, либо отключить их неявно и вообще подвергнуть опасности пассажиров. А зачем вам вообще эти кнопки дали? И представьте насколько больше усилий нужно в большом проекте, чтоб разбираться, предназначена ли эта кнопка для работы, или разработчик просто не спрятал ее
Или, в два слова, это говнокод
Я бы ещё шестой добавил. Всё документировать. В Ворде, Екселе или ручкой в блокноте. Со временем проект разрастётся и какие бы понятные названия переменным и функциям ни давали, придётся сидеть и вспоминать, что за BP_melee и чем stoneroad отличается от brickroad
Ещё, ещё и ещё таких советоооооов!
По мне самое хорошее объяснение "привычке 2" - если не создавать подпапку проекта и начать закидывать ассеты с маркетплейса, то 4-5 ассетов и уже будет каша)))
Ништяк инфа!!!
Совет: всегда закрывайте пины "world context".
Причина: сборка роекта не пройдёт
Хорошая привычка: знать ооп
Америку не открыл, но другие видео очень ценные и полезные. Продолжай в том же духе. Спасибо
А можно подробнее, зачем в проекте всё держать в именной папке? От каких подводных камней это избавит?
Во первых, не будут в общей куче с файлами движка - стартер киты и прочее.
Во вторых, при импорте ассетов можно их закидывать сначала в другую папку, на потестить (в юнити авторы ассетов частенько держат их в корневом каталоге и при импорте все разбрасывается по папкам движка так, что замучаешься вылавливать, еще и перепишут шейдера и т.п.). В третьих, для удобства исключения неиспользуемого из билда.
Спасибо большое
✌✌✌
1:12 Есть один момент: есть некоторые группы ассетов, которые ОБЯЗАНЫ быть в папке Content, а не в дополнительной папке. Мне точно известно, что карты уровней (umap) обязаны лежать в Content/Levels, а видеоролики в Content/Movies, иначе они не будут включены в запакованный проект (то есть в саму игру) для использования через Level Streaming и Media Texture соответственно. Возможно есть что-то ещё, о чём я не в курсе, но на всякий случай держу папку Content/Music отдельно.
Вот с Movies согласен, а вот чтоб уровни не запаковывались если они не в спец папке, такого еще не видел, хотя те же видеоролики можно настроить чтоб они запаковывались из любой папки
К большей части озвученного пришёл самостоятельно, и про тесты в отдельном проекте и создании папки с названием проекта и к наименованию ассетов, опыт однако.
зачем отдельную папку создавать?
@@ivanc86179 удобней во многих случаях, особенно если нужно в другой проект перенести, опять же так ты точно знаешь что всё твое в 1 папке.
Да уж. С пунктами 2 и 3 на себе ощутил. Использовал кучу ништяков из маркетплейса, и как и сказано, зачастую далеко не весь пак, а кусочек от туда, пару ассетов от сюда. В итоге крохотная игруля в запакованом виде 3-4 гига и геймплеем на полчаса-час раздула папку проекта аж до 80-и гигов... О_о Ну и понятно дело все это дело в одной куче. :)
Сам прошло через это. ООО сколько нервов
Пользуюсь Trello. Хорошая вещь. Можно работать как с веб-версией, так и с приложения на телефоне. Создание отдельной папки для проекта и область видимости - хорошие советы. Даже не задумывался о них
Я оч.люблю Trello+Excel, всё никак не привыкну к более новомодным системам :)
@@UNREALRUSSIA Аналогично, но вместо Excel пользуюсь Google Docs. Он автоматически сохраняет изменения, к тому же доступ к нужным файлам можно получить откуда угодно
У меня при создании всегда есть черновик: проект со всеми механиками и основными объектами, без карты. Там я в первую очередь отрабатываю новый код, новые объекты, взаимодействия и т.д. И если все успешно - повторяю в чистовике, основном проекте. А вот то, что переносить не весь пак, а лишь то, что надо.. А как? Идея замечательная, но вот объект из пака, у него бп, меш, материалы, все это надо вычленить и перенести точечно?
Тут не сложно - можно использовать мигрейт на объекте конкретном и всё то, что связано с ним склонируется в новый проект. С той же иерархией папок. Отчего важно правило 2 очень важно
👍👏👍👏
Спасибо, очень полезно. Было бы интересно послушать про настройку среды разработки. Visual Studio или Visual Studio Code, или еще что-то? Меня просто если честно уже добивает это отвратный intellisence в 2019 VS. Пробовал ставить VS Assistant вроде лучше но пока дороговато, мб есть какие-то альтернативы?
А JetBrains Rider пробовали?
Как по мне, Rider шустрее работает, чем MS Visual Studio. И intellisence не тупит так сильно.
Капец ты шаришь
Стоит ли пытатся осилить после 35 лет если раньше вообще ничем подобным не интересовался?
Сделай очень маленькую игрушку, а потом поймешь, надо ли это тебе)
Умоляю можно гайд по assets manager и как поделить ассеты на отледельные pak
Пропускать обновления черевато сложным переходом на новые версии.. кучи деприкейтед методов и т.п...
Согласен. :) Ну это опять же, по ситуации :)
Что такое такски?
с вторым пунктом не согласен.
где перевод конвенции на русский?
Спасибо! Полезная инфа