풀 체인 게이밍의 미래: "MUD ECS 엔진의 약속"

웹3의 아이디어는 게임 산업과 최근의 게임화 트렌드에 완벽하게 부합하는 것 같습니다. 꽤 오랫동안 우리는 온체인 게임이라는 독특한 경험의 형태로 새로운 혁신을 약속받아왔습니다. 힘의 균형을 게임 업계 기존 업체에서 창의적인 주체로 옮기는 탈중앙화, 오랫동안 폐쇄된 정원의 벽을 허무는 구성 가능성, 플레이어의 진정한 소유권 등의 특징이 바로 그것입니다. 그러나 이러한 강력한 이상은 아직 실제로 구현되지 않았기 때문에 제쳐두고, MUD는 차세대 게임에 불을 붙일 수 있는 온체인 게임의 완전한 프레임워크를 만들기 위한 최초의 용감한 시도입니다.

전통 게임 산업에서 얻은 교훈

혁신에 대한 집착, 모든 것을 처음부터 새로 만들고 완전히 새로운 창조물을 만드는 것에 대해 할 말이 많지만 게임의 경우, 디자인 패턴과 새로운 것에 대해 할 말이 많습니다. 엔지니어링 틈새 창작에는 수십 년 동안 쌓아온 교훈이 있으며, 이를 무시하는 것은 아타리 기술을 사용해 AAA급 게임을 만들려고 하는 것과 마찬가지입니다.

게임 개발의 초기 단계를 돌아보면 온체인 게임과 많은 인재와 매우 고무적인 프로젝트가 있지만 조율과 명확한 프레임워크가 부족하다는 점에서 분명한 유사점을 발견할 수 있습니다.

비디오 게임 초창기에는 게임 엔진이 만들어지기 전에 신념과 디자인 패턴이 확립되었습니다. 서로 다른 비디오 게임은 공통점이 거의 없었고, 어떤 면에서는 비슷한 게임이라도 완전히 다른 코드 기반을 가질 수 있었습니다. 하지만 게임 엔진이 도입되면서 모든 것이 바뀌었습니다.

게임 엔진과 게임 자체를 명확히 구분하기는 어렵습니다. 일반적으로 게임 엔진은 다양한 게임 구현을 위해 약간 수정하고 확장할 수 있는 일련의 규칙과 디자인 패턴이 포함된 프레임워크입니다. 1990년대에는 수년간의 파편화된 게임 개발 끝에 상황이 바뀌었고, "유형 기반" 게임 엔진과 범용 엔진을 개발하려는 일부 노력이 지배적이었습니다. 둠이나 언리얼과 같은 게임의 핵심 구성 요소는 다양한 게임을 만드는 데 재사용될 수 있었고, 비슷한 장르의 게임들은 많은 핵심 로직 임팩트를 공유하기 시작했습니다. 레이싱, 격투, 1인칭 슈팅 게임을 개발하는 데 드는 비용과 복잡성은 엄청나게 감소했습니다. 여러 세대에 걸친 게임과 업그레이드된 코드가 축적되면서 불가능이 가능으로 바뀌었습니다. 소프트웨어 관점에서 보면 이것이 게임 개발이 거대한 산업이 된 주된 이유 중 하나입니다.

온체인 게임에는 몇 가지 핵심적인 문제가 있습니다.

1. 프레임워크의 부족 모든 팀이 모든 것을 처음부터 구축하려고 하기 때문에 비효율성이 발생하고 빌더가 동일한 문제를 처리하고 최상의 솔루션을 최적화하는 방법에 대한 집합된 경험과 체계적인 지식이 부족합니다.

2. 코드 재사용성 부족: 오늘날 개발 중인 수많은 온체인 게임을 예로 들어보면, 그 중 성공적으로 복제하여 약간 다르게 만들 수 있는 게임이 몇 개나 될까요? 게임의 여러 레이어와 컴포넌트를 명확하게 구분하여 유사한 코드베이스를 사용하여 새로운 세대의 게임을 구축할 수 있는 게임은 몇 개나 될까요? 게임에서 가장 중요하고 상호 연결된 오픈소스 프로젝트를 만들겠다는 약속은 아직 멀게만 느껴집니다.

