Если влияет скорость - то 99% что виновата дискретность физики. Физика считается в FixedUpdate. Если ваш объект за один FixedUpdate полностью пройдет другой объект - то физика может не стриггерить их пересечение.
Вариант решения простой - участить FixedUpdate (где то в настройках Time проекта).
Вариант решения сложный - своя физика.
Проверять в каком нить апдейте eventSystem.currentSelectedGameObject. Если он изменился и соответствует требованиям (например, на нем есть кнопка. Или можно по тегам сравнивать или еще по чему) - то играть звук.
Платформу вы не указали - а это важно.
Но вообще от ста коллайдеров, которые как я понимаю будут детектить ТОЛЬКО клики и не будут взаимодействовать физически - ничего не случится.
Но я бы так не делал от слова совсем. Можно попробовать использовать какую то карту кликов (цветовую) и по ней уже определять.
Ну в BuildSettings есть exportProject - позволяет выгнать наружу проект под AndroidStudio.
И дальше уже колдовать.
Знаю что люди так извращались. Но вот зачем - вопрос открытый.
Какую то часть - можно. Если вам ВООБЩЕ в игре не нужен визуал (игра для слепых) - то в принципе 90% задач там решается через код.
Если визуал нужен, то уже будет сильно сложнее, но все еще не невозможно.
Но если резюмировать - то юнити для "написания игр ТОЛЬКО кодом" - не лучший выбор.
Из быстрых идей:
- эффект черно-белого делать не камерой, а шейдером объекта. И включать соответственно только для нужных объектов
- несколько камер +разбитие по слоям и перенос объектов между слоями.
