2D 플랫 포머 : 물리를 프레임 속도에 의존하게 만드는 이유는 무엇입니까?

"Super Meat Boy"는 최근 PC 용으로 출시 된 까다로운 플랫 포머로서 뛰어난 제어력과 완벽한 픽셀 점프가 필요합니다. 게임의 물리 코드는 60fps로 고정 된 프레임 속도에 따라 다릅니다. 즉, 컴퓨터가 최고 속도로 게임을 실행할 수 없으면 물리가 미쳐서 캐릭터가 느리게 실행되고 땅에 떨어지게됩니다. 또한 vsync가 꺼져 있으면 게임이 매우 빠르게 실행됩니다.

2D 게임 프로그래밍 경험이있는 사람들이 왜 게임이 이런 식으로 코딩되었는지 설명 할 수 있습니까? 일정한 속도로 실행되는 물리 루프가 더 나은 솔루션이 아닐까요? (실제로, 일부 엔티티는 프레임 속도에 관계없이 정상적으로 움직이기 때문에 게임의 일부에 물리 루프가 사용된다고 생각합니다. 반면에 캐릭터는 [fps / 60]으로 빠르게 실행됩니다.)

이 구현에서 나를 괴롭히는 것은 게임 엔진과 그래픽 렌더링 간의 추상화 손실로 모니터, 그래픽 카드 및 CPU와 같은 시스템 별 항목에 따라 다릅니다. 어떤 이유로 든 컴퓨터에서 vsync를 처리 할 수 ​​없거나 정확히 60fps로 게임을 실행할 수없는 경우 크게 중단됩니다. 렌더링 단계가 물리 계산에 영향을 미치는 이유는 무엇입니까? (현재 대부분의 게임은 게임 속도를 늦추거나 프레임을 건너 뜁니다.) 반면에, 나는 NES와 SNES의 구식 플랫 포머가 그들의 제어와 물리학에 대해 고정 프레임 레이트에 의존한다는 것을 이해합니다. 이것이 왜, 그리고 프레임 속도 의존성을 가지지 않고 그 정맥에서 patformer를 만들 수 있습니까? 그래픽 렌더링을 엔진의 나머지 부분과 분리하면 정밀도가 떨어질 수 있습니까?

감사합니다. 질문이 혼란 스러우면 죄송합니다.

왜?

몇 가지 이유를 선택하십시오. 더 잘 몰랐습니다. 더 빠르고 쉽게 구현할 수 있습니다. 그들은 대부분 게임에서 자라지 않을 수있는 최후의 경우에 더 많은 게임 플레이에 집중했다.

왜 그렇지 않은지를 잘 설명해 주셨습니다. 나는 당신이 주제를 다루는 많은 주제가 있음을 알았습니다 . 내가 제시 한 것 이상의 만족스러운 답변을 찾을 수 있을지 모르겠습니다.

SMB는 원래 모든 Xbox360에서 60fps로 실행할 수 있다고 가정하는 것이 안전한 콘솔 게임이었습니다 (일부 PAL 플레이어의 경우 50 개). 고정 된 타임 스텝을 가정하면 코드가 상당히 복잡해집니다.

가변 시간 간격 ( 'pos + = velocity * timestep')으로 많은 것들을 확장하는 것은 쉽지만, 가속도 및 가속도 변화 속도 등을 다룰 때 올바르게 수행하는 것은 상당히 까다로워집니다.

게임 플레이와 렌더링을 분리하는 것은 이론적 으로 훌륭한 솔루션 이지만, 잘 보간하여 잘 구현하는 것은 매우 까다 롭고 쉽게 지저분해질 수 있습니다. 이 기술이 실제 게임에서 사용되는 것은 매우 드문 일입니다 (일부 큰 게임, 특히 RTS 게임이 있지만 네트워크 게임 동기화에는 더 큰 일이 있습니다).

고정 된 화면 해상도와 고정 된 프레임 속도를 설계 할 때 스크롤을보다 매끄럽게하기 위해 할 수있는 또 다른 방법이 있습니다. 프레임 당 소수의 픽셀을 스크롤하여 얻을 수있는 '서브 픽셀 워블 (subpixel wobble)'을 피하면서 게임이 프레임 당 전체 픽셀 수로 스크롤되도록 할 수 있습니다.

확실한 해결책은 2 개의 루프를 병렬로 실행하는 것입니다. 매 1/60 초마다 렌더링하고 게임 루프는 1/60 초마다.

