GN⁺: 1987년처럼 처음부터 비디오 게임을 만드는 방법
(gaultier.github.io)비디오 게임을 1987년처럼 처음부터 작성하기
우리가 만드는 것
- X 프로토콜의 11번째 버전은 1987년에 탄생했음.
- X11은 GPU가 등장하기 전의 모델이므로 오늘날의 하드웨어와 잘 맞지 않음.
- 모든 Unix 시스템에는 X 서버가 있으며, macOS와 Windows에서도 GUI Linux 애플리케이션을 실행할 수 있음.
- X11 프로토콜은 비교적 간단하며, 소켓을 생성하는 것만으로 시작할 수 있음.
- 2D 애플리케이션의 경우, GPU와 상호작용할 필요 없이 작동할 수 있음.
인증
- 이전 기사에서는 인증 없이 X 서버에 연결했음.
- 이제 X 인증 프로토콜을 지원함.
- 이는 XWayland를 사용하는 일부 데스크탑 환경에서 인증이 필요하기 때문임.
- MIT-MAGIC-COOKIE-1 메커니즘을 사용하여 인증을 처리함.
창 열기
- UNIX 도메인 소켓을 열어 X 서버와 통신함.
- X11 핸드셰이크를 통해 서버와 연결을 설정함.
- 그래픽 컨텍스트를 생성하고 창을 만듦.
- 창을 표시하기 위해
map_window호출을 사용함.
자산 로드
- 게임에 필요한 이미지를 로드하고, X11 이미지 형식에 맞게 변환함.
- Pixmap을 생성하고, 이미지를 업로드한 후, 필요한 부분을 창에 복사함.
GN⁺의 의견
- X11의 간단함: X11 프로토콜은 상대적으로 간단하여 직접 소켓을 통해 통신할 수 있음. 이는 초급 엔지니어에게 네트워크 프로그래밍과 GUI의 기본 개념을 이해하는 데 도움이 됨.
- 최적화 가능성: Pixmap과 같은 오프스크린 버퍼를 사용하여 이미지를 한 번만 업로드하고, 이후에는 빠르게 복사할 수 있음. 이는 성능 최적화의 좋은 예시임.
- 오딘 언어의 장점: 오딘 언어는 메모리 관리와 같은 복잡한 작업을 간단하게 처리할 수 있는 기능을 제공함. 이는 효율적인 프로그래밍을 가능하게 함.
- 레거시 시스템 지원: 이 방법은 오래된 시스템에서도 작동할 수 있음. 이는 다양한 환경에서 소프트웨어를 실행해야 하는 경우 유용함.
- 학습 자원: X11과 같은 저수준 프로토콜을 직접 다루는 것은 GUI의 내부 동작을 이해하는 데 큰 도움이 됨. 이는 엔지니어의 기술 향상에 기여할 수 있음.
Hacker News 의견
-
첫 번째 댓글: 1987년의 PC는 1~2MB의 RAM을 가졌고, Super NES는 128KB RAM을 가짐. Microsoft의 프로그램보다 훨씬 작은 크기의 실행 파일을 만들었음. 링크
-
두 번째 댓글: X11은 오래되었지만, 게임 개발에 필요한 기본 기능만 구현하면 나머지는 신경 쓸 필요가 없음. Xlib를 사용하면 더 쉽게 작업할 수 있음.
-
세 번째 댓글: DOS PC용 지뢰찾기 클론을 Turbo Pascal로 개발했음. 큰 레벨에서 재귀 알고리즘 문제를 겪었고, 시작 위치를 안전하게 선택할 수 있는 기능을 추가했음.
-
네 번째 댓글: 1987년에 게임을 개발하는 것은 오늘날보다 훨씬 힘들었음. DOS는 멀티태스킹을 지원하지 않아 작업 흐름이 매우 비효율적이었음. 링크
-
다섯 번째 댓글: Godot 엔진의 wasm 파일 크기가 최소 50MB라서 실망했음. 특히 간단한 2D 게임에서는 최적화가 필요함. 전체적으로는 인상적이었음.
-
여섯 번째 댓글: Odin 언어에 흥미가 생겼음. Odin은 Zig와 비슷하게 메모리 할당기를 함수에 전달하지만, 더 간편하게 처리할 수 있는 메커니즘을 가지고 있음.
-
일곱 번째 댓글: Windows 3.1의 지뢰찾기에는 치트 코드가 있었음. 특정 키 조합을 입력하면 안전한 칸과 폭탄이 있는 칸을 구분할 수 있었음.
-
여덟 번째 댓글: SDL 같은 라이브러리를 사용하면 오버헤드가 거의 없고, 다양한 운영체제를 지원할 수 있음. 레거시 SDL 1.x를 사용하면 오래된 Linux 버전도 지원 가능함.
-
아홉 번째 댓글: Simon Tatham의 Mines Windows 실행 파일 크기는 약 180KiB임. 링크