오리지널 Doom을 SQL로 포팅하기

SQLDoom은 1993년 Doom의 게임 로직과 렌더러를 SQL로 옮겨 데이터베이스 안에서 실행함. Python 클라이언트는 입력, 타이밍, 반환된 비트맵 표시만 담당함 게임 로직은 원작과 같은 35Hz로 실행하고, 렌더링은 별도로 처리함. 노트북에서 완전한 320×200 프레임버퍼를 보통 60FPS로 생성하며, 복잡한 장면에서는 35FPS까지 내려감 BSP 트리, 윈도 함수, 픽셀별 집계를 조합해 원작의 공간 탐색과 화면 생성을 구현함. 다만 원작이 피했던 깊이 판정을 추가로 수행하며, 이 작업이 렌더링에서 가장 큰 비용을 차지함 무기 속성부터 애니메이션까지 관계형 데이터로 저장해 실행 중 SQL로 수정할 수 있음. 게임 로직도 엔티티를 하나씩 순회하는 대신 조건부 갱신과 테이블 조인으로 처리함 데이터베이스의 트랜잭션과 접근 제어를 활용해 최대 4인 데스매치를 지원함. 공개 서버에서 첫 번째 에피소드를 플레이하거나 SQL 콘솔로 진행 중인 경기 상태를 조회할 수 있음 DOOMQL에서 실제 Doom으로 전작 DOOMQL(GitHub)은 Doom과 비슷한 ASCII 화면을 30FPS로 렌더링했지만, 레이캐스팅을 사용해 실제로는 Wolfenstein 3D에 더 가까웠음 Doom은 BSP 트리로 깊이 순서를 적은 비용으로 계산해 텍스처, 임의 각도의 벽, 서로 다른 바닥 높이를 구현함 SQLDoom의 목표는 외형뿐 아니라 원작의 플레이 감각까지 재현하는 것임 렌더러는 SQL만 사용하며, 모든 픽셀의 정확한 RGB 값을 담은 테이블이나 비트맵만 출력함 게임 루프도 SQL 기반으로 구현하되, 데이터베이스 내부 사용자 정의 함수는 허용함 다른 언어로 만든 클라이언트는 입력 해석, 게임 틱 구동, 출력 비트맵 표시만 담당함 게임 상태와 렌더링을 분리한 구조 단일 Python 스크립트가 pygame 으로 입력과 화면 표시를 처리하고 초당 35회 게임 틱을 요청함. 게임 로직, 상태, 렌더러는 모두 데이터베이스 내부에 있음 게임 로직과 렌더링 경로를 분리해 로직은 고정 35Hz로 실행하고, 클라이언트는 원하는 시점에 새 프레임을 요청함 렌더러는 게임 상태 테이블을 입력으로 받는 순수 함수로 구성함 틱 사이의 카메라 위치를 보간해 렌더링 주기를 게임 로직 주기와 분리함 원작은 틱마다 정확히 한 프레임을 그려 35FPS로 제한됐음. SQLDoom은 원작 상수를 유지하기 위해 틱당 28.6ms 예산을 지키면서, 부드러운 화면을 위...