BookReview [Game Engine Black Book DOOM]

• 읽은 기록

게임 엔진 블랙 북 둠

위대한 게임 둠의 역사와 개발 과정을 담은 책

이 책은 북클럽 8회차 책이다. 총 5회 스프린트로 진행했으며 약 2달간 진행했다.

둠이라는 게임이 세상에 태어나는 과정과 배경에 대해서 다루는 책으로 게임엔진에 대해서 다룬다기 보다 둠이라는 혁신이 어떻게 등장했는지를 다룬다. 물론 개발적 혁신도 포함되고 코드도 어느정도 나오지만 게임엔진에 대한 내용은 아니다.

상용 PC이전에 게임을 개인이 실행하고 멀티가 가능한 게임을 구축하고 이후 홍보와 콘솔로 이식 그리고 개발과정에 대해서 다루기에 개발적인 책이 아니었기에 편하게 읽을 수 있었다.

Chapter 00: 프롤로그

둠은 1993년 등장하여 역사상 가장 중요한 비디오 게임으로 자리잡았다. 소포모어 징크스를 깨뜨리고, 그 시대 열악한 환경에 최첨단 기술을 도입하고, 지금까지 사랑받는 게임이 탄생했다. 현대에는 많은 게임 개발자의 도전정신?으로 다양한 컴퓨터와 게임기에 이식을 진행하고 있다.

과연 현대의 유니티, 언리얼, 강력한 랜더링 등 우월한 개발환경이 존재하는데 왜 추상화 수준이 낮은 기술을 이해할 필요가 있을까? 만약 우리에게 무한한 시간과 자원이 주어진다면 언젠가 모든 문제가 해결될테니 창의력을 굳이 발휘할 필요가 없다.

창의력은 제약이 존재하는 환경에서 싹을 틔우기 마련이다. 사무용 컴퓨터를 목표로 만든 IBM PC에서 재미있으면서 강력한 3차원 게임을 돌리겠다는 목표를 달성하기 위한 제약과 창의력이 맞물려 탄생한 결과물은 둠이었다.

둠은 그렇다면 당시 기술만 뛰어난 게임이었는가? 아니다. 최근 기술로 개발된 AAA급 게임도 한달도 안되서 서비스 종료를 하는 경우가 허다하다. 그만큼 대중의 평가는 정확하다. 기술에 매몰되지 않으면서도 원하는 게임을 구현하기 위한 기술을 중요하게 생각하는 자세. 이것이 이 책에서 얻어야할 가장 큰 교휸이다.

제작자의 말 (존 카맥, 데이브 테일러)

존 카맥은 20년간 쌓은 통찰과 기술을 가지고 다시 그때로 돌아가더라도 큰 변경사항은 없었을 것이라 말한다. 아마 당시 기술력으로 할 수 있는 모든 것을 쏟아 부은 결과가 둠이었을 것이다. 제작 당시부터 모딩을 염두하고 개발을 진행했다고 한다.

데이브 테일러는 127개의 게임을 제작했다고 하는데 그정도 제작하면 제작 못할 게임이 없지 않을까? 나는 너무 적은 게임을 제작해본게 아닌가? 라는 생각이 든다..

여기서 말하는 오락식 게임의 잔재인 점수와 생명 그리고 더 진보된 게임의 특징들은 둠을 포함하여 지금의 게임들에도 영향을 많이 준 것 같다. 브루스 네일러의 이진 공간 분할법 BSP을 적용해 3D 랜더링 속도를 크게 향상했고, 추상 레벨 디자인 방식은 20년을 앞당겼다.

제작자들이 말하는 게임의 살아있음은 소스코드를 공개함으로서 자신들이 없어도 게임이 계속 살아있을 수 있다고 말한다.

프롤로그

과연 구식 기술에 누가 관심을 가질까?

사실 따지고 보면 우리는 구식 기술위에 서 있다. 최신 기술을 도입할 때 팀에 어떻게 전달하는게 좋을까? 에 대한 주제로 개발자 분과 대화한 적이 있는데 그분이 일한 주식과 관련된 매우 빠른 서버와 최적화가 필요한 환경에서 C로 개발할 때는 결국 구식 기술로 돌아가야 함을 말해주었다. 반복문을 5번 반복하고 내부에서 ++을 다섯번 넣어서 최적화하는 등..

최신 기술또한 이러한 기술로 발전된 것일 테니 책을 읽고 힌트를 얻을 수 있지 않을까? 또한 엔진 자체를 개발하는 내용이 아닌 그 시절 둠이 어떻게 개발되었는가 를 알아보는 책이기에 가볍게 읽어보는 것을 추천한다.

Chapter 01: 들어가며

무어의 법칙 때문에, 아주 영리한 그래픽 프로그래머가 개발한 모든 것이 몇 년 후에는 단지 고만고만하게 유능한 프로그래머에 의해 복제될 수 있었습니다. - 존 카맥

혹자는 최근 AI의 빠른 발전으로 프로그래머가 없어질 것이라고 말하지만 반대로 줄어들지 않고 시스템이 더 복잡해질 것이라고 예측한다. 즉, 더 적은 인원으로 팀이 만들어지고 빠르게 만들고 더 복잡한 시스템을 손 쉽게 만드는 모습이 될 것이다.

그 시절 컴퓨터의 개발 속도는 특이점이라고 생각된다. 지금과 다르게 빠르게 변하고 가격또한 높았으며 MS, 애플, 인텔 모두 1980년대 빠른 속도로 발전중이었다.

Chapter 02: IMB PC

2장에서 다루는 올펜슈타인과 둠에서 사용 가능한 하드웨어를 비교하지만 실상 크게 달라지지 않았다. IMB PC위에서 돌아가지만 IMB는 사무용 컴퓨터이기 때문에 적합한 도구가 아니었다.

책에서 종종 등장하는 과거 PC의 GUI에 끌리는 이유는 뭘까?

적은 공간을 최대로 활용하기 위한 기법이나 다른 CPU와 비교하며 그 당시 어떻게 최적화를 이뤄냈으며 문제점은 뭔지 설명해준다. 다만 용어에 대한 설명이 그렇게 친절하지 않아서 전부 이해하기 어렵다.

사운드 시스템은 부분은 실제 현재 PC에서 초콜릿? 둠 프로그램으로 실행해도 사운드가 많이 깨진다. 부족한 사운드 하드웨어에 맞게 제작된 사운드라 현대에서 음질이 깨지는 게 아닐까?

Chapter 03: 넥스트

• 애플의 역사에 대해서 잘 몰랐는데, 애플도 실패하던 시기가 있었다니.. 신기하다..
• 넥스트 컴퓨터가 1989년에 출시되었지만 지금 봐도 디자인은 세련된 것 같다. 진심으로
• 플레이 스테이션과 닮은 넥스트 스테이션.. 영향이 있었을까?
• 역시 스티브 잡스.. 프레젠테이션에서 흑백으로 영화를 재생하다 컬러로 전환하는 연출이라니 낭만적이다.
• 넥스트의 버전이 업데이트 되면서 메인보드 역시 조금씩 탄탄해져가는 모습이다.
• 지금은 대부분 SSD를 사용하지만 과거에 Cd-rom에서 플로피 디스크 그리고 HDD까지 발전 과정이 흥미롭다.
• 스티브잡스의 취미기업 픽사
• 넥스트 디멘션의 860 cpu는 현대의 GPU의 비슷한 역할을 수행한 것 같다. 왜 gpu가 생겨나고 연산이 분리되었을까?
• 책에서 보여주는 넥스트스텝의 GUI는 더 단순하고 단단해보이는 느낌이다. 필요이상의 기능을 제공하는 것과 목적에 맞게 단순함을 보여주는 것의 차이일까?
• 객체지향의 개념의 격동기인 당시에 잡스도 장점을 말하고 많이 발전했다고 생각한다. 그 기준으로 현대에는 표준으로 사용되고 있는데, 앞으로 10년, 20년안에 새로운 패러다임을 가진 언어가 주류가 되는 날이 올까?
• 3장이 재밌는 이유는 실제 컴퓨터 발전과정과 게임이 맞닿아 있고 현대의 컴퓨터 개발에 위인으로 평가받는 사람들의 이야기가 나와서 그런 것 같다.
• 넥스트 PC에서 현재 맥스러움?을 많이 느낄 수 있다.

용어 정리

• CPU: Central Processing Unit, 중앙 처리 장치
• FPU: Floating Point Unit, 부동 소수점 연산 장치
• DSP: Digital Signal Processor, 디지털 신호 처리 장치
• VRAM: Video RAM, 비디오 랜덤 액세스 메모리
• MIPS: Million Instructions Per Second, 초당 백만 명령어 처리량
• 메모리 관리 유닛
• HDD: Hard Disk Drive, 하드 디스크 드라이브
• BSD: Berkeley Software Distribution, 버클리 소프트웨어 배포

Chapter 04: 팀과 도구

• 둠 개발에 참여한 프로그래머는 총 3명이고 그들의 나이 평균은 23세이다.
• 그들의 이야기를 듣고 있으면 90년대 B급 영화가 생각난다.
• gibs -> 식용 내장
• 실제 3D 모델의 움직임을 위해 점토로 모델을 만들고 스캔하여 디지털화하는 과정이 게임을 제작하는 과정이라는게 설레는 느낌이다.
• 지도는 탑뷰로 마치 캐드프로그램같다.
• 지도
  • VERTEX: 정점, 위치 벡터
  • LINEDEF: 선정의, 선분, 방향 벡터
  • SIDEDEF: 면정의, 면, 법선 벡터
  • SECTOR: 섹터, 평면, 높이 벡터
  • THING: 물체, 물체의 위치와 방향
• 둠은 점프가 없다. 점프가 불필요하기도 하고 예외와 조작감의 문제일지도 모른다. 이를 위해 맵 자체를 점프가 없어도 될 수 있도록 구현하는 목적에 맞는 설계를 한 것으로 보인다. 비슷하게 최근 재밌게 플레이한 몬헌 와일즈도 점프가 없기에 기본적인 맵에서 점프를 하지 않아도 되도록 설계되어 있다.
• DoomEd가 오브젝트-C에 영향을 주었다는 말과 nullptr 역참조를 처리했다는 이야기 그 결과가 결함 포용 환경
• 일종의 게임 엔진(GUI를 배치)하는 인터페이스 빌더에 얼굴을 넣어놓고 사용하다니..
• 그들이 어떻게 게임시장 초창기에 홍보하고 대규모 시장의 발판을 형성했는지 알 수 있다.

Chapter 05: 소프트웨어 idTech 1

• 프로젝트를 이식하기 위한 플랫폼 결정에 지금까지 개발중인 리눅스를 선택한 것 자체가 현명하다.
• 아키텍처부분에서 말하는 개발과 빌드의 분리는 현대에도 많이 사용하는데, 나는 데스크탑으로 개발하고 노트북으로 자동 빌드를 돌린다. 명령어를 만들거나 CI/CD자체를 사용하는 전략도 좋을 것 같다.
• 엔디언의 문제는 살짝 컴구시간에 배웠던 것 같은..
• API를 해결하기 위해 자체적인 운영체제와 비슷한 설계를 했다는 점과 미해결 심벌을 해결하는 과정이 인상적이다.
• 네임스페이스가 없기에 접두사를 함수 이름에 사용했다는 점 다른 분들은 자주 사용하는 접두사나 접미어가 있는지?
• 메인 함수를 기점으로 엔트리 포인트로 모든 코드를 탐색하는 방식에서 객체지향 코드가 아니기에 엔트리 포인트에서 시작하는 코드라는 구조
• 둠의 main코드는 현대의 게임 코드와 크게 다르지 않을 것 같다. 초기화하고 루프를 돌리는 코드 아마 앞으로도..
• 둠이 유저가 게임 모드를 제작할 수 있도록 오픈한 최초인가? total conversion TC
• 프레임버퍼 5개 4개는 비디오 1개는 sufff에 사용
• 화면지우기와 같은 기능을 실제 랜더 버퍼를 조합하여 사용한다면 현대에는 쉐이더를 사용할 것이다 비용이 어느정도 일까?
  • 무작위 숫자 수열을 사용하여 물결 효과를 내는 부분과 요즘 개발의 노이즈 활용 방법과 유사하다.
• Doom BSP관련 도움이 된 영상
  • https://www.youtube.com/watch?v=hYMZsMMlubg&t=480s
• 원근법, 선형보간 등 유용한 내용
• paint algorithm -> warnock algorithm -> BSP
  • 워녹은 4분할 알고리즘으로 쿼드트리 알고리즘과 비슷하지만 목적이 다름
• visplane_t 시계면은 프레임 버퍼를 지워서 흰색으로 처리하는 대신 마지막 프레임 내용을 활용
• 조명효과를 제한된 환경내에서 구현하기 위한 방법으로 라이트맵
• 클리핑 drawseg_t, 주인공을 기준으로 거리로 정렬되며 뒤에서 부터 앞으로 그려진다. (배경과는 반대로) 일종의 스프라이트를 뿌리는 것으로, 움직이는 적군을 그리기 때문에 위치가 변경되기에 이중 연결 리스트로 구현
• 주인공은 맨위 레이어에 그려짐
• 오디오 관련 이슈는 이해하기 어려웠음 구동 방식 자체를 잘 모르다 보니..
• C로 객체지향을 위조하는 방법 -> 함수 포인터
• 최적화 기능은 직관적이면서도 효율적이다.
• 게임 틱 아키텍처를 보면서 생각이 드는 것은 선형적인 update를 가지기에 함수 호출 순서에 대한 신경이 많이 들어가는 것 같다.

• 서버 없이 독자적으로 틱을 돌린다. -> P2P방식의 시도와 혁신

Chapter 06: 게임 콘솔 이식

• 1994년부터 1997년까지 둠은 제각기 다른 여섯 개의 시스템으로 이식되었다.
• 하드웨어의 발전이 빨랐던 시기의 둠은 아키텍처 시스템에 밀접한 하위 시스템이 있는 코어에 기반했기에 유리했다.
• 게임프로그래밍에서 단일 프로세서에서 다중 프로세서로 넘어가는 그 시점이 재규어 프로그래밍
• 실제로 PC에서 콘솔로 이식하기 위해서 그 시절에는 몬스터의 스프라이트를 자르거나 해상도를 줄였다.
• 닌텐도의 이식은 처음부터 맨땅에 헤딩하며 시작했다. 최적화를 위해 이미 최적화된 게임을 또..
• “소니는 하드웨어를 만드는 방법을 모른다.”
• 플레이스테이션 둠은 5명으로 구성된 팀이 1년도 안걸리고 이식에 성공했다. pc버전을 능가하는 몇몇 측면에서 최고의 콘솔 이식 제품으로 여겨진다.
• GoldStar(금성사) 한국관련 콘솔이 등장한다. 삼성은 제작하지 않음 3DO
• 꼭 콘솔의 이식이 성공하는 것은 아니며 같은 버전도 아니다. 3DO의 경우 실패이다.
  • 다만 과거의 콘솔은 재개발에 가까웠다고 생각된다. 현대에는 이식성을 처음부터 고려한 개발이나 크로스플랫폼이 많아 이런 문제가 안생긴다.
  • 최근 Godot엔진의 모바일 버전을 실행해보고 놀랐던 경험이 있다.

Chapter 07: 에필로그

둠은 그 시절 엄청난 성공을 거두었고 이는 게임 산업에 매우 큰 영향을 주었다. 1995년에는 추정이지만 윈도우 운영체제보다 더 많이 설치되었다고 추정한다. 물론 지금까지도 많은 사랑을 받으며 여러 시리즈를 만들어내고 있으며 개발자들 사이에선 아주 경량화된 게임으로 디바이스만 존재한다면 둠을 넣을려는 시도가 있다.

사랑하는 일에 임하고, 가능한 한 최선의 노력을 다한다면, 결국에는 좋은 일이 생길 겁니다. 쉽거나 빠르지 않다고 해도, 끝까지 버틴다면 좋은 일은 반드시 다가오는 법이니까요.