Постмортем Divinity: Original Sin 2 для iOS

Разработчики разобрали удачные и неудачные решения при портировании игры.

Авторы Divinity: Original Sin 2 для iOS Сэм Фолкнер, Райан Джон, Платон Фомичев и Никита Шаповалов в начале сентября опубликовали в издании Game Developer постмортем, в котором подробно рассказали о портировании игры на iPad. Мы выбрали из текста главное.

Divinity: Original Sin 2 портировали на Mac ещё в 2019 году, и команде потребовалась всего пара месяцев, чтобы перенести прототип на iOS, так как платформы во многом схожи. Они обе могут использовать один и тот же язык и Metal GPU API. Разработчики не использовали никаких кросс-компиляторов, оболочек API или чего-то подобного на Mac, поэтому особых трудностей с переносом игры не возникло.

На ранней стадии разработки команда использовала Axure RP для быстрого создания прототипов, которые можно запускать на iPad. Часто эти черновые версии выглядели совсем просто — многие элементы были представлены простыми фигурами. Несмотря на отсутствие деталей, это позволяло быстро понимать, подходит такая концепция UI или нет.

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

Чтобы решить проблему, команда обновила инструмент для ПК и Mac, при помощи которого можно загружать изменения на iPad прямо на лету, без перезапуска игры. Эффективные инструменты — это основа для разработки любого проекта.

Адаптировать боевую систему для iPad было достаточно сложно. У команды почти не было удачных примеров реализации этой механики — ни внутри компании, ни в App Store.

Боевая система прошла через множество итераций. Изначально игрок мог произносить заклинания, дважды нажимая в нужное место. Команда тестировала эту систему в течение нескольких месяцев, и люди разделились на две группы — одной всё понравилось, а вторая постоянно жаловалась на боёвку. Плейтестеры постоянно ошибались и случайно совершали действия в игре — это выглядело так, словно управление подходило только опытным пользователям сенсорных устройств.

Разработчики разделили проблему на три части: мисклики, точность, знание команд управления. Для решения первых двух разработчики добавили лупу, которая активируется при подготовке заклинания и позволяет прицельно бить по противнику. А проблему с незнанием команд разработчики решили стандартным способом — добавили текстовые подсказки в HUD.

Команда разработчиков распределена по всему миру, но при помощи TestFlight они могли легко связываться друг с другом и давать обратную связь. Этот сервис позволяет быстро отправлять скриншоты, информацию о сбоях, отзывы.

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

Ещё разработчики добавили NEON acceleration для матриц и векторов, что позволило тратить меньше ресурсов на расчёт физики. В оригинальной версии игры в качестве физического движка использовался PhysX и многие расчёты выполнялись при помощи SSE2 или AVX. В этот раз команда решила перенести процессы SSE2 на NEON — это, например, значительно упростило расчёты поведения одежды.

Также разработчики оптимизировали игру при помощи самого компилятора Clang. Они использовали все возможности — даже оптимизировали размер исполняемого файла за счёт скрытия символов и удаления всего ненужного кода.

Опытные пользователи и разработчики могут легко адаптироваться к системам и элементам UI, которые использовала команда. Но как только начались плейтесты с обычными игроками, которые плохо знакомы с платформой, появились проблемы — тестеры постоянно указывали на недостатки боевой системы. Поэтому проводить плейтесты нужно было намного раньше.

Поскольку экосистема iOS закрыта, у разработчиков сложилось впечатление, что если они протестируют игру со стандартным набором аксессуаров (например, наушниками или клавиатурой), то этого будет достаточно. Они ошибались. После релиза, например, оказалось, что одновременное подключение контроллера и наушников по Bluetooth приводит к полному зависанию игры. Команде пришлось быстро исправлять такие ошибки.

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

Разработчики не использовали систему контроля версий для кода пользовательского интерфейса. Так сложилось, что скрипт UI был встроен в файлы .fla, и при замене значительной части кода могли появиться ошибки. Если бы команда применяла систему контроля версий, то любые ошибочные изменения можно было бы увидеть заранее.

Изначально команда предполагала, что сенсорный экран — это просто замена мыши. Разработчики потратили много времени на код, имитирующий мышь, но в итоге поняли, что сенсорный ввод нужно воспринимать иначе, так как там есть возможность использовать разные пальцы и жесты. Когда команда добавила поддержку всего этого, управление стало интуитивно понятнее.

Выше было упоминание о том, что при ошибках с HALF-типом могут возникнуть большие проблемы — как раз это и произошло с разработчиками: они сталкивались с багами на протяжении всего процесса портирования игры.

Разработчики работали над версией для iOS почти два года и им пришлось преодолеть множество технических препятствий. Тем не менее Divinity: Original Sin 2 встретили очень хорошо, и команда продолжает улучшать игру.

#опыт #ios #divinity