Gamium은 게임 테스트 자동화 라이브러리입니다. 그 목적은 Unity, Unreal 등의 엔진으로 개발된 게임을 다시 빌드하지 않고도 런타임에 클라이언트에 연결하여 UI, 입력 등을 제어할 수 있도록 구현하는 것입니다.

사용사례

Gamium은 빈번한 요청으로 UI 버튼이 표시되었는지 조회하고, 표시되었다면 Click하는 로직이 주를 이룹니다. 아래와 같은 로직이 그 예시입니다.

const button = await ui.wait(By.path('Object path'));
await gamium.wait(Until.elementInteractable(button));
await button.click();

Gamium Client는 Gamium Engine에 지속적으로 요청을 보내며, 해당하는 객체 경로(Object path)의 요소가 표시될 때까지 기다립니다. Gamium Engine은 모든 이러한 요청을 처리하면서 실행 중인 게임의 FPS, 메모리 등에 영향을 주지 않아야 합니다.

Serialization

Protocol Buffers (protobuf)Flatbuffers 같은 직렬화 프로토콜이 있었지만, 저희는 Flatbuffers를 사용했습니다. 두 프로토콜 모두 우수한 성능과 다양한 언어 지원을 제공하지만, 우리 프로젝트에 가장 적합한 프로토콜을 선택해야 했습니다. Flatbuffers와 protobuf를 모두 고려해보았으나, 라이브러리 적용 과정에서 차이점을 발견했습니다.

우리가 제공하는 Gamium Engine SDK에서는 라이브러리 적용이 쉬워야 했습니다. 그래야만 Gamium Engine SDK를 사용하는 개발자들이 직렬화 프로토콜을 쉽게 적용할 수 있을 것입니다. 이 관점에서 Flatbuffers를 선택했습니다. C++에서 Flatbuffers는 .h 파일만으로도 적용할 수 있었고, C#에서는 .cs 파일을 프로젝트에 추가하기만 하면 되었습니다. 플랫폼에 맞는 prebuilt된 .dll과 같은 라이브러리를 선택적으로 import해야 하는 번거로움이 없었습니다. 적용이 매우 간편했습니다.

Network

Gamium Engine과 Gamium Client 간의 통신에는 널리 알려진 방법으로 HTTP, WebSocket, TCP 등이 사용될 수 있었습니다. 우리는 TCP를 선택했습니다. HTTP는 일회성 연결이므로 성능에 영향을 줄 수 있다고 판단하여 배제했습니다. WebSocket과 TCP는 연결이 확립되면 성능 차이가 크게 나타나지 않아 보였습니다. 그러나 WebSocket은 C++ 및 C#에서 내장 모듈이 없어서 외부 모듈을 찾아서 적용해야 했습니다. 그에 비해 TCP는 각 언어에서 기본적으로 소켓(Socket)을 지원하므로 추가 외부 모듈을 사용할 필요가 없었습니다. 특히 C++에서는 이러한 점이 큰 장점으로 작용했습니다. C++에서는 하나의 모듈을 추가하면 해당 모듈을 플랫폼별로 다른 방식으로 임포트할 수 있도록 설정해야 하는 번거로움이 있기 때문입니다. 예를 들어, .dll, .lib, .a, .so와 같은 파일중 알맞은 파일을 플랫폼에 맞게 임포트하도록 해줘야 합니다.

마치며

게임모듈은 항상 성능을 고려하며 개발되어야 합니다. 성능과 쉬운 이식성을 가진 게임 테스트 자동화 Gamium은 오픈 소스로 배포되어있습니다. 다양한 게임 엔진과 클라이언트 언어를 지원하며, 많은 프로젝트에서 반복적이고 지루한 작업을 빠르게 해결할 수 있기를 바라기 때문입니다. Gamium이 현재 프로젝트의 생산성을 높일 수 있다고 생각한다면 주저없이 사용해보세요.