그러나 Flash (AS3, Super Meat Boy가 만들어 졌다고 확신합니다)에 대한 경험으로 인해 스케줄러가 항상 정확하지는 않습니다. 정확도는 또한 환경에 따라 크게 달라집니다. 독립형 플래시 플레이어에서는 1 밀리 초 미만의 해상도를 가질 수 있습니다. 그러나 일부 웹 브라우저에서 실행될 때 정확도는 프레임 속도의 정확도가됩니다.

따라서 렌더링 및 게임 로직 루프를 분리 할 수있는 가장 가까운 방법은 모든 움직임을 시간 기반으로하는 것입니다 (마지막 프레임 이후 경과 한 시간을 기준으로 각 프레임을 실행). 이는 더 복잡한 수학을 도입 할 수 있습니다 (예 : 설정된 간격으로 객체의 속도를 추가하는 대신 중력을 계속 적용 함). 게임이 1 초 동안 지연 될 수 있고 플레이어가 한 번에 200 픽셀을 움직이기 때문에 충돌 감지 및 응답이 더욱 복잡해질 수 있습니다. 프로그래머가 프레임 기반 충돌 감지 (시간 간격마다 충돌 확인)를 수행하는 경우 시간 기반 충돌 감지로도 전환해야합니다. 만약 그들이 자연스럽게 느끼길 원한다면, 위에서 설명한 중력 방법을 사용해야하는데, 이것은 물체의 움직임을 (선이 아닌) 곡선으로 만듭니다.

더 이상 60fps에서 2D PC 게임을 요구하는 것은 그리 중요하지 않습니다. 대부분의 2D 게임조차도 하드웨어가 가속되어 있으므로 개인적으로 fps 요구 사항에 대해 걱정하지 않아도됩니다.

실제 질문은 픽셀 기반을 사용하지 않는 이유입니다. 게임에는 치트와 지름길이 가득합니다.

물리 기반 게임 (새 던지기?)을 만들고 있다면 그 대답은 분명하지만 슈퍼 마리오 클론입니까? 시간 기반 운동은 약간 많을 수 있습니다.

그들이 사용하는 2D 물리에서 이상한 행동을 피하기 위해?

솔직히 나는 추측 할 수있다. 나는 설명을 시도 할 것이다 :

게임의 핵심은 메인 게임 루프입니다. 기본적으로 다음과 같습니다.

while(gameRunning)
{
  updateGame(timestep);
  renderGame(timestep);
}

updateGame은 gameState를 업데이트합니다 : 플레이어 입력을 확인하고 게임 세계에 플레이어 입력을 적용하며 물리 시뮬레이션 등을 실행합니다.

renderGame은 게임을 그리고 애니메이션합니다.

물리 업데이트를 렌더링에 연결합니다. 분리하려면 스레드를 사용해야하고 렌더링 및 gameUpdate 스레드의 각 데이터 액세스를 플레이어 위치와 같은 공유 데이터에 올바르게 동기화해야합니다. 할 수 있습니다.

또 다른 문제는 물리 시뮬레이션에서 안정적인 실행을 위해 일정한 시간 간격이 필요하다는 것입니다. 이것은 supermeatboy가 움직임을 계산하는 방법에 달려 있습니다 (다시 말해 그들이 어떻게했는지 추측 할 수 있습니다).

순진한 접근 방식은 다음과 같습니다 (내 게임에서 사용하고 있습니다 * 한숨 *).

position=position+speed*timestep;
speed=speed+acceleration*timestep;

이것을 오일러 통합이라고하며 일반적으로 나쁜 생각으로 간주됩니다. 시간 단계가 일정하지 않으면 계산 오류가 발생하여 시뮬레이션의 안정성이 떨어집니다. 물체가 과도한 속도로 움직이거나 전부가 아니거나 벽을 통해 화면 밖으로 날아갈 수 있습니다. 시간 단계가 일정하더라도 Euler Integration은 작은 계산 오류를 일으 킵니다. RK4와 같은 다른 통합 방법을 사용하거나 물리 엔진을 사용하는 것이 좋습니다.

그 외에도 시간 간격이 너무 길면 충돌 감지에 문제가있을 수 있습니다. 두 gameUpdates간에 충돌이 확인되지 않기 때문에 오브젝트가 장애물을 통과 할 수 있습니다.