На счет музыки не совсем понял. То есть при смене музыки трек меняется резко, без приглушения? У нас композитор явно настаивал на плавном угасании первого трека и нарастании второго. Иначе может по слуху бить.
А вот идея с указанием в какой канал воспроизводить звук мне не очень понятна. Вот у вас эти классы по умолчанию в первый канал пишут, так если их два запустится, то один прибьется сразу, хотя два канала пустые еще? Зачем указывать номер канала, не лучше ли просто ограничить число каналов до 3 и играть если есть свободные. Причем так можно сделать даже лучше. При запуске звука указывать его приоритет и прибивать менее приоритетные звуки если свободных каналов нет.
Но в целом я думаю, что ограничивать звук 3 каналами смысла мало. Более менее больших звуков в один момент времени больше 1-2 быть не должно. А мелких звуков, вроде клика может быть много, но их можно импортировать без сжатия в wav. Тогда их проигрывание не будет просаживать производительность сильно. Какое то ограничение, конечно нужно, но тут уже экспериментально и от таргет устройства зависит.
Спасибо за поправку. Заменил эту проверку на две. На количество таких же звуков и на общее количество.
А на счет констант. Я вынес в константы то, что с чем можно играться(AutoPause, MusicFadeTime). Мне не хотелось, чтобы кто то увидел это число в константах и решил что его стоит тюнить под себя. Все же это не настройка менеджера в моем понимании, а защита от зацикливаний.
Спасибо!
На счет передачи AudioClip. Я хотел единообразия кода и хранения всех звуковых файлов в одном месте. А с передачей по Clip-у его можно будет положить куда угодно. Начнешь класть в другую папку, а потом захочется этот же звук по имени вызвать и не заработает. В общем то дело вкуса и класс легко можно дописать по нраву.
Интересный эффект, красиво выглядит. А можете проект-образец выложить, чтобы поиграться?
Не совсем понял к чему эти сложности с расчетом круга по радиусу. Почему не использовать текстуру маску?
Батчинг работать будет. Canvas и Image созданы для удобства создания интерфейсов и выйгрыша в скорости в большинстве случаев по сравнению со спрайтами не дадут. Ну и странно немного слышать аргументы о производительности после настолько неоптимального использования ресурсов(read/write текстуры, ReadPixels/SetPixels и пр.) и аргументов о том, что это позволительно, так как производительности хватает.
А расставлять страны вручную, да еще и со скейлом это вообще неблагодарное дело.
Может я просто описал не очень хорошо. Некоторые вещи проще один раз показать: www.dropbox.com/s/pl7l5i5hsck2yjg/2015-06-22_22-37-36.mp4?dl=0
1. Не вижу сложности при соединение стран — спрайтов. Да и особой разницы канвас или спрайт в этом случае тоже.
2. Так редактировать то ничего и не нужно. Ну если только сгенеренный коллайдер не устроит. Так это ж наоборот плюс. По некоторым маленьким странам очень солжно попасть. И область клика у них явно нужно делать больше, чем сама страна.
3-4. Я просто решил, что вам удобно пользоваться PointerClick. Ну и удобно все таки, тут вам и драг энд дропы и все остальное.
5. Самое верное — скачать стандартные шейдеры и изучать их. Удобно, так как достаточно лишь чуть изменить код и у вас уже готовое решение. В частности стандартный шейдер спрайта советую брать за базовый. Ну и литературу тоже полезно читать, но тут уж без конкретики, что найдете. Разницы нет особой.
Какой то список вредных советов, не иначе. Первая картинка особенно пугает. Использовать канвас для такой задачи просто странно. Я бы сделал все так:
1. Страны — это спрайты, рендерятся СпрайтРендерами без всяких канвасов.
2. К СпрайтРендерам добавляется ПолигонКоллайдер2Д и он автоматически принимает форму спрайта, ничего не нужно делать вручную. Если сгенерился не очень аккуратный, можно сразу подредактировать.
3. Вешаем на этот спрайт свой скрипт, он имплементирует iPointerClickHandler.
4. На камеру вешаем PhysicsRaycaster2D, в сцену добавляем объект EventSystem. После этого скрипт карты начинает принимать сообщения о кликах.
5. Если нужно подсветить какую то страну — пишем простенький шейдер и накладываем материал на этот спрайт.
В итоге кода то и не будет в программе. Только обработчик клика. Ну и шейдер осветления, если действительно нужен.
Read/Write — не просто так вынесли в дополнительные настройки — его не стоит использовать просто так.
Если все дело в глобальных результатах и призе, то проблему вовсе не обязательно решать так основательно на мой взгляд. Можно же просто сделать запись реплеев и возможность их воспроизведения. Никакой автоматизации или чего то подобного не нужно. Просто с каждым результатом на сервер присылается файл реплея и хранится. Пользователю показывается его результат сразу, но в глобальной таблице рекордов висит надпись «Обновляется раз в пару дней». И раз в пару дней специальный человек берет лучшие 10 игр и просматривает их реплеи. Если в них все хорошо — заносит их в глобальный лидерборд.
Конечно, такой подход подразумевает, что в глобальном лидерборде будут только 10(или 100) человек отображаться, а не все, но так ли это страшно? В конце концов можно показывать помимо главного лидерборда и, к примеру, «среди друзей» без модерации да и просто свой счет без модерации. Самое интересное в таком подходе то, что игрок сразу видит и понимает, что результат модерируется, а значит и желания взломать будет намного меньше и хакеров будет очень мало.
Да и по поводу ботов — их неуловить. Если взломали протокол или игру — это одно, но если имитируют человека, то это уже очень сложно доказать будет, что это был не человек. Прошел с первого раза? Я на аккаунте друга тренировался! Идеально кликает раз в 33 мс? Я в этом не виноват, презумпция невиновности, все дела. Да и бот скорее всего будет кликать с рандомом. Но если уж очень хочется ловить в том числе и ботов, то описанный способ как никакой другой подходит и для этого. Просмотр реплея вручную может дать очень много и бота придется писать очень сложного, при этом хакеру такой писать не захочется — он же не знает как происходит модерация, но знает, что она есть. Тратить неделю на супер бота при большом риске не пройти модерацию не захочет даже опытный хакер.
Недавно тоже занимался проектом, связанным с парсингом выражений на C#. Использовал NCalc. Есть и функции и переменные. Приведенные примеры реализуемы на нем без проблем.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
А стандартный подход с использованием Shader Variant Collections не работает на WebGL?
А вот идея с указанием в какой канал воспроизводить звук мне не очень понятна. Вот у вас эти классы по умолчанию в первый канал пишут, так если их два запустится, то один прибьется сразу, хотя два канала пустые еще? Зачем указывать номер канала, не лучше ли просто ограничить число каналов до 3 и играть если есть свободные. Причем так можно сделать даже лучше. При запуске звука указывать его приоритет и прибивать менее приоритетные звуки если свободных каналов нет.
Но в целом я думаю, что ограничивать звук 3 каналами смысла мало. Более менее больших звуков в один момент времени больше 1-2 быть не должно. А мелких звуков, вроде клика может быть много, но их можно импортировать без сжатия в wav. Тогда их проигрывание не будет просаживать производительность сильно. Какое то ограничение, конечно нужно, но тут уже экспериментально и от таргет устройства зависит.
А на счет констант. Я вынес в константы то, что с чем можно играться(AutoPause, MusicFadeTime). Мне не хотелось, чтобы кто то увидел это число в константах и решил что его стоит тюнить под себя. Все же это не настройка менеджера в моем понимании, а защита от зацикливаний.
На счет передачи AudioClip. Я хотел единообразия кода и хранения всех звуковых файлов в одном месте. А с передачей по Clip-у его можно будет положить куда угодно. Начнешь класть в другую папку, а потом захочется этот же звук по имени вызвать и не заработает. В общем то дело вкуса и класс легко можно дописать по нраву.
Не совсем понял к чему эти сложности с расчетом круга по радиусу. Почему не использовать текстуру маску?
А расставлять страны вручную, да еще и со скейлом это вообще неблагодарное дело.
www.dropbox.com/s/pl7l5i5hsck2yjg/2015-06-22_22-37-36.mp4?dl=0
1. Не вижу сложности при соединение стран — спрайтов. Да и особой разницы канвас или спрайт в этом случае тоже.
2. Так редактировать то ничего и не нужно. Ну если только сгенеренный коллайдер не устроит. Так это ж наоборот плюс. По некоторым маленьким странам очень солжно попасть. И область клика у них явно нужно делать больше, чем сама страна.
3-4. Я просто решил, что вам удобно пользоваться PointerClick. Ну и удобно все таки, тут вам и драг энд дропы и все остальное.
5. Самое верное — скачать стандартные шейдеры и изучать их. Удобно, так как достаточно лишь чуть изменить код и у вас уже готовое решение. В частности стандартный шейдер спрайта советую брать за базовый. Ну и литературу тоже полезно читать, но тут уж без конкретики, что найдете. Разницы нет особой.
1. Страны — это спрайты, рендерятся СпрайтРендерами без всяких канвасов.
2. К СпрайтРендерам добавляется ПолигонКоллайдер2Д и он автоматически принимает форму спрайта, ничего не нужно делать вручную. Если сгенерился не очень аккуратный, можно сразу подредактировать.
3. Вешаем на этот спрайт свой скрипт, он имплементирует iPointerClickHandler.
4. На камеру вешаем PhysicsRaycaster2D, в сцену добавляем объект EventSystem. После этого скрипт карты начинает принимать сообщения о кликах.
5. Если нужно подсветить какую то страну — пишем простенький шейдер и накладываем материал на этот спрайт.
В итоге кода то и не будет в программе. Только обработчик клика. Ну и шейдер осветления, если действительно нужен.
Read/Write — не просто так вынесли в дополнительные настройки — его не стоит использовать просто так.
Конечно, такой подход подразумевает, что в глобальном лидерборде будут только 10(или 100) человек отображаться, а не все, но так ли это страшно? В конце концов можно показывать помимо главного лидерборда и, к примеру, «среди друзей» без модерации да и просто свой счет без модерации. Самое интересное в таком подходе то, что игрок сразу видит и понимает, что результат модерируется, а значит и желания взломать будет намного меньше и хакеров будет очень мало.
Да и по поводу ботов — их неуловить. Если взломали протокол или игру — это одно, но если имитируют человека, то это уже очень сложно доказать будет, что это был не человек. Прошел с первого раза? Я на аккаунте друга тренировался! Идеально кликает раз в 33 мс? Я в этом не виноват, презумпция невиновности, все дела. Да и бот скорее всего будет кликать с рандомом. Но если уж очень хочется ловить в том числе и ботов, то описанный способ как никакой другой подходит и для этого. Просмотр реплея вручную может дать очень много и бота придется писать очень сложного, при этом хакеру такой писать не захочется — он же не знает как происходит модерация, но знает, что она есть. Тратить неделю на супер бота при большом риске не пройти модерацию не захочет даже опытный хакер.