게임을 개발할 때 "기본"게임 루프가 필요한 이유는 무엇입니까?

Question

대부분의 게임 개발에는 메인 게임 루프가 필요하지만, 왜 필요한지는 알 수 없습니다. 이벤트 리스너를 구현하고 모든 사용자 작업에 응답 할 수 없습니까? 그런 다음 이벤트가 발생하면 애니메이션 (등)을 재생할 수 있습니다.

기본 게임 루프의 목적은 무엇입니까?

Answer 1

"이벤트 리스너를 호출하기 때문에 루프가 필요합니다."라는 인수는 물을 보유하지 않습니다. 틀림없이 주류 OS에서 그렇듯이 실제로 루프가 발생하고 이벤트 리스너가 그러한 방식으로 작동하지만 어떤 종류의 루프도없이 작동하는 인터럽트 기반 시스템을 만드는 것은 전적으로 가능합니다.

하지만 여전히 게임을 그렇게 구성하고 싶지는 않습니다.

루프를 가장 매력적인 솔루션으로 만드는 것은 루프가 실시간 프로그래밍에서 '순환 실행'으로 불리는 것입니다. 아이디어는 여러 시스템 활동의 상대적 실행 속도를 서로에 대해 결정적으로 할 수 있다는 것입니다. 루프의 전체 속도는 타이머에 의해 제어 될 수 있으며 타이머는 궁극적으로 인터럽트 일 수 있지만 최신 OS에서는 세마포어 (또는 다른 동기화 메커니즘)를 기다리는 코드로 인터럽트의 증거를 볼 수 있습니다. "메인 루프"의 일부.

왜 결정 론적 동작을 원하십니까? 사용자의 입력과 baddies AI의 처리 속도를 고려하십시오. 모든 것을 순전히 이벤트 기반 시스템에 집어 넣으면 스레드 우선 순위를 일부 제어하지 않는 한 AI가 사용자보다 CPU 시간을 늘리지 않을 것이라는 보장이 없습니다. 타이밍을 일관되게 유지하는 데 어려움이있다.

그러나 모든 것을 루프에 넣으면 AI 타임 라인이 사용자의 시간과 관련하여 고정 된 관계로 진행된다는 것을 보장합니다. 이것은 루프에서 호출하여 AI에게 타임 라인을 제공하여 사용자가 수행 할 작업을 결정하고, 사용자 입력 루틴을 호출하고, 입력 장치를 폴링하여 사용자의 동작 방식을 확인하고, 당신의 연출을 호소하십시오.

이러한 루프를 사용하면 각 패스를 실제로 실시간으로 처리하는 것보다 시간이 많이 걸리지 않는다는 것을주의해야합니다. 루프를 100Hz로 순환 시키려한다면, 모든 루프 처리가 10msec 이내에 완료되는 것이 좋습니다. 그렇지 않으면 시스템이 갑자기 움직입니다. 실시간 프로그래밍에서이를 시간 초과라고합니다. 좋은 시스템은 당신이 얼마나 가까이에 있는지 감시 할 수있게 해줄 것이고, 그런 다음 당신이 적합하다고 생각하는대로 처리 부하를 줄일 수 있습니다.

Answer 2

이벤트 리스너는 표시 여부에 관계없이 일부 호출 루프에 종속됩니다. 누가 청취자에게 전화 할 것입니까?

명시 적 게임 루프를 작성하면 진행 상황을 절대적으로 제어 할 수 있으므로 이벤트 루프에서 일부 툴킷/이벤트 처리 라이브러리가 어떤 작업을 하든지 의존하지 않게됩니다.

Answer 3

현재 운영 체제가 완전히 이벤트 기반이 아니기 때문입니다. 상황이 이벤트로 자주 표시 되더라도 다음 이벤트가 나타날 때까지 기다린 후 루프를 만들어야합니다 (예 : Windows 이벤트 루프). 유닉스 신호는 아마도 OS 레벨에서 가장 가까운 이벤트 일 수 있지만 이러한 상황에서는 충분히 효율적이지 않습니다.

Answer 4

모든 종류의 게임에 전용 게임 루프가 필요하다는 것은 사실이 아닙니다.

액션 게임은 빈번한 개체 업데이트 및 게임 입력 정밀도 때문에 이러한 루프가 필요합니다.

다른 한편으로는 지뢰 찾기 게임을 구현했으며 알림 용 메시지는
입니다.

Answer 5

두 가지 이유 -

에도 이벤트 기반의 시스템은 일반적으로 어떤 종류의 큐에서 이벤트를 읽고 어쨌든 예를 들어 창에서 이벤트 루프를 끝낼 수 있도록 핸들러에게 전달 어떤 종류의 루프를 필요 그리고 그것을 잘 확장 할 수도있었습니다.

애니메이션의 목적을 위해 애니메이션의 모든 프레임에 대해 일종의 처리해야합니다. 확실히 타이머 나 유휴 이벤트와 같은 작업을 수행 할 수는 있지만 어쨌든 어떤 종류의 루프에서 이들을 생성하게 될 것이므로 루프 을 직접 사용하는 것이 더 쉽습니다.

