3D.ru

Почему на один объект можно наложить только один тег? На один объект по тегам можно вешать кучу характеристик.
Это конечно не критично, но и немножко сковывает.

Неодроповый Антарес поможет, как я понимаю, обтежить чего угодно
Но что Вам мешает вместо тегов пользовать параметры внутри скрипта и бродкаст-сообщения?

Да, в Антаресе есть система мультитагов (Multitags), позволяющая применить любое число тагов (tags) к одному объекту. Качай - изучай.
Система проста в применении как две копейки.

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

Тогда жду пример задачи, в которой желательна мультитаговая надсройка и ваш вариант ее реализации (естесственно, в двух словах).
Зачем? Чтобы привести альтернативные примеры

Например кубик - это нечто по которому бежит персонаж или не бежит. Даю ему тег Road - персонаж по нему спокойно бежит. Без этого тега тоже кубик но с дыркой - персонаж падает. Теперь я на кубик с Road добавляю тег Ice и это уже скользкий кубик с дополнительными действиями.
И перед стартом игры по поиску тегов формирую массив который персонаж читает по ходу движения.

Понятно. Логика поверхности. А <Road>, <Ice> и <Road && Ice> подразумевают разные действия? Точно <Road && Ice> будет отличен от <Ice>?
1 - Можно читать материал/текстуру на поверхности и по результату определять свойства.
2 - Можно из поверхности под ногами ГетКомпонентить все, что хочется. Скажем, по true тэга <могу здесь идти> запрашиваем все данные.
3 - Можно (я извращенец, поскольку до безумия люблю бродкасты) кидать бродкаст в поверхность под ногами и получать бродкастом в ответ нужные данные.
4 - Можно пользовать мультитэги, но тут придется, действительно, создавать хитрые связки тэгов друг с другом и потом это обрабатывать.

Наверное, лучше всего использовать второй вариант, поскольку он нересурсоемкий и не требует никаких массивов и выборок, а описание поверхности достаточно будет сделать в инициализирующем скрипте этой поверхности на флажках и параметрах.

Мультитагами можно это сделать за три строчки. Но, если "не хочется ничего подключать"...

Paul Siberdt писал(а):Понятно. Логика поверхности. А <Road>, <Ice> и <Road && Ice> подразумевают разные действия? Точно <Road && Ice> будет отличен от <Ice>?

Скорее подразумевают <Road + Ice>. То есть, к действию Road - возможность идти по поверхности, добавляется Ice, по которому же тоже можно идти (свойства Road), но с дополнительными фишками.

Спасибо, я то справился. У меня всё на массивах Просто с тегами было бы красивее... Нео бы не делал, если бы не было полезно

Ну, я бы просто поверхности поставил два параметра - булевское isMovable плюс коэффициент льдистости. И для грунтовой дороги коэффициент был бы нулевой, для дороги по пресному льду - эдак 0.6, по солёному - 0.83, а дороге из крем-брюле назначил бы 0.4

Paul Siberdt писал(а):Ну, я бы просто поверхности поставил два параметра - булевское isMovable плюс коэффициент льдистости. И для грунтовой дороги коэффициент был бы нулевой, для дороги по пресному льду - эдак 0.6, по солёному - 0.83, а дороге из крем-брюле назначил бы 0.4

Ну у меня по клеточная игра, так что массив быстрее прочитать. Просто взяв позицию персонажа и по ним обратится к ячейкам в которых всё есть

Ага.. тогда это самое оптимальное решение.
Если массив не из объектов сделать, а из классов, что содержат эти объекты, можно вообще забыть про тэги и их поиск.

Да, возможно...

Можно ещё идентификаторы в имени объекта закладывать через суффиксы-префиксы и gameObject.name.Contains.

Или навешивать монобехи-маркеры. Вариантов куча, в том и сила Юньки - нет одного решения для любой задачи. Всегда есть варианты.