Начало разработки под Android
Разработка игр для устройств с Android OS требует подхода, схожего с разработкой под iOS. С другой стороны, аппаратное обеспечение Android-устройств не подчиняется чётким стандартам, что заставляет решать вопросы, которые отсутствуют при работе с iOS. Также присутствуют различия между версиями Unity для Android и iOS.
Подготовка среды разработки для Android
Прежде чем вы сможете протестировать свои игры на устройстве, вам нужно будет подготовить среду разработки. В частности — скачать и установить Android SDK нужной платформы и добавить ваше устройство в систему (этот процесс отличается для Windows и Mac). Об этом подробно написано на сайте Android-разработчиков, а также дополнительную информацию может предоставлять производитель вашего устройства. Так как это достаточно сложный процесс, мы приготовили небольшую инструкцию которая поможет вам подготовить всё необходимое для разработки. Если вам понадобится больше информации, вы сможете получить её на портале Android-разработчиков.
Доступ к функциям Android
Unity предоставляет API для доступа к средствам ввода и настройкам Android. Доступные классы задокументированы на странице Написание кода для Android сборок.
Привязка C, C++ или Java кода к скриптам
Unity позволяет вызывать функции, написанные на C/C++, непосредственно из скриптов (Java-функции могут быть вызваны непрямым способом). Чтобы узнать как из Unity получать доступ к функциям из нативного кода, посетите страницу о сборке плагинов для Android.
Occlusion Culling (отсечение невидимой геометрии)
Unity предоставляет поддержку occlusion culling, что очень полезно при оптимизации для мобильных платформ. Больше информации можно найти на странице Occlusion culling.
Настройка начальной заставки
Заставка, отображаемая при запуске игры, может быть настроена — см. эту страницу для дополнительной информации.
Решение проблем и сообщения об ошибках
Существует множество причин, из-за которых ваше приложение вылетает или не работает должным образом. Наше руководство по решению специфических для Android проблем поможет вам разобраться с причинами ошибок в кратчайшие сроки. Если после прочтения руководства вы предполагаете, что проблема именно в Unity — вам следует составить сообщение об ошибке. Обратитесь к этой странице за инструкциями.
Как Unity для Android отличается от версии для настольных компьютеров
JavaScript со строгой типизацией
Для улучшения производительности в Android-версии Unity динамическая типизация в JavaScript всегда отключена (как если бы к каждому скрипту автоматически применялась #pragma strict). Это важно помнить, если вы переносите на Android проект со старших платформ, и если вы столкнётесь с ошибками компиляции — проблему стоит искать в первую очередь в типизации. С такими ошибками обычно легко справиться, убедившись что типы всех переменных явно указаны или приведёны при инициализации.
ETC — рекомендуемый способ сжатия текстур
Хоть Unity Android и поддерживает DXT/PVRTC/ATC текстуры, Unity распакует текстуры в формат RGB(A) при выполнении, если эти методы сжатия на поддерживаются на конкретном устройстве. Это может серьёзно повлиять на производительность GPU отрисовки, потому рекомендуется использовать формат ETC. Он является фактическим стандартом для Android, и должен поддерживаться всеми современными устройствами. С другой стороны, ETC не поддерживает альфа-канал, и иногда 16-битные RGBA текстуры будут лучшим выбором по критериям качества, размера и скорости рендеринга там, где нужен альфа-канал.
Также возможно создать несколько дистрибутивов игры (apk-файлов) с разными форматами текстур, чтобы Android Market сам предоставлял для каждого устройства наиболее подходящий из дистрибутивов. За подробностями обратитесь к этой странице.
Проигрывание видео.
Видео текстуры (MovieTexture) не поддерживаются на Android, но программно доступно полноэкранное поточное проигрывание. Для дополнительной информации о поддерживаемых форматах файлов и API скриптинга, ознакомьтесь со страницой класса MovieTexture или со страницей поддерживаемых на Android форматах медиа.
Введение
Прежде всего, хочу сразу отметить, что я не являюсь профессиональным разработчиком. В этой статье я постараюсь изложить свой опыт создания игры «Feel Speed Racing». Данный материал, скорее всего не будет интересен тем, кто уже имеет большой опыт в разработке игр, но начинающим разработчикам, которые хоть немного работали с Unity думаю, будет интересно.
Дизайн
Концепция игры заключается в том, что автомобиль должен пройти, как можно большее расстояние при этом на дороге динамически появляются препятствия их надо объезжать мимо иначе «игра окончена» еще нужно следить за шкалой топлива и собирать на дороге топливные баки, по истечению которой игра тоже останавливается.
Разработка
Игра состоит из 2-х сцен: главное меню и сама игровая сцена:
Где «menu» это главное меню а «1» это игровая сцена.
Главное меню
Для создания столь незамысловатого меню нам потребуется элемент управления GUI, который является стандартным в Unity.
В качестве фона я использовал спрайт с именем «background» заполненный серым цветом. Вы же можете выбрать что угодно.
Далее создаем скрипт «menu.cs»(Щелкаем правой кнопкой->выбираем Create-> C# Script) и вешаем его на background.
В результате должно получиться примерно вот так:
Шрифт, цвет и размер GUI элементов вы можете изменить с помощью MyStyle.
Создание игровой сцены
Основными на этой сцене элементами является дорога, автомобиль и шкала топлива.
Ввиду того что гонка является бесконечной и останавливается только когда машина попадет в препятствие или закончится бензин, дорога является двигающейся. То есть автомобиль может перемещаться влево или вправо, а иллюзию движения по прямой создает дорога.
Кидаем спрайт с дорогой на игровую сцену и подгоняем по размерам камеры.
Затем добавляем как дочерние объекты внутрь дороги 4 блока с препятствиями, топливный бак и не забываем добавить к ним Box Collider 2D.Еще надо отметить Is Triger для пересечения с автомобилем.
Теперь создаем скрипт moveroad.cs и вешаем его на нашу дорогу.
Добавляем в него следующий код:
Должно получиться примерно вот так. Если все так оставить то после того как дорога пройдет до конца то будет оставаться пустое пространство и так будет по кругу, дорога будет исчезать.
Что бы решить эту проблему надо создать дубликат уже готовой дороги и немного изменить скрипт.
Должно получиться вот так.
Кидаем спрайт автомобиля на сцену и устанавливаем его в любое место на дороге. Затем создаем скрипт carcontroller.cs и вешаем его на автомобиль.
Теперь автомобиль может перемещаться.
Для создания шкалы потребовалось 2 спрайта одинаковых размеров, но разных цветов (красный, зеленый). И сделать один из них дочерним (зеленый).
Далее создаем скрипт fuelscript.cs, вешаем его на fuel и добавляем в него код:
Дорога у меня это road183 и ее дубликат road183(1). В ее дочерний объект fueltrack нужно добавить скрипт для обнаружения пересечения с автомобилем и восполнения топлива.
Создаем скрипт triger.cs и вешаем его на fueltrack в обеих дорогах и отмечаем как Is Triger. Код:
В момент выпуска игры на Google Play я особо не занимался ее продвижением ну и само собой закачек не набралось.
В отсутствие профессионального художника, с иконкой пришлось работать самостоятельно:
Как быстро написать игру для Android на Unity
В нынешнее время каждый может стать успешным разработчиком мобильных игр или приложений, не прилагая к этому титанических усилий. Примером такого случая является Донг Нгуен, разработавший Flappy Bird. В игре не было никакой сложной механики или графики, но это не помешало ей стать популярной и приносить своему создателю по пятьдесят тысяч долларов в день. Однако в игре не было ничего примечательного. Всё, что потребовалось для успеха, — оказаться в нужном месте в нужное время и немного удачи. Подобное может произойти и сегодня, вам просто нужна правильная идея.
Чтобы продемонстрировать, насколько легко написать что-то подобное, сегодня мы напишем свой Flappy Bird с помощью Unity всего за 10 минут.
Игровой персонаж
Сначала создайте новый проект и убедитесь, что выбрана опция 2D.
Загрузите свой спрайт птицы в сцену. Не забудьте включить фантазию!
Затем отрегулируйте размер спрайта как вам нравится, перетягивая его за угол в нужном направлении. Спрайт должен быть виден в окне иерархии ( hierarchy ) слева. В нём видны все объекты в сцене, и на данный момент их должно быть всего два: камера и птица.
Перетащите камеру на птицу и отпустите. Камера должна оказаться под птицей, это будет значить, что камера теперь «ребёнок» птицы. Теперь позиция камеры будет фиксироваться относительно птицы. Если птица двигается вперёд, то камера делает то же самое.
Снова выберите птицу в сцене или в окне иерархии. Вы увидите список опций и атрибутов справа в окне под названием Inspector . Здесь вы можете управлять различными переменными, привязанными к определённому объекту.
Теперь нажмите на Add Component . Выберите Physics2D > Rigidbody2D — это готовый набор инструкций для применения гравитации к нашему персонажу. Нажмите на Constraints в этой панели и затем выберите freeze rotation Z . Это позволит предотвратить вращение птицы вместе с камерой по кругу.
Таким же образом добавьте Polygon Collider , который говорит Unity, где находятся границы персонажа. Нажмите Play и увидите, как спрайт вместе с камерой бесконечно падает вниз.
Пока всё идёт хорошо!
Теперь пора заняться полётами персонажа, благо это будет несложно.
Сначала нужно создать C#-скрипт. Создайте для него папку (кликните правой кнопкой мыши где-нибудь в assets и создайте папку «Scripts»), сделайте клик правой кнопкой мыши и выберите Create > C# Script .
Назовём его «Character». Кликните по нему дважды, чтобы открыть его в вашей IDE, будь то MonoDevelop или Visual Studio. Затем добавьте следующий код:
Этот код делает две вещи. Он заставляет персонажа двигаться вперёд со скоростью, которую мы определим в инспекторе, и создаёт ощущение полёта птицы. Метод Update() вызывается повторно на протяжении игры, поэтому всё, что вы сюда поместите, будет выполняться непрерывно. В данном случае мы добавляем немного скорости нашему объекту. Переменная rb является скриптом RigidBody2D , который мы применили к нашему объекту ранее, поэтому когда мы пишем rb.velocity , мы обращаемся к скорости объекта.
Тап по экрану интерпретируется Unity как клик мыши, если вы используете мобильное устройство. После нажатия мы заставляем персонажа немного подняться вверх.
Переменная moveSpeed будет отвечать за скорость движения, а переменная flapHeight — за увеличение высоты полёта птицы после каждого нажатия. Поскольку эти переменные объявлены как public , мы сможем изменить их вне скрипта.
Метод Death() тоже объявлен как public , что значит, что другие объекты и скрипты смогут его вызвать. Этот метод просто возвращает положение персонажа в начало. Также он будет использоваться каждый раз, когда персонаж будет залетать слишком высоко или низко. Скоро вы поймёте, почему он объявлен именно как public . Строка rb.velocity = Vector3.zero; нужна, чтобы убрать импульс — мы же не хотим, чтобы после каждой смерти персонаж падал всё быстрее и быстрее?
Теперь можно выходить из IDE и добавлять скрипт как компонент к персонажу. Для этого нужно выбрать нашу птицу и нажать Add Component > Scripts > Character . Теперь мы можем определять moveSpeed и flapHeight в инспекторе (для этого и нужны public -переменные). Присвоим переменным значения 3 и 5 соответственно.
И ещё: в инспекторе нужно добавить тег к персонажу. Для этого кликните там, где написано Tag: Untagged и затем выберите Player в выпадающем списке.
Препятствия
Теперь добавим препятствия: трубы. Кто-то в трубах находит грибы, а кто-то — свою смерть.
Перетащите спрайт трубы в сцену в место, где должно быть первое препятствие, и назовите его pipe_up .
Теперь создадим новый скрипт под названием Pipe :
Добавьте этот скрипт к спрайту трубы тем же образом, что и раньше. Таким образом, труба будет возвращаться на экран после выхода за его левую границу. Мы тут ещё ничего не сделали, но ещё вернёмся к этому.
Метод OnCollisionEnter2D() вызывается каждый раз при взаимодействии трубы с персонажем. После этого вызывается созданный ранее метод Death() , возвращающий игрока в начальную точку.
Итак, у нас есть одна труба, которая время от времени будет исчезать и появляться на другом конце экрана. Врежешься в неё — умрёшь.
Перевёрнутые трубы
Сейчас у нас есть только один спрайт трубы. Давайте добавим ещё один. Для этого кликните правой кнопкой мыши в окне иерархии, нажмите New 2D Object > Sprite и затем выберите спрайт, который хотите использовать. Ещё проще будет просто перетащить файл в сцену ещё раз.
Назовите этот спрайт pipe_down . В инспекторе в части Sprite Renderer выберите опцию Flip Y , чтобы перевернуть трубу вверх ногами. Добавьте такое же RigidBody2D .
Теперь напишем новый C#-скрипт под названием PipeD . В нём будет похожий код:
Префабы
Итак, нам достаточно этого кода, чтобы сделать всю игру. Мы могли бы передвигать трубы на правую сторону экрана каждый раз, когда они исчезают, или скопировать и вставить столько труб, сколько мы хотели бы встретить на протяжении всей игры.
Если пойти первым путём, то убедиться, что трубы стоят как надо после случайной генерации, и поддерживать честный ход вещей было бы сложно. После смерти персонажа они могли бы появиться в километрах от первой трубы!
Если пойти вторым путём, то всё закончится излишним потреблением памяти, с вытекающим из этого замедлением игры, и ограниченной реиграбельностью, т.к. всё стоит на одних и тех же местах каждый раз.
Вместо этого давайте воспользуемся префабами. Если говорить просто, то мы превратим наши трубы в шаблоны, которые потом сможем использовать для эффективного создания большего количества труб по желанию. Если тут есть программисты, то считайте скрипт Pipe классом, а трубы — экземплярами этого объекта.
Для этого создайте новую папку «Prefabs». Затем перетащите pipe_up и pipe_down из окна иерархии в папку.
Каждый раз, когда вы перетаскиваете объект из этой папки в сцену, у него будут те же свойства, поэтому вам не нужно будет постоянно добавлять компоненты. Более того, если вы измените размер компонента в папке, это повлияет на все трубы в игре, и вам не придётся изменять каждую из них отдельно.
Как вы понимаете, это сильно сэкономит наши ресурсы. Также это означает, что мы можем взаимодействовать с объектами из кода. Мы можем создавать экземпляры наших труб.
Сначала добавьте этот код в условное выражение в методе Update() скрипта Pipe , которое мы оставили пустым:
Это нужно для создания экземпляра нашего gameObject . В результате получается новая идентичная копия. В Unity всегда, когда вы используете слово gameObject , оно ссылается на объект, к которому скрипт в данный момент привязан — в нашем случае к трубе.
Мы генерируем заново наши трубы в случайных вариациях, чтобы было повеселее.
Но вместо того, чтобы проделывать всё то же в скрипте PipeD , мы генерируем оба объекта в одном месте. Таким образом мы можем легко устанавливать положение второй трубы относительно первой. Также это значит, что нам нужно меньше кода для PipeD .
Создайте public gameObject с именем pipeDown . Затем обновите код следующим образом:
Мы добавили переменную gapRan , которая позволяет слегка менять расстояние между трубами, чтобы было интереснее играть.
Возвращаемся обратно в Unity и перетаскиваем префаб pipe_down из папки с префабами (это важно!) в место, где написано «Pipe Down» (заметьте, как наш camel case заменяется пробелом) на спрайт трубы pipe up . Если вы помните, мы определили Pipe Down как public gameObject , что даёт нам возможность определять, чем является этот объект откуда угодно – в данном случае через инспектор. Выбирая префаб для этого объекта, мы убеждаемся, что при создании экземпляра трубы он будет включать в себя все атрибуты и скрипт, которые мы добавили ранее. Мы не просто создаём спрайт, но пересоздаём объект с коллайдером, который может убить персонажа.
Всё, что мы добавим в то же место в скрипте PipeD — просто Destroy(gameObject) , чтобы труба саморазрушалась при выходе за левую границу экрана.
Если вы сейчас запустите игру, то экран будет продвигаться дальше автоматически, и вы умрёте, если столкнётесь с любой из труб. Пролетите достаточно далеко, и эти трубы исчезнут и появятся снова впереди.
К сожалению, между трубами большое расстояние, и экран выглядит пустым. Мы могли бы исправить это, добавив несколько префабов в нашу сцену, чтобы создать конвейер постоянно появляющихся труб. Однако было бы лучше генерировать трубы в скрипте. Это важно, так как в противном случае после смерти персонажа трубы в начале пути уничтожатся, и снова образуется пустое пространство.
Таким образом, мы можем создавать несколько первых труб во время каждой загрузки игры и возвращать всё на свои места после смерти персонажа.
Бесконечный полёт
Теперь создадим public -переменные pipe_up и pipe_down в скрипте Character . Это даст вам возможность ссылаться на созданные объекты, перетаскивая префабы на объект персонажа, прямо как когда мы добавили pipe_down в скрипт Pipe .
Нам нужно добавить эти переменные:
Затем мы напишем такой метод:
Мы будем вызывать его один раз в методе Update() и один раз в методе Death() .
После начала игры вызывается Update() , и наши трубы ставятся согласно заданной конфигурации. За счёт этого первые несколько препятствий всегда будут стоять на одном и том же месте. После смерти игрока трубы встанут на те же самые места.
Вернитесь в сцену в Unity и удалите две трубы, которые сейчас там находятся. Ваша «игра» будет выглядеть просто как пустой экран с птицей. Нажмите Play и трубы появятся, после нескольких первых их положение будет определяться случайным образом.
В заключение
Вот мы и сделали целую игру! Добавьте счётчик очков, попробуйте сделать его более оригинальным и увеличивайте сложность игры по мере продвижения. Также не будет лишним сделать меню. Ещё хорошей идеей будет уничтожать трубы на экране после смерти персонажа. Как только вы с этим закончите — считайте, что готовая к выпуску в Play Store игра у вас в кармане! Когда-то похожая игра сделала другого разработчика очень богатым, и это доказывает, что вам не нужно быть гением-программистом или иметь за своей спиной богатого издателя, чтобы достичь успеха. Вам просто нужна хорошая идея и десять минут!
Хотите писать приложения под Android, но не знаете, с чего начать? Тогда ознакомьтесь с нашей большой подборкой ресурсов для изучения Android-разработки.
Разработка мобильных игр на Unity в современных реалиях. URP, 2D Animation и все-все все на примере игры
Всем привет! Это снова Илья и сегодня мы поговорим о технической реализации мобильной игры в современных реалиях. Статья не претендует на уникальность, однако в ней вы можете найти для себя что-то полезное. А чтобы рассмотреть разработку на реальном проекте — мы возьмем реализацию нашей игры, которая на днях выходит в Soft-Launch.
Итак, запасаемся кофе, открываем Unity и погнали!
Начнем с того, что мы работаем с URP (Universal Render Pipeline). Почему так? Потому что он проще в настройке и обладает более гибким контролем, чем стандартный рендер. Ну и добиться хорошей производительности на тапках исходя из этого — намного проще.
Стоит указать, что ниже пойдет речь о 2D игре. Для 3D игр подходы будут несколько отличаться, как и настройки.
Мы реализовали два уровня графики. Low Level — для деревянных смартфонов и High Level — для флагманов. Уровни графики подключаются при помощи Project Settings.
В нашем проекте стоят следующие настройки (для Quality уровней):
На что здесь следует обратить внимание:
- Texture Quality — качество текстур. Для High — мы берем полный размер текстур, для Low — Четверть. Можно еще внести Middle пресет с дополнительным уровнем.
- Resolution Scaling везде стоит 1 — мы берем это значение из URP Asset.
- VSync на Low уровне стоит отключить.
- Все что связано с реалтаймом — отключаем.
Теперь перейдем к настройкам самих URP Asset. На что следует обратить внимание:
Для разных уровней качества можно установить Render Scale — тем самым снижая разрешение для отрисовки. Также незабываем про Dynamic / Static батчинг.
Adaptive Performance
Отличная штука для автоматической подгонки производительности мобильных игр (в частности для Samsung-устройств):
Другие полезные настройки:
- Отключите 3D освещение, лайтмапы, тени и все что с этим связано.
- Используйте для сборки IL2CPP — ускорьте работу вашего кода.
- Используйте Color Space — Linear.
- По-возможности подключите multithreaded rendering.
Едем дальше. URP и другие настройки проекта сделали. Теперь настало время поговорить о нашем ядре проекта. Что оно включает в себя?
Само ядро фреймворка включает в себя:
- Игровые менеджеры для управления состояниями игры, аудио, переводов, работы с сетью, аналитикой, рекламными интеграциями и прочим.
- Базовые классы для интерфейсов (компоненты, базовые классы View).
- Классы для работы с контентом, сетью, шифрованием и др.
- Базовые классы для работы с логикой игры.
- Базовые классы для персонажей и пр.
- Утилитарные классы (Coroutine Provider, Unix Timestamp, Timed Event и пр.)
Зачем нужны менеджеры?
Они нужны нам для того, чтобы из контроллеров управлять состояниями и глобальными функциями (к примеру, аналитикой).
Хотя мы и используем внедрение зависимостей, менеджеры состояний реализованы в качестве синглтонов и могут быть (и по их назначению должны быть) инициализированы единожды. А дальше мы просто можем использовать их:
А уже сам менеджер распределяет, в какие системы аналитики, как и зачем мы отправляем эвент.
Базовые классы.
Здесь все просто. Они включают в себя базовую логику для наследования. К примеру, класс BaseView и его интерфейс:
А дальше мы можем использовать его, к примеру таким образом:
Классы для работы с контентом, сетью, шифрованием
Ну здесь все просто и очевидно. Вообще, у нас реализовано несколько классов:
1) Классы шифрования (Base64, MD5, AES и пр.)
2) FileReader — считывающий, записывающий файл, с учетом кодировки, шифрования и других параметров. Также он умеет сразу сериализовать / десериализовать объект в нужном формате и с нужным шифрованием.
3) Network-классы, которые позволяют удобно работать с HTTP-запросами, работать с бандлами / адрессаблс и др.
Утилитарные классы
Здесь у нас хранятся полезные штуки, вроде Unix Time конвертера, а также костыли (вроде Coroutine Provider-а).
Unix Time Converter:
Костыль Coroutine-Provider:
Наша игра — это по своей сути интерактивная история с различными мини-играми (поиск предметов, простенькие бои, крафтинг, найди пару, а также большое количество головоломок).
Каждая сцена — содержит в себе основной Installer, который помимо различных View, подключает логические блоки — своеобразные куски механик:
Эти куски механик последовательно выполняются, отдавая события OnInitialize, OnProgress, OnComplete. Когда последний блок сыграет свой OnComplete — он завершит работу сцены (закончит уровень).
Зачем это сделано?
- Мы можем собирать каждую сцену из отдельных механик, как конструктор. Это может быть диалог -> поиск предметов -> катсцена -> поиск предметов -> диалог, или любой другой порядок.
- Мы можем сохранять прогресс внутри сцены, привязываясь к определенному блоку.
- Блоки механик удобнее изменять, нежели огромный инсталлер с кучей разных контроллеров.
При работе с контентом, мы стараемся делать упор на оптимизацию. В игре содержится много UI, скелетные 2D анимации, липсинк и прочее. Вообще, контента достаточно много, не смотря на простоту игры.
Анимации в игре
Самый удобный для нас вариант — оказался из коробки. Мы используем систему для работы с костной анимацией от самой Unity:
Да, можно взять Spine, но у нас нет настолько большого количества анимаций, поэтому вариант от Unity — весьма оптимален.
Упаковка и сжатие
Все, что можно и нужно запихнуть в атласы — мы запихиваем в атласы и сжимаем. Это могут быть элементы UI, иконки и многое другое. Для упаковки атласов — используем стандартный Unity пакер из Package Manager (V1):
Локализация
Вся локализация базируется на JSON. Мы планируем отказаться от этого в ближайшее время, но пока что на время Soft-Launch этого хватает:
Работа с UI
При работе с UI мы разбиваем каждый View под отдельный Canvas. 99% всех анимаций работает на проверенном временем DOTween и отлично оптимизирован.
View инициализируются и обновляются по запросу через эвенты, которые внедряются в Level Installer, либо в отдельных блоках логики.
Что мы используем еще?
- Salsa — для липсинка;
- 2D Lighting — для освещения. В большинстве сцен используется освещение по маске спрайта;
- DOTween — для анимаций;
Работа с механиками получается достаточно гибкой за счет блоков логики, внедрение зависимостей — позволяет контролировать оптимизацию кода. У нас собственная реализация внедрения зависимостей, как и системы реактивных событий, дабы не громоздить Zenject + UniRX. Да, мы сделали проще, но нам и не нужно всех возможностей этих огромных библиотек.
Полезные ссылки:
Надеюсь, вам было полезно.
Готов ответить на все вопросы. 🙂
Ну кода тут кот наплакал. Скорее просто как пример
Подробнее скорее на хабр надо ��
Нихера не понятно , но очень интересно.
Дублирование кода детектед)
Рефактор мне в бухту ��
Главное не чистота, а рабочий результат)
DOTween — хорошая штука, но его "документация" — это пример того, как писать хэлпы нельзя. Там просто описание синтаксиса, без внятных ответов на вопросы "хочу X, когда Y" или "зачем для Z три разных механизма реализации".
Например, о том, что добавленный через визуальный редактор путь нельзя корректировать из скрипта в рантайме, мне удалось узнать только методом разбора исходников. Такие вещи в хороших домах объясняют.
Документация это тема для отдельного разбора. Хороший разработчик не всегда может хорошо написать доку ��
Отличная статья все по делу и ничего лишнего.
Спасибо за статью!
У вас перепутаны скриншоты с настройками Project Settings для Low и Quality.
а можно про URP на мобилках по подробнее? Какие крутые штуки он позволяет делать, недоступные обычному рендеру и при этом не убивает производительность?
У него более гибкая настройка и от него можно отнаследоваться для реализации своего пайплайна рендера.
Вот у меня и вопрос, что можно сделать им такое чего нельзя сделать простым рендером и при этом что бы мобила выдавала больше 2,5фпс?
Сравнительная таблица возможностей есть в Unity доках. А вообще, это просто более гибкий подход, где ты можешь вырубать на рендере то, что не нужно допустим на low-end девайсах и включать на hiend. Ну и универсальность конечно же.
Классно! Я в не-игровых программах на Unity почти также делаю 🙂 Только такую систему с блоками не реализовывал (но думал о подобном), т.к. у меня блоки работают не последовательно, а параллельно. )
Хм, про параллельные блоки я не думал, ибо для реализации геймплея это было бы не нужным.
Галка V sync для мобильных вроде как ни на что не влияет. Мобильные автоматически испольщуют vsync безальтернативно и частота экрана кратна 60/30/15 кадрам.
Я забыл приложить к этому скрипт, который позволяет работать с targetFramerate для насильного отключения на некоторых андроид девайсах
Про Salsa интересно поподробнее узнать. Там вроде чисто от от громкости звука разные blendshap-ы лица дёргаются (что уже выглядит неплохо), но мб вы как-то кастомно допиливали?