Как мы избавились от real-time теней в своей игре Slash Arena.
Игра сделана на Unity и работает как на мобильных девайсах, так и на десктопах. На мобильниках все очень плохо с фпс и приходится использовать любую возможность для оптимизации. Так вышло и с тенями.
В unity есть возможность "запечь" свет - просчитать карту теней заранее для статических объектов и записать ее в текстуру. Но это работает только с неподвижными объектами. А что делать с двигающимися персонажами, их оружием и другими предметами?
Если полностью отключить просчет динамических теней(тени, которые могут менять позицию, масштаб и форму) фпс взлетает до небес на мобильных устройствах. Осталось придумать, как их заменить.
Мы применяем следующее решение: есть набор заранее подготовленных текстур с простыми формами - круг, квадрат, стейк(именно форма стейка:) ) Эти текстурки подкладываются под объекты, которые должны иметь тень, и при помощи скейла и наложения друг на друга создают форму близкую к форме реальной тени. Причет прозрачность тени меняется вместе с высотой объекта, имитируя поведение реальной тени.
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-объекта просчитанного по физике в файл с анимацией. И уже во время боя воспроизводили именно анимацию и тем самым полностью избавились от необходимости симулировать физику.
Смерти получатся разнообразными, аниматоров подключать не нужно, а главное — все будет быстро и красиво.
концепт для адаптации игры под изменение настроения игрока, я не писатель, так-что читать может быть сложно. Возможно, по большому счёту относится только к интерактивным играм, особенно на приставках. Суть в том, что камера в реальном времени оценивает настроение игрока во время прохождения, микрофон следить за громкостью комментариев (если она вообще есть), и сама игра за интенсивностью нажатия клавиш (press x to win) Если, допустим, темное освещение у игрока, игра меняет фильтры цветов на более мрачные, чтобы больше испугать играющего (в идеальности, конечно, считывать эмоции с лица, если игрок заскучал, для контроля уровнем сложности, но это будет еще не скоро). Вообще, интерактивное кино, так устроено, что гейм-дев следующего поколения этого жанра будет примерно на это и заточен, к адаптации к игроку и установления контакта Игра-Игрок, допустим вы не можете пройти один уровень, ну лично вам не комфортно играть тут, и игра чуть-чуть смягчает сложность, но в следующих уровнях будет компенсировано. Еще про звук была идея: Электронное пианино от синтезатора отличается тем, что одно в реальном времени создаёт звук, а другое играет записанный (если хороший синтезатор там несколько звуков на одну клавишу, зависит от степени нажатия), то в играх примерна вторая система, но что если сделать, чтобы например звук от выстрела не записанный был, а по алгоритму создавался каждый раз при нажатии fire?, что если бы звуки были записаны лишь в качестве карты шума, получается при его создании каждый был бы, немного но разный, конечно, в реальности такое почти не осуществимо из-за высокой нагрузки на процессор. контакты свои не оставлю, так-как такой бред далекого от гейм-дева человека, победить не может. p.s: если есть ошибки не серчайте.
У меня есть идея для геймдизайна сетевых тактический шутеров. Внедрение гаджетов для сбора информации (камеры , дроны ,коптеры и тд) в телефон . Так удобно пользоваться и всегда видно расположение врага.
В сетевых шутерах внимание должно быть приковано к экрану. Плюс это введет дизбаланм. Все будут тупо раскидывать все эти гаджеты по карте и сидеть, ждать противника, посматривая в телефон.
Ну что же вы так поздно публикуете, хотя бы за пару недель эту новость, было бы время для подготовки к поездке (в случае победы), а так не успеть многим туда.
Детектор теней в Invisible shadow. Игра в жанре стэлс-экшен, где одной из главных фич возможность прятаться в тени. Игра разрабатывается на Unity под мобильные платформы, поэтому нет реалтайм освещения. Первый вариант: В игре пускать луч ко всем источникам освещения кто находится в определенном радиусе, и проверять есть стена на пути к свету или нет и в зависимости от этого игрок находится в тени или нет. На мобильных это накладно с учетом присутствия ИИ. https://fastpic.co/image/Pr6Qpm
Но это не основная проблема. Проблема в то что при таком методе это будет работать как выключатель. https://fastpic.co/image/Pr6eV6
Плюс возникает ещё проблема если источник света находится рядом, но его стена не загораживает, при этом он светит слабее чем источник 1 и тень за стеной остаётся. И игрок получается не в тени. https://fastpic.co/image/Pr6J30
Конечно можно это решить дополнительными переменными, но первую проблему с вкл\выкл это не решает.
В этом варианте если мы зашли в триггер, начинаем рассчитывать расстояние до центра тени, и от этого мы узнаём в какой мы темноте. Минусы при таком методе это плохие показания в длинных тенях, расстановка триггеров по карте, невозможность спрятаться в слабой тени, при прокачке возможности.
На этой картинке запечённый свет с видом сверху. На этом этапе вытекают ещё минусы первых двух вариантов. После этого мы переносим эту картинку в фотошоп, где переводим в чёрно-белый. Немного работаем размытием, где нам бы хотелось разбавить резкие переходы. 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, управляемый пальцем игрока.
Пока что проект на раннем этапе разработки, но выглядит это уже вот так:
Как мы избавились от 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 и победит лучшая паста
Увы, до Питера мне добраться не суждено в ближайшем будущем. :(
У меня есть идея для геймдизайна сетевых тактический шутеров. Внедрение гаджетов для сбора информации (камеры , дроны ,коптеры и тд) в телефон . Так удобно пользоваться и всегда видно расположение врага.
В сетевых шутерах внимание должно быть приковано к экрану. Плюс это введет дизбаланм. Все будут тупо раскидывать все эти гаджеты по карте и сидеть, ждать противника, посматривая в телефон.
Siege же
Ну что же вы так поздно публикуете, хотя бы за пару недель эту новость, было бы время для подготовки к поездке (в случае победы), а так не успеть многим туда.
А я бы просто не отказался бы от редактора карт в дарк соулсе)
Детектор теней в 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, управляемый пальцем игрока.
Пока что проект на раннем этапе разработки, но выглядит это уже вот так:
Поздравляем, вы стали одним из победителей конкурса! Пожалуйста, оставьте какой-нибудь метод связи с вами, чтобы мы вам приз передали.