Game Dev패턴과 구조

게임 루프와 frame 사고

게임이 input, update, render를 frame 단위로 반복한다는 사고와 variable/fixed timestep을 어떻게 읽어야 하는지 정리합니다.

마지막 수정 2026년 3월 22일

기본 패턴

text
while (running)
  poll input
  update simulation
  render frame

설명

  • 게임 루프는 "사용자 입력을 받고, 월드를 갱신하고, 현재 상태를 화면에 그린다"는 반복 구조입니다. 엔진을 쓰더라도 이 구조는 사라지지 않고, 단지 엔진이 루프를 대신 소유할 뿐입니다.
  • 초보자가 자주 놓치는 점은 render가 빠르다고 simulation도 정확해지는 것은 아니라는 점입니다. 프레임이 흔들려도 물리나 판정은 일정하게 유지하고 싶다면 fixed timestep 사고가 필요합니다.
  • variable timestep은 구현이 단순하고 대부분의 일반 로직에 잘 맞지만, frame rate에 따라 결과가 미세하게 달라질 수 있습니다. 반대로 fixed timestep은 안정적이지만 누적 시간 관리가 들어가고, 업데이트가 밀리면 catch-up cost가 생깁니다.
  • 그래서 실무에서는 "입력 수집 -> 고정 간격 simulation update -> 현재 상태 render"처럼 역할을 나누는 경우가 많습니다. physics, deterministic rule, replay, network sync는 이 구분의 영향을 크게 받습니다.
  • 이 카드는 루프 문법을 외우는 카드가 아니라, "지금 내가 만든 코드는 frame마다 실행돼도 되는가, 아니면 일정 간격으로 고정해서 돌려야 하는가"를 판단하는 카드에 가깝습니다.

짧은 예제

text
input는 매 frame 읽는다
physics는 0.02초마다 갱신한다
render는 가능한 한 자주 현재 상태를 그린다

빠른 정리

항목핵심 포인트
input사용자의 현재 의도를 읽는다
update게임 규칙과 상태를 진행시킨다
render현재 상태를 시각적으로 표현한다
variable timestep구현은 쉽지만 frame 의존성이 생기기 쉽다
fixed timestepsimulation 안정성은 좋지만 시간 누적 관리가 필요하다

주의할 점

Update에 모든 것을 넣고 나중에 물리, 네트워크, replay를 붙이려 하면 구조를 다시 뜯게 됩니다. 게임 루프는 단순 반복문이 아니라 시간과 책임을 분리하는 설계의 출발점으로 보는 편이 안전합니다.

참고 링크

2 sources