Ares Interactive는 고객 업데이트를 기다리지 않고 어떻게 실시간 운영을 진행하는가?

라이브 게임을 운영한다는 것은 끊임없는 변화에 대비하여 시스템을 구축하는 것을 의미합니다. 팀은 성능과 안정성을 유지하면서도 새로운 이벤트, 밸런스 업데이트, 혜택 및 콘텐츠를 통해 플레이어의 참여를 지속적으로 유도해야 합니다.

Ares Interactive는 매우 다른 두 가지 라이브 게임을 운영합니다. Baseball Hits 26은 7th Inning 팀에서 개발했으며, 그만큼 워킹 데드: 여파 Swift Games 스튜디오에서 개발했습니다. Baseball Hits 26은 실제 야구 일정과 밀접하게 연관되어 있습니다. 워킹 데드: 여파 핵심 루프를 방해하지 않고 확장할 수 있는 로그라이트 기반 위에 라이브 서비스를 구축합니다.

저희는 7th Inning의 스튜디오 책임자인 Andre Taube와 Swift Games Germany의 전무이사인 Carsten Granig와 인터뷰를 진행했습니다. 그들은 라이브 서비스 시스템을 구축하고, 원격 콘텐츠 및 구성을 관리하고, 반복 주기를 단축하고, 두 게임 모두 계속 발전함에 따라 모바일 버전을 안정적으로 유지하는 방법에 대해 설명해 주었습니다.

클라이언트 릴리스가 아닌 데이터를 중심으로 실시간 운영을 구축합니다.

Baseball Hits 26은 야구 팬과 게이머들에게 언제 어디서든, 짧은 시간 동안 즐기거나 장기적인 전략 플레이를 통해 본질적인 야구 경험을 선사하기 위해 제작되었습니다. 접근성은 실제 야구 경기 운영, 경기 진행 상황, 라이브 이벤트, 소셜 클럽 및 커뮤니케이션 기능과 함께 제공됩니다. 이러한 시스템을 최신 상태로 유지한다는 것은 게임을 단순히 출시된 상품이 아니라 끊임없이 변화하는 것으로 취급하는 것을 의미합니다.

예를 들어, MLBPA 라이선스를 보유한 선수가 특정 경기나 시리즈에서 특히 뛰어난 활약을 펼칠 경우, 해당 팀은 다음 주 내에 열리는 라이브 이벤트에서 그 선수를 적극적으로 활용할 수 있습니다.

"이러한 수준의 관련성은 신속하고 데이터 기반의 서버 업데이트와 라이브 운영팀이 적절한 매치업을 빠르게 적용하는 능력 덕분에 가능합니다."라고 타우베는 말합니다.

해당 팀은 클라이언트 출시나 서버 배포를 기다리지 않고도 이벤트, 스토어 판매, 프로모션, 보상 및 매치메이킹 설정을 변경할 수 있도록 자체 백엔드 및 라이브 운영 파이프라인을 구축했습니다.

기반에는 플레이어, 이벤트, 상점 아이템, 보상 상자, 배틀 패스 및 기타 시스템을 포괄하는 50개 이상의 구성 영역을 갖춘 맞춤형 콘텐츠 제공 및 원격 구성 시스템이 있습니다. 팀은 관리자 패널을 통해 변경 사항을 관리합니다. 시스템은 변경 사항을 수락하기 전에 유효성을 검사하며, 서버는 재시작 없이 몇 초 내에 변경 사항을 반영합니다.

모든 것은 버전 관리되고 로그로 기록됩니다. 팀은 이전 상태를 검토하거나 되돌릴 수 있으며, 변경 사항을 프로덕션 환경에 적용하기 전에 내부 테스트 계정에 대해 변경 사항을 적용할 수 있습니다.

이벤트 일정 관리도 같은 토대 위에 세워집니다. 이벤트, 토너먼트 및 기간 한정 판매는 시작 및 종료 기간이 정해져 있습니다. 세분화 엔진은 타겟팅을 처리하고 A/B 테스트를 지원하므로 팀은 더 넓은 범위로 출시하기 전에 일부 고객을 대상으로 새로운 제안이나 이벤트 형식을 시험해 볼 수 있습니다.

실제로 이러한 방식을 통해 팀은 프라임 클럽 및 타워 클럽 이벤트와 같이 한 주에 최대 4개의 이벤트를 진행할 수 있으며, 각 이벤트에는 고유한 보너스 플레이어와 특별 혜택이 제공됩니다.

"이벤트 도중에 문제가 발생했을 때 전체 시스템을 소유하는 것이 가장 큰 도움이 됩니다."라고 타우베는 말합니다. "팀은 문제를 진단하고, 설정을 수정하고, 영향을 받은 플레이어에게 보상하고, 클라이언트에 [설정] 업데이트를 배포하는 모든 작업을 몇 분 안에 한 곳에서 모두 처리할 수 있습니다."

