Если что то непонятно с миллиарда других гайдов, заходишь на данный канал, находишь нужную тему, если такая имеется и все становится легче, проще, понятней и интересней). Уже не раз выручал в этом плане. Конечно изначально все пытаются находить инфу на живых примерах, и я так же, но почти всегда, на живых примерах объсняется менее понятно и доступно, чем это делаешь ты)
Спасибо за видео! В который раз убеждаюсь, что канал просто находка! Единственное, пока слушаешь всё понятно, но если бы еще явные примеры были, как это применять в игре, было бы супер. Я например открываю проект и начинаю тупить, не знаю, как впихнуть знания ))) Наверно у всех ньюфагов такая беда. Вообще бы запилить стрим, создание простенькой игры с 0. Видел зарубежные коллеги такое практикуют.
Про то, как применять в игре - услышал, подумаю, как можно сделать. А вот со стримом - сложности, т.к. мой контент направлен на развитие мышления разработчика, чтобы потом получить работу или самому делать игры. За один стрим игру с хорошим кодом не напишешь)
@@gamedevlavka Спасибо за ответ. Согласен, концепцию канала не надо менять, большая редкость в РУ сегменте. Планируются видео про MVC + Unity? Весьма актуальная тема, т.к. подавляющее большенство RU Unity (Рунити %)) ) разработчиков, которые решились перейти на архитектуру, используют именно MVC... А по ECS?
Позволю себе пару замечаний: 1. Писать this в свойствах (например this._id) не нужно. Нижнее подчеркивание в именах приватных полей как раз и пишут, чтобы не нужно было постоянно писать "this". 2. Свойства принято именовать с большой буквы. Рад, что нашел твой канал, очень круто и понятно объясняешь, и видео выходят чуть ли не каждый день. Спасибо :)
Отвечу на пару замечаний) 1. this я пишу всегда в локальных переменных. Почему? Об этом я писал в телеграм канале тут t.me/gamedevlavka/15. Нижнее подчеркивание я использую тогда, когда нужно использовать такое же имя, как у свойства, но чтобы я мог менять его через редактор. 2. Так принято в венгерской нотации (по классике), да. Однако, внутри Unity все свойства пишутся с маленькой буквы, и чтобы мой код не отличался от кода Unity, я решил, что также буду использовать маленькую первую букву и для свойств. Спасибо за комментарий :)
@@gamedevlavka, тут скорее момент, что если пойти работать на дядю, то там обычно придерживаются код стайла C#, поэтому может быть неприятно переучиваться. Лично я для себя выбрал сразу привыкнуть к общепринятому именованию, чтоб меньше головняка было.
@@toxicknight3079 У разных дядь разные кодстайлы приняты. Есть стиль, который больше похож на Джаву, есть, который Майкрософт у себя написала. Например, лично мне открывающая фигурная скобка на новой строке кажется менее удобной, чем в конце предыдущей (вместо увеличения читабельности варит лапшу). И я видел много на Ютубе, кто пишет в джавовском стиле, кто в смешанном, кто по Майкрософту. Так что если ты придерживаешься хоть какого-то более-менее распространённого и адекватного стиля, то уже хорошо. Тут нет единого железобетонного стандарта. И стиль Майкрософта нравится далеко не всем.
Видео очень информативное, твой канал очень помогает развиваться в данной сфере, остался один вопрос, по функциональности очень похожу на обычный префаб, так чем отличается ScriptableObject от Prefab ?
Андрей, добрый день. Спасибо за видео. А можете еще рассказать, как переносить данные из сцены в сцену. Например, мы прошли уровни и заработали монеты и рубины. Когда мы вернулись на главную карту после уровня, заработанные монеты и рубины добавились к их общему количеству. Думаю подобное очень актуально, заранее спасибо ❤
я так и не понял для чего нужен этот гемор? Почему просто в обыкновенном префабе в проекте не держать ссылку на иконку сундука, саму 3д модель, сколько монет он содержит и многое другое?
вопрос... Ну мало ли время будет на глупые вопросы. var _hero = Resources.Load(""); пытался так вот файлик получить прилетает null. то есть если его в инспекторе прокидываешь все работает. если собираешь в массив все работает. а если просто в переменную пытаюсь закинуть то нифига не работает ...странно просто как то
Добрый день, появился вопрос по ScriptableObject. Создал с помощью ScriptableObject описание оружия для шутера, в котором хранится префаб оружия, скорострельность, обьем магазина и метод стрельбы через Raycast. На основе данного шаблона создал ассет винтовки. Создал скрипт, который принимает в поле данную винтовку и вызывает метод Shoot(), у Player через инпут, а у Enemy, если в его поле видимости зашел Player, однако при нажатии кнопки выстрела стреляет только оружие врага, при этом если войти в поле видимости враг тоже стреляет! Решил продублировать ассет винтовки и дать врагу, то все работает как было задумано.
Префаб - шаблон игрового объекта. ScriptableObject - объект с информацией, конфиг, он нужен для хранения информации. У одного не может быть преимущества перед другим, потому что они созданы для разных целей. Конечно, ты можешь сделать конфиг и в качестве префаба, но это все равно что из пушки по воробъям стрелять.
@@gamedevlavka А почему не создать просто класс Config ? Для чего нужен именно ScriptableObject, пока вижу преимущество только в том, что: 1. Его не нужно инициализировать (Но это решается на уровне архитектуры, создаем объектный пулл и инжектим туда) 2. Можно добавить в контекстное меню
Автопроперти - это фишка C#, но она еще не была официально добавлена в Unity, что означает, она работает нестабильно. Например, существуют проблемы с переопределением свойств в Prefab Variants.
Зачем SerializedField так и не понял, посмотрел фулл видос, обещание словил что дальше объяснение будет и все, так же почему с нижним подчеркиванием тоже не понятно, насколько я знаю допустим из питона нижние подчеркивание, при импорте import library не импортирует то что написано с нижним подчеркиванием.
Это разные типы данных для разных задач. SO для хранения и использования конфигурации, структуры - для быстрого и наименее ресурсозатратного использования данных. Кроме того, SO - ссылочный тип, а структуры - значимый, со всеми вытекающими последствиями. Для более детального понимания рекомендую глянуть видео с типами данных на канале
Хм, про безопасность полей это вполне очевидно, но архитектура на so подразумевает запись данных в поля. С префиксом [nonserialised] дабы не сохранять данные из runtime в ассете. Да и вопрос что можешь сказать по архитектуре на SO ? Плюсы, минусы? Спасибо за видео!
Не совсем понятно. Если пишешь [serialisable field] для private переменной то ведь ты и так можешь менять значения ТОЛЬКО в инспекторе. Или я не так что то понял...
А почему Вы всегда явно пишите слово private? Отсутствие модификатора доступа вообще ведь тоже самое, что и private. Т.е. чуточку короче запись получается.
В таком случае отсутствия private методы и переменные уже не выглядят унифицировано, а следовательно при беглом чтении кода создается маленький хаос в голове. Удобнее читать, когда все методы и переменные выглядят одинаково. Это такой маааленький пенёк, об который спотыкаешься при чтении, если не писать.
Скажу сразу - в ООП программировании далеко не джун. Изучаю юнити. И зачем ScriptableObject? Нам нужен сундук. Пишем скрипт для сундука, указываем в нем необходимые поля (сериализуемые-доступные из редактора), скрипт прикрепляем к сундуку. Всё. Один сундук в префабах, к нему подключен скрипт. Там есть выпадающее поле (enum) какой это сундук (обычный, необычный и т.д.). Удобно. Никаких меню с 1000 сундуков, кучи объектов в ресурсах и т.д. Смысл ScriptableObject?
Это сокращенное написание свойства: string id { get { return this._id; } } Согласись, написать string id => this._id гораздо быстрее, короче и аккуратнее
В первом случае это свойство только с возможность чтения, а I'd = this._id это присваивание, нам присваивать ничего не нужно, только возвращать (читать)
Абсолютно непонятно на кой такое удовольствие. Чем это отличается от создание обычного класса с 3 полями? Нужно будет 3 сундука - сделаешь префабы. Что так у тебя 3 объекта лежат в директории, что эдак будут. Только при этом на префабы еще всякие интересные вещи по типу риджидбоди или коллайдера накинуть можно
Спасибо, что увеличиваешь окно IDE, на телефоне тоже код видно👍
4 видео пол статьи прочитал , и наконец тихий и спокойный подробный разбор , спасиба , не досмотрел но уже нравиться
жаль что походу это не то что мне нужно (грусный смайлик)
По моему мнению твой канал самый полезный, среди русскоязычных туториалов.
Если что то непонятно с миллиарда других гайдов, заходишь на данный канал, находишь нужную тему, если такая имеется и все становится легче, проще, понятней и интересней). Уже не раз выручал в этом плане. Конечно изначально все пытаются находить инфу на живых примерах, и я так же, но почти всегда, на живых примерах объсняется менее понятно и доступно, чем это делаешь ты)
Спасибо, было очень полезно!
Ты гений реально
Спасибо за видео! В который раз убеждаюсь, что канал просто находка!
Единственное, пока слушаешь всё понятно, но если бы еще явные примеры были, как это применять в игре, было бы супер.
Я например открываю проект и начинаю тупить, не знаю, как впихнуть знания ))) Наверно у всех ньюфагов такая беда.
Вообще бы запилить стрим, создание простенькой игры с 0. Видел зарубежные коллеги такое практикуют.
Про то, как применять в игре - услышал, подумаю, как можно сделать.
А вот со стримом - сложности, т.к. мой контент направлен на развитие мышления разработчика, чтобы потом получить работу или самому делать игры. За один стрим игру с хорошим кодом не напишешь)
@@gamedevlavka Спасибо за ответ. Согласен, концепцию канала не надо менять, большая редкость в РУ сегменте.
Планируются видео про MVC + Unity? Весьма актуальная тема, т.к. подавляющее большенство RU Unity (Рунити %)) ) разработчиков, которые решились перейти на архитектуру, используют именно MVC...
А по ECS?
@@vicmeateater5508 Когда-нибудь и до них руки дойдут :)
Спасибо большое! Всё понятно и приятно объясняешь. Я так понимаю на эти объекты универсальные характеристики накидываются и используются в игре
Спасибо за видео. Впринципе осталось только цену придумать легендарному и редкому сундукам и можно в Юбисофт идти.
СПАСИБО!!!!
Отличный материал!
Крутая тема!!!
Позволю себе пару замечаний:
1. Писать this в свойствах (например this._id) не нужно. Нижнее подчеркивание в именах приватных полей как раз и пишут, чтобы не нужно было постоянно писать "this".
2. Свойства принято именовать с большой буквы.
Рад, что нашел твой канал, очень круто и понятно объясняешь, и видео выходят чуть ли не каждый день. Спасибо :)
Отвечу на пару замечаний)
1. this я пишу всегда в локальных переменных. Почему? Об этом я писал в телеграм канале тут t.me/gamedevlavka/15. Нижнее подчеркивание я использую тогда, когда нужно использовать такое же имя, как у свойства, но чтобы я мог менять его через редактор.
2. Так принято в венгерской нотации (по классике), да. Однако, внутри Unity все свойства пишутся с маленькой буквы, и чтобы мой код не отличался от кода Unity, я решил, что также буду использовать маленькую первую букву и для свойств.
Спасибо за комментарий :)
@@gamedevlavka, тут скорее момент, что если пойти работать на дядю, то там обычно придерживаются код стайла C#, поэтому может быть неприятно переучиваться.
Лично я для себя выбрал сразу привыкнуть к общепринятому именованию, чтоб меньше головняка было.
@@toxicknight3079 я и есть такой дядя :)
@@toxicknight3079 У разных дядь разные кодстайлы приняты. Есть стиль, который больше похож на Джаву, есть, который Майкрософт у себя написала. Например, лично мне открывающая фигурная скобка на новой строке кажется менее удобной, чем в конце предыдущей (вместо увеличения читабельности варит лапшу). И я видел много на Ютубе, кто пишет в джавовском стиле, кто в смешанном, кто по Майкрософту. Так что если ты придерживаешься хоть какого-то более-менее распространённого и адекватного стиля, то уже хорошо. Тут нет единого железобетонного стандарта. И стиль Майкрософта нравится далеко не всем.
Очень короткое, но полезное видео
спасибо
Видео очень информативное, твой канал очень помогает развиваться в данной сфере, остался один вопрос, по функциональности очень похожу на обычный префаб, так чем отличается ScriptableObject от Prefab ?
жесть, насколько просто вы объяснили сложную для понимания модель сохранения данных)
Так в каком месте оно сложное?
Но да, автор очень хорошо объясняет тему
Андрей, добрый день. Спасибо за видео. А можете еще рассказать, как переносить данные из сцены в сцену. Например, мы прошли уровни и заработали монеты и рубины. Когда мы вернулись на главную карту после уровня, заработанные монеты и рубины добавились к их общему количеству. Думаю подобное очень актуально, заранее спасибо ❤
Это вопрос архитектуры, доберёмся и до него!
Ну по идее используя Scriptable object это легко реализуется, т.к. они сохраняют все данные на жёстком диске.
@@АлександрБычко-п9ъ слышал про то что они не попадают в билд. Может не правильно понял...
я так и не понял для чего нужен этот гемор? Почему просто в обыкновенном префабе в проекте не держать ссылку на иконку сундука, саму 3д модель, сколько монет он содержит и многое другое?
вопрос...
Ну мало ли время будет на глупые вопросы.
var _hero = Resources.Load("");
пытался так вот файлик получить прилетает null.
то есть если его в инспекторе прокидываешь все работает.
если собираешь в массив все работает.
а если просто в переменную пытаюсь закинуть то нифига не работает ...странно просто как то
А почему _id здесь string, а не enum?
Вот у меня задача при смене оружия, чтобы патроны одного оружия не ссылались на уже патроны другого оружия, тут подойдет ScriptableObject?
Добрый день, появился вопрос по ScriptableObject. Создал с помощью ScriptableObject описание оружия для шутера, в котором хранится префаб оружия, скорострельность, обьем магазина и метод стрельбы через Raycast. На основе данного шаблона создал ассет винтовки. Создал скрипт, который принимает в поле данную винтовку и вызывает метод Shoot(), у Player через инпут, а у Enemy, если в его поле видимости зашел Player, однако при нажатии кнопки выстрела стреляет только оружие врага, при этом если войти в поле видимости враг тоже стреляет! Решил продублировать ассет винтовки и дать врагу, то все работает как было задумано.
Все никак не возьму в толк, по сути единственное преимущество и надобность(перед просто префабом) в том что можно создавать их из меню?
Префаб - шаблон игрового объекта.
ScriptableObject - объект с информацией, конфиг, он нужен для хранения информации.
У одного не может быть преимущества перед другим, потому что они созданы для разных целей. Конечно, ты можешь сделать конфиг и в качестве префаба, но это все равно что из пушки по воробъям стрелять.
@@gamedevlavka огромное спасибо что отвечаешь и объясняешь!)
@@gamedevlavka А почему не создать просто класс Config ?
Для чего нужен именно ScriptableObject, пока вижу преимущество только в том, что:
1. Его не нужно инициализировать (Но это решается на уровне архитектуры, создаем объектный пулл и инжектим туда)
2. Можно добавить в контекстное меню
через [field: serializeFIled] можно сериализовать проперти, и не придется писать каждый раз пару филд + проперти.
Автопроперти - это фишка C#, но она еще не была официально добавлена в Unity, что означает, она работает нестабильно. Например, существуют проблемы с переопределением свойств в Prefab Variants.
Зачем SerializedField так и не понял, посмотрел фулл видос, обещание словил что дальше объяснение будет и все, так же почему с нижним подчеркиванием тоже не понятно, насколько я знаю допустим из питона нижние подчеркивание, при импорте import library не импортирует то что написано с нижним подчеркиванием.
Хороший вопрос. Ответ писал тут:
t.me/gamedevlavka/13
Но что лучше использовать? Структуры или SO?
Это разные типы данных для разных задач. SO для хранения и использования конфигурации, структуры - для быстрого и наименее ресурсозатратного использования данных. Кроме того, SO - ссылочный тип, а структуры - значимый, со всеми вытекающими последствиями. Для более детального понимания рекомендую глянуть видео с типами данных на канале
Кстати, в чем разница private void Start() от void Start()?
Функционально - ни в чем. Дело в читабельности. Писал об этом тут => t.me/gamedevlavka/7
@@gamedevlavka на телегу подписан, не листал:D Теперь стоит))) Ну вообще я их не писал только в Start Update и подобных, так, в принципе, это логично)
стоит ли применить принципы СОЛИД в Юнити?
Обязательно!
@@gamedevlavka а в будушем в вашим канале будет такое видео где покажете приминение солид в скирптах юнити?
@@developerazcom SOLID Применяется независимо, в юнити ты работаешь или нет. Но устроить можно.
@@gamedevlavka было бы круто
@@gamedevlavka ждём!!! :)
Хм, про безопасность полей это вполне очевидно, но архитектура на so подразумевает запись данных в поля. С префиксом [nonserialised] дабы не сохранять данные из runtime в ассете. Да и вопрос что можешь сказать по архитектуре на SO ? Плюсы, минусы? Спасибо за видео!
для записи лучше использовать методы для тех же полей, что бы логика записи данным была внутри самого объекта и он мог валидировать всё
Не совсем понятно. Если пишешь [serialisable field] для private переменной то ведь ты и так можешь менять значения ТОЛЬКО в инспекторе. Или я не так что то понял...
все верно, только вот получать данные публично тоже надо. В этом и проблема
А почему Вы всегда явно пишите слово private? Отсутствие модификатора доступа вообще ведь тоже самое, что и private. Т.е. чуточку короче запись получается.
В таком случае отсутствия private методы и переменные уже не выглядят унифицировано, а следовательно при беглом чтении кода создается маленький хаос в голове. Удобнее читать, когда все методы и переменные выглядят одинаково. Это такой маааленький пенёк, об который спотыкаешься при чтении, если не писать.
Где пчелиная война 2?
Ну по сути scriptable object это сериализуемая структура получается. За исключением того что можно создавать обьекты в юнити.
Скажу сразу - в ООП программировании далеко не джун. Изучаю юнити. И зачем ScriptableObject? Нам нужен сундук. Пишем скрипт для сундука, указываем в нем необходимые поля (сериализуемые-доступные из редактора), скрипт прикрепляем к сундуку. Всё.
Один сундук в префабах, к нему подключен скрипт. Там есть выпадающее поле (enum) какой это сундук (обычный, необычный и т.д.). Удобно. Никаких меню с 1000 сундуков, кучи объектов в ресурсах и т.д. Смысл ScriptableObject?
id => this._id почему нельзя просто так id = this._id ?? в чем разница между ними ?
Это сокращенное написание свойства:
string id {
get {
return this._id;
}
}
Согласись, написать string id => this._id гораздо быстрее, короче и аккуратнее
В первом случае это свойство только с возможность чтения, а I'd = this._id это присваивание, нам присваивать ничего не нужно, только возвращать (читать)
Абсолютно непонятно на кой такое удовольствие. Чем это отличается от создание обычного класса с 3 полями? Нужно будет 3 сундука - сделаешь префабы. Что так у тебя 3 объекта лежат в директории, что эдак будут. Только при этом на префабы еще всякие интересные вещи по типу риджидбоди или коллайдера накинуть можно
Почему нельзя одной строчкой записать приватный ID ?
[SerializeField] public string _id {get; private set; }
Потому что редактор не умеет отображать свойства
@@gamedevlavka Не совсем понял как редактор отображает свойства, можете поподробней объяснить?
Большое Вам спасибо.
Свойства он никак не отображает. Если вы напишете строчку, как предложили, вы не сможете задать ее через редактор
@@gamedevlavka [field: SerializeField] это на автосвойства, а если надо с логикой в сеттере то погугли [SerializeProperty]