Как мы избавились от real-time теней в своей игре Slash Arena.

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

В unity есть возможность "запечь" свет - просчитать карту теней заранее для статических объектов и записать ее в текстуру.
Но это работает только с неподвижными объектами. А что делать с двигающимися персонажами, их оружием и другими предметами?

Если полностью отключить просчет динамических теней(тени, которые могут менять позицию, масштаб и форму) фпс взлетает до небес на мобильных устройствах. Осталось придумать, как их заменить.

Мы применяем следующее решение: есть набор заранее подготовленных текстур с простыми формами - круг, квадрат, стейк(именно форма стейка:) )
Эти текстурки подкладываются под объекты, которые должны иметь тень, и при помощи скейла и наложения друг на друга создают форму близкую к форме реальной тени. Причет прозрачность тени меняется вместе с высотой объекта, имитируя поведение реальной тени.

Вот как это выглядит в игре:
На простом объекте https://i.gyazo.com/1d34108c449fc55a4846e1f1d31d3aff.mp4
На сложном объекте https://i.gyazo.com/c73905c1bc0ce9d945754b12505e8497.mp4
(оранжевым внизу выделены фейковые тени)

Еще несколько из примеров визуального "обмана":

1) Камера в главном меню не двигается и не крутится, поэтому мы заменили все окружение на статичную картинку:
https://i.gyazo.com/316a9328a3e917556732384da678aa2e.mp4
(вверху - то, что отображается в игре, внизу - то, как объекты расположены в реальности)

2) В бою мы отображаем только те объекты которые попадают в область видимости камеры
https://i.gyazo.com/93a5d61a94269b4ef04b537e5dcddfa2.mp4
(вверху - то, что отображается в игре, внизу - то, как объекты расположены в реальности)