콘텐츠 제공 및 모바일 출시 일정을 예측 가능하게 유지하기

해당 팀은 경기장 번들에 특화된 Addressables 사용합니다. 앱에는 기본 경기장 하나가 포함되어 있으므로 처음 사용하는 사용자는 추가 다운로드가 필요하지 않습니다. 해당 팀은 모든 경기장을 하나의 패키지로 묶어 팀 서버에 업로드하고, 플레이어가 선택할 때마다 다운로드할 수 있도록 제공합니다.

해당 팀은 엄격한 용량 및 메모리 제한을 준수하는지 확인하기 위해 가장 저사양 기기에서 각 스타디움 번들에 대한 스트레스 테스트를 실시합니다. 공유되는 공통 번들에는 여러 경기장에서 재사용되는 자산이 포함되어 있으므로 다운로드할 때마다 동일한 데이터가 중복되지 않습니다.

iOS 및 Android 릴리스에도 예측 가능성을 강조하는 동일한 원칙이 적용됩니다. 팀은 플랫폼별 코드를 최소한으로 유지하며, 두 플랫폼 모두 마일스톤 및 제출 마감일을 공유합니다. 해당 팀은 매일 Android 및 iOS 빌드를 생성하고 테스트합니다.

대부분의 콘텐츠가 데이터 기반이기 때문에 실시간 캘린더는 앱 스토어 심사 시기와 긴밀하게 연동될 필요가 없습니다.

클라이언트는 모든 서버 호출이 실패할 수 있다는 가정하에 설계되었습니다.

"특히 라이브 게임의 경우, 모든 서버 호출을 기본적으로 신뢰할 수 없는 것으로 간주해야 합니다."라고 타우베는 말합니다. "서버 속도가 느리거나 연결이 끊기거나 응답이 없더라도 플레이어 경험이 중단되지 않도록 클라이언트를 구성하십시오."

그 원칙은 기기 지원에도 적용됩니다. 해당 팀은 디바이스 시뮬레이터를 사용하여 UI가 지원하는 모든 화면 크기와 해상도 범위에서 UI 적용 범위를 확인합니다. Unity 프로파일러는 게임플레이 중 발생하는 성능 문제를 찾아내는 데 널리 사용됩니다. 또한 해당 팀은 Wi-Fi 연결 여부와 관계없이 다양한 Android 및 iOS 기기에서 성능 저하 테스트를 진행합니다.

타우베는 모바일 팀이 기기 전략을 조기에 수립해야 한다고 강조합니다.

"특히 Android 의 경우 하드웨어 및 OS 버전 간의 파편화가 실질적인 위험 요소이므로, 기기 지원을 위한 강력한 아키텍처 계획에 조기에 투자하는 것이 중요합니다."

워킹 데드 제작 과정: 사후 처리로 인해 살아있는 시스템이 독립적으로 진화할 수 있습니다.

Baseball Hits 26은 실제 스포츠 일정을 반영하여 제작되었습니다. 워킹 데드: 여파 라이브 서비스 측면에서 또 다른 과제는 기본적인 로그라이트 경험을 해치지 않으면서 새로운 플레이 방식을 추가하는 것입니다.

이 액션 RPG 로그라이트 게임은 플레이어를 워킹 데드 의 세계로 안내합니다. 그들은 릭 그라임스, 대릴 딕슨, 미숀을 포함한 생존자 팀을 구성하고 실시간 전투에서 워커 무리와 다른 적들과 싸웁니다. 플레이어는 게임 플레이 사이사이에 생존자와 장비를 잠금 해제하고, 레벨을 올리고, 스킬을 해제하고, 기지를 건설합니다.

"본질적으로 저희는 '워킹 데드' 의 끊임없는 위험과 어려운 선택들을 담아내면서도 로그라이트 게임에서 기대하는 재플레이성과 성장 요소를 제공하는 게임을 만들고 싶었습니다."라고 그라니그는 말합니다.

실시간 서비스는 도전 과제와 제약 조건, 그리고 동맹, 협력 이벤트, 순위표와 같은 소셜 시스템을 통해 이러한 기반 위에 구축됩니다.

"개발 관점에서 볼 때, 우리는 이러한 시스템들이 독립적으로 발전할 수 있도록 게임을 설계했습니다." 이를 통해 핵심 로그라이트 게임 플레이를 방해하지 않고 라이브 경험을 지속적으로 확장할 수 있는 유연성을 확보할 수 있습니다."

열 번째 라이브 피처링 콘텐츠를 첫 번째 콘텐츠만큼 저렴하게 배송하기

