Привет! Я что-то не понимаю. У меня есть в планах создать на сцене 100 врагов и если он будут брать данные о своем здоровье из скриптбобжекта, то тогда, получается что если я одного врага уничтожу , то и все тоже уничтожатся? Или нужно иметь поле со здоровьем у врага и присваивать ему при создании параметры из скриптбобжекта и тогда получается каждый враг будет не зависим друг от друга, но в итоге ведь получается все равно память кушают? Или нет? Или я что-то не так понял?
давай по порядку: то, что 100 врагов будут брать данные из SO, означает лишь то, что у них будет *ссылка* на сам SO, который будет храниться как ассет в проекте. Если враг уничтожается, это никак не затронет оригинальный ассет, хоть даже все враги уничтожатся. Касательного второго тезиса - да, если явно хранить поля у врагов, и инициализировать (по сути копировать) со скриптабл обжекта, то у каждого врага будут свои копии данных, которые и будут кушать память. Поэтому посыл такой - те данные, которые статические и не меняются по ходу игры (например, максимальное хп, скорость ходьбы, урон и тд) - лучше хранить в SO, и назначать ссылку на него во врагах. В общем точно также как в видео
Супер! Хотелось бы увидеть на простом примере, как реализовать расчет, к примеру, монет. Например - 1.есть класс(не монобех), который содержит методы подсчета монет. 2. Есть класс, который хранит количество монет(не моноюбех). 3. Есть класс, который обновляет и выводит в UI монеты, после получения/вычетания(монобех). Собственно, как это все подружить между собой?
не совсем понял суть задания - что именно такое подсчет монет. Но в любом случае, связь между классами будет такая: в каком-то месте создается класс (2), затем создается (1), и в его конструктор передается экземпляр класса (2) (как я понял, класс (1) будет зависеть от класса (2), а наоборот нет). Ну и напоследок инстанциируем класс UI, в нем создаем метод Setup/Create(), куда и передаем класс (2). по сути имеем MVC: (1) - контроллер / сервис (2) - модель (3) - представление
Спасибо за видео! В видео был наведен пример, что для многих монобехов можно использовать один и тот же скриптабл обджект. Я правильно понял, что это имееться ввиду имено какой-то конфиг? Вот что я имею ввиду. У нас есть 2 врага, хп которых ссылаеться на один SО. Получаеться что значение хп будет одно на всех. И при дамаге будет уменьшаться хп у всех врагов. Я понял, что если это например значение, которое будет меняться в каждого монобеха индивидуально, то в SO мы просто задаем стандартное значение для всех врагов, а уже внутри врагов это значение просто копируеться в переменую монобеха.
Да, все верно! именно так. В скриптабл обжекте должны быть так называемые immutable в runtime данные - т.е. во время игры мы не можешь их изменить, только считать.
По моему мнению немного плохой пример был в видео. Для подобных целей лучше просто создать статические переменные и не париться. Ссылка на scriptable object сама по себе весит какое-то количество бит (32 или 64 бита), как и любая другая ссылка.
@@SliverRus Возможно конкретно для примера с видео статические переменные и будут альтернативой, но для реального проекта учти такие нюансы: 1) Расширяемость: если тебе помимо хп и скорости нужно будет добавить куча других параметров (урон, ускорение, мана и тд), то тебе постоянно нужно добавлять все новые статические переменные. Да, можно выделить это все в отдельный класс, но см. след. пункты; 2) Удобство: чтобы менять баланс, тебе нужно менять код, и таким образом ты теряешь гибкость и скорость теста. Со скриптабл обжектами ты можешь прямо в инспекторе во время игры легко менять переменные и смотреть результат. 3) Переиспользуемость: если у тебя много типов врагов, то ты можешь для одних использовать одни данные, для других - другие, НЕ добавляя новый класс - для обычных статических данных ты так не сделаешь.
@@SliverRus нужно смотреть не только на производительнось, а и на практичность. Так можно собственный движок писать, если так смотреть. Статика не хороший вариант. По имени метода ты уже не будешь понимать что внутри. Когда идет обьявление конфига в скрипте, то стает понятно, от этих данных, что подразумевает под собой данная сущность. И не нужно раскрывать каждый приватный метод, чтобы посмотреть а не юзаеться ли там какие-то статические данные.
Чет как то избегал SO, когда что-то делал в юнити. Может быть и зря... Очень часто использую ОнТриггер и ОнКоллижн, ибо удобно. Ну и монобехи, ессно... даже слишком часто))) Собственно я вообще пишу как курица лапой)) Сказывается отсутствия опыта и нормального ментора, который бы не просто говорил "Все г - переделывай", а показал как надо... В онлайн школе такого обещали, но потом сказали "специалистов слишком мало, так что ментора не будет" :D Так что пишу диплом ломая мозг даже над очевидными задачами... А учиться по ютубу... в интернете десятки тысяч видео о том, как делать игры на юнити, но на поверку оказывается, что 99% из них пишут такие же недоучки как я, просто с умением подать свои посредственные навыки, как что-то высокое и правильное. Даже на оффсайте юнити можно найти уроки, на которых забивают большой болт не то, что на ооп, но и, банально, на модификаторы доступа... Надеюсь у вас можно будет найти много полезной информации, которая поможет мне понять что к чему с другого угла обзора! )) Есть ли шанс увидеть от вас видео разбора кода, какой-нить "игры" с гита? О том, как там все плохо\хорошо и как надо было сделать лучше с примерами? Благодарю за видео и успехов вам в развитии канала!..
Добрый день, спасибо за отзыв! Да, понимаю ситуацию насчет онлайн школ ) Хороший ментор в таких ситуациях действительно необходим. Но если его нет, то стараться "вычленять" кусочки полезной инфы с разных источников, на том же самом оф сайте юнити - там может и действительно забивают на модификаторы доступа, но если взять цельную игру (те же Creator Kits: assetstore.unity.com/packages/templates/tutorials/creator-kit-rpg-149309 ; assetstore.unity.com/packages/templates/tutorials/2d-game-kit-107098 и другие), то можно много полезной инфы узнать, в т.ч. и по ООП и принципам хорошего кода. Через годика пол у вас уже сформируется неплохая картина, вполне достаточная чтобы вас взяли на работу джуном) А там дело быстрее пойдет (если вы конечно преследуете цель пойти работать профессионально 🙂 ) А что касается видео разбора кода - то вы по адресу) ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-jUBARokz-uw.html есть видео, где я делаю обзор кода с гита, там правда совсем простенькое тестовое задание, но вероятно ,узнаете для себя что-то новое. Также есть плейлист по созданию первой игры - ru-vid.com/group/PL1GWBpbrZiCm0JqqrV89NvIDINxUCK7Cr . Да, там тоже много базовой инфы для самых новичков, но все же и принципы хорошего кода тоже имеются. В будущем планирую повышать уровень проф. советов, не пропустите :)
Спасибо за урок, хотел бы предложить написать урок по поводу патерна состояния, во всех уроках про этот патерн, все убирают монобех и делают переклюячение в стейт машине, а как использовать тогда в игре если допустим в состоянии спокойствия, ты можешь подобрать камень а в других состояниях нет?Тоесть связи с объектами на сцене как пробрасывать?
планирую сделать уроки по паттернам, как появится больше времени. по поводу вопроса - как вариант хранить интерактивные объекты как коллекцию в какой-то сущности, с доступом по ключу (мб строке-имена). И при создании объектов состояния давать им ссылку (если организован DI), либо через синглтон напрямую обращаться.
Я правильно понимаю что вы предлагаете в SO запихнуть health персонажей когда их много, чтобы не хранить каждый из них отдельно? Не выйдет ли таакого что при изменении хитов у одного они поменяются у всех? Или вы предлагаете SO както инстантиировать для каждого отдельно? Или речь вообще была про maxHP?
Да, вы все правильно заметили. Использовать один SO на всех имеет смысл только если эти данные не меняются - т.е. если это maxHP например. Если же речь идет о текущем хп, то это уже динамические данные, которые уникальны для каждого персонажа. В этом случае можно в принципе вообще их не хранить в SO, а сделать просто полем в классе (но если уже и делать как SO, то только инстанциировать).
Перемещать игрока через Update. Привязывать перемещение к частоте кадров. Кто хочет, может загуглить, чем чревато перемещение по кадрам, в отличие от перемещения с помощью физики.
Во многих случаях использовать Update абсолютно допустимо - если твой персонаж не использует физику для перемещения, и если нет тяжелых (прям сильно) операций обновления. К тому же, реализовать кадронезависимое движение не составляет труда.
Расскажи про использование monoBehavior в качестве типа переменных Например есть скрипт Health.cs и в другом скрипте могут писать privat List heal = List(); Какие данные в данном случае передает Health?? Методы и переменные??
Не уверен что до конца понял вопрос, но попробую ответить) Монобехи в принципе - это обычные классы из c#, поэтому работа с их методами и переменными будет такая же. Единственное , юнити дает возможность удобно работать с ними в редакторе, например ссылаясь на них из других монобехов (так, в твоем случае, если заменить private на public, можно назнать ссылки на другие Health, в твой скрипт). И дальше ты можешь оперировать экземпляром Health как обычно - вызывать его методы, возможно обращаться к полям, если те публичные.
А что если создам 10 персонажей, мне нужно будет создать 10 скриплт обджектов для того что бы каждому выдать уникальное значение хп, скорости, урона или лучше в таком случае использовать унаследование от монобехейвор
тут зависит не сколько у тебя типов врагов, а сколько экземпляров каждого из них. Будь у тебя хоть 100 типов врагов, но если каждого из них нужно в сцене 1000 экземпляров, то все равно оптимально засунуть данные в скриптабл обжект, и ссылаться на него в каждом экземпляре врага.
Скажите, какая разница занесу я данные врага в scriptable object или в mono, если я каждому врагу прикрепляю один скрипт, а не тысячу разных? Или один скрипт у разных врагов создаёт новую ячейку в памяти?
Да, даже если вы прикрепите один скрипт, в игре будет создаваться столько экземпляров скрипта, сколько врагов. Соот-но, и копия данных будет находиться в каждом из экземпляров. В случае со скриптабл обожектом, вы просто ссылаетесь на данные, на единственный экземпляр. К слову, на самом деле ссылаться на данные можно даже если и они в MonoBehe находятся) тогда вам просто нужно иметь объект на сцене (с прицепленным скриптом), но это менее удобный способ, т.к. легче потерять ссылку (например если случайно удалить объект)
