체인 상 게임 기술 스택: 게임 상태를 어떻게 동기화할까요?

작성자: Fiona, IOSG Ventures

감사합니다 @BriefKandle, @netherscape_xyz의 제작자, @stokasz CEO @rhascau @mintersworld, @0xcurio 팀, @SebastienGllmt 공동 창립자 @PaimaStudios, @hiCaptainZ, @SerenaTaN5의 도움과 귀중한 의견에 감사드립니다!

TL;DR

• 전체 체인 게임 / 자치 세계(「FOG/AW」)는 Web 3을 중심으로 한 몇 가지 중요한 서사 중 하나입니다. NFT를 통해 Web3에 연결되는 Web2.5 애플리케이션과 달리, FOG/AW는 게임 논리를 체인에 배치합니다. 블록체인을 게임 서버로 활용하여 게임 상태의 분산 신뢰 소스가 됩니다. 이는 지속성, 검열 저항성, 조합 가능성 등의 장점을 가져오지만, 그 위에 구축된 게임의 다양성과 복잡성을 제한하기도 합니다.
• 게임의 복잡성과 플레이 가능성 요구가 증가함에 따라 엔진 아키텍처에 대한 더 많은 도전 과제가 제기되었습니다: 예를 들어 프레임 지연, 난수, 생명력 회복, 연속적인 패시브 효과, 타이머 등이 있습니다. 이 중 시간 개념과 Ticks 단위는 블록체인에서 다르게 작용합니다. Mud는 시간 경과와 패시브 회복 기술을 시뮬레이션하는 여러 아이디어를 제공합니다. 예를 들어, 플레이어가 방 안에서 이동할 때, 거래에 따라 일부 미리 정의된 디자인에 따라 방 안의 모든 물체가 이동합니다. 이를 통해 시간과 상태의 변화를 인식합니다.
• FOG/AW 기술 스택은 다음과 같이 추상화될 수 있습니다: 개발자는 UI/UX 및 게임 핵심 논리를 위해 프론트엔드와 백엔드 코드를 작성하고, 게임 상태의 루프를 통해 모든 변화를 동기화한 후, 인덱서가 새로운 상태를 프론트엔드의 로컬 장치에 반영합니다.
• RTS와 같은 많은 게임 유형은 높은 tickrate를 요구하지만, 합의에 의해 생성된 블록체인은 블록 시간의 변화를 처리할 수 있습니다. tickrate는 여기서 해결해야 할 큰 문제입니다. Curio와 Argus는 이 분야의 선두주자로, 체인 레벨에서 게임 tickrate를 증가시키기 위해 노력하고 있습니다. Mud는 전체 체인에서 애플리케이션 상태를 EVM에 저장하여 최대한 구현하려고 합니다. 게임의 더 높은 tickrate를 달성하기 위해 체인 외부 결합 솔루션을 도입하지 않았습니다.
• 다양한 체인 선택에 있어, Dojo는 Starknet의 전체 체인 생태계를 이끌고 있습니다. @tarrenceva의 설명에 따르면, Starknet은 상태 차이(State diffs)를 가지고 있으며, 이는 낙관적 롤업과는 다르게 실행 출력을 중심으로 하고 있습니다. 게임에 대한 영향은 주로 비용 최적화에 있을 수 있습니다. 예를 들어 체스 게임에서는 3분의 게임에서 50수의 움직임이 발생할 수 있습니다. 상태 차이를 통해 단일 증명과 최종 상태는 "출력"을 증명할 수 있습니다. 반면 낙관적 롤업은 모든 중간 상태의 "입력"이 필요합니다.

FOG/AW 정의: 게임 상태는 어떻게 동기화되는가

FOG인지 여부를 판단하기 위한 기준은 게임 상태가 어떻게 동기화되는가(진실의 출처)입니다.

