2D платформеры: почему физика зависит от частоты кадров? - PullRequest
7 голосов
/ 27 декабря 2010

«Super Meat Boy» - сложный платформер, недавно вышедший для ПК, требующий исключительного контроля и совершенного прыжка в пикселях. Физический код в игре зависит от частоты кадров, которая установлена ​​на 60 кадров в секунду; это означает, что если ваш компьютер не сможет запустить игру на полной скорости, физика сойдет с ума, в результате чего (среди прочего) ваш персонаж будет работать медленнее и падать сквозь землю. Кроме того, если vsync выключен, игра запускается очень быстро.

Могут ли те, кто знаком с программированием в 2D, помочь объяснить, почему игра была написана таким образом? Разве физический цикл, работающий с постоянной скоростью, не будет лучшим решением? (На самом деле, я думаю, что физический цикл используется для частей игры, так как некоторые из сущностей продолжают нормально двигаться независимо от частоты кадров. С другой стороны, ваш персонаж работает точно [fps / 60] так же быстро.)

Что меня беспокоит в этой реализации, так это потеря абстракции между игровым движком и графическим рендерингом, которая зависит от системных особенностей, таких как монитор, видеокарта и процессор. Если по какой-либо причине ваш компьютер не может справиться с vsync или не может запустить игру со скоростью ровно 60 кадров в секунду, он впечатляюще сломается. Почему шаг рендеринга должен каким-либо образом влиять на физические расчеты? (В настоящее время большинство игр либо замедляют игру, либо пропускают кадры.) С другой стороны, я понимаю, что платформеры старой школы на NES и SNES зависели от фиксированной частоты кадров для большей части их управления и физики. Почему это так, и можно ли создать патформер в этом ключе, не имея зависимости частоты кадров? Обязательно ли потеря точности, если вы отделяете рендеринг графики от остальной части движка?

Спасибо, и извините, если вопрос был запутанным.

Ответы [ 3 ]

7 голосов
/ 27 декабря 2010

Нет причин, по которым физика должна зависеть от частоты кадров, и это явно плохой дизайн.

Я однажды пытался понять, почему люди так делают. Я сделал обзор кода для игры, написанной другой командой в компании, и я не видел ее с самого начала, но они использовали много жестко закодированного значения 17 в своем коде. Когда я запустил игру в режиме отладки с показанным FPS, я увидел, что FPS было ровно 17! Я снова просматриваю код, и теперь все ясно: программисты предполагали, что в игре всегда будет постоянная частота кадров 17 FPS. Если FPS был больше 17, они делали сон, чтобы FPS был ровно 17. Конечно, они ничего не делали, если FPS был меньше 17, игра просто сходила с ума (например, когда играли на 2 FPS и ехали на машине в В игре игровая система предупредила меня: «Слишком быстро! Слишком быстро!»).

Итак, я пишу электронное письмо с вопросом, почему они жестко закодировали это значение и используют его в своем физическом движке, и они ответили, что таким образом они упрощают этот движок. И я снова ответил, хорошо, но если мы запустим игру на устройстве, которое не способно к 17 FPS, ваш игровой движок работает очень забавно, но не так, как ожидалось. И они сказали, что исправят проблему до следующего обзора кода.

Через 3 или 4 недели я получаю новую версию исходного кода, поэтому мне было очень любопытно узнать, что они сделали с константой FPS, поэтому первое, что я делаю, это поиск по коду после 17, и есть только пара совпадений , но один из них не был тем, что я хотел увидеть:

final static int FPS = 17;

Таким образом, они удалили все жестко закодированное значение 17 из всего кода и вместо этого использовали константу FPS. И их мотивация: теперь, если мне нужно поставить игру на устройство, которое может делать только 10 FPS, все, что мне нужно сделать, это установить постоянную FPS на 10, и игра будет работать плавно.

В заключение, извините за написание такого длинного сообщения, но я хотел подчеркнуть, что единственная причина, по которой кто-либо может сделать такую ​​вещь, - плохой дизайн.

2 голосов
/ 28 декабря 2010

Вот хорошее объяснение того, почему ваш временной шаг должен оставаться постоянным: http://gafferongames.com/game-physics/fix-your-timestep/

Кроме того, в зависимости от физического механизма, система может работать нестабильно при изменении временного шага.Это связано с тем, что некоторые данные, которые кэшируются между кадрами, зависят от временного шага.Например, начальное предположение для итеративного решателя (то есть, как решаются ограничения) может быть далеко от ответа.Я знаю, что это верно для Havok (физический движок, используемый во многих коммерческих играх), но я не уверен, какой движок использует SMB.

Несколько месяцев назад в журнале Game Developer была также статья, иллюстрирующаякак был достигнут скачок с одинаковой начальной скоростью, но разными временными шагами, с разными максимальными высотами при разных частотах кадров.Был вспомогательный анекдот из игры (Тони Хок?), Где можно было совершить определенный скачок при запуске на NTSC-версии игры, но не на версии PAL (поскольку частоты кадров разные).Извините, я не могу найти проблему в данный момент, но я могу попытаться найти ее позже, если хотите.

0 голосов
/ 27 декабря 2010

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

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

Я думаю, что это не нужно, и я видел это раньше (некоторые ранние игры 3d-hw использовали то же самое, где игра шла быстрее, если вы смотрели на небо, и медленнее, если вы смотрели на землю).

Это просто отстой. Сообщите разработчикам об этом и надейтесь, что они исправят это, если смогут.

...