после сбора которых на экране должно выводить какое либо сообщение(ты победил/все собрал). Я предполагаю, что делать через массив и FindgameobjectWithTag, но не получается полностью реализовать...
FindgameobjectWithTag - Зачем?
Создаёшь скрипты-пустышки. Именуешь CoinSpawnPoint. Расставляешь по карте. На старте уровня - ищешь все эти скрипты, на их месте спавнишь нужные тебе коллектаблс. Заносишь все заспавненные коллектаблс в список. Прокидываешь в них скрипт-спавнер. При подборе коллектаблс - обращаешься к скрипту спавнеру и просишь удалить себя из списка. В корутине, которую запустил на старте уровня, ждёшь пока список всех коллектаблс не станет равным 0. Profit.
У меня монеты вручную расставлены. Вариант сверху пока проще реализоват. Но учту
Так по факту +- то же самое будет. На родителе скрипт с счётчиком и ждёшь нуля , просто без спауна
Варианты сверху мало того что по производительности будут бить, используя теги и проходясь по всем объектам на сцене, так ещё и при попытке добавить логики придётся писать костыли. Про возможность в один клик подменить все нужные тебе объекты на новые, я и вовсе молчу
А лучше расставлять пустышки, искать их на сцене,удалять, создавать новые объекты , кэшируешь их с помощью того же поиска в спавнер ? Почему это производительнее чем положить все в родителя? Я может что-то не так поняла
Дело в том, что жизнь разработчика полна сюрпризов. Сегодня ты сделать вариант "по-проще". А завтра приходит геймдиз и просит тебя на месте монеток заспавнить врагов и ты в мыле сидишь всё переписываешь. На следующий день тебе скажут что всё фигня - давай вернёмся обратно к монеткам, только подкинем другой тип монеток. Ещё через день попросят не маяться фигнёй и добавить возможность проведения А/Б тестов. Поэтому лучше сразу учитывать такие неприятные вещи, тем более что для написания кода, который будет способен подстраиваться под разные ситуации, много времени не нужно
Все равно не вижу проблемы пихать все в родителя Объект сам себя удалил, соответственно он сам убрался из списка , спавнера в каждом объекте хранить не надо, не надо никого на сцене искать и считать Провериь на ноль - просто на пустоту родителя Пихай туда что хочешь Если могут быть разных типов монеты - так интерфейсы в помощь
Проверка на null в каждом кадре - тоже не бесплатное удовольствие. А я жадный. Да и в целом это такой себе архитектурный подход. Как и писал выше - банальная замена префаба монетки выльется в многочасовую боль. Особенно если монеток на уровне штук 300
Ну поменять префабы это написать один скрипт для эдитора В твоём же варианте ты предлагал запустить корутину, которая ждёт пока список не станет 0 В чем отличие от запустить такую же и не ждать пока patent.length не станет 0?
Потому что, как минимум, появляется зависимость от редактора юнити. Закинет твой коллега в этот объект какую-нибудь шелупонь, которая удаляться никогда не будет и всё - сиди думай почему у тебя игра не кончается. По поводу корутины - выбрал для примера как наиболее понятный. Для себя бы подключил UniRx, сделал бы ReactiveCollection и подписался на его "обнуление". Да и в целом многие моменты поменял бы. Но для старта - и предложенного варианта хватит, чтобы понять в какую сторону воевать
Отличие в том, что не мешается иерархия сцены (конфигурация) и код. В этого родителя можно легко случайно добавить что-нибудь, что монеткой являться не будет. Если же использовать список/массив ICollectable/Coin, то ты точно можешь быть уверена, что там ничего кроме подбираемой монетки не будет лежать.
Да, с этой точки зрения точно лучше:) поняла, спасибо
каким методом проверить
Обсуждают сегодня