3. 데이터 구성성 부족: 이는 코드 재사용성에서 끝나는 것이 아니라 온체인 게임이 공유된 블록체인 상태를 활용하여 A 게임과 B 게임의 데이터를 사용하여 서로를 구축할 수 있는 능력과도 관련되어 있습니다. 서로를 기반으로 구축할 수 있는 능력입니다. 실제로 게임 A의 데이터와 로직을 통합하려면 많은 작업과 리소스가 필요하며, 하나의 게임이 다른 게임이 됩니다.

MUD의 솔루션:

MUD는 유지보수 가능하고 확장 가능하며 가변적인 구조를 온체인 게임 제작 엔진 및 프레임워크로 제공하는 최초의 용기 있는 시도입니다. MUD가 지지하는 엔티티 컴포넌트 시스템(ECS) 모델은 일반적인 게임 개발에서 의미가 있으며 온체인 게임 개발에서는 더욱 의미가 있습니다.

스마트 컨트랙트에서의 ECS:

MUD에서 가장 기본적인 구성 요소는 컴포넌트입니다( 컴포넌트는 엔티티 데이터를 저장하는 데이터베이스처럼 작동하는 스마트 컨트랙트입니다. 예를 들어, 플레이어의 지갑 주소와 같은 엔티티(이더 주소)가 있습니다. 이 주소는 위치 구성 요소의 위치(x,y), 레벨 구성 요소의 레벨 10, 토큰 구성 요소의 값 50 등 다양한 속성을 가질 수 있는 엔티티를 나타내며, 구성 요소에는 매핑과 기본 구성만 포함되어 있습니다.

시스템은 더 복잡하며 구성 요소의 값을 변경하는 로직을 구현합니다. 시스템의 지정된 데이터베이스(컴포넌트)에 대한 POST 요청 API로 생각할 수 있으며, 해당 컴포넌트에 대한 쓰기 권한이 있는 경우에만 특정 컴포넌트에 데이터를 쓸 수 있는데, 여기서 흥미로운 점이 있습니다. 시스템은 다양한 컴포넌트와 상호 작용하여 세부적인 로직을 만들 수 있습니다. 예를 들어 플레이어가 한 번에 두 걸음씩 이동할 수 있는 유효 이동을 지정하는 이동 시스템을 만들 수 있고, 레벨이 올라갈 때마다 플레이어에게 골드를 지급하는 보상 시스템을 만들 수도 있습니다.

이 모든 것이 월드 계약에 등록되어 컴포넌트 데이터가 변경될 때마다 이벤트가 발생하도록 합니다. 월드 컨트랙트는 라이선스가 필요 없으며 누구나 새로운 시스템과 컴포넌트를 추가할 수 있습니다. 이론적으로는 서로 다른 월드 컨트랙트가 서로 상호작용할 수 있습니다.

온체인 게임에 ECS를 도입하면 매우 우아한 구조가 만들어지며, OP크래프트는 10개의 컴포넌트와 약 15개의 시스템으로만 구성됩니다.

진정한 구성성

진정한 구성성

ECS 시스템은 웹만 위한 것이 아닙니다. 왼쪽;">ECS 시스템은 전통적인 게임 개발뿐만 아니라 온체인 게임에서도 두 가지 중요한 기능을 제공하기 때문에 더욱 적합합니다.

1. 다음 두 가지 기능이 있습니다. 배포된 게임의 확장성

2. 최고 수준의 컴포저빌리티

두 가지를 상상해보십시오. 하나는 기본 디자인을 유지하는 것이고, 다른 하나는 핵심 게임 로직을 변경하는 것입니다.

플레이어들이 군대를 만들어 서로 싸우는 일반적인 PVP 전략 게임을 상상해 보세요. 기본 버전은 2D이지만, 지금 팀은 이 게임을 3D 렌더링으로 만들기로 결정했습니다. 위치에 따라 달라지는 모든 시스템을 가져와서 (x,y) 대신 (x,y,z) 좌표를 사용하는 업그레이드 버전을 만들기만 하면 됩니다. 다른 모든 시스템과 구성 요소(예: 공격 시스템, 생명체, 군대 건물)는 변경하지 않고 그대로 유지할 수 있습니다. 초기 개발팀을 넘어 커뮤니티는 시스템과 구성 요소를 재배포하여 게임의 다양한 모듈(모드)을 만들 수 있으며, 새로운 시스템에 쓰기 권한을 부여하여 동일한 구성 요소와 상호작용할 수도 있습니다(커뮤니티 소유 게임의 경우 다양한 거버넌스 모델을 사용하여 이러한 결정에 투표할 수 있습니다).

동일한 컴포넌트와 시스템을 유지하면서 새 시스템에 쓰기 권한을 부여하지 않고 대신 컴포넌트와 시스템을 추가하여 게임 내 기능을 확장하는 또 다른 접근 방식은 어떤 모습일까요? 이동과 규칙 시스템이 이미 배포된 체스 기본 게임을 생각해 보세요. 사람들은 실제 체스처럼 게임을 플레이할 수 있지만, 팀에서 매칭이나 기타 사용 사례를 위한 등급 시스템이 포함된 소셜 레이어를 추가하기로 결정할 수 있습니다. 등급 컴포넌트와 등급 규칙이 있는 시스템을 추가하기만 하면 됩니다. <이렇게 하면 사용자를 새로운 버전의 게임으로 원활하게 마이그레이션할 수 있을 뿐만 아니라(더 나은 사용자 경험), 스마트 컨트랙트 수준에서 서로 다른 버전이 공존하거나 겹쳐질 수 있는 기술적 수단이 만들어집니다. 플레이어가 동일한 핵심 구성 요소의 데이터와 상호 작용하면서 다양한 버전의 게임을 플레이할 수 있다는 사실은 컴포저빌리티 애플리케이션 외에도 매우 혁신적입니다. 이는 불변성을 선택할 수 있는 기능을 생성하여 온체인 게임이 제공하는 또 다른 차원의 소유권을 창출합니다. 각종 게임 자산(예: 점수, NFT, 업적)의 진정한 소유권은 추가 업그레이드로 확장할 수 있지만 핵심은 변하지 않는 불변 로직으로 보호됩니다. 웹3 게임의 주요 문제 중 하나인 크리에이터가 동의 없이 에셋을 무력화할 수 있다는 문제를 해결합니다.

전체 클라이언트 측 보기:

MUD는 진행 중인 작업이라는 점에 유의하시기 바랍니다. 다음 섹션은 최신 정보가 아닐 수 있으며 일부 부정확한 설명이 있을 수 있지만 전체 아키텍처는 크게 달라지지 않습니다.

지금까지는 스마트 컨트랙트 수준에서 MUD를 살펴봤지만, MUD는 그 외에도 클라이언트 측 라이브러리와 레이어 전체를 제공하며 몇 가지 고유한 기능을 갖도록 설계되어 있습니다.

1. 클라이언트 구성 가능성

2. 블록체인과의 클라이언트 구성 가능성

3. < strong>블록체인 상태 변경(게임 데이터)과 완전히 동기화된 클라이언트

4. 렌더링 레이어로서의 PhaserX

더 구체적으로 설명하기 위해 기술적인 세부 사항을 살펴보겠습니다.

네트워크 레이어:

네트워크 레이어는 클라이언트의 기본 레이어입니다. 네트워크 계층에는 기본 구성(월드 컨트랙트, 게임 및 네트워크 구성)과 게임 상호작용을 위한 API가 포함되어 있으며, 클라이언트가 상호작용할 수 있는 모든 다양한 컴포넌트와 시스템의 사양으로 생성되고 특정 컴포넌트/시스템과만 상호작용하도록 선택할 수 있습니다.

예를 들어 게임에서 움직임을 생성하고 프론트엔드에서 이를 표현하려면 위치 컴포넌트와 함께 배포하기 위한 스마트 컨트랙트와 움직임 시스템과 동기화하기 위한 네트워크 레이어를 만들어야 합니다. 이제 위치와 일부 게임 내 오브젝트(엔티티)에 작용하여 위치를 설정하거나 한 장소에서 다른 장소로 이동하는 Move API를 만들 수 있습니다. 플레이어가 이동 API를 사용할 수 있을 때마다 블록체인에 트랜잭션을 제출하게 됩니다. 이동 시스템의 경우 이동 시스템 스마트 컨트랙트의 기능을 수행하게 됩니다.

이 구조는 멀티 클라이언트 기반 게임을 가능하게 합니다. 블록체인과 동기화되고 네트워크 레이어 인프라를 따르기만 하면 누구나 고유한 클라이언트를 만들 수 있으며, 모두 동등하게 유효합니다. <저희는 플레이어들이 서로 경쟁하지만 서로 다른 클라이언트와 플러그인을 사용하는 다크 포레스트와 같은 멀티 클라이언트 게임의 멋진 사용 사례를 보았습니다. 이러한 클라이언트 구조 덕분에 네트워크 계층에 임플란트하고 API를 수정하여 다양한 클라이언트 버전을 매우 빠르게 얻을 수 있어 높은 수준의 클라이언트 가변성과 구성성을 구현할 수 있습니다.

클라이언트 컴포넌트가 체인 컴포넌트와 어떻게 동기화되는지 궁금할 수 있습니다. 이는 개발자가 체인 게임 클라이언트를 다룰 때 직면하는 주요 과제 중 하나이며, MUD에는 몇 가지 해결책이 있습니다.

먼저, MUD는 스냅샷을 도입하여 클라이언트가 과거의 모든 이벤트를 처리하여 상태를 다시 빌드할 필요 없이 월드 상태(즉, 컴포넌트의 엔티티 값)와 동기화할 수 있으므로 지연 시간을 줄이고 복잡성을 줄일 수 있습니다.

또한, 각 시스템과 컴포넌트는 이름에 따라 ID를 부여받고 배포 시 월드 컨트랙트에 등록되는 MUD의 ID 시스템을 사용하면 변경 사항을 추적하고 게임과 상호작용하기가 더 쉬워집니다.

렌더링 레이어: 이벤트 렌더링 시기와 방법

MUD에는 "Phaser 위에 구축된 확장성이 뛰어난 프레임워크인 PhaserX가 함께 제공됩니다. PhaserX는 필수는 아닙니다. OPcraft에서는 PhaserX가 아닌 Noa 복셀 엔진이 사용됩니다. 이론적으로는 구조를 따르기만 하면 어떤 엔진이든 사용할 수 있습니다.

앞에서도 언급했듯이 각 컴포넌트와 시스템은 월드 컨트랙트에 등록되며, 변경이 발생하면 컴포넌트 ID와 엔티티 ID와 같은 식별 데이터가 포함된 이벤트가 발생합니다. 여기서 ECS 스트리밍 서비스는 클라이언트가 구독할 이벤트를 선택할 수 있는 옵션을 제공할 수 있습니다.

엔티티의 그래픽 표현은 원하는 대로 할 수 있습니다. 격투 게임에는 애니메이션 캐릭터, 기사, 심지어 좋아하는 크립토 도메인 KOL이 등장할 수 있습니다. 온체인 이벤트를 표현하고 이에 반응하기만 한다면 모두 유효한 버전입니다.

원문 링크: https://mirror.xyz/matchboxdao.eth/d3lVAOa9Bi0kY-caoUT3lDC6E61mWJqtP1q6tME4xGY