CedarDB, 1993년 원본 Doom의 게임 로직과 렌더러를 SQL로 이식해 35 FPS로 구동
- CedarDB가 1993년 원본 Doom의 게임 로직과 렌더러를 SQL로 이식해 데이터베이스 안에서 실행함. 게임 루프는 원본과 같은 35 FPS로 돌고 렌더러는 320x200 프레임 버퍼를 최대 60 Hz로 만들며, Python은 타이밍과 키보드 입력, 비트맵 표시만 맡음
- 게임 로직은 SQL 약 5900줄로 같은 일을 하는 원본 C 소스 약 9000줄보다 짧음. 쿼리 플래너를 상태 머신처럼 쓰는 방식임
- 렌더링과 게임 루프는 순수 SQL로 짜야 하고 DB 내부 UDF는 허용, 클라이언트는 입력 파싱과 틱 구동, 출력 비트맵 표시만 담당한다는 규칙을 세움. 렌더러는 게임 상태 테이블의 순수 함수라 클라이언트가 원하는 만큼 자주 프레임을 요청함
- Doom의 WAD 파일 형식이 이미 관계형에 가까워 VERTEXES가 LINEDEF로, LINEDEF가 SIDEDEF와 SECTOR로 이어지는 구조를 그대로 옮겼고 변환 코드는 Python 약 1000줄, Doom 1 전체 임포트는 노트북에서 약 18초 걸림
- 작년 DOOMQL은 레이캐스팅 기반 ASCII 아트를 30 FPS로 그려 Wolfenstein 3D에 가깝다는 지적을 받았음. 이번에는 Doom의 BSP 트리를 써서 텍스처와 임의 벽 각도, 다양한 바닥 높이를 지원하고 EU/US 데스매치 서버 4석에서 셰어웨어 1에피소드를 지금 플레이할 수 있음
Hacker News opinions
말도 안 되게 잘 만들었는데 진짜 돌아감. 오른쪽 아래 비주얼이 설명을 다 해줌.
게임 로직이 SQL 5900줄이라니. 원본 C가 9000줄인데 SQL이 더 짧다는 게 제일 웃김.
이거 여러 번 올라왔는데 매번 프론트페이지 못 갔음. 그래서 댓글 달린 가장 이른 글 복사본으로 다시 올림.
vanilla C보다 줄 수가 적은데 쿼리 플래너를 상태 머신으로 악용한다? 엔지니어링 과실의 정점임. 좋아.
맞아 이거 환상적임. 나 지금 해보는 중인데 예상보다 훨씬 잘 돌아감. 언젠가 LLM 추론도 SQL 쿼리 하나로 지구 나이보다 짧게 끝나는 날이 오겠지. cedardb 블로그는 슬래시도트 맞은 것 같은데 게임 자체는 잘 돌아감.
나는 워드프레스 동적 콘텐츠 로딩도 당밀처럼 느린데.
EU랑 US 멀티플레이 서버까지 세팅한 건 좋은 디테일임.
SQL DB 시장에서 눈에 띄기 힘든데 좋은 광고임. 확실히 눈썹 올라가게 만들었음.
게임 상태가 SQL 테이블이라는 대목에서 2010년에 카지노 만들면서 최적화 1년 한 게 떠오름. 원격 호출마다 SQL 테이블 상태를 소스 오브 트루스로 업데이트했는데 데드락이 끔찍했고 스케일링은 악몽이었음. 그래도 전부 원자적이라 상태를 잃을 일이 없었음.
턴제 멀티플레이 게임이면 나쁘지 않은 패턴임. 근데 액션 게임에서 그 읽기/쓰기 루프를 돌린다고? 순전히 어리석은 짓인데 웃김.