Swift Games는 라이브 서비스 기반을 완전히 처음부터 다시 구축한 것은 아닙니다. 이 게임은 이전 라이브 타이틀인 Heroes vs Hordes 에서 시작되었습니다. 스토어, 경제, 인증, 분석, 원격 구성 및 클라우드 저장 시스템은 검증된 기술로 여겨졌으며, 새로운 로그라이트 핵심 기능은 별도로 프로토타입을 제작한 후 해당 기반 위에 통합되었습니다.

매주 변경될 것으로 예상되는 모든 사항은 클라이언트 릴리스 없이 변경될 수 있도록 설계되었습니다. 디자이너는 스프레드시트에서 콘텐츠와 밸런스를 작성하고, 이를 원격 번들로 게시하며, 각 번들에는 지원하는 클라이언트 버전이 표시됩니다.

저장 데이터는 마이그레이션 체인을 통해 버전 관리되므로 라이브 업데이트로 인해 오랫동안 플레이해온 유저가 데이터를 잃어버리는 일이 없습니다. 이벤트와 시간 기반 제공은 시간에 따라 달라지기 때문에 시간은 기기가 아닌 서버에서 가져옵니다.

하지만 절충점은 실시간 기능은 단순히 켜지는 것뿐만 아니라 안전하게 꺼지도록 설계되어야 한다는 것입니다.

"바로 그 점 때문에 열 번째 라이브 기능의 출시 비용이 첫 번째 기능과 거의 비슷하게 유지되는 것입니다."라고 그라니그는 말합니다.

이 게임은 주로 GameObjects 와 NVIDIA PhysX를 사용합니다. Entities 와 Burst 적을 이동시키는 A* 경로 탐색 시스템에 사용됩니다.

실시간 개발에서 더 중요한 것은 스코프가 지정된 의존성 주입입니다. 이 게임은 루트, 게임 저장, 메인 화면, 게임플레이 라는 네 가지 중첩된 컨텍스트를 가지고 있습니다. 각 컨텍스트는 자신이 생성하는 것과 그것을 정리하는 것에 대한 책임이 있습니다.

즉, 라이브 이벤트는 설치 프로그램과 컨텍스트에 연결되는 구성 파일로 구성될 수 있습니다. 해당 서비스가 종료되면 관련 자산과 구독도 함께 종료됩니다.

또한, 해당 팀은 UI와 로직을 분리합니다. 상점이나 상품은 엔진을 실행하지 않고도 테스트할 수 있는 일반 C# 클래스로 존재할 수 있으며, 디자이너는 구성 자산을 직접 다룰 수 있습니다.

실시간 데이터와 게임 에셋 사이에 명확한 경계를 설정하기

~ 안에 워킹 데드: 여파 Addressables 원격 콘텐츠 전송보다는 메모리 관리 및 로딩을 처리합니다. 29개의 그룹은 개별 기능에 해당하며, 게임의 컨텍스트와 거의 동일한 방식으로 로드되고 언로드됩니다.

실시간 콘텐츠는 Addressables 아닌 AssetBundles API 기반으로 직접 구축된 별도의 파이프라인을 따릅니다. 번들 파일은 플랫폼별로 생성되어 업로드되고, 게임 실행 시 게임에서 불러옵니다. 각 파일에는 해시, 체크섬 및 가장 오래된 호환 클라이언트 버전이 포함되어 있습니다.

팀의 규칙은 간단합니다. "디자이너들이 매주 디자인을 바꾸고 싶다면, 세트로 묶어서 판매하는 게 낫습니다." 예술 작품이든 코드든, 모두 빌드에 포함되어야 합니다.

해당 경계 내에서 팀은 매장으로 돌아가지 않고도 이벤트를 이동하고, 보상을 재조정하고, 제안을 재조정하고, 기능이나 구매 행동을 켜거나 끄고, A/B 테스트를 실행할 수 있습니다. 새로운 아트워크와 새로운 코드는 빌드를 필요로 합니다.

"우리는 의도적으로 그 경계를 설정했습니다. 그래야만 문제가 발생했을 때 무엇이 ​​바뀌었는지 파악할 수 있도록 실제 작동 영역을 충분히 작게 유지할 수 있기 때문입니다."라고 그라니그는 말합니다.

시각적 다양성 또한 유사하게 통제된 접근 방식을 따릅니다. 경기장은 절차적으로 생성되는 것이 아니라 수작업으로 만들어집니다. 이 팀은 환경을 복제하는 대신 기존 형상에 재질, 조명 및 셰이더를 적용하여 외관을 변경합니다. 해당 시스템은 약 35개의 셰이더 그래프와 10개의 직접 작성한 셰이더로 구성됩니다.

