두 플레이어가 본 세계를 동시에 맞출 수 있나: Minecraft 월드 모델 Solaris

멀티플레이 월드 모델은 각 화면을 그럴듯하게 만드는 것보다 한 플레이어의 행동이 다른 플레이어 화면에도 같은 시점과 위치로 나타나게 해야 하며, Solaris는 이를 토큰 인터리빙으로 다룹니다. 논문 범위는 Minecraft의 두 플레이어와 비교적 짧은 에피소드이므로 대규모 게임 서버나 실사 시뮬레이션으로 바로 확대할 수는 없습니다. 평가는 화면 품질과 별개로 사건 시각, 객체 위치, 지속되는 세계 상태가 관점 사이에서 맞는지 보아야 합니다.

멀티플레이 예측은 싱글 플레이와 무엇이 다른가요?

한 명의 화면만 예측할 때는 현재 관측과 행동에 맞는 다음 프레임을 만들면 됩니다. 여러 명이 같은 공간에 있으면 A가 블록을 놓거나 공격한 결과가 B의 위치와 시야에 맞게 보여야 합니다. 개별 영상 품질과 시점 간 세계 일관성을 동시에 만족해야 합니다.

따라서 평가는 플레이어별 프레임 점수만으로 부족합니다. 동일 사건의 발생 시점, 객체 위치, 한 화면에서 바뀐 세계 상태가 다른 화면에도 반영됐는지를 쌍으로 비교해야 합니다.

두 플레이어가 서로 다른 방향을 보고 있으면 한 화면에 사건이 보이지 않는 것이 정상일 수 있습니다. 따라서 픽셀을 직접 같게 만드는 것이 아니라 각 카메라 자세와 시야에서 같은 숨은 세계 상태를 일관되게 투영했는지를 판단해야 합니다. 한 화면에만 보이는 물체가 오류인지 시야 차이인지 구분하려면 서버 상태나 사건 로그 같은 참조가 필요합니다.

관점 간 일관성은 어떤 사건으로 측정하나요?

블록 설치, 파괴처럼 세계에 남는 사건, 공격처럼 짧게 발생하는 사건, 플레이어 이동처럼 위치가 계속 변하는 사건을 나눕니다. 사건 시작 시간, 두 화면에 나타난 위치와 이후 상태 유지 여부를 기록하면 단순한 영상 유사도보다 멀티플레이 목적에 가까운 지표가 됩니다. 시야에 들어온 시점이 플레이어마다 다르다는 점도 시간 정답에 반영해야 합니다.

한 플레이어의 화면이 자연스럽고 다른 화면만 틀린 경우와 두 화면이 서로 맞지만 실제 서버 상태와 모두 다른 경우도 구분합니다. 전자는 관점 결속 오류이고 후자는 공통 세계 예측 오류에 가깝습니다. 두 종류를 한 점수로 합치면 인터리빙 구조와 기본 비디오 모델 중 어디를 고쳐야 할지 알기 어렵습니다.

객체가 화면 밖으로 나갔다 다시 들어올 때 상태가 유지되는지도 중요합니다. 관측되지 않는 동안 모델이 블록이나 다른 플레이어의 위치를 잊으면 다시 등장할 때 세계가 바뀔 수 있습니다. 가림과 재등장을 포함한 평가가 짧은 동시 시야보다 장기 기억을 더 잘 드러냅니다.

1,264만 프레임은 어떻게 동기화됐나요?

SolarisEngine은 Docker 컨테이너에서 Minecraft 봇과 서버 상태, 행동, 화면을 동기화해 데이터를 모으는 시스템으로 소개됩니다.

데이터는 건축, 전투, 이동, 채굴의 네 범주와 9,240개 에피소드로 구성됩니다. 플레이어당 632만 프레임, 합계 1,264만 프레임이며 20fps로 기록했습니다. 대부분의 에피소드는 128~512프레임, 즉 6.4~25.6초 범위입니다.

이 규모는 다양한 상호작용을 제공하지만 Minecraft의 블록형 시각과 규칙을 벗어난 실사 환경까지 입증하지는 않습니다.

