Моделирование персонажей и создание графического дизайна для мобильной игры
Недавно увидела свет игрушка в стиле Tower Defense под названием Bug Invasion для Windows Phone. В статье разработчики делятся ключевыми моментами моделирования жучков и разработки дизайна игры.
Для создания игры были использованы два инструмента: Adobe Photoshop CS5 и Autodesk 3D`s Max 2011.
Первым шел этап обсуждения — какие элементы графического интерфейса нужно нарисовать и как они приблизительно должны выглядеть. На основании этих обсуждений создавались скетчи интерфейса пользователя, схематические рисунки размещения декораций и элементов игрового экрана, а также схематические рисунки будущих персонажей. Красоты тут мало, просто схемы.
Скетч меню выбора башни
Дизайн игры начал с рисования фона игры в Adobe Photoshop — рисования цветов, травы, камней, оградки, мест для размещения башен, холмы и т.д. В дальнейшем этот фон мы разрезали на две части, с прозрачностью. Первая часть — холм со слотами для установки башен, нижние и верхние декорации (для того, чтобы жуки могли заходить за кустики, ну чтобы было прикольнее :-), вторая, собственно, фон с зеленой травой и клевером.
Кажется, что все просто, но на самом деле все это миллион раз перерисовывалось, дорисовывалось, та как приходили приходили новые идеи.
Потом рисовались элементы GUI: кнопки, менюшки, иконки скилов, табы и фончики:
По поводу иконографики: никогда не нужно забывать о том, что иконки должны быть понятными и интуитивными. Также очень важно попадать в пиксель, отчего границы ваших иконок будут четкими:
Пример не попадания shapes в пиксель:
А тут мы исправились и попали:
В итоге получился полноценный графический интерфейс для игры. Ничего сложного, но уж больно трудоемкая это работа — тратится очень много времени и сил. Но, когда получаешь приемлемый результат, то радуешься и понимаешь, что оно того стоило.
Далее делались персонажи игры в Autodesk 3D`s Max. Мы всегда помнили, что персонажи должны гармонично сочетается с фоном игры. Процесс создания персонажа делится на такие этапы: скетчирование, моделирование, текстурирование и анимация, ну и порендерить еще надо.
Представьте или посмотрите на фотографию жука и нарисуйте на планшете скетч — это ускорит процесс моделирования. Создайте модель жука с небольшим количеством полигонов, потом их можно будет сгладить с помощью модификатора Mesh Smooth. Далее создаем материалы для жука и назначаем их на бездушный серый полигон:
Этапы создания башен такие же. Только при анимации нужно создавать дополнительные источники света перед дулом для имитации выстрела и освещения огнем.
Для создания персонажей использовался Autodesk 3D`s Max 2011. Такой способ показался нам оптимальным и более быстрым, нежели рисовать каждый кадр для башен и жуков. Для того, чтобы анимация жука была плавной использовалось 48 кадров. 12 кадров на умирание букашки, 18 для движения, 18 для пожирания посевов. Все кадры собирались посредством Photoshop в один спрайт. Для башен количество кадров больше — 84. 21 кадр на поворот без выстрела, 21 — на начало выстрела башни, 21 — для отображения выстрела во всей красе, 21 — для затухания огня.
Также для каждой башни нужно было создавать частицу, которая использовалась при выстреле. Для рендеринга использовал Mental Ray Render.
По поводу анимации. Если вы хотите, чтобы жук получился динамичным и не пластиковым — уделяйте много внимания мелочам в процессе анимирования. К примеру, когда гусень двигается, то ее тело сжимается и в центре как будто немного раздувается, усики двигаются, а глаза увеличиваються, что, в принципе, говорит о том, что ей не легко ползать быстро 🙂 Это самый простой пример анимации жука.
Для некоторых экземпляров, чтобы ускорить процесс анимирования, нужно было настраивать систему костей (Bones System). Система костей упрощала на порядок анимирование лапок жука.
Также важно настроить один раз сцену в 3ds Max с одинаковым освещением (для того, чтобы тени и освещенность наших игровых объектов были одинаковыми), установить камеру в одном положении (чтобы вид на жука или башню был всегда с одной и той же точки)
и что не мало важно — настроить откидывание тени на плоскость, невидимую для рендера, используя материал matte/shadow/reflection.
В итоге получаем красивыю детализированую тень на прозрачностью в формате *.png а не безвкусное овальное пятно.
Создание 3D-моделей для мобильной игры: опыт Playkot
Сложности работы с аутсорсерами и ограничения платформы.
На конференции DevGAMM 2017 разработчики Age of Magic из компании Playkot рассказали о создании 3D-моделей персонажей для мобильной игры на всех этапах разработки: от идеи до оптимизации. Редакция DTF расшифровала выступление.
Даниил Козловский: Я арт-лид в проекте Age of Magic. Это игра для мобильных устройств от Playkot, которая напоминает карточную. Но у нас настоящие герои со своими способностями и внешним видом. Их можно собирать и прокачивать в сюжетной кампании, PvP и других активностях.
Сегодня мы поговорим о том, как создаются персонажи. Из слайда видно, что это многоступенчатый процесс, который требует экспертиз и работы большого количества специалистов.
Самое сложное для нас — это создание арта. В игре порядка 70 персонажей и производство каждого из них занимает 1-1,5 человеко-месяца. Производственный процесс завязан на сотрудничестве с аутсорсерами, что накладывает определённые риски, ведь идея должна быть максимально понятной для тех, кто работает вне основной команды.
В нашем случае всё начинается с технического задания от геймдизайнера. Оно даёт нам базовое представление о том, что это за персонаж, его истории и способностях. Наш геймдизайнер прикладывал визуальные референсы, чтобы лучше показать, как он представляет себе героя.
Мы начинали поиск с маленьких скетчей сразу поверх арены. Ключевая цель — найти тот образ, задуманный геймдизайнером. Иногда для этого приходится нарисовать много персонажей.
При переходе от 2D к 3D моделлер может неправильно уловить пропорции, исказить характер или силуэт. Поэтому мы стали использовать 3D-скетч — быстрый, черновой «скульпт», который делает сам концепт-художник в программе ZBrush. На его пропорциях и силуэте будет базироваться финальная модель. Скетч делают без лишних деталей и подробных текстур.
Имея на руках такую модель, мы сразу можем осмотреть её в игре. ZBrush позволяет оптимизировать количество полигонов в ней с нескольких миллионов до нескольких тысяч. На этом этапе, пока не начался долгий и дорогой процесс изготовления финальной модели, ещё можно что-то поправить.
Мы получаем 3D-скетч на пятый день работы над персонажем, а готовый продукт — только через месяц. Весь период производства модели мы спокойны за её качество и за то, как она впишется в мир игры.
Иногда с помощью 3D-скетчей мы создаём прототипы анимаций, чтобы продумать некоторые нюансы. Такие черновики позволяют нам также увидеть некоторые неожиданные проблемы с дизайном героев.
Например у нас есть персонаж, которого зовут Магнус. Мы предполагали, что его крылья будут постоянно раскрыты. Но на арене они перекрывали других героев. Тогда мы решили, что крылья Магнуса будут появляться в процессе анимации и атак.
Однако 3D-скетчи не дают полной информации о дизайне персонажа: многие нюансы костюма (такие как узоры на броне или мелкие детали) здесь либо отсутствуют, либо сделаны очень приблизительно. Нам важно максимально информировать аутсорсеров. Поэтому мы ставим наши модельки в подходящую позу и обрисовываем их, чтобы были видны цвет, фактура, материалы, дизайн одежды и так далее.
В конце производственной цепочки мы имеем отличное техническое задание для тех, кто будет работать над героем дальше. Оно состоит из описания героя, 3D-скетча, детализированного 2D-арта, тестовых анимаций и раскадровок. Такой подход позволяет минимизировать риски на следующих этапах создания модели.
Антон Ивичев, глава 3D-продакшна: я расскажу, что идёт после 3D-скетча и какие критерии качества мы предъявляем к финальной высокополигональной модели.
Во-первых, она должна передавать пластику и стилизацию форм скетча. Кроме того, нужно сохранить характер персонажа. Для нас также важно сделать узнаваемый силуэт, чтобы все персонажи хорошо смотрелись на разных устройствах.
Мы используем классический принцип разделения на три уровня детализации. Первый — большие узнаваемые формы, не насыщеные деталями. Второй — средние детали, дополняющие силуэт и обогащающие персонажа, а третий — мелкая детализация. Она имеет большое значение на экране развития героев, где игрок может увидеть персонажей в полном размере.
У высокополигонального «скульпта» более 20 миллионов полигонов, а на его создание уходит пять дней. Здесь помогает использование заранее заготовленных деталей (таких как руки и ноги) и то, что многие модели делаются на аутсорсе.
Следующий этап — создание упрощенной версии героя. В Age of Magic она состоит из 4-6,5 тысяч полигонов. Именно эту модель позднее добавят в игру, поэтому необходимо продумать точки артикуляции и оптимизировать её с сохранением визуального качества.
Дальше идёт этап «запекания», в результате которого мы получим карту нормалей, передающую рельеф персонажа. Обе версии модели изначально делаются в одной позиции в программе xNormal. Мы выставляем область «запекания» и получаем фиолетовую карту — нормаль.
Теперь можно приступать к текстурированию. Здесь мы не ограничиваем художников какой-то программой — в любой из них можно достичь необходимого результата. Исходные текстуры делаются в 4К, а в игру они попадают в разрешении 1024px. В движке они собираются в шейдер, и мы получаем финальный результат.
Затем идет риггинг, а потом — скиннинг — привязка низкополигональной модели к скелету. На первом этапе автоматизировать процесс помогут скрипты, а на втором— плагин ngSkinTools.
Для оптимизации мы используем влияние двух костей на один вертекс — вершину полигона. Такой подход хорошо показывает себя в мобильных играх и, как правило, работает на всех персонажах.
Однако у Магнуса «гнулись» крылья, когда он их открывал. Сейчас мы планируем проводить тесты, чтобы посмотреть, как сильно пострадает производительность при использовании влияния четырёх костей на один вертекс.
Дмитрий Лебедев, ведущий программист: я коротко расскажу о технических деталях, с которыми мы сталкиваемся при разработке и внедрении персонажей в игру.
Начнем со сборки. На мобильных устройствах «размер» приложения влияет на скорость загрузки, на то, как быстро разряжается телефон или планшет и на то, как много людей скачают вашу игру. Если взять готовые ассеты, то каждый персонаж будет «весить» около 73 мегабайт. Умножаем это на 70 героев и получаем порядка пяти гигабайт. Это слишком много для мобильной игры.
Для компрессии непрозрачных текстур на устройствах от Apple мы выбрали PVRTC. Этот метод даёт хорошее сжатие. Текстуры с альфа-каналом мы используем только для эффектов. Они проигрываются быстро, поэтому тут тоже можно использовать PVRTC. Однако если вам критично качество, то можно выбрать другой формат, использовать специальный шейдер и упаковывать «альфу» отдельно от основной компоненты, а можно оставить полноцветную текстуру и уменьшить её размер.
В случае с Android всё гораздо сложнее. На этой операционной системе работает множество устройств, для каждого из которых оптимален свой формат компрессии. Мы собираемся написать специальный скрипт, который займётся созданием сборок на разные устройства. Для этого в Unity есть возможность выбрать Texture Compression. Скрипт же позволит Google Play проверять все возможные версии приложения, и предлагать ту, которая поддерживается устройством.
Следующий момент — это MIP-текстурирование. Оно помогает снизить нагрузку на графическое ядро, устранить «шумы» и положительно влияет на энергопотребление.
Для компрессии анимации и звука мы используем встроенные средства Unity. Инструмент Keyfame Reduction даёт очень хороший результат: он «сжимает» исходные данные в шесть-восемь раз. Если важен момент проигрывания звука, то мы используем Vorbis, потому что MP3 запускается с задержкой порядка 30 миллисекунд.
В итоге каждый персонаж занимает до 5 мегабайт. 70 героев в таком случае будут «весить» около 350 мегабайт.
В Unity все данные загружаются и инициализируются в едином потоке. Из-за большого количества персонажей, мы разбиваем все игровые элементы на максимальное количество частей и не создаём прямых ссылок. Кроме того, мы подгружаем только то, что нужно приложению в данный момент.
Нас не удовлетворяло качество быстрых шейдеров для мобильных устройств в Unity, а стандартные проигрывали по скорости. Мы старались обойтись как можно меньшим количеством проходов рендеринга, поэтому разрабатывали шейдинг в рамках специфики каждой отдельной сцены.
Мы отказались от постпроцессинга, но встроили соответствующие этапы в шейдер. Вместе с настройками освещения это позволяет добиваться разных «погодных эффектов» или смены времени суток на арене.
Несмотря на все попытки оптимизировать игру, всё равно будут устройства, на которых приложение будет «тормозить». Для таких платформ мы уменьшили размеры карт теней и отключили сглаживание.
После ряда плей-тестов стало понятно, что невозможно предусмотреть все идеи геймдизайнеров, поэтому я не мог заранее написать универсальную модель умений и способностей. Нужна была система, которая позволит гибко настраивать персонажей. В качестве основы мы выбрали язык собственный разработки. Таким образом мы сможем вносить исправления в уже готовый продукт. На создание рабочей системы ушло около четырех месяцев.
Вопрос из зала: Можете ли вы подробнее рассказать о сроках выполнения работ на каждом этапе?
Даниил Козловский: Процесс создания концепт-арта у нас занимает неделю или полторы, в зависимости персонажа. Этому, конечно, предшествуют некоторые дизайнерские поиски.
Антон Ивичев: на высокополигональный «скульпт»уходит примерно пять дней, а низкополигональный — четыре. Ещё столько же времени тратится на текстурирование и риггинг. Анимация и скиннинг требуют примерно неделю.
Рецепт идеальной мобильной игры
Дисклеймер 1. Я не работаю в гейм-деве, я разработчик прикладного ПО и геймер с большим стажем (в том числе, на телефоне). Сейчас играю в Genshin Impact и Call of Antia.
Дисклеймер 2. Речь тут пойдет о «боевых фермах», в которые нужно заходить каждый день, качать героев, проходить кампанию и т. п. Это игры, в которые играют месяцами и даже годами. Игры, которые (как правило) постоянно развиваются и растут. Примеры: Hustle Castle, AFK Arena, Age of Magic.
Раньше я много играл на ПК и консолях, но в последнее время в основном играю на телефоне. Я играл во множество мобильных игр, в некоторые из них — месяцами (а, значит, они были хорошими и интересными). Но я все равно бросал их. Почему так происходит?
Есть ряд причин, которые побуждают игроков продолжать играть в мобильную игру, а также есть причины их бросать. Я уже давно над этим раздумываю и выделил ряд паттернов, которые повторяются от игры к игре. Попробую вам рассказать, какова же моя идеальная мобильная игра.
Эта статья не претендует на откровение, возможно, это все прописные истины для мобильных разработчиков и дизайнеров, но в играх эти проблемы и ошибки встречаются повсеместно, так что, возможно, этот текст кому-то и пригодится.
Для начала попробую систематизировать причины оставаться в игре или ее бросить, основываясь на моем опыте.
Причины продолжать играть:
Причины бросить игру:
Все можно свести к тому, сколько времени тратит на игру человек и насколько ему это интересно и приносит радость/удовлетворение.
То есть, разработчику надо стремиться к тому, чтобы игра была интереснее и приносила больше удовлетворения, при этом игроку не пришлось бы тратить на это много времени (особенно, на рутину).
Большинство игр тут все делают правильно — побуждают игрока заходить каждый день, что-то ему дается просто так («вырастает на ферме»), а что-то нужно и заработать («сражаясь в бою») — собственно, это и есть «боевая ферма» in a nutshell.
Однако, эта мотивация не должна быть слишком частой. Если игра заставляет (побуждает) вас зайти в 4 часа ночи (иначе вы что-то упустите и отстанете от других игроков) — это плохая игра. Бросайте ее сразу, потому что вы все равно бросите ее потом, но потратите к тому моменту на нее кучу времени. Пример: Deck Heroes.
Решение 1. Более сложное и промежуточное. Учитывать часовой пояс игрока и побуждать его к заходу в игру в определенные моменты, но только в его дневные часы. Ведет к ряду сложностей и до конца не решает проблему. Пример: Juggernaut Wars.
Решение 2. Попроще и получше. Игроку достаточно зайти в игру один раз в любое время суток, чтобы ничего не пропустить. Это может быть одна сессия или несколько сессий поменьше. Пример: AFK Arena, Call of Antia (и множество других игр).
Многим (особенно, пришельцам с больших игровых платформ) не нравится система энергии, потому что она ограничивает игрока и побуждает донатить. Это правда, но система энергии для мобильных игр — норма, и никуда особенно от нее не денешься (хотя есть примеры успешных игр без энергии: Hearthstone).
Если у игрока в порядке с самообладанием и не подгорает кредитная карта, то система энергии даже полезна — она не дает залипать в игре постоянно. Хотя, в то же время, энергия является дополнительной мотивацией к заходу (что тоже в минус) — ее нужно тратить, когда она полная, иначе падает эффективность игрока. Компенсировать этот эффект можно регулировкой скорости накопления энергии. Как минимум, она не должна накапливаться настолько быстро, чтобы пропадать зря за средний период сна человека (8-10 часов). Так что, если в какой-то игре ваша энергия копится слишком медленно, радуйтесь!
Но хуже всего живется с энергией (точнее, без нее), когда на нее завязано всё и вся в игре. Если в вашей игре есть энергия, добавьте в нее режимы, которые ее не требуют, чтобы игроку было чем заняться в отсутствие энергии (и была возможность прогресса без энергии). Впрочем, многие популярные игры так и делают (например, режим кампании требует энергии, а режим «башни» — нет).
Подытоживая: энергия — ок, но она не должна копиться слишком быстро и быть необходимой для всех режимов игры.
Под «боем» здесь подразумевается не обязательно бой, а прохождение каких-то уровней и испытаний в любом виде (даже если это и раскладывание пасьянса).
Если в вашей игре нужно каждый день сражаться (особенно, с одними и теми же противниками), и эти битвы занимают не несколько секунд, а минуты, в ней обязан быть авто-бой, иначе вашу игру обязательно бросят со временем, какой увлекательной она бы ни была.
В идеале, должна быть возможность переключения между авто- и ручным режимами. И большинство игр это позволяют делать.
И если вы снова тот пришелец с больших платоформ, который ищет в играх вызов и любите каждому герою отдавать команду каждый раз, то вы молодец. Вот только один и тот же уровень (или его аналог), который надо делать в десятый (и сотый!) раз, уже никакой не вызов, а жуткая рутина, которую хочется удалить и никогда больше не видеть.
Кроме этого, мобильные игры с авто-боем удобны тем, что можно запустить бой и проверить результаты спустя пару минут, занимаясь параллельно своими делами. И даже если вероятность пройти уровень 20% и понадобится 10 таких попыток, у игрока это отнимет примерно 0 минут.
Казалось бы, авто-бой есть почти везде, но есть примеры отличных игр, в которых его нет (по крайней мере, его не было, когда я их бросил после месяцев игры): Sdorica, Legend of Solgard.
Вторая производная от боя — пропуск уже пройденных боев (авто-победа). Чаще всего для активации этого режима требуется безупречно пройти уровень (на три звезды), а для пропуска боя бывают нужны специальные билеты.
Ярчайшим примером того, где это просто необходимо быть реализовано, являются ежедневные битвы, которые приходится проходить по 100 раз (битва с гильдейским боссом или дейлики всякие). И если в игре при этом постепенно открываются или добавляются новые режимы, которые надо ежедневно «окучивать», все это со временем превращается в рутинную работу, набивает оскомину и становится причиной ухода из игры.
Частично эта проблема решается авто-боем, но бывают ситуации, когда ИИ туповат и не может пройти уровень так, как это может сделать игрок. Ну и даже в автономном режиме игра дольше оккупирует телефон (пусть и не тратит время игрока, но сажает батарею, например), что тоже минус (чем меньше, тем лучше).
Как правило, мобильные игры имеют нулевой порог вхождения, а при наличии авто-боя могут проходиться и обезьяной. Но взыскательных игроков с опытом других игр это навряд ли заинтересует.
Им будет интересно пораскинуть мозгами, чтобы пройти нетривиальный уровень, да и принимать решения о том, каких героев использовать и как именно их качать, тоже всегда интересно. Главное, чтобы все это не превращалось в рутину и не блокировало прогресс (см. выше).
Многие игры по мере развития игрока (и самой игры) добавляют новые режимы и возможности фармить какие-то ресурсы и развивать своих героев / «ферму». Это здорово, конечно, но если в результате это линейно увеличивает время, которое требуется тратить на игру ежедневно, это тоже путь к провалу.
Если добавляются новые режимы, старые должны проходиться при этом быстрее или вообще моментально (ну или быть пройдены и не требовать внимания игрока).
Это для меня убило, казалось бы, идеальную AFK Arena. Я играл в нее больше года и был счастлив, но зачем-то туда стали добавлять режимы и контент (некоторые очень даже увлекательные), которые полностью убили ее главное преимущество — «afk»-составляющую — она стала требовать непозволительно много времени.
Ну это классика. Зачем добавляют новых героев, никому не надо объяснять. Разработчики хотят денег, а часть игроков хочет потратить свои деньги на новых героев. И пока они целуются взасос, обычные игроки (а f2p — и подавно) стоят в сторонке и кусают локти.
Это приводит к тому, что обычные игроки вообще не могут собрать старых героев (точнее, этот процесс все больше растягивается во времени), а новые им при этом нафиг не сдались. Все это сказывается на замедлении прогресса и общей фрустрации, что приводит к уходу.
Тут тоже есть решения, например, позволить игроку указывать, какие герои ему нужны в приоритете (см. AFK Arena). Если бы при этом можно было указывать, какие герои тебе больше не нужны, было бы совсем шикарно (например, мне совсем не нужны ваши 4 Дионы подряд в Genshin Impact, когда она у меня давно уже максимально прокачана).
Ну и есть совсем простое решение — меньше добавлять героев (наверное, тут могут быть какие-то метрики, которые позволят оценить прогресс в прокачке старых героев у обычных игроков).
Правилом хорошего тона является давать игрокам халяву («джемы», в основном) за такие вещи, как любая профилактика (плановая или нет), а также временные ошибки / неисправности или изменения баланса.
С этим все хорошие игры отлично справляются, за что им спасибо!
Кстати, что-то мне подсказывает, что и донатят в таких играх охотнее (сужу по себе), потому что это возможность выразить благодарность разработчикам. Наверняка, для исследования этого вопроса тоже можно ввести специальные метрики.
Пожалуй, на этом у меня пока все. Если вы заметили в мобильных играх какие-то еще вредные или полезные паттерны, напишите об этом в комментариях.
И еще. Абсолютно прокляты все игры, в названиях которых есть слова «merge», «tap» и «click». 😉
