анимированные персонажи для игры
10 полезных сайтов с 2D ресурсами для игр
С развитием HTML5 и мобильных платформ 2D-игры возвращаются в моду. Заниматься такими проектами, будь то браузерные игры, игры на телефон или для ПК, стало легче благодаря таким инструментам, как Unity, и онлайн-ресурсам с игровыми ассетами. Ниже представлен список из 10 лучших сайтов с 2D-ресурсами для игр – как платными, так и бесплатными.
*Сайты перечислены в случайном порядке*
Крупнейший сайт с платными игровыми ассетами. Использовать движок Unity для работы необязательно – чтобы получить доступ к ресурсам на Asset Store, нужно лишь загрузить его бесплатную версию. Скачанные файлы будут сохранены в папку проекта Unity, откуда их можно импортировать в любой игровой 2D движок.
Стоит отметить, что Unity в руках умелого разработчика обладает огромным потенциалом, о чем свидетельствует большое количество успешных 2D игр (чего только стоит популярная Bad Piggies от Rovio). А Unity Asset Store предлагает широчайший выбор 2D ассетов.
GameDev Market – относительно новый сайт, удобно организованный по категориям контента (как и Super Game Asset, о котором пойдет речь ниже). Здесь вы найдете как 2D, так и 3D ресурсы, включая UI, спрайты персонажей, иконки и окружения. Художники выставляют ассеты на продажу, и ассортимент растет с каждым днем.
Graphicriver – один из самых популярных ресурсов шаблонных изображений. В связи с развитием казуальных мобильных игр, там появилась отдельная категория с 2D ассетами. До размещения на сайте весь контент проходит внутреннюю проверку, а после публикации любой пользователь может оставить свою оценку и отзыв. Итого: это надежный, активно развивающийся сайт под пристальным модерированием Envato.
Scirra – компания-разработчик Construct 2, популярного 2D редактора на HTML5, у которой недавно появился собственный магазин ассетов. Здесь можно найти аудио-, графические ресурсы и даже готовые игровые шаблоны для Construct 2. Впрочем, для работы можно использовать и любой другой 2D редактор.
Если вы создаете RPG или игру с изометрической графикой – этот сайт для вас. Здесь вы найдете самые высококачественные ассеты: красочные иконки для RPG (пожалуй, лучшие из доступных онлайн), 2D спрайты, анимированные спрайты персонажей и огромные изометрические карты. Что немаловажно, большинство представленных ресурсов выполнены в одном стиле.
Исчерпывающий ресурс для разработчиков игр с открытым исходным кодом, Open Game Art можно назвать крупнейшим собранием игровых ассетов со свободной лицензией. Все материалы – от спрайтов до иконок – можно загрузить по лицензиям GNU или Creative Commons. Это отличный сайт для новичков, но многие ассеты отличаются по визуальному стилю, поэтому их придется тщательно отбирать.
Game-icons.net – лучший сайт с бесплатными иконками, которых здесь ни много ни мало 2000. Несмотря на то что все иконки черно-белого цвета, они достаточно универсальные и могут быть использованы для обозначения действий, заклинаний, навыков, предметов и т. п. Приятный бонус – векторный формат.
Анимирование для новичков — поэтапный туториал Статьи редакции
Разбейте процесс рисования на множество мелких этапов и постепенно улучшайте качество работы.
Инди-разработчик экшена Scrabdackle, известный под ником jakefriend, опубликовал на Reddit туториал, в котором рассказал, как анимировать персонажей без продвинутых художественных навыков. Мы выбрали из текста главное.
По признанию Джейка, он обладает недостаточно развитыми художественными навыками. Поэтому стиль своей игры он выстроил на основе нескольких аспектов, которые у него хорошо получаются — пиксель-арт с толстыми контурами и плоскими однотонными объектами. Несмотря на ограниченные художественные навыки, автор нашёл способ быстро анимировать игровые объекты.
Разработчик советует начинать рисовать с плохих, но простых набросков. Затем постепенно улучшайте рисунок шаг за шагом. Постарайтесь разбить весь процесс на несколько небольших этапов, чтобы последовательно улучшить свою работу.
На этом этапе не стремитесь рисовать качественно. Ничего, если набросок выглядит совсем плохо — со временем вы его сильно переработаете. Вы можете рисовать прямо на бумаге, чтобы максимально ускорить процесс.
В бумажном эскизе вы должны передать идею персонажа. В этом примере автор хотел изобразить «злой огненный шар», который парит в воздухе. Разработчик добавил объекту лицо, чтобы выразить его эмоции и личность.
Всё ещё не стремитесь делать это качественно. На этом этапе очень важно найти правильный масштаб для объекта — вы точно не хотите анимировать персонажа, а потом обнаружить, что он не подходит к размерам остальных игровых элементов.
Начинайте рисовать прямо на скриншоте своей игры рядом с главным героем — это позволит вам сразу же встроить объект в контекст. В первую очередь нарисуйте самую крупную форму, например, силуэт огненного шара.
На этом этапе Джейк решил, что у персонажа должно быть внутреннее шарообразное тело, которое покрывают языки пламени. Автор признался, что отрисовка заняла лишь несколько минут работы в Aseprite.
Ничего, если объект выглядит недостаточно хорошо. Рисуйте все нужные элементы, ориентируясь на изначальный эскиз. Для удобства разместите их на разных слоях.
На этом этапе Джейк нарисовал тело шара, глаза, ухмылку и пламя. Чтобы создать тело он применил следующий подход — автор быстро рисовал круг, а затем отменял действие, если форма не соответствовала задумке. По его словам, он потратил минуту, чтобы нарисовать около 50 вариантов шара. В итоге один из них подошёл.
Глаза он создал таким же образом — просто рисовал одни и те же линии снова и снова, пока они не перестали выглядеть плохо.
Но для создания огня такой вариант не подходит — он состоит из сложных форм, поэтому невозможно сделать его красивым парой простых движений. Помните, что рисунок не должен быть идеальным — даже некрасивые формы подойдут для начальных этапов. Затем вы сможете исправить и дополнить рисунок.
Не боитесь менять изначальный эскиз, если это действительно нужно. Джейк советует не тратить много времени на перерисовку элементов, которые вам не нравятся. Например, он решил не переделывать огонь, а нарисовать несколько вариантов и объединить их в анимацию.
Также разработчик решил сделать анимацию короткой — всего из трёх кадров. Автор признался, что его пугала необходимость рисовать движущийся огонь. Поэтому он разбил этот процесс на более мелкие задачи — наметил точки, до которых должны доходить языки пламени.
В результате у Джейка получилась слишком быстрая анимация. К тому же языки пламени вышли чрезмерно острыми и неестественными. Третья проблема, которую отметил автор: в некоторых местах анимация выглядит рваной — разница между кадрами слишком большая.
Скелетная анимация в играх. Обзор техник и ресурсов
Anima — это душа, отличающая живое от мертвого. Аристотелевская душа — это принцип движения, проявляющегося в четырёх видах: перемещение, превращение, убывание и возрастание. Спустя почти две с половиной тысячи лет мы используем те же категории в компьютерной графике. Скелетная анимация определяет перемещение, морфинг служит для превращений, а убывание и возрастание это обычное масштабирование. Анимированная графика оживляет образ, вдыхает в картинку душу, и это, на мой взгляд, даже важнее, чем достоверная игра света и тени.
Создание качественных скелетных 3D анимаций сегодня, пожалуй, самая труднодоступная для инди разработчиков задача. Вероятно поэтому так мало инди игр в 3D, и так много проектов в стилях пиксель арта или примитивизма, а также бродилок без персонажей в кадре. Но теперь это соотношение может измениться…
Попробуйте сосчитать количество разнообразных анимаций в Uncharted 4. По моим оценкам там около часа уникальных движений, не считая лицевой анимации (850 выражений по словам авторов). Подобные игры задают фантастическую планку качества.
Мне не удалось отыскать примеров создания хотя-бы близкой по уровню анимации при помощи ручного кадрового подхода или какой-либо процедурной анимации. Максимум что возможно сделать вручную, на мой взгляд, — это простые удары, быстрые движения и стилизованная мультяшная анимация. Но как сделать реалистичную ходьбу по лестнице, где очень много деталей, связанных с переносном центра тяжести и балансом тела? Невозможно их все воспроизвести вручную. Может быть я ошибаюсь, и кто-нибудь покажет работы специалистов такого уровня.
Все это я вспоминаю для того, чтобы оценить по достоинству щедрый подарок от Mixamo. Он буквально открывает дверь на новый уровень для независимых разработчиков: компания Adobe купила Mixamo, и теперь 2.5 тысячи скелетных анимаций для персонажей они отдают совершенно бесплатно «for unlimited commercial or non commercial use»:
www.mixamo.com
Существуют и не менее проработанные наборы анимаций, доступные для приобретения энтузиастами. Но такой гигантский и качественный набор впервые оказался доступен совершенно бесплатно. Еще одним неплохим источником клипов остается база анимаций Университета Карнеги — Меллон и ее адаптированная под Unity версия, однако качество и содержание этой базы не так хороши.
Кроме ручной кадровой анимации и захвата движения актера, существуют и интересные процедурные методы симуляции движений: эволюционное моделирование, нейронные сети, task based locomotion. Что интересно, на конференции SIGGRAPH 2016 этим непростым техникам уделяют много внимания. Но широким кругам независимых разработчиков эти вещи пока не доступны, и мне самому хотелось бы больше узнать о возможности их реального применения. Однако сегодня есть и доступные инструменты, симулирующие мускульную динамику (Euphoria Engine и Puppet Master для Unity3d), которые позволяют привнести разнообразные реакции персонажей на обстоятельства.
Получить качественные и разнообразные анимационные клипы это только первая часть задачи.
Вторая часть заключается в том, чтобы корректно использовать полученные анимации при управлении персонажем. Для этого сначала нужно решить, как вообще сдвигать персонажа в сцене: на основании данных самой анимации (1), либо на основании каких-то иных соображений (например физики твердого тела) (2). То есть, либо анимация будет вычисляться исходя из произвольного (физического) движения объекта в пространстве (2), либо само смещение в пространстве будет исходить из записанной анимации, игнорируя иные вмешательства (1).
У обоих подходов есть достоинства и недостатки. В прежние времена, до массового использования захвата движений, вопрос об этом почти не стоял — персонажи двигались процедурно, на основании каких-то простых принципов, а анимационные клипы просто проигрывались для некоторого соответствия этому движению. Но чем лучше становилась анимация и графика в целом, тем заметнее становилось несоответствие движения ног и смещения персонажа, а также неестветсвенность динамики движения.
Одним из ярких примеров может быть игра Guild Wars 2 где анимация движений и графика уже достаточно хороши, но вот большой диапазон возможных скоростей и направлений движения персонажа не обеспечен столь же большим набором анимаций, и персонажи либо буксуют на месте, либо проскальзывают вперед как по льду. Та же проблема долгое время преследует и игры на движке Gamebryo (серия TES: Morrowind, Skyrim), да и многие другие.
Настоящее движение человека нелинейно — сначала мы наклоняемся вперед, затем выбрасываем ногу, и только потом начинаем движение, быстро ускоряясь после соприкосновения стопы с землей, и двигаемся по инерции до следующего шага. Подобрать функцию, точно описывающую подобное движение, сложно, и редко кто вообще об этом задумывается. Что уж говорить о более сложных движениях — стрейфе, переходах между направлениями, торможением и поворотами.
Поэтому для достижения реализма нам в любом случае потребуется гигантский набор разнообразных клипов с движениями в различных направлениях, с различной скоростью, и т.п… Кроме того, анимационные клипы редко можно использовать изолированно, воспроизводя один за другим. Чаще всего в игре присутствует множество анимаций, между которыми не заготовлено специальных анимированных переходов. Поэтому для их симуляции применяется плавное смешивание через линейную интерполяцию поворотов костей. Для удобной настройки таких переходов используется т.н. конечный автомат или машина состояний (State machine). В UE и Unity для этого есть специальные инструменты: Persona и Mecanim. Каждый узел там это некоторое состояние скелетной модели (заготовленный анимационный клип или результат их смешения — Blend Tree). Когда выполнены некоторые заданные условия, осуществляется плавный переход из одного состояния в другое, во время которого оба оказывают пропорциональное времени влияние на повороты костей и смещение объекта. Таким образом достигается иллюзия непрерывности движения.
Состояние может быть не одиночным клипом, а смешанным по тому же принципу набором клипов (Blend Tree / Blend Space). Например из клипов движений персонажа в стороны можно выбрать несколько, смешав их пропорционально вектору желаемого движения, и получить движение под любым произвольным углом. Однако существуют такие анимации, для которых смешивание оборачивается некорректными позами. Например когда одна анимация двигает ноги персонажа вперед, а другая вбок, линейное смешивание может привести к пересечению ног друг с другом. Чтобы этого избежать нужно тщательно подбирать анимационные клипы, синхронизировать их фазу, длину и скорость, либо добавлять отдельный клип специально для данного вида движений. Все это сложная и кропотливая работа. И чем больше возможных состояний и переходов между ними, тем сложнее привести их в согласие друг с другом, и проследить за тем, чтобы все нужные переходы срабатывали когда это требуется.
1) Самым очевидным решением является захват движений реального актера при помощи Motion Capture и привязка смещения персонажа в игре к смещению «корневой кости» в самой анимации — принцип Root Motion. Тогда персонаж будет двигаться ровно так, как двигался актер во время записи.
Но этот подход несет в себе и очевидные проблемы.
Допустим, персонаж хочет подвинуться к краю обрыва: актер на записи наклоняется, поднимает ногу и делает смелый широкий шаг по сцене. А персонаж шагает прямо в пропасть… Чтобы этого избежать, нужно прервать шаг где-то посередине, но это не только выглядит неестественно, но и затрудняет игроку выбор нужного момента из-за нелинейности движения, в котором может быть долгая подготовка (наклон), а затем резкое уверенное движение (шаг). Можно записать несколько вариантов движений. Допустим: осторожные маленькие шаги, нормальные, и бег. А затем смешать их по параметру требуемой скорости, который можно увеличивать линейно и предсказуемо. Но что если нам нужны движения в стороны? Значит для каждого варианта ширины шага нам нужны еще три-четыре варианта (за вычетом зеркальных). А еще персонаж должен уметь поворачивать во время движения. Значит для каждого варианта нам нужны движения с поворотом. А если поворот может быть быстрым и медленным? Значит еще раз умножаем число необходимых клипов на два. А теперь нам нужно движение по наклонной поверхности! А потом нам захочется, чтобы персонаж умел делать тоже самое вприсяди. Итого — просто сотни и тысячи вариантов анимации которые нужно смешивать и следить за тем, чтобы это происходило корректно и приводило к движениям с нужной скоростью. И все равно, во многих случаях управление будет ощущаться как «ватное», поскольку инерция актера и наша невозможность предусмотреть все возможные человеческие маневры будет лишать игрока контроля над персонажем. Эту проблему, к слову, прочувствовали на себе игроки в The Witcher 3, поэтому в одном из крупных обновлений разработчики внедрили альтернативный вариант управления, где анимация быстрее отзывается на управление в ущерб реализму. В шутерах же проблема нелинейности движения обретает особенно выраженный характер: игроку часто приходится выглядывать из-за угла и быстро уходить обратно, и момент резкой смены направления может очень отличаться — игроку требуется как можно скорее вернуться обратно за укрытие, а у нас нет возможности предсказать заранее, какой ширины шаг он планировал и проиграть соответствующую анимацию. Игроку, в свою очередь, будет трудно привыкнуть к ширине шага, которую делает его персонаж, и к скорости этого шага, чтобы прервать его вовремя.
Во-вторых, Root Motion плохо годится для сетевых игр. Нелинейность движения не только затрудняет игроку предсказание скорости, но и лишает нас возможности интерполировать и экстраполировать движение чтобы компенсировать сетевую задержку, что является очень важным и сложным аспектом в быстрых сетевых играх. Если смещение персонажа задается только анимацией, то трудно аналитически подобрать нужные параметры машины состояний (смешивающей разные анимации), которые приведут к движению персонажа в точно нужном нам направлении и с точно нужной нам скоростью (выбранных для компенсации расхождения). Если же сделать наоборот, так, что анимация будет ориентироваться на фактическое движение, то при коррекции расхождения между сервером и клиентом легко можно будет подобрать наиболее подходящую анимацию, и даже если она будет чуточку несоответствовать фактическому смещению, этого почти никто не заметит.
Поэтому техника Root Motion используется часто в одиночных играх от третьего лица, где управление осуществляется контекстуально — в зависимости от наличия укрытия, препятствия, режима движения или других обстоятельств, и редко применяется в сетевом режиме и MMOG.
Из последних заметных проектов, использующих Root Motion, можно выделить The Witcher 3. Трудно переоценить усилия, вложенные в производство всех его движений.
2) Другое решение обратно принципу Root Motion — нужно приводить анимацию в наиболее точное соответствие с произошедшим или планируемым движением. Тогда многие описанные выше проблемы решаются — движение персонажа можно сделать равноускоренным и предсказуемым с возможностью сколь угодно быстрой смены направления. Но как привести нелинейную и инерционную анимацию в соответствие с таким движением? Интересный комплексный подход описали разработчики игры Paragon. Суть его заключается в том, чтобы находить и проигрывать только нужную серию кадров анимации для достижения требуемого смещения/поворота, пропуская лишние. И использовать инверсную кинематику для модификации ширины шага.
Первая очевидная трудность при приведении анимации в соответствие с движением, в том, что движение уже произошло, а анимация еще не проиграна. Поэтому очень пригодится система предсказания движения, вычисляющая положение персонажа для следующего кадра. Затем, зная смещение, которое должен осуществить персонаж за следующий кадр, нужно пропустить столько кадров анимационного клипа движения, сколько будет нужно чтобы достичь требуемого смещения, и проиграть тот кадр, на котором требуемое смещение достигнуто. В таком случае анимация станет воспроизводиться с измененной скоростью, так, чтобы точно соответствовать фактическому смещению, и эта скорость может быть быстрее или медленнее оригинальной, поскольку невозможно заставить реального актера поддерживать постоянное ускорение или скорость. Данный подход позволит сгладить анимацию и привести в соответствие с любой сложной процедурной моделью движения, меняющейся во время игры (персонаж может выпить какое-нибудь ускоряющее зелье или оказаться замедлен противником). Недостатком, разумеется, является то, что анимация может стать менее реалистичной из-за сильных изменений в скорости. Однако на практике это дает очень хорошее окно доступных вариаций в котором нарушения скорости незаметны. А вкупе с поправками ширины шага при помощи инверсной кинематики, покрывает еще больший диапазон.
Но, к сожалению, этот метод довольно сильно нарушает привычный подход к анимированию, и поэтому я не смог найти простого способа реализовать его, например, с использованием стандартного анимационного компонента Unity. В Unreal Engine также пока нет необходимого функционала, однако разработчики обещают когда-нибудь перенести низкоуровневые наработки, сделанные для Paragon, в общедоступную версию движка. Основной сложностью является поиск и воспроизведение нужного кадра на основании данных о фактическом смещении и повороте. Для этого авторы предлагают делать пре-процессинг анимационных клипов и генерировать для каждого из них дополнительный блок данных: Distance Curve, в котором будут покадрово сохранены значения смещения и поворота корневой кости относительно начала или конца анимации. Затем, в ходе выборки, можно производить быстрый бинарный поиск нужного кадра, где достигнуты соответствующие параметры смещения и поворота, и воспроизводить его.
Пока же можно ограничиться прежним подходом, и делать менее точную подгонку скорости анимации к скорости планируемого движения, ориентируясь только на скорость персонажа за последний кадр. Самое главное — неплохой набор душ для экспериментов теперь имеется!
Персонаж за 4 часа: создать 2D-героя, не забыв про анимацию
Как совместить большие планы и сжатые сроки.
Поговорим о персонажах — именно с их конкретными образами мы связываем многие проекты, будь то Tomb Raider, The Witcher или Pac-Man.
Даже с ограничениями во времени и ресурсах можно создать героев, которые полюбятся игрокам. Если у вас есть хорошая механика, не стоит бояться проблем с артом — исходите из реальных возможностей и помните, что даже самая простая стилизованная графика может выглядеть классно.
Ваши главные инструменты — это стилизация и обобщение, они помогут сделать персонажей узнаваемыми. Возьмём «Симпсонов» — их герои выполнены в одном обобщённом стиле — не таком натуралистичном, как на картинах художников Возрождения.
Тут главное — узнаваемый считываемый образ и чёткое следование канону.
В быстром цикле разработки, например, при создании инди-платформера нужно думать не только о внешнем виде персонажей, но и об удобстве для масштабирования.
Хорошо, когда персонажи легко тиражируются — в этом поможет минимальное количество деталей и читаемый силуэт. Чем сложнее персонаж, тем трудозатратнее производство графики и анимации.
Bowmasters — мобильная контентная игра в стиле GaaS. Для таких проектов, с учётом быстрого цикла разработки, необходимо выпускать новый контент и поддерживать интерес игроков. Для них новый контент становится одним из уникальных USP, а разработчикам нужно делать ставку на оптимизацию скорости выпуска персонажей.
Но не только скорость разработки повлияла на внешний вид наших персонажей и стилистику в целом. Отсылки к мемам, популярным образам и любимым героям играют важную роль. Есть небольшой лайфхак: сделали игру — добавьте туда котика.
Самые доступные инструменты, которые помогут понять востребованность образов, — это Google Trends и Yandex Wordstat. С ними можно не только определить, какой из героев больше на слуху, но и оценить динамику тренда — вовремя заметить, что один из вариантов уже пошёл вниз и начинает забываться.
К разработке графики стоит переходить, когда природное чутьё, понимание трендов, художественный вкус и знание рынка привели к взвешенному образу персонажа.
Обычно пайплайн разработки 2D-контента для мобильных раннеров, платформеров или экшенов не сильно отличается от студии к студии. Коротко расскажу о нашем:
Геймдизайнер создает документ с подробным визуальным описанием персонажа, а также необходимыми анимациями, суперспособностями, и даже репликами — это очень важно, чтобы получить релевантный образ. Туда же прикладываются референсы, и задача отправляется художнику.
Создаются первые черновые скетчи — 3-6 максимально разных идей в рамках одной концепции. Скетчи обычно делаются в ч/б линиях или «от пятна», чтобы определиться с примерным силуэтом, образом и ключевыми деталями.
Выбирается общий образ, после чего уточняются формы и детали, предлагаются различные решения для нюансов. Проработанные скетчи через фидбек и уточнения приобретают необходимый внешний вид.
После согласования монохромного скетча подбирается цветовая схема персонажа, после выбора которой вносятся последние правки — получается финальный скетч.
Разработка финального арта происходит в Photoshop. Все важные детали создаются в отдельных слоях с соблюдением иерархии наложения объектов друг на друга, как для привычной перекладной анимации, которая позволяет не рисовать каждый кадр отдельно. То есть ноги — это нижние слои, затем части туловища, элементы лица, одежда. Верхние слои — это рука, которая ближе к игроку, так как при анимации она может перекрывать корпус.
Все слои именуются в соответствии с содержанием и на английском языке — это облегчает экспорт и поиск какого-либо определённого элемента персонажа.
Финальный персонаж также проходит этап согласования перед тем, как задачу на арт можно считать завершённой.
Важный момент: для персонажей очень важна «читаемость» — они не должны сливаться с фоном, потому герои всегда проверяются не в вакууме или на дефолтной подложке, а на реальных игровых бэкграундах. И так как мы разрабатываем мобильные игры, то тестируем сразу на устройствах, а не на мониторах, чтобы понимать, как это видит игрок.
Это же работает и на сложных проектах — персонажи должны выглядеть в окружении гармонично. Нельзя жертвовать считываемостью в угоду дизайну отдельных элементов.
По опыту могу сказать, что такой итеративный процесс разработки и апрува скетчей помогает избежать дорогостоящих правок или замены финальной графики.
А для удержания стилистического единства персонажей мы пользуемся простыми правилами:
Отдельно стоит прописать то, чего делать не стоит, и к каким последствиям это может привести. Например, не менять пропорции без согласования, так как может не подойти анимация. Такой документ тоже поможет сэкономить время на правках, быстро обучать и онбордить новых членов команды.
Когда сделали одного такого персонажа по всем правилам, то сделать пачку следующих по образу и подобию уже будет проще.
Если проект не ограничивается одним персонажем и парой спрайтов для фона, то следует также организовать систему хранения файлов и каталогов. Это отдельная тема, но могу точно сказать, что хорошая структура хранения и понятный нейминг — ключ к сохранению порядка на проекте и экономии времени.
Такой подход облегчит поиск и доступ к необходимым файлам как самими 2D-художниками, так и аниматорам и программистам.
Когда арт готов, можно переходить к созданию анимации. Для персонажей Bowmasters мы используем костную анимацию в Spine.
Для стандартных героев по умолчанию есть три типа скелета (для толстяка, накачанного и обычного телосложения) и набор универсальных движений и поз — это позволяет в разы сокращать трудозатраты при сохранении стандарта качества графики. То есть все наши персонажи заранее адаптированы под «пересадку» стандартных анимаций, что минимизирует время на риг. Десять минут — и новый герой может прыгать, падать, грозно размахивать руками или трястись от испуга.
А вот уникальные, сочные анимации припасены для фаталити — мы проводили опросы игроков и ничто их так не радует, как сокрушительная победа над соперником. Таким образом игрок не пресыщен перманентным визуальным безумием.
Когда стиль выработан и понятен, можно позволить себе некоторые отступления от правил. Если это сделает вашего героя действительно особенным и ценным для игрока, то вы вправе отойти от канона, не нарушив стилистической гармонии образа. Мы тоже так делаем.
Например, один из наших любимых персонажей — Акула. Может показаться, что она отличается по форме от гуманоидных персонажей, но если разобраться, в её основе все тот же классический набор основных спрайтов — под неё легко адаптировать стандартный персонажный риг.
Мы немного «нарушили» правило только по части визуального стиля, а на трудозатратах со стороны аниматоров и кодеров это никак не отразилось. Отбросив условности, можно сказать, что внутри акула — тоже человек!
Бывает так, что есть и далеко идущие цели, и готовые пайплайны с инструкциями, но присутствует стойкое ощущение, что порядка на проекте всё ещё не хватает. Возможно, просадка именно в планировании — нет понимания, сколько, чего и какими силами можно добавить в игру в следующем апдейте. И это очень важный момент, о котором забывают многие начинающие разработчики игр.
Если знать, сколько времени было затрачено в среднем на типовые образцы графики, можно выделить общие сроки для каждого вида контента, будь то персонаж или какая-нибудь стандартная интерфейсная кнопка.
Но даже в рамках одного типа, арт может разниться по степени трудоёмкости — это следует учитывать при планировании, условно разделив внутри типов графику на простую, обычную и сложную в исполнении.
После этого можно прогнозировать реальные сроки путём простых вычислений.
Для условного примера рассмотрим графику для простого персонажа гиперказуальной игры с минимальной детализацией, для которого уже утверждены технические требования и порядок разработки:
Аналогичным образом прогнозируем трудозатраты на производство прочей необходимой графики и делим получившиеся результаты на количество художников команды, которым предстоит заниматься разработкой.
Мы попробовали разобрать процесс разработки персонажа для гиперказуальных проектов, но при этом есть много нюансов у воркфлоу разных жанров. Для быстрого старта можно взять готовый, это особенно полезно на этапе проработки прототипов.
Оптимизируйте, планируйте и помните, что незаурядные персонажи и весёлая анимация могут вдохнуть жизнь в игру с самой простой графикой.