Перейти к содержанию

ViGaCi

Игроделы
  • Постов

    23
  • Зарегистрирован

  • Посещение

  • Победитель дней

    2

ViGaCi стал победителем дня 30 ноября

ViGaCi имел наиболее популярный контент!

Информация о ViGaCi

Персональная информация

  • Лицензия
    Да

Посетители профиля

Блок последних пользователей отключён и не показывается другим пользователям.

Достижения ViGaCi

Новичок

Новичок (1/12)

35

Репутация

  1. Специально для теста создал новый проект, добавил два тайлмапа (земля, тень), два тайловых бэкграунда для облаков и объект Player с двумя анимациями по 4 кадра в каждой и поведением Platform. Тестирование проводил на низкопроизводительном мобильном устройстве с очень слабым GPU. Для теста производительности самое то. К сожалению, отследить нагрузку на GPU не получится, т.к. выражение выдаёт "NaN", но зато есть показатель FPS. Если FPS падает — значит GPU не успевает отрисовать кадр за 0.016 (1/60) сек. 1. Начало уровня. FPS 41-42. 2. Прохожу чуть дальше, FPS 54-55. 3. Прыгаю на уступ, FPS 62 Почему так происходит!? Для начала, разберёмся с теорией. Основы Базовый принцип оптимизации нагрузки на GPU — это сокращение площади отображаемой на экране (в области просмотра) графики. Есть определённый физический лимит графики (её фактической площади), которую GPU может отрисовать и уложиться в 0.016 сек (что даёт 60 FPS). Разрешение игры Чем выше разрешение экрана — тем больше площадь отрисовки, и тем выше нагрузка на GPU. Следует понимать, что разрешение игры и размер области просмотра это не одно и тоже. Разрешение игры (в полноэкранном режиме) равно разрешению экрана устройства игрока. Размер области просмотра не влияет на производительность. Например, если размер области просмотра 480x240, а разрешение экрана 1440 x 720, то GPU будет отрисовывать кадр в разрешении 1440 x 720. Как происходит отрисовка кадра GPU отрисовывает кадр по пикселям от нижнего слоя к верхнему, пропуская все невидимые слои и объекты. Даже когда ваши графические объекты перекрыты чем-то сверху, GPU по-прежнему потратит ресурсы на отрисовку и перерисовку всех пикселей. Следовательно, наихудшая с точки зрения нагрузки ситуация - это когда в кадре есть стопка больших, перекрывающих друг друга изображений. Важно: Невидимый слой/объект — это тот, у которого параметр visible установлен на "invisible". Даже если объект имеет opacity = 0, он всё равно будет отрисован. Объекты отрисовываются полностью, включая прозрачные пиксели. С точки зрения нагрузки, решающую роль играет площадь изображения. Не исходная, а фактическая. Спрайт 1x1 пикселей, растянутый на весь экран (например, в вашем проекте это 480x240), превращается в текстуру, которая будет имеет разрешение, равное разрешению экрана устройства. Если у вас пиксель арт игра, вы можете установить параметр "Downscaling quality" на "Low" и тем самым значительно снизить нагрузку на GPU, но об этом как-нибудь в отдельном уроке. Посмотрим ещё раз на кадр из игры Игровая сцена состоит из нескольких слоёв: задний фон, движущиеся облака, тайлмап и спрайт героя. На отрисовку всего, что попало в область просмотра GPU потратит ресурсы. И чем больше в кадре объектов, а точнее, чем больше площадь попавших в кадр объектов — тем выше нагрузка на GPU. Специально для теста добавил на экран кнопки, которые отключают облака и тайлмапы. 4. Попробуем зайти в самую загруженную область на карте. Получаем 41-42 FPS. 5. Теперь отключаем облака. Вы не видите на скрине облаков? Я тоже не вижу, но GPU всё равно тратит ресурсы на их отрисовку. Сделав облака невидимыми программно, получаем FPS 47-50. 6. Теперь отключим тайлмап с тенью. Получаем FPS 53-55. 7. А теперь, попробуем вернуть облака. Получаем FPS 46-48. 8. Отключаем тайлмап земли, получаем максимальные FPS 62. Выводы Надеюсь, вы уловили суть — причина падения FPS заключается в физических ограничениях GPU. У мобильных устройств разрешения экранов высокие, а GPU очень слабые. Если вы делаете игру для мобильных устройств, то вы уже на уровне геймдизайна должны думать о том, чтобы не допускать нахождения в кадре слишком большого количества перекрывающих друг друга объектов (повторюсь, что дело не в количестве, а в их суммарной площади).
  2. Смотря какие условия и какие действия. Проверка и установка значений переменных, например, минимально тратит ресурсы. Проверка коллизий объектов, при условии что этих объектов на сцене очень много, тратит больше ресурсов. Но дело всё в том, что падение FPS из-за нагрузки на CPU (то есть, из-за событий) — крайне редкое явление, может происходить из-за тяжёлых циклов, но точно не из-за простых условий вроде "every ..".
  3. @pagurus Вызов принят, начну как всегда издалека. До наступления промышленной революции 90% населения планеты было занято сельским хозяйством. Но еды всё равно на всех не хватало, отсюда и постоянные войны феодалов друг с другом за плодородные территории и работающих на них крестьян. Потом произошла промышленная революция, а вместе с ней массовое производство товаров. Там где раньше требовался многонедельный труд сотен крестьян, теперь нужен один человек и один трактор. Бывшие крестьяне мигрировали в города, чтобы работать на фабриках и заводах. Вследствии индустриализации 20% занятого в сельском хозяйстве населения обеспечивают пищей себя и всех остальных, проблема голода исчезла. Индустриальный период тоже не вечен. Продать человеку первый автомобиль гораздо проще, чем второй. Когда базовый спрос удовлетворён, проблема "произвести автомобиль" заменяется на проблему "продать автомобиль". Так на смену индустриальной эпохе приходит постиндустриальная. Эпоха услуг. Потребитель теперь не хочет покупать такой же продукт, как у всех. Он хочет получить индивидуальный товар, под свои запросы и потребности. Да здравствует кастомизация! Теперь при покупке одного и того же автомобиля потребитель имеет широкие возможности выбора: от мощности двигателя до материала обшивки кресел в салоне. И как всё вышеописанное относится к методологии разработки игр? Да самым прямым образом. В играх всё то же самое. Есть некий базовый спрос, который удовлетворяют крупные разработчики, а есть ниши, где денег меньше и куда крупным разработчикам лезть нет смысла. Потребитель, т.е. игрок, предпочитает выбирать игру, которая больше других удовлетворяет его потребности. Например, есть популярный PvP шутер Counter Strike. Среди игроков этой игры есть определённый процент тех, кто предпочёл бы шутер с большим упором на RPG механики и реализм. Инди разработчик видит неудовлетворённый спрос, видит прибыль, которая его устроит (но не устроит крупную студию, иначе бы ниша была уже занята) и делает игру Escape from Tarkov. Вот и вся логика, которую я пытаюсь донести в этой теме. Благодаря технологиям (тому же Construct'у) можно создавать игры такого качества и с такой скоростью, которая была недоступна лет 10 назад. Я уже молчу, что есть возможность подсмотреть реализацию любых механик в чужих исходниках, чтобы не проходить самому весь путь с нуля, а сразу взять на вооружение лучшие практики. Именно это я и подразумевал под "методологией разработки".
  4. В Construct 3 есть много новых функций, которых не было в Construct 2. Думаю, имеет смысл сделать по каждой из них мини-гайд. Этот урок будет максимально подробным, чтобы даже новички смогли понять суть. Итак, что вообще такое фреймрейт? Большинство современных экранов имеют частоту обновления экрана 60 Гц. То есть, частота обновления изображения на экране имеет физическое ограничение в 60 кадров/секунду. Обработка всего, что происходит в игре происходит в два последовательных этапа. Сначала происходит проверка листа событий/выполнение действий, чем занимается CPU. Далее GPU занимается отрисовкой изображения на экране (всего того, что попало в область просмотра). Поскольку экран не может обновляться чаще, чем 60 раз в секунду, то нет смысла обрабатывать лист событий чаще максимальной частоты обновления экрана (минимальное время между "тиками" составляет 1/60 = 0.016 сек). Обработка листа событий (проверка условий и выполнение действий) напрямую зависит от FPS и происходит от 30 до 60 раз в секунду. Когда FPS падает ниже 30 кадров, игра начинает работать в slow-motion, т.е. как бы "замедляется". Самая частая проблема с производительностью — это слабые GPU, которые не успевают отрисовать изображение за 1/60 секунды. В этом случае FPS начинает падать, а параметр delta time увеличиваться. Что такое delta time? Если спрайт перемещается из точки A в точку B со скоростью 240 пикселей в секунду, то на уровне движка это означает, что спрайт меняет своё местоположение 60 раз в секунду, перемещаясь каждый тик на 4 пикселя (240/60) в заданном направлении. Но как посчитать расстояние, на которое должен переместиться спрайт, чтобы его скорость соответствовала реальному времени, а не зависела от FPS?! На помощь приходит выражение dt (delta time) — время между тиками. Это выражение принимает значение от 0.016 до 0.032 (при стандартном макс. FPS в 60 кадров/сек. и минимальном 30 кадров/сек). Умножая скорость на dt, ваши объекты будут двигаться со скоростью, независимой от FPS (напр., "Every tick > set position > 240*dt"). Во всех стандартных поведениях с движением (Platform, MoveTo, Car, Pathfinding и т.д.) dt "вшит" уже изначально, делать ничего не нужно. Так на что же влияет "minimum framerate"? Так вот, "System > set minimum framerate" устанавливает пороговое значение для delta time. По умолчанию минимальный FPS равен 30 кадрам, т.е. значение delta time может увеличиться с 0.016 (при 60 fps) до 0.032 (при 30 fps). Если вы установите минимум фреймрейт на "60", то при падении FPS ниже 60, ваша игра сразу же будет переходить в slow-motion. Если вы установите, скажем, на "15", то игра начнёт замедляться только когда fps упадёт ниже 15. А для чего вообще нужно это замедление? При высоких значениях delta time, ваши спрайты будут перемещаться на большее расстояние за тик. Может возникнуть ситуация, когда пуля проходит сквозь противника (потому что чисто с технической стороны колизии объектов не было). Замедление игры как раз позволяет избежать таких ситуаций. Так нужно ли менять стандартное значение минимального фреймрейта? Если ваша игра чувствительна к проседанию fps (вы часто сталкиваетесь с проблемой, когда коллизии объектов не регистрируются), то попробуйте установить более высокие значение минимального фреймрейта (выше 30). Если в вашей игре проблем с коллизиями нет и вы хотите избавиться от эффекта замедления игры — то установите более низкие значения минимального фреймрейта (ниже 30).
  5. Разница будет только во времени загрузки Layout'a и размере игры. Я как-то ещё на C2 эксперементировал, спрайт 1x1, растянутый на весь экран даёт такую же нагрузку, как если бы этот спрайт изначально имел размер, соответствующий размеру экрана. Вообще, проблемы с производительностью - это головная боль слабых мобильных устройств. Там разрешение экрана высокое, такое же как на ПК, при этом, железо слабое (энергоэффективность, все дела).
  6. Спасибо! Для того, чтобы у игрока появилось желание прокачивать героя, необходимо чтобы эффект от прокачки ощущался. В начале игры герой вооружен одними только кулаками и умирает от каждого вражеского чиха. Дальше игрок находит меч, потом возможность улучшать этот меч у кузнеца. На каждом уровне игрок находит новую экипировку, новые навыки и новых врагов, что будет подогревать интерес на протяжении всего прохождения. Вообще, на данный момент у игры всего 4 уровня. Но за счёт прокачки игроку на прохождение потребуется не менее одного часа времени.
  7. Дневник разработки #02 Жизнь в деревне кипит! Кузнец работает над улучшением оружия, алхимик смешивает ингредиенты для нового зелья, а местная детвора играет друг с другом в догонялки.
  8. Gothic Adventures. Блог разработки #01 Одна из особенностей графического стиля игры — это сочетание пиксельарта и динамических эффектов, вроде "размытия фона". Путешествуя по локации игрок переходит из пещерных участков в открытые. В зависимости от нахождения игрока, меняется размытие фона. Когда герой находится в пещерной области — фон чёткий, но как только игрок выходит в открытую область — фон становится размытым. Всё статичное воспринимается игроком как скучное. Даже если игрок ничего не делает, картинка в игре должна быть "живой", т.е .динамичной. Один из самых простых и эффективных способов сделать красивую картинку в игре — это добавить частицы. Здесь, например, частицы используются для создания эффектов дыма и искр от огня в окне экипировки. Благодаря этому, интерфейс окна не выглядит статичным.
  9. 1. Если их прям настолько много, можно сделать отдельный лист событий только для функций. 2. Можно давать "говорящие" названия функциям. Например, "HUD HealthBar UPD", "CALC EnemyDamage" и т.д.
  10. Я, конечно, не художник, но на мой взгляд, количество кадров в анимации вообще не играет роли. Вся фишка в... синхронности. Точно так же как разнопиксельность убивает графический стиль, разная скорость анимаций убивает "восприятие плавности". Если персонаж ходит со скоростью 5 кадров/сек., но атакует со скоростью 12 кадров/сек., то такая разница в скорости анимаций будет сильно бросаться в глаза, независимо от того, из скольких кадров состоит каждая анимация. У меня в Gothic Adventures большая часть анимаций состоит из 4-х кадров. И только некоторые состоят из 6 кадров (анимации ходьбы, атаки и смерти). Ощущение плавности создаётся не за счёт дополнительных кадров анимации, а за счёт дополнительных частиц — пыль при ходьбе (а также в прыжке и приземлении), кровь при ударе и т.д.
  11. Я, конечно, не эксперт по платформерам, у меня тоже первая игра в этом жанре и тоже в разработке, и, тем не менее, могу как человек со стороны дать пару рекомендаций: 1. Нужно скорректировать скорость анимации персонажа со скоростью его движения. На данный момент персонаж "скользит" как по льду. Можно попробовать увеличить скорость анимации. 2. Назначение кнопок будет проще понять, если вместо буквы "A" будет изображен, скажем, меч. Вместо буквы "B" — фаерболл, а вместо "X" — стрелка вверх. 3. Слишком большие и пустые пространства, конечно, увеличивают время прохождения уровня, но ходьба — это не геймплей. В какой-то момент игроку просто наскучит ходить по уровню и он закроет игру. Можно разнообразить уровень какими-то объектами, которые можно разбивать — бочки, ящики. Можно добавить мелкие препятствия, через которые игрок должен будет перепрыгнуть.
  12. Gothic Adventures — платформер с элементами RPG (или RPG с элементами платформера, тут поди разбери). Никогда раньше я не делал классические платформеры. Более того, игры этого жанра всегда казались мне слишком линейными и предсказуемыми. И в тоже время, был интерес попробовать свои силы в чём-то новом. Статус: в разработке Актуальный геймплей (на 4 нояб. 2021) (прошу извинить за подлагивания в видео, я нуб в настройках захвата экрана) Суть игры Проходим уровни. После каждого уровня попадаем в деревню, в которой можно прокачивать героя. С каждым пройденным уровнем в деревне появляется новый NPC, открывающий игроку новые возможности для прокачки (кузнец — улучшение экипировки, алхимик — создание зелий, торговец — покупка/продажа предметов и т.д.). Убивая врагов игрок получает опыт, который используется для повышения уровня навыков, и лут, который используется в качестве материалов для создания и улучшения снаряжения. Навыки открывают доступ к новым механикам. Например, навык "Фехтование" — позволит использовать оружие в каждой руке, "Блокирование" — парировать атаки щитом и т.д. В случае смерти героя игрок теряет весь накопленный опыт и начинает прохождение с первого уровня. При этом, весь собранный лут, вся экипировка, изученные навыки сохраняются. Таким образом, после каждой смерти игроку становится всё легче и легче проходить первые уровни и больше шансов выжить на более сложных уровнях.
  13. А почему ты определяешь "жанр" как некую субъектную сущность? Как будто жанры могут существовать сами по себе, в отрыве от тех игр, которые они характеризуют. Всё как раз наоборот. Жанр — это всего лишь условность, способ обозначить общность тех или иных игр по тем или иным признакам. А значит новый жанр нельзя придумать, поскольку невозможно найти общность между тем, чего ещё не существует. Жанры рождаются сами по себе в процессе развития игровой индустрии. Например, была такая игра "Rogue". Её характерными особенностями были генерируемые случайным образом уровни, пошаговость геймплея и необратимость смерти персонажа (в случае смерти игрок терял всё и начинал игру заново). Впоследствии, игры, включающие в себя один или несколько основных принципов Rogue стали классифицировать как "roguelike" или "рогалик". Другие жанры появились как результат описания набора правил нескольких игр. Например, жанр "метроидвания" описывает набор элементов игровых механик игр из серии Metroid и Castlevania. Невозможно дважды изобрести колесо. Обе попытки приведут к одному и тому же результату. Зато колесу можно придумать почти бесконечное количество разных применений. То же самое касается игр. Игры развиваются ни сколько за счёт изобретения новых механик, сколько за счёт эволюции уже имеющихся. Например, пошаговая стратегия × RTS стратегия × история древнего Рима = Rome Total War. То же самое касается жанров: 1. Dune II × фентези = Warcraft 2. Warcraft × MMO × RPG = World of Warcraft 3. Warcraft × карта Defense of the Ancients = MOBA. Жанр MOBA использует элементы механик из RTS, RPG и других жанров. А в результате у него появляются совершенно новые свойства, не присущие по отдельности какому-либо из уже существующих жанров.
  14. @pagurus Прости, но я не понимаю, что ты хочешь сказать... Если твой посыл в том, что геймдизайна не существует, что игры это просто математика, то я с этим не согласен. Мне лично ближе точка зрения, что игры — это про генерацию опыта и принятие решений, а не просто менеджмент ресурсов. Геймдизайн – это не события, не графика или звук. Это не создание игровых спрайтов или расставление объектов на сцене. Геймдизайн – это разработка правил, благодаря которым эти части оживают. Возьмём, к примеру, шахматы. Цель игры — поставить мат противнику. То есть, создать на доске такую ситуацию, при которой у короля противника не осталось бы никаких вариантов хода. Уникальная ценность шахмат заключается в том, как они задают идеальный ритм головоломки и решения, напряжения и облегчения. Сами по себе фигуры или доска не имеют смысла, вся ценность заключается в геймдизайне – системе правил, которая определяет ход игры. Задача геймдизайнера заключается в разработке систем правил, которые позволяют получить такой результат. Да, в каком-то смысле, шахматы — это игра про менеджмент ресурсов, о котором ты упомянул. В шахматах есть выигрышная стратегия — игрок должен стремиться к тому, чтобы занять центр доски, параллельно сокращая количество фигур противника, стараясь сохранить как можно больше собственных фигур. Занимая центр доски сильными фигурами игрок увеличивает количество собственных возможных ходов и, тем самым, сокращает потенциальное количество ходов соперника. Весь этот "менеджмент" можно просчитать математически и не удивительно, что компьютер ещё в 1997 году обыграл чемпиона мира по шахматам. Но! Менеджмент ресурсов в шахматах — это средство, а не самоцель. Если увеличить размер доски или сделать её трёхмерной, игра сохранит "менеджмент ресурсов" и станет намного сложнее, но это не сделает её более интересной. Увеличение поля игры не увеличит тактические возможности игрока, а только уменьшит. Так как ценность каждого хода уменьшится, появится больше рутинных ходов, вырастет вероятность ошибки из-за невнимательности, а значит, игра станет чуть менее зависящей от тактики игрока.
×
×
  • Создать...