프레임 수가 많아도 두 관점의 시각과 행동이 정확히 같은 서버 tick에 대응하지 않으면 모델은 잘못된 지연을 학습합니다. 화면 캡처, 봇 행동과 서버 상태의 타임스탬프를 어떤 기준으로 맞췄는지 확인하고, 누락 프레임이나 네트워크 지연이 생긴 에피소드를 별도로 표시해야 합니다. 평균 20fps라는 기록률이 모든 샘플의 균일한 간격을 보장하지는 않습니다.

동기화 데이터의 오류는 어떻게 찾나요?

동일 사건의 서버 로그와 두 비디오 타임라인을 표본 대조해 블록 변화와 공격 시각이 맞는지 확인합니다. 플레이어별 프레임 수, 시작, 종료 시각과 행동 수가 어긋난 에피소드를 자동 검사하고, 보정하거나 제외한 기준을 남깁니다. 잘린 에피소드가 특정 전투나 긴 작업에 몰리면 데이터 분포도 달라질 수 있습니다.

9,240개 에피소드의 분할은 프레임 무작위가 아니라 월드, 작업, 플레이어 구성 단위로 나눌 필요가 있습니다. 같은 건축물의 인접 프레임이 학습과 평가에 걸치면 보지 못한 세계 일반화가 과대평가될 수 있습니다. 네 범주별 에피소드와 길이 분포를 분할 사이에서 비교해야 합니다.

Minecraft 데이터는 상태 정답을 서버에서 얻기 쉽다는 장점이 있지만 실사 비디오와 물리 복잡도는 다릅니다. 이 연구의 가치는 통제된 멀티플레이 환경에서 구조를 시험한 데 있으며, 카메라 추적과 숨은 상태를 알기 어려운 현실로 옮길 때는 새로운 데이터 정렬 문제가 생깁니다.

Visual Interleaving은 플레이어 정보를 어떻게 섞나요?

모델은 같은 시점의 플레이어별 시각 토큰을 시퀀스 차원에서 번갈아 배치합니다. 하나의 DiT 어텐션 안에서 A의 토큰이 B의 토큰을 참조할 수 있게 해, 독립적으로 영상을 생성할 때 생기는 불일치를 줄입니다.

원문의 Python 조각은 이 아이디어를 설명하는 의사 코드일 뿐 실행 가능한 모델 구현이 아닙니다. 실제 구현에는 플레이어 수, 시간 위치, 행동 조건을 구분하는 임베딩과 마스크 설계가 필요합니다.

토큰을 번갈아 놓을 때 모델은 어느 토큰이 어느 플레이어와 시간에 속하는지 알아야 합니다. 플레이어 식별자가 약하면 두 관점의 외형이나 카메라 움직임이 섞일 수 있고, 시간 위치가 어긋나면 서로 다른 순간을 같은 사건으로 볼 수 있습니다. 플레이어 순서를 바꾸어도 결과가 대응해서 바뀌는지 확인하면 고정 위치 지름길을 시험할 수 있습니다.

인터리빙의 기여는 어떤 기준선과 비교하나요?

각 관점을 독립 생성한 모델, 하나의 공유 상태를 거쳐 두 화면을 만든 모델, 인터리빙 모델을 같은 데이터와 파라미터 예산에서 비교합니다. 플레이어별 화질과 사건 일관성, 메모리와 지연을 함께 봅니다. 인터리빙이 화면 품질은 조금 낮추더라도 세계 상태 오류를 크게 줄인다면 멀티플레이 목적에서는 의미가 있을 수 있습니다.

한 플레이어의 입력을 가리거나 잘못된 행동을 넣었을 때 다른 플레이어 출력까지 얼마나 오염되는지도 봅니다. 모든 토큰이 연결된 구조는 정보를 공유하는 만큼 한 관점의 오류가 전체로 퍼질 수 있습니다. 신뢰도가 낮은 관점을 제한하거나 새 관측으로 복구하는 정책은 모델 구조 밖에서도 필요할 수 있습니다.

긴 구간 학습에서 메모리와 오류는 어떻게 늘어나나요?

