물리 협동 게임 네트워킹: LEGO® Voyagers

2020년에 설립된 Light Brick Studio는 장인정신과 플레이어 통찰력에 중점을 둔 독립 팀입니다. 그들의 최신 출시작인 LEGO Voyagers는 두 친구가 우주비행사가 되기 위한 꿈을 쫓는 협동 모험입니다. 2025년 9월 15일 여러 플랫폼에서 출시되었습니다. 이 경험은 대화보다는 소리와 상호작용에 의존하여 플레이어가 플레이를 통해 이야기를 느낄 수 있게 합니다.

온라인 협동 기능은 개발 후반에 추가되어 팀에 독특한 도전을 안겼습니다. 우리는 LEGO Voyagers의 수석 프로그래머인 Kasper Honnens de Lichtenberg와 프로그래머 Daniel Zastrow와 온라인 협동을 물리 기반 프로젝트에 통합하는 것에 대해 이야기했습니다.

LEGO Voyagers를 개발하는 동안 주요 목표는 무엇이었나요?

Kasper Honnens de Lichtenberg (KHdL): 우리는 감정을 불러일으키고 강력한 협동 경험을 지원하는 재미있는 게임을 만들기 위해 노력했습니다.

Daniel Zastrow (DZ):우리의 목표는 LEGO 놀이의 본질을 포착하는 것이었습니다. 친구와 함께 즐거운 시간을 보내고 실제 LEGO 블록이 되는 것처럼 최대한 가까운 느낌을 주며, 함께 이야기를 경험하는 모험을 떠나는 것이었습니다.

어떤 시스템이 구현하는 데 가장 기술적으로 도전적이었나요?

KHdL: 개발 중간에 온라인 플레이를 추가하는 것은 기존의 아트 및 디자인 워크플로우를 유지해야 한다는 것을 의미했습니다. 우리는 팀이 방해받지 않고 계속 창작할 수 있도록 객체와 장면을 자동으로 변환하는 도구를 만들었습니다.

DZ: 부착 시스템의 네트워킹이 가장 어려웠습니다. 어떤 블록이든 무수히 많은 방법으로 연결할 수 있으며, 두 플레이어가 동시에 상호작용할 수 있습니다. 우리는 온라인 플레이를 위해 게임을 만들지 않았기 때문에, 호스트가 클라이언트가 기다리는 동안 행동을 검증할 수 있도록 많은 논리를 다시 작성했습니다. 나는 지연을 숨기기 위해 벽돌 부착 전환을 부드럽게 만들었다.

여러 느슨한 LEGO 벽돌을 네트워크에서 동기화하는 데 NVIDIA PhysX가 어떻게 도움이 되었나요?

DZ: 우리는 완벽한 결정론을 추구하지 않았다. 각 클라이언트는 물리를 로컬에서 시뮬레이션한 다음, 시각적으로 일관성을 유지하기 위해 네트워크 업데이트에 맞춰 물체를 밀었다. 투석기와 같은 빠른 시나리오에서는 순수 물리가 신뢰할 수 없었기 때문에 결정론적 궤적을 사용하고 착륙 후 PhysX를 다시 활성화했다. 이 하이브리드는 결함 없이 물리적 느낌을 유지했다.

Netcode for GameObjects와 Relay가 네트워킹 워크플로를 어떻게 간소화했나요?

KHdL: Netcode for GameObjects와 Relay 덕분에 네트워킹 인프라를 처음부터 구축하지 않고도 온라인 협동을 빠르게 실행할 수 있었다. 온라인 플레이가 개발 후반에 추가되었기 때문에, 우리는 게임 플레이에 집중할 수 있도록 안정적인 스택이 필요했다. 패키지를 열고 사용자 정의할 수 있는 능력은 매우 중요했으며, 특히 NGO 워크플로가 수동 변경을 가정할 때 자동 씬 전환을 가속화하는 데 도움이 되었다. 그 유연성 덕분에 우리는 개발 후반에 버그를 수정하고 문제를 해결할 수 있었으며 궁극적으로 게임을 출시할 수 있었다.

DZ: 디자이너들은 오프라인에서 계속 작업할 수 있었고, 자동 씬 전환 도구 덕분에 모든 사람을 단일 공유 씬으로 강제할 필요가 없었다. 우리는 네트워킹 레이어의 안정성에 영향을 주지 않고 몇 가지 워크플로 조정을 했다.

크로스 플랫폼 성능 목표가 물리학 및 네트워킹 구현에 어떤 영향을 미쳤나요?

