Как мы разрабатывали части персонажа. Персонаж : правдоподобие против удобства управления
Разработчики находятся в достаточно трудной ситуации. С одной стороны начальство требует дойную корову, которая стабильно работает как автомат калащникова и приносит денежку. C другой стороны таких дойных коров уже изобретено достаточно и в целом все они похожи друг на друга с точки зрения наличия новых уникальных механик и их развития.
На первый взгляд все кажется просто. Вот, на самом деле, почему нельзя просто создать какую-то новую механику, даже много новых механик и улучшать их пока они не устроят? Если что, неудачные механики можно выкинуть :)
<<Для начала в игре существует только одна core-механика. И для ее реализации, поверьте, придется уйти в работу с головой. Создавать нексолько механик = создавать несколько разных игр. А это равносильно усложнению своей жизни. Вместо шлифовки одной механики вы должны распылиться на 10, а потом оставить из них только одну, а остальные выкинуть. Печально выкидывать результаты работы, правда?>>
Разработка игры с новой механикой - это примерно то же самое как работа над открытием или даже процесс поиска клада. Отлично, если вы опытный кладоискатель. Такие кладоискатели знают, что клад вряд ли спрятан в песочнице на детской площадке и не будут его там искать, тратить на это время. Потому что в свое время они уже наступали на эти грабли и ничего там не нашли. То есть существуют механики, которые заведомо неудачны / непригодны для игр. Конечно, все можно адаптировать, видоизменить, подогнать. Но все же существуют вещи которые не следует делать.
Вот рассмотрим очень простой пример такой механики на мобильной игре.
Допустим у нас есть персонаж в мобильной игре и наша задача управлять им. Мы видим персонажа сверху (2D). Как бы в сделали его управление?
Это очень щепетильный вопрос. Управление - это задача задач, которую решают в процессе разработки.
(1) Если вы будете приказывать персонажу идти за пальцем, когда он опущен на экран, то ваша рука будет перекрывать экран и вы будете смотреть на свою руку;
(2) А если персонаж будет идти в противоположную о пальца сторону, то будет ли удобно такое интвертирование управления?
(3) Если персонаж будет идти в точку, которую вы кликнули, то сможет ли он увернуться от летящей ракеты? Не перекроется ли экран рукой, когда вы смените направляение движения персонажа? Это управление точно удобно?
(4) А если просто... Джойстик и все тут! Не перекроет ли джойстик экран? Сколько экранного пространства он занимает (допустимо ли это)? Удобен ли он? Функционален? Позволяет ли он погрузиться в атмосферу игры?
Кто-то скажет: вот вы написали столько всего, так и управления не сделаешь, если все плохои все "неочень". Сделаешь, как раз это частично задача дизайнера интерфейсов, частично дизайнера, отвечающего за управление. Но больше, конечно, задача дизайна управления.
Да, вот такими задачами и занимаются дизайнеры: сделай то, не знаю что, пойди туда, не знаю куда и чтобы все было круто и никак иначе.
Оптыный дизайнер (опытный кладоискатель) способен быстро оценить все "за" и "против" каждого из пунктов [1-4]. Новичок же, очень вероятно, будет экспериментировать и постигать тайны управления с нуля :)
Надеюсь теперь стало очевидней, что разработка новой механики - это работа.
Это работа и она не всегда увенчивается успехом. Не всегда даже опытному дизайнеру удается создать новую механику. И это часто зависит не только от дизайнера, но и от команды, от возможностей платформы для которой все разрабатывается.
Дизайнер создает тех. задание, отдает ее на реализацию дизайнерам и программистам, через какое-то время получает результат. Если результат устраивает, то это успех. Если результат не устраивает, то процесс повторяется до того момента, пока инвестору все это не надоест или пока команда не замучается "пробовать". Да, людям не нравится работать, а потом выкидывать свою работу. Особенно, когда ты старательно работаешь и не один месяц. Да, ты получаешь зарплату, но где удовлетворение от проделанной работы? Так и свихнуться недолго, если каждый день все рабочее время выкапываешь, а потом закапываешь выкопанную яму.
Вот потому-то все и идут на ухищрения. Зачем пидумывать что-то новое, когда старое хорошо работает? Возможно нужно немного изменить старое и все будет хорошо?
То, что я написал, касается многих вещей. Не только core-механики. Другие вещи могут быть подвержены этому.
//===
В процессе работы над персонажем всплыло множество моментов, которые требовали такой хорошей и основательной проработки как со стороны дизайнера-программиста, так и со стороны дизайнера по механикам.
В процессе разаработки, было принято решение показыват игроку тело персонажа, чтобы он мог видеть себя своими глазами. Почему нет? Это добавляет атмосферы, смотрится круто.
Мы все фанаты крутого графона и в 21-м веке неприемлимо, когда твоя голова, руки, ноги или пушка влазят в полы или стену или еще куда-то. Нужно было это учесть.
С другой стороны, если персонаж стоит одной ногой на выступе обрыва, то все его тело должно как-то отреагировать на то, что вторая нога в воздухе. А если центр тела персонажа смещен в сторону обрыва, то тут уж 100% нужно это как-то отобразить на персонаже.
Мы справились с этой задачей, сбоку это выглядит так (скрины специально не содержат текстур, дабы не наспойлерить):
По части влияния смещения тела на механику движения: удалось добиться стабильности и минимизировать влияние анимации ног на перемещение игрока.
Ноги опускаются процедурно. Пришлось водключить инверсную кинематику и совместить ее с процедурной анимацией движения всего персонажа. О том как мы анимировали персонажа можно ознакомиться здесь: Процедурная анимация движения персонажа
Получилось весьма недурно :)
Руки.
C руками, как и со всем остальным, отдельная история. И она длинная.
Что требуется от рук? Чтобы они не пересекали стены, чтобы держали пушку. И чтобы это все выглядело нормально. Бывшый мой босс всегда ставил задачу примерно так. Он перечислял все требования до мельчайших и в конце добавлял: "И да, сделайте все это так, чтобы выглядело круто. Просто сделайте так, чтобы все было круто и не заставляйте меня говорить что получился отстой."
Руки персонажа эволюционировали и прошли очень долгий путь развития. Сперва мы работали над встроенной в руку "спец.пушкой". Всячески безуспешно пытались совместить то, что совместить трудно, да и нужно ли совмещать: руку + пушку + возможность изменения рукой гравитационного поля. Вот пара каких-то ранних скетчей "спец.пушки":
Подключенные первые варианты рук/манипуляторов выглядел примерно так:
Здесь один из вариантов ранних анимаций. Главное не внешний вид, а принцип работы:
Пробовали такие варианты:
Один манипулятор наехал на другой. Да, такое часто встречалось и приходилось много работать над исключением самопересечения манипуляторов.
Тесты инверсной кинематики. Чисто математика:
А здесь искусственный интеллект нечеловеческими способами учился взаимодействию рукой. Короче, робот как ребенок учился двигать рукой, а на видео некоторые промежуточные результаты, причем неуспешные XD
Инверсная кинематика в чистом виде (IK):
Еще немного инверсной кинематики для тех кому понравились видео:
Здесь эксперименты того как смотрится перемещение обьекта манипуляторами (как манипуляторы ведут себя при перемещении аюстрактного куба):
Навозившись порядочно с манипуляторами, убив тонну времени, сил и нервов, исписав кучу бумаги, мы все же сумели добиться желаемого результата. Финальный вариант на данный момент показать не могу, но могу рассказать к чему мы пришли и как.
Манипулятор мы разделили, условно, на руку (манипулятор) и пушку. Пушка выполняет свои функции, а рука дополняет пушку. Не в воздухе же ей висеть.
Пришлось прописат анимации обхвата пушки рукой и то как рука двигается за пушкой (законы движения, которые позволяют руке не пересекать пушку).
Так же рука может быть и без пушки. Для этого случая мы научили кисть немног взаимодействовать с окружением: если игрок вплотную подходит к стене, то рука как бы занимает промежуточную позицию между стеной и телом игрока. не дает игроку лицом воткнуться в стену. Классно, правда? Так же рука может огибать предметы, если игрок захочет как-то повести себя нестандартно и влезть рукой во что-то.
Когда рука держит пушку, то для этого случая прописаны процедурные анимации движения пушки, которые предостерегают ее от влазания в стены или еще куда-то там. Пришлось порядочно поработать чтобы хитрый игрок никак не смог засунуть пушку туда, куда нельзя.
Некоторые скетчи из процесса разработки игры выкладываю здесь:
https://www.instagram.com/cgaleksey/
--
Надеюсь статья понравилась и вы почерпнули из нее что-то новое.
На сегодня у меня все.
Спасибо за внимание!
Heroes 3. Citadel - MIX
4 месяца назад выкладывал пост "в процессе 2". Шли недели, месяца и потихоньку я закончил все оборонительные сооружения города Цитадель =)
Надеюсь вам понравится (хотя текстурирую я плоховастенько).
Отдельные рендеры
Heroes 3. Castle
Наконец-то закончил делать Замок.
20 дней, от начала и до финального рендера, который занял 8 часов.
8 часов(600 фреймов) ради 10 секунд КАРЛ! xD
Рендер из Substance Painter.
Рендер из Blender
С флагами была определённая проблема.
Задача герба была на отдалённом расстоянии хорошо отображать содержимое.
Сначала я взял иконку из HD Edition, но она была не совсем такой какой хотелось бы видеть. Пошёл искать в дискорде и в ВК может у кого есть получше что-нибудь, со мной поделились официальными рендерами грифона. Ну, а один парень в ВК предложил за небольшую сумму сделать с нуля герб. В конечном счёте я решил всё же купить у него герб ручной работы, так как мы в процессе вносили правки. Задача была сделать так что бы грифон был вытянут по вертикали и слегка приплюснут по горизонтали для полноценного размещения на прямоугольном флаге. Проблема HD Edition грифона и оф рендера как раз таки заключалась в том что они были более квадратные и в итоге тогда чтобы поместились и крылья и когти приходилось сильно сжимать картинку.
1) HD Edition
2) Оф рендер
3) Первый вариант сделанный Никитой ( https://vk.com/im?sel=266308928 )
4) Финальный вариант который может быть с близкого расстояния и выглядит похуже немного чем его первый вариант, но с дальней дистанции отлично смотрится, в то время как первый вариант хорошо смотрится с близкого расстояния, но на отдаление уже не разберёшь что там.
Ну, что же, до скорых встреч =)
Солдат в PUBG
Моделька
Класс - строитель
Раса - древние
Особенность - мутирует в здание (может построить только одно)
Трофи модели Land Rover Defender
6 языков программирования для мобильных игр
Рынок растет, к 2027 году аудитория мобильных игр увеличится на треть — до 35 миллионов человек. Рассказываем, какие языки программирования учить, чтобы войти в IT через геймдев.
Игровым разработчикам требуются программисты под разные проекты, от уровня казуальной Among Us до action RPG вроде Genshin Impact. Но выбор языка определяется не только графикой.
Есть две основные платформы для разработки мобильных игр:
Android;
iOS.
Ниже привели примеры популярных языков программирования, совместимые с этими операционными системами.
Основой язык для разработки игр для смартфонов с полной поддержкой Android. Его относительно просто освоить с нуля благодаря развитому сообществу и обилию библиотек. А встроенная виртуальная машина Java (JVM) обеспечивает производительность.
Kotlin
Новый перспективный язык, который призван заменить Java. Он тоже работает на JVM, но при этом его код легче и проще. В основном на Kotlin создают игры на Android, но при желании можно кодить и под iOS: например, прописывать логику через Kotlin Multiplatform (KMP).
Swift
Язык программирования от Apple, который пришел на смену устаревшему Objective-C. На нем пишут игры для iOS. В Swift интуитивный код, доступно много фреймворков для работы с 2D и 3D (SpriteKit, SceneKit, Metal), постоянно обновляются функции и библиотеки.
Lua
Скриптовый производительный язык, который используют в игровых движках и фреймворках вроде Solar2D, Defold. Благодаря этому он кроссплатформенный: на нем пишут игры для Android и iOS.
Универсальный язык программирования для игр, который поддерживает в том числе Android и iOS. Он очень мощный, поэтому используется для портирования крупных проектов на мобильные платформы. Совместим с движком Unreal Engine.
С#
«Облегченная» версия С++, на которой основан игровой движок Unity. Язык понятный для новичков в программировании. С его помощью можно создавать 2D и 3D игры любого уровня сложности.
Для тех, кто хочет создавать мобильные игры, мы в Яндекс Практикуме подготовили онлайн-курсы по направлениям «Android-разработчик» и «iOS‑разработчик». С ними вы освоите все нужные языки программирования, чтобы устроиться в геймдев или начать свой проект.
Реклама ООО «Яндекс», ИНН: 7736207543
Здания в Dangerous Depth (часть 2)
Dangerous Depth - это новая подводная RTS.
Здание по сбору ресурсов (силос)
Склад. На него с добытчиков специальные корабли привозят ресурсы.
После постройки открывает доступ к научному центру и сонару.
Улучшение:
• 2/3 место сброса ресурсов
Броня - средняя
Здание для производства снарядов (арсенал)
Производит снаряды всех типов. Открывает доступ к постройке верфи и лаборатории.
Улучшения:
• производит торпеды с повышенной скоростью
Броня - средняя
Сонар
Обнаруживает объекты
Улучшение:
• дальность
• распознавание
Броня - легкая
Научный центр
В нем изучают новые технологии. После постройки открывает возможность строить верфь
Броня - легкая
Верфь
В ней производятся фрегаты, крейсеры, линкоры
Улучшения:
• стратегические запасы (производит бесплатные снаряды)
Броня - тяжёлая
(Это здание в разы больше остальных)
Ремонтная станция
Ремонтирует корабли
Улучшения:
• реактор (быстрее ремонт)
Броня - средняя
Лазерная турель
Эффективна против : истребителей, торпедоносцев, разведчиков
Малоэффективна против :
фрегатов, линкоров, крейсеров
Броня - легкая
Торпедная турель
Эффективна против :
фрегатов, линкоров, крейсеров
Малоэффективна против :
истребилетей, торпедоносцев, разведчиков
Оружие - осколочные торпеды
Броня - средняя
Если кому-то интересен проект, то вот ссылка на сообщество:
https://vk.com/dangerous_depth