Solaris는 Checkpointed Self Forcing을 사용해 긴 구간 학습의 메모리 부담을 다루는 것으로 설명됩니다. 체크포인팅은 중간 활성값을 다시 계산하는 대가로 저장량을 줄이므로, 메모리와 학습 시간의 교환 관계를 측정해야 합니다.

에피소드가 길어질수록 생성 오류가 다음 프레임과 다른 플레이어 화면으로 함께 전파될 수 있습니다. 짧은 클립의 일관성이 장시간 세계 상태 보존을 보장하지 않습니다.

체크포인팅으로 저장 메모리는 줄어도 중간 계산을 다시 수행하므로 학습 시간이 늘어납니다. 플레이어 수와 프레임 길이별 peak memory, step time과 처리한 토큰 수를 함께 기록해야 실제 교환 관계를 알 수 있습니다. 같은 GPU에 들어간다는 사실만으로 더 효율적인 학습이라고 결론내리면 안 됩니다.

자기회귀 생성 중 한 관점에서 블록 위치가 틀리면 그 상태가 다음 프레임과 다른 관점에도 전달될 수 있습니다. 길이별로 첫 불일치가 발생한 시점과 이후 회복 여부를 재고, 실제 서버 상태를 중간에 다시 주입했을 때 드리프트가 줄어드는지도 시험할 수 있습니다. 이는 Solaris가 제공한다고 단정하는 기능이 아니라 장기 적용을 평가하는 방법입니다.

플레이어 수를 늘리기 전에 무엇을 확인해야 하나요?

인터리빙된 모든 토큰이 서로 어텐션하면 플레이어와 시퀀스가 늘수록 계산량이 빠르게 증가합니다. 두 명에서 맞았던 구조를 10명이나 100명에 바로 적용하기 어렵다는 뜻입니다. 시야가 겹치는 플레이어만 연결하거나 공유 상태를 별도로 압축하는 확장 전략이 필요할 수 있지만, 이는 이 글의 원문이 검증한 구현은 아닙니다.

Solaris는 Minecraft에서 다중 시점 월드 모델을 시험한 연구입니다. 네트워크 게임 서버를 대체하는 완성형 엔진이나 현실의 멀티에이전트 시뮬레이터로 보지 말고, 플레이어 수, 구간 길이별 일관성과 비용을 함께 평가해야 합니다.

플레이어 수를 늘릴 때는 토큰 수뿐 아니라 실제로 시야와 사건을 공유하는 관계가 얼마나 희소한지 봅니다. 멀리 떨어져 서로 영향을 주지 않는 플레이어까지 완전 attention으로 연결하면 계산을 쓰면서 잡음만 늘 수 있습니다. 거리, 시야, 공통 사건을 기준으로 연결을 제한하는 후보는 별도 연구와 검증이 필요합니다.

완성형 게임 엔진은 권위 있는 서버 상태, 충돌과 규칙을 정확히 유지해야 합니다. 생성 비디오가 그럴듯하더라도 숨은 인벤토리나 블록 상태를 보장하지 않으므로 Solaris를 서버 대체물로 보면 안 됩니다. 활용 여부는 일관된 영상 시뮬레이션이 필요한 연구인지, 정확한 게임 상태가 필요한 제품인지부터 구분해야 합니다.

arXiv 논문, 논문 페이지

함께 읽으면 이해가 이어지는 글

• LingBot-World의 16 FPS는 실시간 월드 모델을 뜻할까: 1초 지연과 장기 기억 점검 — 16 FPS, 1초 미만 지연, 분 단위 기억 주장을 처리량, 입력 반응성, 물리 정확도로 나눠 검토합니다.
• 생성 영상의 배경과 움직임이 무너진다면: DreamWorld의 결합 월드 모델링 — DreamWorld가 시간, 공간, 의미 피처를 함께 맞추는 방식, CCA와 다중 소스 가이드, VBench 개선치와 물리 이해 주장 사이의 한계를 짚습니다.
• 로봇이 미래 Frame을 맞히면 Action도 나아질까? LingBot-VA의 World Model — LingBot-VA가 video와 action token을 교차 배치하고 미래 visual state를 flow matching으로 예측한 뒤 inverse dynamics로 action을 내는 구조, 지연, 환각, 안전 한계를…