KHdL: LEGO Voyagers는 물리학에 크게 의존하므로 성능이 네트워킹 안정성에 직접적인 영향을 미쳤습니다. 닌텐도 스위치ᵀᴹ에서는 물리를 위해 30 fps를 목표로 했으며, 이는 모든 것을 신중하게 최적화해야 함을 의미했습니다: 모델 축소, 저해상도 자산 및 그림자 사용, 물과 같은 무거운 기능 단순화. 조명 베이킹과 모델 축소는 자동으로 이루어졌지만 수동으로 트리거되었습니다.

DZ: 시스템 관점에서 우리는 물리 작업 부하가 예측 가능하게 유지되도록 해야 했습니다. 그래야 네트워크 상의 상호작용이 부하에 따라 저하되지 않았습니다. 우리는 스크립트를 최적화하고 필요할 때 무거운 시스템을 다시 작성했으며, Unity의 작업 시스템을 사용하여 물리 작업을 병렬화하는 것이 캐스트, 트리거 및 신호에 크게 도움이 되었습니다. 이로 인해 물리 시뮬레이션과 네트워크 업데이트를 반응적으로 유지할 수 있는 여유가 생겼습니다.

KHdL: 우리는 모든 씬을 프로파일링하고 프레임 드롭을 추적했으며 성능이 일관되게 목표를 충족할 때까지 최적화했습니다. 이 숫자를 달성하는 것은 필수적이었습니다. 시각적 요소뿐만 아니라 물리학과 네트워킹이 동기화되고 플레이어에게 신뢰할 수 있는 느낌을 주기 위해서였습니다.

돌이켜보면, 어떤 네트워킹 접근 방식을 변경하시겠습니까?

DZ: 우리는 더 일찍 네트워킹을 시작했어야 했습니다. 온라인 플레이를 추가할 때쯤에는 게임이 사실상 완성되었습니다. 디자이너들은 로컬 협동에서 완벽하게 작동하는 씬과 메커니즘을 구축했지만, 종종 같은 메커니즘을 내부적으로 다른 방식으로 구현했습니다. 우리가 그것들을 네트워크화하려고 할 때, 그러한 불일치는 주요 문제가 되었습니다. 모든 것이 인게임에서 동일하게 보이더라도 말입니다.

KHdL: 예를 들어, 우리는 세 가지 다른 레버 스크립트를 가지고 있었습니다. 디자이너들이 초기 게임플레이 프로토타입을 만들 때 이러한 중복이 자연스럽게 발생하지만, 공유 구조가 없으면 나중에 마찰을 일으킵니다. 특히 네트워킹에 대해 그렇습니다.

DZ: 사전 리팩터링이 없었다면, 우리는 같은 메커니즘의 여러 버전에 적응해야 했습니다. 네트워킹은 구조적 문제를 드러냅니다. 일관성이 중요하며, 그렇지 않으면 모든 기능이 특별한 경우가 됩니다.

KHdL: 초기 경량 네트워킹 구조가 있으면 도움이 되었을 것입니다. 공유된 기반 위에 새로운 기능을 구축하면 자동 변환 및 도구가 훨씬 더 효과적입니다.

DZ: 또 다른 도전 과제는 물리 기반 디자인 자체였습니다. 우리가 원하는 게임플레이를 제공했지만 네트워킹을 더 어렵게 만들었습니다. 프로토타이핑을 자유롭게 하는 것과 기술적 안정성을 위해 사물을 고정하는 것 사이에는 항상 긴장이 존재합니다. 돌이켜보면 실험에서 구조로의 더 명확한 전환이 도움이 되었을 것입니다.

KHdL: 균형입니다. 팀으로서 그 대화를 더 일찍 시작했다면 많은 고통을 덜었을 것입니다.

크로스 플랫폼 협동 게임에서 네트워킹을 처리하기 위한 팁은 무엇인가요?

DZ: 실행을 검증과 분리하세요. 클라이언트가 행동을 실행하게 하되, 검증은 호스트나 서버에서 유지하세요. 그 책임이 얽히면 네트워킹이 훨씬 더 어려워지고 취약하고 지나치게 복잡한 코드로 이어집니다. 필요하지 않다면 100% 결정론을 강요하지 마세요. 올바르게 보이고 느껴지는 일관성을 목표로 하세요.

KHdL: 게임의 컨텍스트에 맞게 설계하는 것도 중요합니다. LEGO Voyagers는 우리가 유연하게 행동할 수 있는 캐주얼 협동 경험입니다. 완벽한 동기화는 항상 필요하지 않습니다.

Unity로 제작된 프로젝트에 대해 더 읽으려면 리소스 페이지를 방문하세요.

*Nintendo Switch는 Nintendo의 상표입니다.