Как вам провода?
Сколько км провода в игре TReload... Несколько сотен?
Здесь некоторые тесты проводов-шлангов из игры : IK + работа со сплайнами + физика + блендинг.
Финальный провод:
Как мы разрабатывали части персонажа. Персонаж : правдоподобие против удобства управления
Разработчики находятся в достаточно трудной ситуации. С одной стороны начальство требует дойную корову, которая стабильно работает как автомат калащникова и приносит денежку. C другой стороны таких дойных коров уже изобретено достаточно и в целом все они похожи друг на друга с точки зрения наличия новых уникальных механик и их развития.
На первый взгляд все кажется просто. Вот, на самом деле, почему нельзя просто создать какую-то новую механику, даже много новых механик и улучшать их пока они не устроят? Если что, неудачные механики можно выкинуть :)
<<Для начала в игре существует только одна core-механика. И для ее реализации, поверьте, придется уйти в работу с головой. Создавать нексолько механик = создавать несколько разных игр. А это равносильно усложнению своей жизни. Вместо шлифовки одной механики вы должны распылиться на 10, а потом оставить из них только одну, а остальные выкинуть. Печально выкидывать результаты работы, правда?>>
Разработка игры с новой механикой - это примерно то же самое как работа над открытием или даже процесс поиска клада. Отлично, если вы опытный кладоискатель. Такие кладоискатели знают, что клад вряд ли спрятан в песочнице на детской площадке и не будут его там искать, тратить на это время. Потому что в свое время они уже наступали на эти грабли и ничего там не нашли. То есть существуют механики, которые заведомо неудачны / непригодны для игр. Конечно, все можно адаптировать, видоизменить, подогнать. Но все же существуют вещи которые не следует делать.
Вот рассмотрим очень простой пример такой механики на мобильной игре.
Допустим у нас есть персонаж в мобильной игре и наша задача управлять им. Мы видим персонажа сверху (2D). Как бы в сделали его управление?
Это очень щепетильный вопрос. Управление - это задача задач, которую решают в процессе разработки.
(1) Если вы будете приказывать персонажу идти за пальцем, когда он опущен на экран, то ваша рука будет перекрывать экран и вы будете смотреть на свою руку;
(2) А если персонаж будет идти в противоположную о пальца сторону, то будет ли удобно такое интвертирование управления?
(3) Если персонаж будет идти в точку, которую вы кликнули, то сможет ли он увернуться от летящей ракеты? Не перекроется ли экран рукой, когда вы смените направляение движения персонажа? Это управление точно удобно?
(4) А если просто... Джойстик и все тут! Не перекроет ли джойстик экран? Сколько экранного пространства он занимает (допустимо ли это)? Удобен ли он? Функционален? Позволяет ли он погрузиться в атмосферу игры?
Кто-то скажет: вот вы написали столько всего, так и управления не сделаешь, если все плохои все "неочень". Сделаешь, как раз это частично задача дизайнера интерфейсов, частично дизайнера, отвечающего за управление. Но больше, конечно, задача дизайна управления.
Да, вот такими задачами и занимаются дизайнеры: сделай то, не знаю что, пойди туда, не знаю куда и чтобы все было круто и никак иначе.
Оптыный дизайнер (опытный кладоискатель) способен быстро оценить все "за" и "против" каждого из пунктов [1-4]. Новичок же, очень вероятно, будет экспериментировать и постигать тайны управления с нуля :)
Надеюсь теперь стало очевидней, что разработка новой механики - это работа.
Это работа и она не всегда увенчивается успехом. Не всегда даже опытному дизайнеру удается создать новую механику. И это часто зависит не только от дизайнера, но и от команды, от возможностей платформы для которой все разрабатывается.
Дизайнер создает тех. задание, отдает ее на реализацию дизайнерам и программистам, через какое-то время получает результат. Если результат устраивает, то это успех. Если результат не устраивает, то процесс повторяется до того момента, пока инвестору все это не надоест или пока команда не замучается "пробовать". Да, людям не нравится работать, а потом выкидывать свою работу. Особенно, когда ты старательно работаешь и не один месяц. Да, ты получаешь зарплату, но где удовлетворение от проделанной работы? Так и свихнуться недолго, если каждый день все рабочее время выкапываешь, а потом закапываешь выкопанную яму.
Вот потому-то все и идут на ухищрения. Зачем пидумывать что-то новое, когда старое хорошо работает? Возможно нужно немного изменить старое и все будет хорошо?
То, что я написал, касается многих вещей. Не только core-механики. Другие вещи могут быть подвержены этому.
//===
В процессе работы над персонажем всплыло множество моментов, которые требовали такой хорошей и основательной проработки как со стороны дизайнера-программиста, так и со стороны дизайнера по механикам.
В процессе разаработки, было принято решение показыват игроку тело персонажа, чтобы он мог видеть себя своими глазами. Почему нет? Это добавляет атмосферы, смотрится круто.
Мы все фанаты крутого графона и в 21-м веке неприемлимо, когда твоя голова, руки, ноги или пушка влазят в полы или стену или еще куда-то. Нужно было это учесть.
С другой стороны, если персонаж стоит одной ногой на выступе обрыва, то все его тело должно как-то отреагировать на то, что вторая нога в воздухе. А если центр тела персонажа смещен в сторону обрыва, то тут уж 100% нужно это как-то отобразить на персонаже.
Мы справились с этой задачей, сбоку это выглядит так (скрины специально не содержат текстур, дабы не наспойлерить):
По части влияния смещения тела на механику движения: удалось добиться стабильности и минимизировать влияние анимации ног на перемещение игрока.
Ноги опускаются процедурно. Пришлось водключить инверсную кинематику и совместить ее с процедурной анимацией движения всего персонажа. О том как мы анимировали персонажа можно ознакомиться здесь: Процедурная анимация движения персонажа
Получилось весьма недурно :)
Руки.
C руками, как и со всем остальным, отдельная история. И она длинная.
Что требуется от рук? Чтобы они не пересекали стены, чтобы держали пушку. И чтобы это все выглядело нормально. Бывшый мой босс всегда ставил задачу примерно так. Он перечислял все требования до мельчайших и в конце добавлял: "И да, сделайте все это так, чтобы выглядело круто. Просто сделайте так, чтобы все было круто и не заставляйте меня говорить что получился отстой."
Руки персонажа эволюционировали и прошли очень долгий путь развития. Сперва мы работали над встроенной в руку "спец.пушкой". Всячески безуспешно пытались совместить то, что совместить трудно, да и нужно ли совмещать: руку + пушку + возможность изменения рукой гравитационного поля. Вот пара каких-то ранних скетчей "спец.пушки":
Подключенные первые варианты рук/манипуляторов выглядел примерно так:
Здесь один из вариантов ранних анимаций. Главное не внешний вид, а принцип работы:
Пробовали такие варианты:
Один манипулятор наехал на другой. Да, такое часто встречалось и приходилось много работать над исключением самопересечения манипуляторов.
Тесты инверсной кинематики. Чисто математика:
А здесь искусственный интеллект нечеловеческими способами учился взаимодействию рукой. Короче, робот как ребенок учился двигать рукой, а на видео некоторые промежуточные результаты, причем неуспешные XD
Инверсная кинематика в чистом виде (IK):
Еще немного инверсной кинематики для тех кому понравились видео:
Здесь эксперименты того как смотрится перемещение обьекта манипуляторами (как манипуляторы ведут себя при перемещении аюстрактного куба):
Навозившись порядочно с манипуляторами, убив тонну времени, сил и нервов, исписав кучу бумаги, мы все же сумели добиться желаемого результата. Финальный вариант на данный момент показать не могу, но могу рассказать к чему мы пришли и как.
Манипулятор мы разделили, условно, на руку (манипулятор) и пушку. Пушка выполняет свои функции, а рука дополняет пушку. Не в воздухе же ей висеть.
Пришлось прописат анимации обхвата пушки рукой и то как рука двигается за пушкой (законы движения, которые позволяют руке не пересекать пушку).
Так же рука может быть и без пушки. Для этого случая мы научили кисть немног взаимодействовать с окружением: если игрок вплотную подходит к стене, то рука как бы занимает промежуточную позицию между стеной и телом игрока. не дает игроку лицом воткнуться в стену. Классно, правда? Так же рука может огибать предметы, если игрок захочет как-то повести себя нестандартно и влезть рукой во что-то.
Когда рука держит пушку, то для этого случая прописаны процедурные анимации движения пушки, которые предостерегают ее от влазания в стены или еще куда-то там. Пришлось порядочно поработать чтобы хитрый игрок никак не смог засунуть пушку туда, куда нельзя.
Некоторые скетчи из процесса разработки игры выкладываю здесь:
https://www.instagram.com/cgaleksey/
--
Надеюсь статья понравилась и вы почерпнули из нее что-то новое.
На сегодня у меня все.
Спасибо за внимание!
Процедурная анимация движения персонажа
Этот пост скорее всего не будет полезен профессиональным аниматорам так как они делают анимации на завтрак, обед и ужин. Думаю их этим не удивить. Так же в посте отсутствует мат.часть ибо писал не для того чтобы учить кого-то. Пост в целом для того чтобы показать обобщенное направление работы и полученный мною результат.
Возникла необходимость сделать анимацию персонажа для игры, которую делаю "на коленке".
Ссыли на наработки по игре:
https://www.instagram.com/cgaleksey
Чем не угодили mocap - анимации:
1) нужно искать наиболее подходящие анимации
2) нужно много анимаций
3) визуально анимации должны сочетаться
Покопавшись в сети и немного поэкспериментировав с аниматором, пришел к тому, что для создания реалистичной анимации нужно записывать анимацию непосредственно с человека.
Можно брать готовые анимации с https://www.mixamo.com но есть НО:
1) анимации неуникальны
2) все же урезаный набор анимаций
Побираясь, как бездомный в чьем-то ведре, в поисках нужных анимаций в течении недели я собрал некого Франкенштейна. Именно Франкенштейна потому, что анимаций надыбал отовсюду. Ходил персонаж как офисный работник, крался как эльф 80-го уровня, приседал как человек-паук. Шучу, все было не так уж и ужасно, конечно, для обывателя может и пойдет, а вот меня все же неустраивало разношерстность анимаций. Хотя блендинг и прочие процедурные фишки сильно улучшали дело... Да и ноги не прилипали к земле как надо. Меня это жутко раздражает, когда анимация персонажа не на 100% соответствует тому, что он делает, ноги проходят сквозь пол, руки сквозь стены... ну вы поняли, 21-й век как никак.
Что важно для анимации персонажа: нужно передать ощущение того как персонаж передвигается с учетом физики. Короче, аимация нужна процедурная. Это крайне важно для нашего 3D паззла от первого лица.
Итак поехали. Обобщенно задача состоит в разработке системы анимации персонажа таким образом, чтобы можно было относительно гибко настраивать анимацию под свои нужды (корче, еще раз, чтобы анимация была процедурной).
Для реализации этого, нужно знать что есть инверсная кинематика и уметь ее. Погуглив и ознакомившись собрал простейшую IK, подключил пару костей. Работает. Добавили ограничения, чтобы локти не выворачивались в другие стороны и чтобы кости были похожи на кости. Сделано.
Далее, настало время для машинного обучения. Подключаем обучалку к ногам и обучаем ноги ходить, а руки крутиться. На Github был пример с какими-то бегающими человечками с разным количеством ног. Этот проект лег в основу. Далее не помню как закончил этот адский ад.
В итоге после 2-х недель возни по 12 часов со всей этой ерундой у меня на столе лежал набор как-то дергающихся тестовых конечностей. Кстати, некоторые видео сохранил. Не думал что решу писать об этом пост:
Отлично, цепляем все к боди, еще немного IK и получаем что-то типа (одно из приближений):
Внимание на лодыжку ^. C ней вечно были проблеммы. Дело в том, что наш робот сделан инженерами-конструкторами и соединения должны гнуться строго по оси и никак иначе. Хотя это далеко не последний вариант робота, но в целом все примерно так. (Спойлер: соединение ложыжки мы все же переделали. Инженеры поставили его на 3 гидропривода, что дало нужное число степеней свободы).
Далее используем наш ИИ для ноги. Не зря же нога у нас обучалась ходить сама по себе без тела XD
Подключаем ИИ к ногам и говорим им болтаться:
А теперь ногам приказываем ходить. Здесь нет отклика от пола, ноги не воспринимают коллайдер пола. Иначе роботу на самом деле пришлось бы пойти.
Ну вот все что сделано выглядит вроде и ничего, по отдельности. Когда я соединил все в одно тело, то понял: емое... Позиция ноги, руки, головы (короче, каждой части тела) должна вносить изменение в позицию всего тела и следовательно влиять на другие конечности. Иначе робот ходил как деревянный буратино. Ничего не поделаешь, видать именно так ходят "идеальные" машины лишенные уникальности (уровень робота "Вертер" достигнут!):
Повозившись еще с инверсной кинематикой и мозгами всех частей тела, все же удалось сделать анимацию более естественной.
Здесь экспериментирую с тем как робота придавливает плита. Робот должен корректно анимировать позицию своего тела:
На вторые руки не обращайте внимания. Сделал доп.пару рук чисто для себя, для сравнения того как разные алгоритмы будут обрабатывать стену.
Что хотелось бы добавить. Полностью избежать использования mocap анимации не удалось. Почему так? Дело в том, что роботу нужна индивидуальность, стиль перемещения. именно для этого ему даются наборы анимаций с которых он перенимает пластику движения и испоьзует ее при расчете процедурной анимации перемещения. Как-то так.
В тестах использовалась модель-аналог робота Федора. Извините, это неточная копия. Чертежей не было, собрали "на глаз" XD
Демка — валентинка
Сделал процедурную анимацию с помощью кода на JavaScript и трёх картинок. Для того, чтобы сделать поворот, генерирую облако точек, которое спереди выглядит как одна картинка, а сбоку как другая. Правда такое облако можно сгенерировать не для любой пары изображений, поэтому пришлось добавить немного магии.
В живую можно посмотреть на гитхабе https://mblkolo.github.io/vday4.html
JS, canvas и немного линейной алгебры.
Процедурная валентинка
Вот уже третий год я делаю процедурные валентинки. В этом году получилась вот такая вот
К сожалению гифка пережалась в какое-то мыло :(
Лучше смотреть вживую http://mblkolo.github.io/vday3.html выглядит лучше, да и грузится быстрее.
Я точно не уверен кому такой подарок приносит больше радости: мне или получателю :) Обычно есть какая-то идея процедурной генерации и общее представление о том, что должно получиться, но результат всегда удивляет.
Скажем, в это раз, я хотел сделать точки, степенно плавающие внутри квадрата, точки находящиеся внутри или снаружи сердца должны были соединяться линиями, линии тем ярче, чем ближе точки меж собой. А получилась какая-то Коралина в стране кошмаров, по крайне мере, никак не могу отделать от этой ассоциации.