"경기장을 수작업으로 짓기 때문에, 단순히 샘플링하고 기대하는 방식이 아니라 선수가 볼 수 있는 모든 것을 고려하고 측정할 수 있습니다."

스프레드시트에서 실제 게임으로 가는 경로를 단축합니다

팀의 실시간 운영 속도는 상당 부분 툴링에서 비롯됩니다.

디자이너는 설정을 직접 편집합니다. 내부 가져오기 도구는 스프레드시트에서 챕터, 텍스트 및 보상 표를 직접 가져오며, 스프레드시트가 정보의 원천으로 유지됩니다.

결과: 팀에서 운영 또는 밸런스 문제를 발견하면 전체 릴리스 프로세스를 거치지 않고 약 15분 만에 수정 사항을 배포할 수 있습니다.

빌드 파이프라인은 반복 작업 시간을 단축하도록 설계되었습니다. 심층 프로파일링은 전용 브랜치가 아니라 빌드 스위치이므로 개발자는 회귀 오류가 의심될 때 작업 중인 항목에 대한 프로파일링 빌드를 요청할 수 있습니다. 캐싱 및 빌드 시간 개선 작업은 팀이 매일 생성하는 대량의 빌드를 처리하는 데에도 도움이 됩니다.

UI 변경 사항이 매주 배포되기 때문에 팀은 다양한 화면 모양에서 노치 및 안전 영역 검사를 위해 장치 시뮬레이터를 사용합니다. 물리적 기기 테스트를 대체하는 것은 아니지만, 레이아웃 문제를 더 일찍 발견할 수 있습니다.

가장 어려웠던 운영상의 문제는 개발 환경과 실제 운영 환경을 분리하는 것이었습니다. Firebase 설정은 빌드 파일에 포함되어 있으며, Firebase, Play Services 키, Facebook 설정, 번들 ID, 이름 및 아이콘이 모두 일치해야 합니다.

팀은 결국 해당 환경에 대한 책임을 지속적 통합(CI)으로 옮겼습니다. 개발 버전과 실제 운영 환경에서의 빌드는 서로 다른 번들 ID, 이름, 아이콘을 사용하므로 동일한 기기에서 공존할 수 있습니다. 개발 빌드가 라이브 서버에 연결되면 게임 내에 경고 메시지가 표시됩니다. 구성이 누락되면 업로드가 실패하며, 잘못된 환경을 대상으로 조용히 실패하는 일은 없습니다.

"우리는 그 책임을 사람들에게 맡기는 대신 CI 부서로 옮겼습니다."라고 그라니그는 말합니다.

작게 시작하고, 초기에 테스트하세요.

두 팀 모두 서로 다른 방향에서 같은 교훈에 도달합니다. 지속 가능한 라이브 개발은 무엇을 바꿔야 할지 조기에 결정하고, 변화해야 할 부분을 안정적으로 유지해야 할 부분과 분리하며, 언젠가는 문제가 발생할 수 있다는 것을 가정한 시스템을 구축하는 데 달려 있습니다.

Baseball Hits 26 의 경우, 이는 실제 야구 시즌에 신속하게 반응하면서 클라이언트 릴리스, 기기 및 서버 오류로 인해 게임 플레이가 중단되지 않도록 하는 데이터 기반 백엔드를 의미합니다.

을 위한 워킹 데드: 여파 즉, 모듈형 라이브 시스템, 엄격하게 제어되는 구성, 그리고 의도적인 경계를 의미합니다. 콘텐츠는 원격으로 변경할 수 있으며, 코드와 아트워크는 빌드에 포함되어 배포됩니다.

Granig은 첫 모바일 게임 출시를 앞둔 팀들에게 라이브 서비스 시스템을 구축하기 전에 핵심 경험을 먼저 입증하라고 조언합니다.

"1~3일 분량의 콘텐츠를 제작하여 다른 작업을 시작하기 전에 먼저 공개하세요." 그럼 다음 날 얼마나 많은 플레이어가 다시 접속하는지 살펴보세요. 그들이 돌아오지 않는다면, 아무리 후반 콘텐츠가 많아도 게임을 살릴 수는 없을 겁니다."라고 그는 설명한다.

그럼 다시 해 보세요. 콘텐츠를 추가하고, 3일차를 살펴보고, 이 과정을 반복하세요. 작게 시작하고, 초기에 테스트하고, 수치를 통해 게임이 효과적인지 판단하세요. 가장 어려운 부분은 핵심 순환 시스템이 입증될 때까지 만들고 싶은 모든 것을 포기해야 한다는 것입니다.

야구 26 타 워킹 데드: 여파 앱 스토어 와 Google Play 에서 지금 바로 다운로드하실 수 있습니다. Unity 블로그 와 리소스 허브 에서 Unity 개발자들의 더 많은 이야기를 확인해 보세요.