이벤트를 사용하여 모든 시스템을 처리하는 시스템을 보았을 때 각 프레임의 시작 부분에서 전달되는 이벤트를 수신하는 프레임 수신기가 있습니다. 그들은 여전히 ​​내부적으로 작은 게임 루프를 가지고 있지만 윈도우 시스템 이벤트를 처리하고 프레임 이벤트를 생성하는 것 이상의 역할을합니다.

Answer 6

무한정 앉아서 사용자 입력에 응답 할 수있는 프로그램은 어떤 종류의 루프가 필요합니다. 그렇지 않으면 프로그램 끝까지 도달하여 종료됩니다.

Answer 7

메인 루프는 이벤트 리스너를 호출합니다. 이벤트 중심 운영 체제 또는 창 관리자를 보유 할만큼 운이 좋다면 이벤트 루프가 그곳에 상주합니다. 그렇지 않으면 I/O, poll 또는 select을 기반으로하는 시스템 호출 인터페이스와 일반적인 이벤트 기반 응용 프로그램 간의 "임피던스 불일치"를 중개하는 기본 루프를 작성합니다.

P. 함수 프로그래밍으로 질문에 태그를 추가 했으므로 Functional Reactive Programming을 확인해보십시오. 높은 수준의 추상화를 낮은 수준의 이벤트 기반 구현에 연결하는 훌륭한 작업입니다.

Answer 8

게임 루프

 
initialise 
do 
    input 
    update 
    render 
loop 
clean up 

이 게임 그리는 프레임마다 일어날 것이다 (이하 매우 단순화이다). 따라서 60fps에서 실행되는 게임의 경우 매초 60 회 이상 수행됩니다.

이것은 게임이 원활하게 실행되고 게임이 동기화 상태를 유지하며 사이클 당 업데이트/그리기가 자주 발생한다는 것을 의미합니다. 애니메이션은 단순히 눈의 속임수이며 물체는 여러 위치 사이를 이동하지만 충분히 빨리 재생하면이 위치 사이를 오가는 것처럼 보입니다.

사용자 입력에 대해서만 업데이트하는 경우 사용자가 입력을 제공 할 때만 게임이 반응합니다. A.I 게임 객체와 같은 다른 게임 구성 요소는 자체적으로 반응하지 않습니다. 따라서 루프는 게임을 업데이트하는 가장 쉽고 최상의 방법입니다.

Answer 9

게임은 real-time에서 실행해야하므로 한 CPU/코어에서 계속 실행되는 경우 가장 잘 작동합니다. 이벤트 중심 응용 프로그램은 일반적으로 대기열에 이벤트가 없을 때 다른 스레드에 CPU를 양보합니다. CPU가 프로세스로 다시 전환되기까지 상당한 시간이 걸릴 수 있습니다. 게임에서 이것은 짧은 매점과 지저분한 애니메이션을 의미합니다.

Answer 10

실제적으로 다른 사람들이 지적했듯이 루프가 필요합니다.

그러나 아이디어는 이론적으로 건전합니다. 에 루프가 필요하지 않습니다. 에는 이벤트 기반 조작이 필요합니다.

간단한 수준에서 CPU를 개념화하여 여러 타이머를 사용할 수 있습니다.

• 60Hz의 상승 에지에서 하나가 발사되고 블리 팅 코드가 호출됩니다.
• 또 하나는 60kHz에서 똑딱 거리며 게임 세계의 개체에 대한 최신 업데이트를 블리터 버퍼로 렌더링 할 수 있습니다.
• 또 하나는 10kHz에서 똑딱 거리고 사용자로부터 입력을받는 것일 수 있습니다. (꽤 높은 해상도, 롤)
• 또 하나의 게임 '하트 비트'와 60MHz에서 틱; 인공 지능과 물리학은 하트 비트 시간에 작동 할 수 있습니다.

물론이 타이머를 조정할 수 있습니다. 실질적으로

, 무엇과 같이 당신이 (다소 생략) 될 수있다 일이 될 것이다 :

void int_handler1(); 
//... 
int main() 
{ 
    //install interrupt handlers 
    //configure settings 
    while(1); 
} 

Answer 11

게임의 본질은 그들이 일반적 대한 모의있어, 그냥 외부 이벤트를 기반으로 반응하지 않는 것을 있지만, 내부 프로세스에 대해서도 마찬가지입니다. 대신 폴링의 이벤트를 반복하여 이러한 내부 프로세스를 나타낼 수 있지만, 실질적으로 동등한 위치 :

schedule(updateEvent, 33ms) 

function updateEvent: 
    for monster in game: 
     monster.update() 
    render() 

대 : 흥미롭게도

while 1: 
    for monster in game: 
     monster.update() 
    wait(33ms) 
    render() 

, pyglet 대신 전통적인의 이벤트 기반 메소드를 구현 고리. 시간이 오래 걸리더라도 성능 문제 나 시계 해상도, vsync 등으로 인해 예기치 않은 동작이 발생하는 경우가 있습니다. 루프는 더 예측 가능하고 이해하기 쉽습니다 (웹 프로그래밍의 독점적 인 배경이 아니면).