В своей игре Slash Arena нам пришлось оптимизировать анимацию смерти.
Боевка игры - бегать по арене и крутить вокруг себя здоровенным топором, стараясь попасть по другим игрокам. Хорошо попал — убил.
(пример геймлея https://www.youtube.com/watch?v=Wyx1ju4s6hY)

Чтобы смерть от топора была эффектной, мы использовали обычную ragdoll анимацию, построенную на физике. И всё было хорошо. Поначалу.

А потом, с увеличением количества персонажей и расчетов, игра начала подтормаживать на старых телефонах. Отключали всю физику — получали 50-60 кадров секунду и абсолютную плавность процесса.
Но отказываться от красивых смертей персонажей уже совсем не хотелось.

Можно было озадачить аниматоров. Мы даже почти отдали эту задачу в работу, как пришла мысль: почему бы не записать несколько ragdoll смертей прямо в Unity, и потом просто показывать нужную анимацию?

Мы написали специальный класс, который записывает все поведение ragdoll-объекта просчитанного по физике в файл с анимацией. И уже во время боя воспроизводили именно анимацию и тем самым полностью избавились от необходимости симулировать физику.

Смерти получатся разнообразными, аниматоров подключать не нужно, а главное — все будет быстро и красиво.

ссылка на исходники https://github.com/DrunkenMonday/AnimationRecorder

4С это 4 х 1С

концепт для адаптации игры под изменение настроения игрока, я не писатель, так-что читать может быть сложно.
Возможно, по большому счёту относится только к интерактивным играм, особенно на приставках.
Суть в том, что камера в реальном времени оценивает настроение игрока во время прохождения, микрофон следить за громкостью комментариев (если она вообще есть), и сама игра за интенсивностью нажатия клавиш (press x to win)
Если, допустим, темное освещение у игрока, игра меняет фильтры цветов на более мрачные, чтобы больше испугать играющего (в идеальности, конечно, считывать эмоции с лица, если игрок заскучал, для контроля уровнем сложности, но это будет еще не скоро). Вообще, интерактивное кино, так устроено, что гейм-дев следующего поколения этого жанра будет примерно на это и заточен, к адаптации к игроку и установления контакта Игра-Игрок, допустим вы не можете пройти один уровень, ну лично вам не комфортно играть тут, и игра чуть-чуть смягчает сложность, но в следующих уровнях будет компенсировано.
Еще про звук была идея: Электронное пианино от синтезатора отличается тем, что одно в реальном времени создаёт звук, а другое играет записанный (если хороший синтезатор там несколько звуков на одну клавишу, зависит от степени нажатия), то в играх примерна вторая система, но что если сделать, чтобы например звук от выстрела не записанный был, а по алгоритму создавался каждый раз при нажатии fire?, что если бы звуки были записаны лишь в качестве карты шума, получается при его создании каждый был бы, немного но разный, конечно, в реальности такое почти не осуществимо из-за высокой нагрузки на процессор.
контакты свои не оставлю, так-как такой бред далекого от гейм-дева человека, победить не может.
p.s: если есть ошибки не серчайте.

То чувство, когда живёшь вдалеке от городов, где проходят гейм-дев мероприятия и не имеешь возможности съездить на них. =_=

Боюсь ребята в комментариях начнут копипастить идеи из интернета, на манеру кошек в фаллоут 4 и победит лучшая паста

Увы, до Питера мне добраться не суждено в ближайшем будущем. :(

У меня есть идея для геймдизайна сетевых тактический шутеров. Внедрение гаджетов для сбора информации (камеры , дроны ,коптеры и тд) в телефон . Так удобно пользоваться и всегда видно расположение врага.

Комментарий недоступен

А я бы просто не отказался бы от редактора карт в дарк соулсе)

Детектор теней в Invisible shadow. Игра в жанре стэлс-экшен, где одной из главных фич возможность прятаться в тени. Игра разрабатывается на Unity под мобильные платформы, поэтому нет реалтайм освещения.
Первый вариант:
В игре пускать луч ко всем источникам освещения кто находится в определенном радиусе, и проверять есть стена на пути к свету или нет и в зависимости от этого игрок находится в тени или нет. На мобильных это накладно с учетом присутствия ИИ.
https://fastpic.co/image/Pr6Qpm

Но это не основная проблема. Проблема в то что при таком методе это будет работать как выключатель.
https://fastpic.co/image/Pr6eV6

Плюс возникает ещё проблема если источник света находится рядом, но его стена не загораживает, при этом он светит слабее чем источник 1 и тень за стеной остаётся.
И игрок получается не в тени.
https://fastpic.co/image/Pr6J30

Конечно можно это решить дополнительными переменными, но первую проблему с вкл\выкл это не решает.

Второй вариант не привязываться к освещению. Т.е. расставляем триггеры и центр тени.
https://fastpic.co/image/Pr6FEH

В этом варианте если мы зашли в триггер, начинаем рассчитывать расстояние до центра тени, и от этого мы узнаём в какой мы темноте.
Минусы при таком методе это плохие показания в длинных тенях, расстановка триггеров по карте, невозможность спрятаться в слабой тени, при прокачке возможности.

Третьим способом на котором я остановился это создание карты теней.
https://fastpic.co/image/Pr6uRn

На этой картинке запечённый свет с видом сверху. На этом этапе вытекают ещё минусы первых двух вариантов.
После этого мы переносим эту картинку в фотошоп, где переводим в чёрно-белый. Немного работаем размытием, где нам бы хотелось разбавить резкие переходы.
https://fastpic.co/image/Pr6feO

Теперь нам осталось лишь научить игрока получать значение от 0 до 1, о его текущей освещенности.

В Unity есть хорошая возможность RenderTexture. Создаём камеру, ставим сверху игрока и делаем чтобы она двигалась вместе с игроком.
https://fastpic.co/image/Pr6ZYr

Создаём RenderTexture несколько пикселей, нам нужен только один центральный, и делаем выборку GetPixel().grayscale. В итоге мы получаем значение от 0 до 1 об уровне освещенности в данном месте. И для оптимизации делаем свой Update с 15 кадрами в секунду.

Для теста напишу что-нибудь про звук. Для шутеров подключаем поддержку SUBPAC или аналогов. Теперь можно физически ощущать вибрацию от низкочастотных звуков (взрывы, выстрелы и подобное), что даст еще больше ощущений от игры.

Часто на мобилках встречаю проекты с неподходящими для платформы решениями в плане интерфейса (сенсорные джойстики придумал Сатана), обратной связи и геймплея в целом. Ужасно надоели эти 2d бродилки с кучей кнопок, просто переносящие привычные элементы из других систем. Собственно поэтому я решил попробовать поэкспериментировать и представить своё видение подобного жанра (а конкретно dungeon crawler) игры, созданной специально для мобильных платформ. Вот какие интересные идеи ко мне пришли в процессе:
1) Основной акцент я сделал на максимально удобном управлении. Отсюда, во-первых, вертикальная ориентация, чтобы можно было держать телефон одной рукой. Во-вторых, все основные действия (пока что только перемещения, но в дальнейшем введу мини-игры и сражения с противниками) выполняются свайпом в одну из 4х сторон из-за чего игроку достаточно использовать лишь один большой палец.
2) Что касается геймплея, то я решил отойти от канона «зачистки подземелий» и предоставить игроку роль уязвимого героя, которому совершенно необязательно и даже опасно сражаться с противниками. В имеющемся прототипе встреча с врагом вообще значит game over! Видимость ограничена, в единственный момент времени игроку доступна только узенькая комнатка. Как же узнать, что дальше мы наткнемся на блуждающего по этажу туда-сюда противнику? Сам персонаж нам подскажет! Мы не можем довериться его подсказкам на 100% (в подземельях темно, мог перепутать), но если при попытке перехода в следующую комнату на экране появится восклицательный знак, то стоит вернуться на этаж выше и пропустить патруль мимо. Так, не изменяя модель управления, я расширил игровую механику элементом стелса.
3) Я не хотел использовать уже опостылевший всем пиксель-арт, поэтому попросил своего художника сделать какой-нибудь оригинальный хэнд пейнт стиль. Ему пришлось бы отрисовать целую кучу высококачественных кадров от руки, если бы не одно элегантное решение: каждая анимация состоит из единственного кадра – их ключевые состояния, а переходы между ними программно сглаживаются уходом спрайта в альфа-канал. Получился этакий stop-motion, управляемый пальцем игрока.

Пока что проект на раннем этапе разработки, но выглядит это уже вот так: