Rust로 6년간 게임을 개발해 출시한 경험

AI 요약

Mason은 2018년부터 Rust로 퍼즐 게임 Way of Rhea를 개발해 출시했습니다. 출시 뒤 진행한 AMA에서 Rust를 선택한 이유와 게임 엔진을 직접 만든 경험, 테스트와 출시 과정에서 얻은 교훈을 소개합니다.

Rust를 선택한 이유와 아쉬운 점

당시 C++ 게임 엔진을 만들던 Mason은 CMake 문제로 잠시 다른 작업을 찾다가 Steve Klabnik의 Rust 책을 처음부터 끝까지 읽었습니다. 언어에 빌드 시스템과 단위 테스트, 문서 생성 기능이 내장돼 있고, 대수적 데이터 타입과 예외에 의존하지 않는 오류 처리를 제공한다는 점에 놀랐다고 합니다. 메모리 안전성도 장점이지만, 싱글 플레이어 게임을 만드는 자신에게는 우선순위가 높은 이유가 아니었다고 덧붙입니다.

반면 엔진 개발에서 필요한 저수준 작업은 Rust로 처리하기 까다로웠습니다. unsafe Rust는 문서가 부족하고 다루기 어렵다고 평가합니다. unsafe 코드를 쓴다는 이유만으로 온라인에서 비난받는 분위기도 불편하다고 합니다. Rust는 기본적으로 스택과 힙 할당을 중심에 두며, 커스텀 할당자를 만들 수는 있어도 언어가 자연스럽게 이끄는 방향과는 다르다고 설명합니다. 컴파일 시간도 불만으로 꼽았고, 리플렉션 지원이 없다는 점을 아쉬워했습니다.

그는 Rust와 Zig를 서로 경쟁하는 진영으로 보지 않습니다. 저수준 언어가 여러 개 있어야 각 언어가 서로의 약점을 점검할 수 있다고 말합니다. 입문자는 언어 선택에 지나치게 매달리기보다 당장 필요한 도구를 살펴보라고 권합니다.

직접 만든 엔진과 도구

Way of Rhea는 여러 라이브러리를 썼지만, 개발을 좌우하는 주요 구성요소는 대부분 직접 만들었습니다. OpenGL 함수 포인터를 얻는 데 gl을 썼고, OpenGL 같은 API에서 RAII를 다루기 편하도록 scopeguard를 활용했습니다. 창 관리와 키보드·마우스 입력 코드는 직접 작성했지만, 막힐 때는 SDL을 참고했습니다. 파일 변경 감지에는 notify를, 글꼴 처리에는 STB 헤더를 사용했고, 오류 보고에는 reqwest를 썼습니다.

게임 스크립트 언어도 직접 만들었습니다. 기존 Rust 스크립팅 언어가 목적에 맞게 성숙하지 않았고, Lua의 동적 타입보다 정적 타입을 선호했습니다. 파서 라이브러리 대신 재귀 하강 파서를 작성했는데, 문법을 단순하게 설계하면 실용적인 문제를 해결하기 쉽다고 설명합니다. 엔진을 직접 만든 덕분에 라이브러리 변화에 따른 작업을 피했지만, 대부분을 직접 구현하면 개발 속도가 빨라진다는 뜻은 아니라고 덧붙입니다.

컨트롤러 지원에는 Steam Input을 도입했습니다. 여러 컨트롤러의 입력과 버튼 아이콘, 입력 레이어, 재설정 화면 등을 제공하는 점은 좋았지만, Steam 상점에 종속되고 구현이 불안정했다고 합니다. 입력 레이어가 플랫폼마다 다르게 동작하고, 재설정 화면이 나타나지 않는 경우가 있었으며, 설정 언어의 문서와 오류 처리도 부족했습니다. 다음 게임에서는 사용하지 않을 계획이라고 밝혔습니다.

엔진 개발보다 중요한 사용자와 콘텐츠

6년 중 엔진 개발이 차지한 시간은 약 20~30%였고, 나머지 대부분은 콘텐츠 제작에 썼습니다. 취미로 시작해 우선순위를 정하는 법을 몰랐던 점도 개발 기간이 길어진 이유라고 합니다. 직접 만든 엔진은 작업 흐름을 세밀하게 통제하고 핫 리로딩을 구현하기 좋지만, 기존 엔진을 쓰는 편이 대체로 수고가 적습니다. Mason은 게임 엔진을 게임 실행기보다 게임 디자이너를 위한 창작 도구로 보고, 설계 판단에서 디자이너를 먼저 고려해야 한다고 말합니다.

그는 장르와 플레이어를 이해하는 일도 강조합니다. 퍼즐 플랫폼 게임인 Way of Rhea는 취미 프로젝트로 시작해 시장 조사를 하지 않았고, 이후 장르 선택이 얼마나 중요한지 배웠습니다. 인디 게임의 성과를 운으로만 여기지 말고, 사람들이 무엇을 왜 즐기는지 조사하라고 조언합니다. 베타 테스트는 개발 7일째부터 시작했으며, 출시 몇 달 전 전체 게임을 대상으로 진행한 비공개 베타도 완성도에 큰 도움이 됐습니다. 다음에는 테스트를 더 일찍 시작할 계획입니다.

테스트 방식은 게임의 구조에 맞춰야 한다고 설명합니다. 퍼즐을 한 번 풀면 다시 할 이유가 적은 콘텐츠 중심 게임은 대규모 공개 테스트가 정식 출시 구매를 줄일 수 있어 소규모 그룹을 차례로 초대했습니다. 그룹 사이에 수정할 시간을 확보했고, 각 테스터와 직접 이야기할 수 있었습니다. 직접 플레이를 관찰하기 어렵다면 플레이 녹화 영상이나 메모가 도움이 된다고 덧붙입니다.

출시와 홍보에서 얻은 교훈

출시 첫날 유료 구매자 리뷰 10개를 확보해 Steam Discovery Queue 노출을 얻는 것이 목표였습니다. 목표를 첫날 넘겼고, 작성 시점에는 게임을 구매한 이용자에게서 긍정 리뷰 30개를 받았다고 전합니다. 행사 참여도 홍보에 활용했지만 비용이 많이 들었습니다. Steam에서 노출되는 오프라인 행사는 효과가 컸고, 온라인 행사는 무료인 경우 유용했지만 Steam 노출이 없다면 성과가 제한적이었다고 합니다. 온라인 행사 주최자에게 비용을 낼 때는 신중해야 하며, 행사 노출로 늘어난 위시리스트가 자연 유입 위시리스트만큼 구매로 이어지지는 않을 수 있다고 설명합니다.

원문: Games by Mason / 번역·요약: Trawling

Lobsters 반응

• @PuercoPop — 가장 흥미로웠던 답변은 “Rust를 쓰면서 가장 답답했던 점은 무엇이었나요?”였습니다. 저도 작성자처럼 컴파일 타임 리플렉션이 있으면 좋겠습니다. RustConf에서 벌어진 일도 그 아쉬움에 한몫했다고 봅니다. 생태계가 중요하게 여기는 가치가 제가 중요하게 여기는 가치와 달라 보이는 점도 비슷합니다. 저 역시 Rust 생태계 전반과 가치관이 맞지 않는다고 느낄 때가 있습니다. 작성자는 Zig 쪽으로 기운 것 같습니다. 가치 측면에서는 Zig가 제 생각과 더 잘 맞아 보입니다. 하지만 Zig 언어를 살펴봤을 때는 @This() 같은 요소가 눈에 띄었습니다. Common Lisp나 Guile의 운영체제 지원이 더 나았으면 좋겠다고 생각할 때도 있습니다.