Web 2.5 게임이나 전통적인 멀티플레이어 게임에서는 중앙화된 서버가 현재 게임 상태를 정의합니다. 플레이어가 행동을 보낼 때, 서버는 이러한 입력을 컴파일하고 업데이트된 결과를 각 연결된 플레이어의 장치에 반환합니다. 서버는 모든 입력(tick)을 처리하고 불일치 문제를 해결하며, 정기적으로 플레이어에게 업데이트를 전송하여 게임 내 모든 요소의 스냅샷을 제공하며, 매 tick마다 게임 상태를 업데이트합니다. 게임 상태(「game state or tick」)는 게임 세계에서 각 객체의 속성의 시간 스냅샷입니다. Tickrate는 게임 서버가 매초 계산하고 플레이어에게 방송하는 업데이트된 게임 상태의 횟수를 의미합니다. Tickrate가 높을수록 게임 경험은 더 정확하고 고충실도입니다. 일반적으로 실시간 전략 또는 액션 게임은 높은 tickrate가 필요하지만, 카드 게임과 같은 턴제 게임은 필요하지 않습니다.

출처: https://www.gabrielgambetta.com/client-server-game-architecture.html

완전히 체인에서 실행되는 게임의 경우, 블록체인은 게임 서버이자 게임 상태의 분산 신뢰 소스입니다. 이 경우, NFT나 토큰뿐만 아니라 게임자의 ticks 및 게임 논리도 체인에 있습니다. 이것이 진정한 소유권, 지속성, 검열 저항성, 조합 가능성을 실현할 수 있는 이유입니다. 이상적으로는, 게임자의 각 행동은 블록체인에 제출되어 합의에 도달한 후 게임 상태가 업데이트되고 로컬 장치로 반환되어야 합니다. 따라서 자연스럽게 tickrate가 적은 게임 유형이 완전히 체인에서 실행되는 데 더 적합합니다.

게임의 지연, 시간 등의 도전 과제 해결

게임의 복잡성과 플레이 가능성 요구가 증가함에 따라 엔진 아키텍처에 대한 더 많은 도전 과제가 제기되었습니다: 예를 들어 프레임 지연, 난수, 생명력 회복, 연속적인 패시브 효과, 타이머 등이 있습니다.

프레임 지연은 사실 Web2 세계에서도 매우 일반적이며, 클라이언트 렌더링 및 사용자 작업에서 발생하는 지연에서 비롯됩니다. 특히 FPS와 같은 높은 tickrate 게임에서는 지연이 발생하면 플레이어 경험이 매우 나빠집니다. Web2에서의 한 가지 해결책은 lockstep state update로, 모든 플레이어의 동기화를 플레이어 중 가장 높은 지연 기준에 맞춰 동기화하여 플레이어의 공정한 경험을 해결합니다. 블록체인을 도입하고 거래 확인을 기다려야 할 경우, 이 지연은 더욱 심각해질 수 있습니다. 이를 위해 Mud는 게임에서 일반적으로 사용되는 optimistic rendering(낙관적 렌더링) 메커니즘을 추가하여, 사용자 작업이 성공했다고 가정하고 서버의 동의 이전(또는 이 경우 거래 확인 이전)에 클라이언트에서 렌더링합니다.

체인에서 난수 생성은 자주 논의되는 주제이며, Mud는 사용자 행동을 난수 결과의 입력으로 사용할 수 있다고 생각합니다. 상호작용이 발생한 후 생성됩니다.

시간 개념 및 Ticks 단위는 블록체인에서 다르게 작용합니다. @SebastienGllmt는 fraud proof 개념을 사용하는 체인(예: Op)에서는 타이머를 사용하는 것이 어렵다고 생각합니다. 오류가 발생하면 롤백이 필요하기 때문입니다. 게임에서 타이머를 사용하면 경험이 매우 나빠질 것입니다. Mud는 시간 경과와 패시브 회복 기술을 시뮬레이션하는 여러 아이디어를 제공합니다. 예를 들어, 시간이 지남에 따라 동전을 증가시키고, 플레이어가 동전을 필요로 하는 작업을 수행할 때마다 플레이어의 이전 동전 수, 최근 갱신 수 및 갱신 속도에 따라 플레이어의 동전 수를 계산합니다. 또 다른 예로, 플레이어가 방 안에서 이동할 때, 거래에 따라 일부 미리 정의된 디자인에 따라 방 안의 모든 물체가 이동합니다. 이를 통해 시간과 상태의 변화를 인식합니다.

스크립트 "치트" 작성은 아마도 문제가 아닐 것입니다. @BriefKandle은 게임 시스템의 MEV를 치트로 간주하지 않으며, 스크립트가 간단한 MEV를 방지하는 것은 게임 팀이 고려해야 할 사항입니다. Web2의 게임 개발은 사고 방식을 전환해야 하며, 좋은 MEV 봇은 게임 내 NPC입니다.

일부 기능은 최근 출시된 몇몇 체인 게임에서 구현되었습니다. 예를 들어 Rhascau에서는 타이머와 연속적인 패시브 효과를 사용했습니다. 기본적으로 블록 시간을 척도로 사용합니다. (현재 L2에서 블록 시간 = tickrate).

FOG/AW 기술 스택

FOG/AW 엔진 프레임워크는 개발자가 블록체인을 서버 및 신뢰 소스로 활용하여 게임을 구축할 수 있도록 하는 개발자 도구 스택입니다. 또한 현재의 몇 가지 문제를 해결할 수 있습니다:

• 표준/기성 프레임워크가 없기 때문에 체인에서 FOG/AW를 구축하는 효율성이 낮습니다.
• 모듈화 및 코드 재사용성이 부족합니다.
• 조합 가능성이 부족합니다. FOG/AW 엔진의 발전에 따라 체인 게임은 더욱 흥미롭고 상상력이 풍부해질 수 있습니다.

이해를 돕기 위해, 이러한 엔진의 일반적인 기술 프로세스는 다음과 같습니다: 개발자는 UI/UX 및 게임 핵심 논리를 위해 프론트엔드와 백엔드 코드를 작성하고, 게임 상태의 루프를 통해 모든 변화를 동기화한 후, 인덱서가 새로운 상태를 프론트엔드의 로컬 장치에 반영합니다.

블록체인에서 실행되는 게임이 이 루프를 원활하게 실행할 수 있도록 Mud, Dojo, Curio, Argus, Paima 엔진 및 Lootchain 등이 각자의 기술 스택을 개발하고 있습니다. 기술 스택은 3개의 핵심 부분으로 구성됩니다: 체인, 핵심 개발 스택 및 게임 프론트엔드. 그들은 모두 분산화와 게임 복잡성 간의 균형을 맞추기 위해 각자의 혁신을 가지고 있습니다.

• 게임 프론트엔드: 전통적인 엔진인 Unity, Unreal 등과 react/Threejs와 같은 언어 및 강력한 도구를 포함하여 렌더링 등의 기능을 제공하며, 게임의 플레이 가능성과 경험을 향상시키는 데 필수적인 요소입니다. 위의 프로젝트는 기본적으로 개발자가 사용할 수 있는 관련 SDK를 제공합니다.
• 핵심 개발 스택: 게임 논리가 블록체인에서 실행될 수 있도록 설계된 솔루션으로, 적시에 프론트엔드에 동기화될 수 있습니다. 주요 구성 요소에는 적절한 데이터베이스 구조(게임 행동 및 논리 정의)와 게임 상태의 동기화 및 반환이 포함됩니다.
• 체인: 대부분 Ethereum, Optimism 및 Starknet에서 구축되었습니다.

아래 그림은 다양한 프로토콜이 각자의 기술 스택을 어떻게 설계했는지를 보여줍니다. Mud V2를 예로 들어 그 작동 흐름을 살펴보겠습니다:

1. 개발자는 Mud에서 일부 Web2 프론트엔드 도구를 호출하여 코드를 작성하고, 이러한 강력한 기능을 활용하여 게임을 더욱 시각적으로 재미있게 만듭니다.
2. 동시에 개발자는 Mud의 스마트 계약 프레임워크(Mud World)를 사용하여 게임의 캐릭터, 아이템 및 구체적인 실행 논리 등을 작성합니다. 예를 들어, 영웅 A가 X에서 Y로 이동하고 Y 지역을 정복하려고 할 때, 얼마나 높은 확률로 또는 어떤 상황에서 성공적으로 해당 지역을 점령할 수 있는지를 정의합니다.
3. 위의 행동 및 게임 상태는 Mud Store에 기록됩니다. Mud Store는 체인 상의 데이터베이스로, 전역 게임 상태를 책임지며 게임 상태 동기의 신뢰 출처입니다.
4. 영웅 A가 Y를 정복하려고 할 때, 실제로는 플레이어가 프론트엔드 로컬에서 마우스를 클릭하고 해당 명령을 체인에 제출한 것입니다. 이 명령은 개발자의 게임 디자인 논리와 현재 Store의 게임 상태에 따라 결과를 생성하며, 이 결과는 새로운 게임 전역 상태로 업데이트되고 체인에 동기화됩니다.
5. Mud의 게임은 웹, 모바일 등 다양한 프론트엔드를 지원하지만, 복잡한 인덱스 요구에 직면할 수 있으며, Mode는 이를 위해 개발된 체인 외부 인덱서입니다.

이제 이러한 핵심 프레임워크의 공통점과 차이점 디자인에 대해 이야기해 보겠습니다.

• 그들 중 대부분은 Mud v1 디자인을 따르며 ECS를 게임 개발 데이터 구조로 사용합니다. 이는 게임 논리의 작성 및 표현 방식입니다. Mud V2는 이를 개선하여 데이터가 Tables 및 Systems에 정의되며, 이는 다른 데이터 표준(반드시 V1의 ECS 데이터 모델링 표준을 준수할 필요 없음)을 허용하여 개발자에게 더 많은 선택권을 부여하고 포용성을 높입니다.
• 대부분은 분산 데이터베이스를 사용합니다. 블록체인은 자연스럽게 게임 상태와 데이터베이스의 신뢰 출처입니다. Mud는 전체 체인에서 애플리케이션 상태를 EVM에 저장하여 최대한 구현하려고 합니다. 게임의 더 높은 tickrate를 달성하기 위해 분산화를 희생하거나 체인 외부 결합 솔루션을 도입하지 않았습니다.
• FPS와 같은 많은 게임 유형은 높은 tickrates를 요구하지만, 합의에 의해 생성된 블록체인은 블록 시간의 변화를 처리할 수 있습니다. tickrate는 여기서 해결해야 할 큰 문제입니다. Curio와 Argus는 자신의 혁신 디자인에서 체인 레벨에서 tickrates를 증가시키기를 희망하고 있습니다.
• 다양한 체인 선택에 있어, Curio와 Loot는 Caldera를 활용하여 Op stack 체인을 구축하고 있으며, Dojo는 Starknet의 전체 체인 생태계를 이끌고 있습니다. @tarrenceva의 설명에 따르면, Starknet은 상태 차이(State diffs)를 가지고 있으며, 이는 낙관적 롤업과는 다르게 실행 출력을 중심으로 하고 있습니다. 게임에 대한 영향은 주로 비용 최적화에 있을 수 있습니다. 예를 들어 체스 게임에서는 3분의 게임에서 50수의 움직임이 발생할 수 있습니다. 상태 차이를 통해 단일 증명과 최종 상태는 "출력"을 증명할 수 있습니다. 반면 낙관적 롤업은 모든 중간 상태의 "입력"이 필요합니다.

현재 이미 이러한 엔진 위에 구축된 게임이 있으며, Mud와 Dojo는 이를 위해 해커톤을 개최하여 개발자가 애플리케이션을 구축하도록 유도하고 있으며, Curio는 ETHCC에서 월드 오브 워크래프트의 미니게임 데모를 발표했습니다.

명백히, FOG/AW는 공공 블록체인 간의 경쟁에서 중요한 생태계로 자리 잡고 있으며, Lattice가 제안한 AW(자치 세계)는 게임에 국한되지 않고 사회적, 금융적 속성을 포함하는 큰 개념입니다. 따라서 이 위에 구축된 것은 상상력이 풍부한 가상 세계인 메타버스입니다. 우리는 새로운 형태의 게임, 사회적, 금융적 융합 애플리케이션을 기대할 수 있습니다.

참고문헌:

1. https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY-caoUT3lDC6E61mWJqtP1q6tME4xGY

2. https://jumpcrypto.com/writing/defining-on-chain-gaming/

3. https://www.oneqode.com/what-is-a-game-server/

4. https://medium.com/@qingweilim/how-do-multiplayer-game-sync-their-state-part-2-d746fa303950

5. https://latticexyz.notion.site/Building-Autonomous-Worlds-with-MUD-39d5eb5d31034589bc54a2053efb4c56

6. https://twitter.com/tarrenceva/status/1660686571270705152

7. https://book.dojoengine.org/framework/sozo/overview.html

8. https://www.youtube.com/watch?v=A0OXif6r-Qk