계획
1. 일반
1.1. 문서 소개
이 문서의 목적은 Clarus Victoria가 어떤 게임을 만들고 어떤 길로 가려는지에 대한 입장과 의도를 밝히는 데 있습니다.
앞으로 수년간 스튜디오가 개발할 게임들은 Nexus라는 더 크고 장기적인 프로젝트로 가는 단계로 간주됩니다.
이 문서는 기술 사양서나 요구사항 문서, 혹은 구체적인 일정이나 결과에 대한 약속이 아닙니다. 프로젝트가 발전하고 새로운 아이디어가 등장함에 따라 업데이트되고 수정될 수 있습니다.
이 문서는 Nexus 프로젝트의 전체 비전과 Clarus Victoria의 방향성에 관심 있는 플레이어, 그리고 새로운 시스템의 원리와 메커닉을 더 잘 이해하고자 하는 개발자를 위해 작성되었습니다.
1.2. 프로젝트 소개
Nexus는 플레이어가 장르, 배경, 메커닉을 섞어 자신만의 게임을 만들고 구성해 다른 사람과 공유할 수 있는 보편적 컴퓨터 게임입니다.
기존 게임과 달리 Nexus는 미리 정해진 장르나 단일 시나리오를 제공하지 않습니다. 여기서 장르는 플레이어가 선택하고 조합하며 플레이 도중에도 바꿀 수 있는 규칙과 시나리오의 집합입니다.
Nexus는 단순한 Roblox나 Garry's Mod의 또 다른 버전이 아닙니다. 대부분의 유사 플랫폼에서는 세계를 스크립트와 에디터로 조립합니다. Nexus에서는 인간 언어에 가까운 언어를 기반으로 세계를 구축합니다. 이 언어는 의미, 규칙, 콘텐츠를 만들어 냅니다. 이 접근은 무엇을, 어떻게 플레이할지에 더 많은 유연성과 자유를 제공합니다.
1.3. 문서 구조
이 문서는 번호가 매겨진 섹션으로 구성되어 탐색과 링크 공유가 쉽습니다.
전체 구조는 다음 섹션을 포함합니다:
- 1장은 서론입니다. Nexus 프로젝트와 이 문서에 대한 일반 정보를 담고 있습니다.
- 2장은 Nexus 프로젝트가 구현된 이후 어떤 모습일 수 있는지에 대한 아이디어를 설명합니다.
- 3장은 프로젝트를 기술적으로 구현할 수 있게 하는 아이디어와 접근을 담고 있습니다.
- 4장은 로드맵으로, 프로젝트를 만들기 위한 단계적 순서를 설명합니다.
- 5장은 도전 과제에 대해 다룹니다. 위험과 제약, 그리고 이를 해결하는 접근을 설명합니다.
3장을 제외한 모든 섹션은 일반 독자를 대상으로 합니다. 3장은 전문가와 게임 개발자를 위한 내용에 더 가깝습니다.
이 문서는 모듈형 구조로, 섹션 순서를 엄격히 따르지 않고 선택적으로 읽을 수 있습니다.
1.4. 작성자 소개
문서의 작성자는 Clarus Victoria의 창립자이자 게임 디자이너, 개발자인 미하일 바실리예프입니다. 이 문서는 저자의 주관적 관점을 반영하며, 완전하거나 최종적 진리를 주장하지 않습니다.
2. 콘셉트

2.1. 섹션의 목적
Nexus 프로젝트가 구현된 후 어떤 모습일 수 있으며 어떤 기능을 가질 수 있는지를 보여 줍니다. 이 섹션에서는 Nexus가 속할 보편적 컴퓨터 게임이라는 장르의 형성 아이디어를 다룹니다.
설명된 아이디어 중 일부는 구현이 어려워 보일 수 있지만, 방향과 기준점으로 제시됩니다. 이 섹션은 게임 메커닉의 개념과 게임의 전체 이미지에만 전념하며, 규칙 설계와 기술 구현의 문제는 3장으로 옮겨집니다.
2.2. 게임 시작
메인 메뉴에는 유튜브를 연상시키는 인터페이스가 있지만, 영상 대신 게임 시나리오가 표시됩니다. 화면의 중심에는 추천 블록과 히스토리 섹션이 있습니다. 추가 기능으로는 좋아요 표시된 시나리오 목록과 나중에 다시 보려는 시나리오 목록이 제공됩니다.
2.2.1. 추천을 통한 게임 만들기
첫 실행이라면 게임이 여러 카테고리의 인기 시나리오 트렌드를 제공합니다. 첫 실행이 아니라면 게임이 이미 취향을 알고 있어 추천에서 아직 해보지 않았지만 좋아할 만한 시나리오를 보여 줍니다. 예를 들어 로마, 우주, 레이싱을 좋아한다면 추천에 다음과 같은 주제가 등장할 수 있습니다: "트라야누스 황제", "로마의 몰락", "고대 게르만", "화성 개척", "몬차 서킷", "제트 엔진". 원하는 주제를 선택할 수 있습니다.
2.2.2. 게임 불러오기
히스토리 섹션을 열어 이전에 만든 게임을 이어서 플레이할 수 있습니다. 이는 익숙한 저장 및 이전 세션 복귀 방식입니다. 저장 파일은 다른 플레이어와 공유할 수 있습니다.
2.2.3. 시나리오 설정
시나리오의 기본 아이디어를 선택한 뒤, 향후 캠페인의 성격을 더 구체적으로 정의할 수 있습니다. 원하면 시작 조건을 설정할 수 있습니다: 세계와 캐릭터의 특성, 그리고 이야기가 시작되는 핵심 특성들입니다.
2.2.4. 게임 생성
선택한 시나리오에 따라 해당 테마에 맞는 게임 세계가 생성됩니다. 같은 추천이라도 시작 조건이 달라질 수 있어 각 시작은 독특하게 느껴집니다. 원한다면 "게임 시드"를 설정해 새 플레이에서 비슷한 시작 조건을 재현할 수 있습니다.
2.3. 세계
2.3.1. 규칙
세계의 보편적 규칙은 RPG와 전략 게임에 이상적으로 맞는 공통된 규칙성의 집합입니다. 이를 통해 액션, 스포츠, 레이싱, 어드벤처 및 그 하위 장르 같은 다른 장르도 설명할 수 있습니다. 여기서 말하는 것은 특정 메커닉이 아니라, 대부분의 게임 세계의 논리를 표현할 수 있게 하는 원리입니다.
2.3.2. 장르
이 게임에는 메커닉을 제한하는 고정된 장르가 없습니다. 대신 장르는 모듈로 존재하며, 조립식처럼 결합하고 설정할 수 있습니다. 기초는 여전히 RPG입니다. 이는 인간이 세계와 상호작용하는 가장 자연스럽고 이해하기 쉬운 방식입니다.
전략적 경험을 원하고, 예를 들어 카이사르의 삶을 살고 싶다면, 당신은 한 사람으로서 사건 속에 들어가 1인칭 전투에 참여하며 군단을 이끕니다. 전체를 조망해야 한다면 인간의 역할을 벗어나 특별한 능력을 부여하고 위에서 전장을 관찰해 전략적 관점을 얻을 수 있습니다. RPG 모드에서는 명령이 즉시 실행되지 않습니다. 전달자와 장교의 전달 체계를 거치며 지연되거나 왜곡되거나 완전히 사라질 수 있습니다. 그러나 역할을 벗어나 마치 텔레파시처럼 명령을 직접 전달하는 능력을 얻으면 즉각적이고 무조건적인 실행을 이끌 수 있습니다—자기희생이 필요하더라도 말입니다. 이 단계는 경험을 RPG적 인식에서 명령이 즉시 정확히 수행되는 전통적 전략으로 점차 이동시킵니다.
일반적인 액션 게임에서는 찰나의 반응이 결정적 요인이라면, 여기서는 결과가 캐릭터의 숙련도에 의해 결정됩니다. 특히 민첩한 영웅에게는 시간이 느리게 느껴질 수 있습니다. 레이싱에서는 고속 코너를 통과하는 성공이 많은 요인의 결합으로 나타납니다: 운전자의 기술과 컨디션, 차량 특성, 노면 품질, 접지력, 주변 경쟁자, 그리고 우연성.
2.3.3. 게임의 기반으로서의 지식
보편적 게임의 세계는 지식에 의존합니다: 과거와 현재의 사실, 미래에 대한 상상, 그리고 허구와 판타지. 이 지식은 게임 엔티티, 속성, 관계로 반영되어 플레이어가 상호작용할 수 있게 됩니다.
생물군계, 장비, 생물, 자연 현상, 행성, 그리고 전체 세계는 이러한 지식의 객체로 인식됩니다. 기본 이미지에서 이러한 세계는 현실에 가깝습니다: 식물상과 동물상, 계절 변화, 지질 및 역사 시대, 과학기술 발전. 사람들은 기술, 강점과 약점, 개인 이력과 동기를 갖습니다. 그들은 병에 걸리거나 부상을 입고, 도움 없이 죽을 수도 있습니다. 판타지, SF, 대체 역사, 포스트 아포칼립스 시나리오는 이 기반 위에 겹쳐져 세계의 일부 측면을 변화시키지만 통일성을 파괴하지는 않습니다.
2.3.4. 사건
사건은 스스로 발생하지 않습니다. 다른 과정의 결과입니다. 가뭄은 풀의 죽음을 초래하고, 풀이 사라지면 초식동물이 죽으며, 먹이가 사라진 굶주린 포식자는 사람을 공격하기 시작할 수 있습니다. 세계는 원인과 결과의 연쇄로 발전하며, 각 변화는 새로운 과정을 촉발합니다.
세계는 당신의 개입을 기다리지 않습니다. 그 역사는 미리 정해져 있거나 스크립트로 만들어지지 않습니다. 그것은 당신의 선택, 다른 존재들의 행동, 세계의 법칙, 그리고 우연에 의해 형성됩니다. 시나리오가 역사적 기반을 가진 경우, 사건이 반복되는 이유는 "프로그램되어서"가 아니라 같은 원인이 다시 같은 결과를 낳기 때문입니다—기후로 촉발된 변화의 연쇄가 만든 청동기 붕괴처럼 말입니다.
2.3.5. 플레이어 결정의 결과
플레이어의 행동은 세계에 남는 사건의 연쇄를 촉발합니다. 예를 들어, 위기 상황에서 집단의 리더가 팀원을 희생하기로 결정하면 명성이 훼손되고, 이는 이후의 삶에 흔적을 남깁니다.
영향력이 클수록 결과도 큽니다. 강의 흐름을 바꾸고 시간을 한 세기 앞당겨 지형 변화을 볼 수도 있습니다. 위업을 이루고 천 년 동안 사라졌다가 이름이 전설이 된 새로운 시대에 돌아올 수도 있습니다.
세계는 자신의 역사를 유지하며 핵심 사건, 그 원인과 먼 결과를 보존합니다. 수백 년 후 책과 고고학을 통해 과거의 플레이 세션을 탐구하고, 당시의 결정이 현재 세계를 어떻게 형성했는지 확인할 수 있습니다.
2.3.6. 동기
세계의 어떤 존재—사람, 동물, 조직, 국가—든 자신의 역할과 동기에 따라 행동합니다. 그들은 당신과 상관없이 자신만의 목표를 추구합니다. 꿈, 사랑, 공격성, 탐욕은 인물의 행동을 좌우하고 행동을 촉진하는 상태입니다. 예를 들어:
- 사랑하는 사람과의 장기적인 부재는 인물의 상태에 큰 영향을 주고 결정을 바꿀 수 있습니다.
- 파라오는 재상에게 피라미드를 건설하라고 명령할 수 있으며, 이는 재상에게 결정적인 과제가 됩니다.
- 사슴은 먹이를 찾고 번식하며 포식자를 피합니다.
- 범죄 신디케이트는 영향력을 확장하고 새로운 영토를 차지하려 합니다.
2.3.7. 드라마투르기
완전히 시뮬레이션된 세계에서는 긴 "고요한 기간"이 가능할 수 있습니다. 농부로 플레이한다면 전쟁이나 재난, 큰 변화 없이 10년을 살아갈 수도 있습니다. 그 역할을 있는 그대로 살아보고 싶다면 세계를 그대로 둘 수 있습니다.
하지만 지루하다면 드라마투르기를 강화할 수 있습니다. 이는 전체적인 느낌을 바꾸며, 속도는 빨라지고 사건은 밀집되며, 차분함과 긴장감의 균형이 세계의 논리를 깨지지 않게 이동합니다. 이 모드에서는 세계가 덜 예측 가능하게 행동하기 시작합니다: 작은 사건, 예상치 못한 만남, 드문 운명의 전환이 나타납니다. 시뮬레이션은 깨지지 않지만 인물의 삶은 더 영화적으로 변해, 평범한 경찰이 점차 추격, 수사, 드라마틱한 분기점이 있는 이야기로 흘러가기도 합니다.
최대의 역동성을 원한다면 드라마투르기를 더 강화할 수 있고, 그러면 거의 모든 모퉁이마다 새로운 이야기가 생기며 일어나는 일이 액션 블록버스터처럼 느껴질 것입니다.
2.3.8. 게임 규칙 변경
언제든 선택한 역할을 벗어나 진행 중인 규칙을 바꿀 수 있습니다. 일본 회사원을 플레이하던 중 슈퍼히어로가 되기로 결정한다면, 이는 세계 안의 일반적인 행동이 아니라 서사의 논리를 바꾸는 단계입니다.
당신은 세계와 그 법칙을 변경할 수 있습니다: 마법을 추가하거나 객체와 생물의 속성을 바꿀 수 있습니다. 그런 세계에서는 물이 나무처럼 타고, 비둘기가 지능을 가질 수도 있습니다. 그 이후에도 세계는 새로운 규칙 아래 일관성 있게 발전합니다.
더 나아가 기반 자체를 실험해, 익숙한 논리에 반하는 세계를 만들 수도 있습니다: 역설의 세계, 거울 세계, 자신만의 물리와 현실 구조를 가진 다른 우주들. 이 접근은 게임플레이, 시뮬레이션, 세계 편집을 결합하여 거의 무한한 가능성을 엽니다. 법칙을 바꾸더라도 인과성의 원칙은 새로운 틀 안에서 계속 작동하기 때문에 세계는 일관성을 유지합니다.
현재 세계의 스냅샷은 새로운 게임의 기반이 될 수 있습니다. 한 플레이어가 "신" 역할로 다른 이들이 살아갈 세계를 만들 수 있습니다. 이는 모드나 맵 에디터와 비슷하지만, 보편적 게임의 논리에 내장되어 있습니다.
2.4. 게임플레이
2.4.1. 롤플레잉
가장 부자가 되고 싶나요? 초능력을 얻고 영원히 살고 싶나요? 우주를 정복하고 싶나요? 현재의 지식을 가진 채 과거로 가고 싶나요?
원하는 역할로 즉시 시작할 수도 있고, 처음부터 시작해 캐릭터의 능력과 경계를 점차 확장할 수도 있습니다. 롤플레잉은 사람뿐 아니라 사건, 추상, 아이디어로도 가능합니다: 화재, 전염병, 조직, 종교, 언어. 초기 시나리오는 시작점만 정할 뿐이며, 이후의 발전은 전적으로 당신의 선택에 달려 있습니다.
2.4.2. 게임 목표
게임의 목표는 시나리오에 의해, 또는 당신에 의해, 혹은 둘의 조합으로 설정될 수 있으며, 아예 없을 수도 있습니다. 평범한 과제부터 시대적 업적까지 무엇이든 가능합니다 — 꿈의 직업을 얻거나 "철학자의 돌"을 발명하는 일처럼 말입니다. 목표를 달성해도 게임은 끝나지 않습니다. 세계는 계속 살아 있으며, 원하는 만큼 머물 수 있습니다.
2.4.3. 역할의 동적 전환
언제든 역할을 바꾸고 같은 세계의 다른 존재의 관점에서 이야기를 이어갈 수 있습니다. 이러한 전환은 진행 중인 일을 중단하지 않고, 사건을 다른 시각에서 볼 수 있게 해 줍니다. 예를 들어, 한 가족의 구성원들을 번갈아 롤플레잉하거나 전장에서 다른 병사로 살아볼 수 있습니다. 이는 게임 자체가 환생의 개념으로 구성되지 않는 한, 하나의 역할만 수행하는 기존 롤플레잉을 넘어서는 경험입니다.
2.4.4. 플레이어 행동
사용 가능한 행동은 현재 상황과 캐릭터의 특성에 맞게 제공됩니다. 이는 현재 상황의 맥락과 그 순간의 당신이 누구인지에 따라 구성됩니다.
예를 들어, 화재 상황에서는 대개 도망치기, 불 끄기, 다른 사람 돕기 같은 선택지가 나타납니다. 하지만 당신은 다르게 행동해 불을 확산시키는 데 가담할 수도 있습니다. 이런 행동의 차이는 캐릭터의 성격 — 그가 누구이며 어떻게 행동하는지 — 를 반영합니다. 방화광에게 화재 상황은 일반인과 다르게 인식될 것입니다.
2.4.5. 자동 및 수동 제어
기본적으로 세계의 모든 엔티티는 자율적으로 존재하며, 자신의 성격, 동기, 목표에 따라 행동합니다. 이는 당신의 캐릭터에도 적용되며, 직접 조종하기 전까지는 자동으로 움직입니다. 리더 역할을 선택해 여러 엔티티 집단과 상호작용할 때, 제어는 직접 조종이 아니라 요청, 명령, 기대의 시스템으로 이해됩니다.
다른 엔티티는 당신의 명령을 따르거나 거부할 수 있습니다 — 당신에 대한 태도, 가용 자원, 두려움, 피로, 신체적 제약에 따라 달라집니다.
2.4.6. 관찰
직접 플레이하지 않을 수도 있습니다. 흥미로운 캐릭터를 만들고 특이한 상황에 배치한 뒤 원하는 드라마투르기 수준(2.3.7 참조)을 설정하고 사건이 어떻게 전개되는지 관찰하세요. 이 경험은 이야기가 스스로 전개되는 영화를 보는 것과 비슷할 수 있습니다.
관찰 결과는 세계 상태를 저장하고 전달하여 다른 플레이어와 공유할 수 있습니다. 누군가의 이야기가 새로운 블록버스터가 될 수도 있습니다. 이 모드는 오락뿐 아니라 모델링에도 적합합니다. 예를 들어 "거북이 문명"을 만들고 그것이 석기 시대에서 우주 비행까지 어떻게 발전하는지 관찰할 수 있습니다.
2.5. 게임플레이 상호작용
2.5.1. 카메라와 표현
게임에서 일어나는 일은 1인칭, 3인칭, 탑다운, 또는 텍스트로도 인식될 수 있습니다. 표현 방식은 맥락과 선택한 역할에 따라 변합니다. 예를 들어 사람에게는 1인칭이 자연스럽고, 생각은 텍스트로 인식될 수 있으며, 국가나 행성으로 플레이할 때는 위에서 보는 전략적 관점으로 전환됩니다.
보편적 게임은 하나의 표현 방식에 얽매이지 않으며, 현재 가장 편한 방식으로 보일 수 있습니다. 시각 장애인도 소리와 설명을 통해 객체와 사건을 인식하며 세계와 상호작용할 수 있습니다.
지각되는 세계의 범위는 항상 현재 역할에 맞습니다. 사람이면 감각의 한계에 묶이고, 특별한 능력을 부여하면 숨겨진 것과 먼 것까지 볼 수 있도록 지각이 확장됩니다.
2.5.2. 그래픽과 사운드
인터페이스, 비주얼 스타일, 애니메이션, 음악, 사운드는 게임 경험을 풍부하게 하고 선택한 역할을 느끼게 해 줍니다. 고대와 마법적 사고의 세계에서는 시각·청각적 이미지가 인간과 신의 세계의 이중성을 강조해, 모든 행동이 신성한 의미로 채워진 추가 차원의 느낌을 줍니다. 포스트 아포칼립스에서는 그래픽과 사운드가 생존의 취약함, 상실감, 그리고 새로운 시작에 대한 희미한 희망을 전달합니다. 박쥐의 세계에서는 공간이 다르게 인식됩니다: 규모와 형태는 시각이 아니라 소리를 통해 느껴집니다.
2.5.3. 지도
세계나 지도는 선택한 역할에 따라 어떤 표면이든 될 수 있습니다 — 행성, 지역, 선박, 심지어 사람의 몸도 가능합니다. 예를 들어 개미로 플레이하면 지도는 개울가의 풀밭이 됩니다. 공간에 대한 인식은 규모에 따라 달라지며, 시점은 확대·축소될 수 있고 시야 각도도 바뀔 수 있습니다.
확대하면 디테일이 드러나고, 축소하면 디테일이 사라져 더 큰 구조와 연결로 대체됩니다.
2.5.4. 시간
시간은 선택한 역할과 선호도에 따라 다른 속도로 흐릅니다. 전투에서는 초 단위로 흐를 수 있습니다. 지질 과정을 모델링하는 글로벌 모드에서는 게임 시간 1초가 수백만 년에 해당할 수도 있습니다. 시간 가속은 다른 시간 감각을 가진 존재 — 식물이나 장수 생명체 — 를 플레이할 때 특히 적절합니다.
시간은 정지, 가속, 건너뛰기, 역전이 가능합니다. 원한다면 턴제 모드로 천천히 결정을 내리며 플레이할 수도 있습니다. 어떤 상황에서는 특정 캐릭터를 조종할 때만 시간이 흐르고, 다음 단계에 대해 생각하는 동안은 시간이 멈춥니다.
2.5.5. 온라인 플레이
온라인 플레이어는 시간 흐름 규칙을 사전에 합의한 뒤 같은 세계에서 서로 다른 캐릭터와 엔티티로 동시에 플레이할 수 있습니다. 한 명은 군대에 명령을 내리는 나폴레옹이 될 수 있고, 다른 한 명은 전장에서 적을 공격하는 척탄병이 될 수 있습니다. 플레이어는 서로 적대할 수도 있습니다: 어떤 이는 마을 주민이고, 어떤 이는 정착지를 위협하는 약탈자이며, 또 다른 이는 도적을 추적하는 현상금 사냥꾼일 수 있습니다.
2.6. 보편성
2.6.1. 의미
Nexus는 기존 대부분의 게임이 가진 규칙과 상호작용의 논리를 표현하고 재현할 수 있습니다. 이는 특정 구현을 그대로 복제하는 것이 아니라, 핵심 게임플레이 논리를 재현하는 것입니다.
이는 모든 게임이 규칙의 집합이며, 규칙을 단순한 의미 문장(트리플)으로 설명할 수 있기 때문에 가능합니다.
예시: Dark Souls(규칙 기준):
- Death -> causes -> loss_of_souls
- Bonfire -> is -> respawn_point
- Enemy -> difficulty -> high
- Strike -> depends_on -> stamina
Civilization(규칙 기준):
- Turn -> duration -> depends_on_era
- City -> produces -> [units, buildings]
- Victory -> conditions -> [science, military, culture]
The Sims(규칙 기준):
- Character -> needs -> [hunger, sleep, socialization]
- Need_low -> causes -> bad_mood
- Action -> satisfies -> need
2.6.2. 장르 조합
규칙이 모듈로 조직되기 때문에 서로 조합할 수 있습니다. 이를 통해 알려진 규칙 세트로부터 새로운 게임플레이 형식을 만들어낼 수 있습니다.
예시: Dark Souls + Civilization:
- 로드란 왕국을 문명으로 통치한다.
- 전투와 조우는 Dark Souls 규칙(기술, 타이밍, 위험)에 따른다.
The Sims + 좀비 아포칼립스:
- Sims의 일상적 필요(음식, 수면, 사회성).
- 그 위에 생존 규칙(피난처, 무기, 위험)이 추가된다.
보편성의 원칙: 게임 논리를 말로 표현할 수 있다면 Nexus에 구현할 수 있다.
2.7. 예시
2.7.1. 세계의 상황
플레이어는 자레치예 마을의 농민 이반입니다. 그는 배가 고프고, 아내는 임신 중이며, 이웃 표트르가 소를 잃었습니다. 비가 다가오고 있습니다.
2.7.2. 시스템이 이해하는 방식(트리플)
시스템 내부에서 이 상황은 간단한 진술의 집합으로 설명됩니다:
- Ivan -> is -> peasant
- Ivan -> hunger -> 30% (또는 Ivan -> satiety -> 30%)
- Ivan -> located_in -> Zarechye
- Marya -> relation -> Ivan_wife
- Marya -> pregnant -> 8_months
- Cow -> belongs_to -> Pyotr
- Cow -> location -> forest
- Weather -> approaching -> rain
각 진술은 지식의 원자입니다. 함께 현재 세계의 상태를 형성합니다.
2.7.3. 플레이어가 보는 방식
논리는 시각화와 분리되어 있으며 그대로 유지됩니다. 표현 모드에 따라 동일한 트리플이 다르게 표시됩니다. UX 언어에 대한 자세한 내용은 3.9절을 참조하세요.
2.7.3.1. 텍스트 모드
"당신은 농민 이반이다. 배가 고파 꾸르륵거린다. 아내 마리야는 곧 출산한다. 이웃이 소리친다 — 그의 소가 도망쳤다. 지평선에는 비구름이 드리워져 있다."
2.7.3.2. 아이콘이 있는 헥스 맵 모드
- 마을 타일과 오브젝트: 🏠(집), 🏚️(헛간), 💧(시냇물)
- 캐릭터: 👤 이반 [🍞30% 빨간색]
- 가족: 👩 마리야 🤰 ~30일
- 이벤트: 🏠 표트르 🔊, 발자국 🐾🐾 -> 🌲
- 효과: 🌧️ 접근 중
2.7.3.3. 3D 모드
완전한 마을, 배를 잡고 있는 이반의 모델, 집 옆에 앉아 있는 마리야, 멀리서 들리는 외침과 부서진 울타리, 지평선에 검은 구름이 보입니다.
2.7.4. 플레이어 행동
플레이어는 의도를 정합니다: "표트르가 소를 찾도록 돕는다" 이 행동은 트리플로 변환됩니다:
- Ivan -> intention -> help
- Help -> whom -> Pyotr
- Help -> task -> find_cow
시스템의 해석: 1. 이반이 도울 수 있는가? -> 예 (신체적으로 건강하고 가까이 있음) 2. 시간이 걸리는가? -> 예 (~1시간) 3. 배고픔에 영향을 주는가? -> 예 (증가) 4. 무엇이 일어나는가? -> 숲 수색, 소를 찾을 확률
2.7.5. 결과
게임 시간 1시간 후:
- Cow -> location -> found_at_stream
- Ivan -> hunger -> 20% (증가)
- Pyotr -> relation_to_Ivan -> gratitude +10
- Pyotr -> obligation -> help_with_roof
시각적으로:
- 플레이어는 소와 함께 돌아오는 애니메이션을 본다
- 🍞 20% (더 붉게)
- 알림: "표트르가 고마워합니다. 지붕을 돕겠다고 약속했습니다."
2.8. 개념에서 구현으로
2.1–2.7절은 Nexus의 원하는 모습을 플레이어 관점에서 설명합니다: 무엇을 보는지, 어떻게 상호작용하는지, 어떤 기회를 얻는지.
핵심 원칙:
- 어떤 게임 상황도 말로 설명할 수 있다.
- 말은 트리플(간단한 진술)로 형식화될 수 있다.
- 트리플은 해석될 수 있다(추론 가능).
- 결과는 어떤 방식으로든 시각화될 수 있다.
3. 구현 개념

3.1. 섹션의 목적
이 섹션은 Nexus 프로젝트를 기술적으로 구현하는 방법과 내부 구조를 어떻게 구성할 수 있는지에 대한 아이디어를 다룹니다. 구체적 기술 해법이 아니라, 이런 게임을 가능하게 하는 원칙과 방향을 설명합니다. 구체 구현은 개발 과정에서 결정되고 실무에서 다듬어질 것으로 예상됩니다.
이 섹션은 게임 컨셉을 아이디어로 자체적으로 다루지 않으며, 구현 접근에만 초점을 둡니다. 이 섹션은 주로 전문가와 컴퓨터 게임 개발자를 대상으로 합니다.
3.2. 유연한 접근
컴퓨터 게임을 만드는 고전적 접근은 미리 설계된 고정된 게임 시스템 안에서 플레이어가 행동하도록 구성됩니다. 높은 자유도를 제공하는 샌드박스 게임조차도 사실은 여러 개의 분리된 시스템 집합입니다. 이는 가능성의 다양성을 느끼게 하지만, 경직된 아키텍처라는 기본 원칙은 바뀌지 않습니다. 시간이 지날수록 새로운 시스템을 추가하면 개발과 지원의 복잡성만 증가하고, 게임플레이 경험의 질적 확장은 발생하지 않습니다.
진정한 유연성을 얻기 위해서는 이 접근의 기반을 재고해야 합니다. 새로운 게임 메커닉을 추가한다고 해서 프로젝트의 아키텍처 복잡성이 증가해서는 안 됩니다. 대신 게임의 기본 요소는 원자처럼 — 최소적이고 보편적이며 서로 호환되는 단위로 조직되어야 합니다.
이 접근을 잘 보여주는 예가 Minecraft입니다. 수백만 개의 블록으로 성, 도시, 우주 정거장 같은 극도로 복잡한 구조물을 만들 수 있습니다. 동시에 객체 수가 늘어도 내부 아키텍처의 복잡성은 커지지 않습니다. 시스템이 처음부터 확장성을 고려해 설계되었기 때문입니다.
깊이 있는 보편적 게임에서는 이 원칙을 전체 아키텍처에 적용할 수 있습니다. 게임 메커닉의 수는 얼마든지 많을 수 있지만, 서로 일관되게 공존하고 결합해 어떤 복잡도의 세계도 형성할 수 있도록 조직되어야 하며, 시스템의 일관성과 제어 가능성을 유지해야 합니다.
3.3. 의미망
유연한 접근을 구현하는 한 가지 방법은 게임 데이터를 원자적 논리 단위—트리플—로 표현하는 것입니다. 트리플은 “주어 – 술어 – 목적어” 형식의 간단한 진술입니다. 예:
- 사과 – 이다 – 먹을_수_있음
- 사과 – 영양 – 5
- 인간 – 먹을_수_있다 – 과일
- 풀 – 성장 – 일정 이상의 습도
- 사슴 – 이다 – 초식동물
- 신디케이트 – 통제 – 도시_구역
트리플로는 모든 것을 설명할 수 있습니다: 객체, 속성 및 상태, 관계, 가능한 행동, 게임 규칙, 기술 또는 마법. 이는 특정 게임 구현에 종속되지 않는 지식 표현입니다. 단순한 데이터 저장 형식이 아니라, 세계의 의미를 설명하는 방법입니다.
깊고 일관된 세계를 위해서는 방대한 데이터가 필요합니다 — 세계 구조의 일반 원칙부터 개별 게임 사실에 이르기까지. 이 데이터는 동물, 기술, 아이템, 건물, 역사적 사건, 기타 엔티티 등의 구체적인 콘텐츠로 채워집니다.
3.4. 인터프리터
데이터 레이어 위에는 인터프리터가 동작합니다. 이는 논리 시스템(예: Apache Jena)이나 신경망 접근을 기반으로 할 수 있습니다. 그 역할은 트리플을 처리하고 논리적 추론을 수행하는 것입니다. 예:
- 사과 - 이다 - 과일
- 인간 - 먹을_수_있다 - 과일
- 결론: 인간은 사과를 먹을 수 있다
인터프리터는 여러 사실을 결합하여 이런 결론을 도출합니다. 추론 사슬은 훨씬 길어질 수 있습니다.
게임 안에서 인터프리터는 세계를 채우고 가능한 행동을 결정하는 데 사용됩니다. 예를 들어 다음과 같은 질문에 답합니다:
- 아라비아의 열대 사막에서 어떤 나무가 자랄 수 있는가.
- 초기 석기 시대와 현대에서 사람들이 개에 대해 어떤 행동을 할 수 있는가.
- 현재 순간에 플레이어가 인식할 수 있는 객체는 무엇인가.
인터프리터는 이러한 질문을 더 단순한 데이터 질의로 분해하고, 이를 통일된 의미 표현으로 변환해 답을 형성합니다. 인터프리터는 이미 형식화된 질의와만 작업하며 자연어와 직접 상호작용하지 않습니다.
3.5. 의미 기반 ECS
보편적 게임의 세계가 의미, 논리, 방대한 사실 배열에 기반해 작동하려면, 객체와 속성을 가능한 한 유연하게 설명할 수 있는 아키텍처가 필요하며, 경직된 하드코드에 의존하지 않아야 합니다.
이 문제는 의미 기반 ECS로 해결할 수 있습니다. 이는 지식과 엔티티 간 관계를 표현하도록 적응된 ECS의 변형입니다. 이 맥락에서 ECS는 시스템 업데이트 루프보다 데이터 모델로서의 역할에 더 초점을 맞추며, 최종 아키텍처라기보다는 실용적 진입점으로 사용됩니다.
세계의 기초는 엔티티입니다: 캐릭터, 아이템, 동물, 조직, 선박, 식물. 고전적 ECS처럼 엔티티 자체는 논리나 데이터를 갖지 않고, 컴포넌트가 붙는 식별자 역할을 합니다.
핵심 차이는 컴포넌트 구조에 있습니다. 전통적 ECS에서 컴포넌트는 여러 필드를 가진 구조체지만, 의미 ECS에서는 큰 컴포넌트 대신 “이다”, “가지다”, “포함하다”, “할 수 있다”, “관계하다” 같은 술어 컴포넌트를 사용합니다. 각 술어는 세계에 대한 하나의 관계 또는 진술을 표현합니다.
예를 들어 “사과” 엔티티는 “이다” 술어 컴포넌트를 통해 “과일”과 “먹을 수 있음” 엔티티를 가리킬 수 있습니다. 동시에 “먹을 수 있음” 또한 자체 속성을 지닌 엔티티입니다: “가지다 - 영양”, “가지다 - 맛”. 각 값 컴포넌트는 정확히 하나의 값을 저장합니다. 예: “영양 = 5”, “맛 = 달콤함”, “무게 = 0.2”.
이로써 각 연결이 원자적으로 유지되는 속성 네트워크 혹은 트리가 형성됩니다. 세계의 어떤 객체, 속성, 관계도 독립된 최소 사실로 설명됩니다. 덕분에 규칙과 상호작용은 하드코드가 아니라 데이터로 존재합니다.
성능을 보장하기 위해 캐시, 인덱스, LOD(아래 참조) 메커니즘이 사용됩니다. 이는 수백만 개의 사실로 구성된 세계를 성능, 논리적 일관성, 의미 규칙을 통한 관리 가능성을 유지하면서 모델링할 수 있게 해 줍니다.
3.6. 게임 규칙
데이터와 이를 다루는 논리는 그 자체로 게임이 아닙니다. 게임플레이가 생기려면 추가 층이 필요합니다 — 게임 규칙입니다. 이들은 하드코드되지 않고, 언어의 기본 규칙을 확장하며 필요에 따라 연결될 수 있습니다. 단어 게임처럼 규칙의 역할은 경계를 설정하는 것입니다: 무엇이 허용되고 무엇이 금지되는지, 어떤 목표가 존재하는지, 어떤 역할이 가능한지, 그리고 게임플레이가 어떻게 전개되는지. 게임 규칙은 언어의 거의 무한한 가능성을 제한된 공간으로 축소해 그 안에서 게임플레이가 발생하도록 합니다.
게임 산업에서는 새 게임마다 규칙을 바닥부터 다시 만드는 것이 일반적입니다. 하지만 게임 간 차이는 대부분 근본적이지 않으며, 대부분의 RPG와 전략은 개념적으로 유사하고 메커닉 디테일, 그래픽, 로어만 다를 뿐입니다. 이 접근은 게임 개발의 사실상 표준이 되었고, 게임플레이 경험의 균질함은 당연하게 받아들여집니다. 다양성은 주로 비주얼 스타일, 분위기, 서사에서 나옵니다.
보편적 게임 규칙은 검증된 메커닉의 체계화와 통합을 의미합니다. 이를 통해 개발자는 매번 기반을 다시 만들 필요 없이 더 복잡하고 상위 수준의 요소에 집중할 수 있습니다. 규칙은 모듈로 구성되어 필요에 따라 연결되며 특정한 게임플레이 경험을 형성합니다.
이 접근은 게임 엔진의 구조와도 유사합니다. 예를 들어 Unity나 Unreal Engine은 저수준 기능 구현 부담을 덜어줍니다. 하지만 여기서 말하는 것은 기술 구현이 아니라 보편적 게임 규칙입니다. GURPS 같은 테이블탑 시스템이나 Minecraft, Dwarf Fortress, RimWorld 같은 복잡한 샌드박스에서도 일부 규칙이 이미 보편적 성격을 보입니다.
기본적으로 “규칙”은 모듈을 연결할 때만 내용이 채워지는 빈 구조입니다. 모듈의 조합이 세계의 동작을 결정합니다: 피해 계산 방식, 이니셔티브, 경제의 작동, 엔티티 상호작용, 이벤트 처리, 그리고 적용되는 제약 등입니다. 이 접근은 세계의 메커닉을 조립식으로 구성할 수 있게 합니다.
모듈은 자유롭게 조합되며 장르도 섞을 수 있습니다. 턴제 모듈에 전투 모듈을 추가하면 캐릭터가 체력과 스킬을 갖게 됩니다. 플랫폼 모듈을 추가하면 엔티티가 점프할 수 있게 되며, 경제 모듈을 연결하면 자원 생산이 도입됩니다. 규칙 구성은 세계의 다른 요소처럼 시나리오, 배경, 장르까지 게임 자체의 일부가 됩니다.
결국 규칙의 모듈성은 게임 로직을 고정된 제약 집합에서 유연한 아키텍처로 바꿉니다. 이를 통해 동일한 시스템이 규칙과 데이터의 조합만으로 RPG, 전략, 시뮬레이션, 레이싱 등 다양한 장르를 코드 변경 없이 지원할 수 있습니다. 이 모듈성이 보편적 게임을 진정으로 보편적으로 만듭니다.
3.7. 추상화와 LOD
3.7.1. 제한된 지각과 추상화의 필요
보편적 게임의 세계에는 동물 이동과 도시 성장부터 미생물의 행동이나 항성계의 역학까지 수많은 과정이 존재할 수 있습니다. 모든 공간과 규모를 완전히 다시 계산하는 것은 불가능하며 불필요합니다 — 플레이어는 언제나 주관적이고 제한된 범위 안에서 세계를 인식합니다. 따라서 시스템은 세계의 논리를 유지하면서 확장성을 보장하기 위해 추상화 층을 사용합니다.
추상화는 높은 디테일이 게임플레이 결과에 영향을 미치지 않는 곳에 적용됩니다. 미시 세계, 행성의 생물권, 항성계 수준에서는 그 규모에 맞는 다른 엔티티와 규칙을 사용합니다. 따라서 시스템은 개별 엔티티의 행동을 모두 모델링하지 않고, 과정의 전체 결과를 즉시 반영합니다.
3.7.2. 시간과 공간의 스케일링
시간을 빠르게 넘길 때, 게임은 모든 누락된 순간을 다시 계산하지 않습니다. 대신 시스템은 현재 세계 상태를 분석하고 집계된 규모에서 인과 관계를 적용한 뒤 가능한 결과를 보간합니다: 인구가 어떻게 변하는지, 어떤 트렌드가 강화되는지, 어떤 사건이 가장 발생 가능성이 높은지 등입니다. 이를 통해 수십 년, 수천 년을 건너뛰어도 세계의 일관성을 유지할 수 있습니다.
공간 스케일링은 세계의 구조를 바꾸지 않지만, 시뮬레이션이 다루는 엔티티와 과정의 수준을 결정합니다. 큰 규모에서는 기후, 이동, 정치 구조 같은 집계된 엔티티와 과정이 고려됩니다. 지역 규모로 이동하면 세계는 개별 엔티티와 그 속성을 드러냅니다. 모든 경우에서 인과 관계의 통일된 논리가 유지됩니다.
추상화 덕분에 게임은 마을, 행성, 생태계, 은하 등 어떤 규모의 세계도 담을 수 있습니다. 세부 사항은 플레이어나 사건의 논리상 중요해질 때만 나타나며, 그 외는 인과 관계를 유지한 채 단순화되어 설명됩니다.
플레이어는 참조 시스템처럼 세계의 구조를 파고들어 엔티티를 탐구하고 속성을 탐색할 수 있습니다. 여기서 유일한 제한은 세계의 데이터와 규칙입니다.
3.7.3. 세계의 실체화
세계는 탐험될수록 형성됩니다. 플레이어가 어떤 위치를 방문하기 전까지 그곳은 특정 객체 없이 데이터와 규칙으로만 존재합니다. 객체는 플레이어가 세계와 상호작용할 때만 실체화됩니다. 이는 Minecraft의 청크 로딩과 비슷합니다: 세계는 완전히 계산되지 않지만, 주관적으로는 이미 존재하는 것처럼 느껴집니다.
사건은 세계가 전적으로 존재하는 것처럼, 플레이어의 관측 범위를 넘어선 곳까지 포함해 생성됩니다.
어떤 위치나 엔티티와의 상호작용이 끝나면 그 상태는 세계에 대한 새로운 지식으로 저장되고, 더 이상 활성 계산에 참여하지 않습니다. 이 접근은 미시 세계에서 은하까지 안팎으로 스케일링을 가능하게 하며, 불필요한 세부사항을 저장하고 재계산하지 않도록 해 줍니다.
긴 시간 간격에는 통계적 추세를 사용합니다. 예를 들어, 지름 수 km의 소행성이 지구와 충돌하는 빈도는 대략 백만 년에 한 번으로 알려져 있습니다. 수천 년의 지평선에서 기술 문명이 사라질 확률을 추정하는 모델도 존재합니다. 이러한 추정은 정확한 결과를 정하지 않지만 가능한 시나리오의 범위를 정합니다. 따라서 플레이어가 천 년 앞으로 이동하면, 시스템은 문명 폐허, 안정적 발전, 또는 다른 일관된 시나리오 중 하나를 선택합니다.
3.7.4. 온라인 플레이
온라인 모드에서는 동일한 '상호작용에 의한 실체화' 원칙이 사용됩니다. 서버는 세계를 완전히 계산되고 고정된 지도 형태로 저장하지 않습니다. 대신 데이터, 규칙, 그리고 이미 드러난 사실—플레이어가 발견하거나 변경한 것—을 기반으로 동작합니다.
한 개 이상 플레이어가 동일한 영역과 상호작용하면, 서버는 해당 영역에 대한 공유된 실체 상태를 만들어 모든 참가자와 동기화합니다. 이 상태는 실제로 관측되고 사용되는 수준의 디테일만 유지합니다.
상호작용 영역 밖에서는 세계가 지속적으로 재계산되지 않습니다. 규칙, 통계적 추세, 축적된 사실로 설명되는 잠재 상태로 남습니다. 이는 많은 플레이어가 동시에 존재하는 하나의 큰 연속 세계를 유지하면서, 실제로 관측되고 게임플레이에 관련된 것만 동기화할 수 있게 해 줍니다.
3.8. 에이전트와 세계 시뮬레이션
세계의 모든 엔티티—사람, 동물, 조직, 국가—는 목표, 동기, 상태를 가진 에이전트로 간주됩니다. 에이전트는:
- 자신의 지식 범위 안에서 세계를 인식한다.
- 가능한 행동 옵션을 평가한다.
- 목표와 세계의 규칙에 따라 결정을 내린다.
- 세계의 상태를 바꾸는 사건을 촉발한다.
세계 전체는 다층 시뮬레이션으로 작동합니다:
- 자연은 기후와 이용 가능한 자원의 영향으로 변화합니다.
- 생태계는 환경 변화에 반응합니다.
- 사람과 사회는 자연, 기술, 정치의 변화에 반응합니다.
- 플레이어는 이 과정에 세계의 한 엔티티로 참여합니다.
세계의 역사는 미리 정해져 있지 않으며 손으로 써 놓은 것도 아닙니다. 이는 공유된 법칙과 인과 관계 속에서 행동하는 많은 에이전트의 상호작용 결과로 탄생합니다.
예를 들어 가뭄은 풀을 줄이고, 풀 부족은 초식동물의 굶주림으로 이어지며, 굶주림은 이동을 초래하고, 이동은 포식자나 인간과의 충돌로 이어집니다. 이러한 연쇄는 사실과 규칙에 기반해 형성되며, 현재 조건에서 자연히 따라오는 결과를 결정합니다.
3.9. UX 언어
게임과의 상호작용 언어는 인간 언어에 가까운 논리에 기반합니다. 이를 통해 플레이어와 게임은 효과적으로 소통합니다. 이 언어에는 거의 모든 복잡도의 의미 구조를 만들 수 있는 규칙이 있습니다.
인터페이스나 맵의 각 상태는 “지금 무엇을 보고 있는가?”라는 질문으로, 가능한 행동의 집합은 “현재 상황에서 무엇을 할 수 있는가?”라는 질문으로 볼 수 있습니다. 게임은 세계 상태, 플레이어 아바타의 위치, 상호작용 대상 객체를 분석해, 새로운 세계 상태와 새로운 인터페이스 표시 형태로 답을 구성합니다.
가장 단순한 수준에서 언어는 세계에서 인식되는 것의 이름입니다: “나무”, “어머니”, “태양”. 다음 수준에서는 그 속성과 상태를 설명할 수 있습니다: “화난 사람”, “많은 별”, “강한 사자”, “스파르타인 300명”.
게임에서 이러한 개념은 실제 엔티티로 표현되거나, 아이콘 같은 픽토그램으로 표현될 수 있습니다. 각 단어 또는 개념은 하나의 아이콘에 해당합니다.
객체 속성은 시각적 기법으로 표현됩니다:
- “화남”, “나쁨”, “부정적” — 아이콘의 빨간 배경.
- “많음”, “300”, “수백만”, “무한” — 구체적 또는 추상적 수치를 가진 다중성 미니 픽토그램.
- “강함”, “위험함”, “강력함”, “레벨 3” — 값 표시가 있는 별도의 레벨 미니 픽토그램.
- 프레임 색상은 엔티티가 다른 플레이어나 팩션에 속하는지를 나타낼 수 있습니다.
자주 쓰이는 속성이나 감정 톤을 전달하기 위해 추가 픽토그램, 애니메이션, 글로우 등 시각 요소를 메인 아이콘에 더할 수 있습니다. 더 복잡하거나 드문 특성은 보조 아이콘으로 메인 엔티티 옆에 배치하거나 더 작은 크기로 삽입합니다.
아이콘은 애니메이션으로도 표현할 수 있어 정보의 추가 층을 제공합니다. 예를 들어 체력이 매우 낮을 때 아이콘의 하트가 불규칙하고 약하게 뛰면 위험 상태를 나타냅니다.
언어는 캐릭터의 제한된 지식도 반영합니다. 아바타가 다른 문화의 인물을 만나 그들의 언어를 이해하지 못하면, 아이콘이 왜곡되거나 읽을 수 없는 기호로 변할 수 있습니다. 정보가 부분적으로만 알려진 경우 해당 요소는 숨겨집니다: 플레이어는 적의 유형은 알지만 수는 모를 수 있습니다.
같은 엔티티도 문화에 따라 다르게 보일 수 있습니다. 고대 이집트인은 상형문자를, 로봇형 존재는 기술적·디지털 상징을 보게 됩니다.
플레이어가 행동을 수행하면 세계의 객체와 상호작용합니다. 직접 시뮬레이션에서는 물리적인 1인칭 행동이 되고, 추상 모드에서는 조건부 아이콘을 선택합니다. 행동 자체는 기본 언어 구문으로 형성됩니다.
게임 언어의 핵심은 의미적 트리플: 주어 - 행동 - 목적어입니다.
예시:
- “나 - 원하다 - 사과”
- “우리 - 당신에게 전쟁을 선포하다”
- “우리 - 하얀 깃털 부족을 공격하다”
인터페이스에서는 주체(플레이어 아바타 또는 다른 엔티티)를 선택하고, 객체를 선택한 뒤, 행동을 지정하는 방식으로 보입니다.
구문은 시간, 형용사, 조건 같은 수식어를 추가해 복잡하게 만들 수 있습니다. 예: “노예(주어) - 건설하다(술어) - 피라미드(목적어) - 빠르게(술어 수식어)”. “빠르게”라는 수식어는 특별한 규칙이 적용됨을 의미합니다: 작업은 더 빨리 수행되지만 사고 위험이 증가하거나 결과 품질이 떨어집니다.
행동이 아바타 자신이 아니라 다른 주체를 대상으로 한다면, 이는 요청이나 명령으로 해석됩니다.
4. 로드맵

4.1. 전략적 비전
이 섹션은 Nexus 프로젝트를 구현하기 위한 계획을 설명합니다.
단일 프로젝트를 개발한 뒤 얼리 액세스를 진행하는 접근은 이 경우 적합하지 않습니다. 더 적절한 접근은 단계별로 일련의 프로젝트를 개발하는 것으로, 각각이 개별 아이디어와 방향을 구현하고 검증하며 Nexus의 최종 비전에 다가가게 합니다. 각 단계 프로젝트는 피드백과 비판을 통해 프로젝트가 초기 개념과 일치하는지, 선택한 방향이 올바른지 평가할 수 있게 해 줍니다. 시간이 흐르면서 이러한 프로젝트는 더 복잡하고 고품질이 되며, 그중 하나는 결국 2장에서 설명한 완전한 Nexus 프로젝트로 성장할 수 있습니다.
Nexus의 개발은 여러 단계 프로젝트로 나뉩니다. 현재에 가까운 단계는 목표와 과제가 더 명확하고 구체적으로 정의됩니다. 더 먼 단계는 구체적 세부화 없이 일반적인 방향과 아이디어 수준에서 설명됩니다. 단계의 순서는 엄격히 고정되지 않습니다. 로드맵은 프로젝트의 전반적 방향을 제시할 뿐, 상세한 계획이 아닙니다. 개발이 진행됨에 따라 단계와 과제는 정리 및 보완될 수 있습니다.
4.2. 단계
4.2.1. 단계 0. 보편적 게임 이해 형성(완료)
2013년부터 Clarus Victoria가 수행해 온 작업, 여섯 개 프로젝트 출시, 그리고 수년간의 연구, 실험, 프로토타입 제작을 통해 보편적 게임이 무엇인지와 그 기반 원리가 무엇인지에 대한 기본 이해가 형성되었습니다. 이 단계의 결과가 바로 이 문서입니다.
4.2.2. 단계 1. ECS 및 엔티티 통합(완료)
- Next Run 프로젝트를 통해 ECS 아키텍처를 검증했습니다. 엔티티는 컴포넌트 집합을 가진 빈 컨테이너로 표현되며, 이를 통해 아이템, 생물, 생물군계, 이벤트, 효과 같은 세계 객체를 유연하게 구성할 수 있습니다.
- RPG와 전략의 결합 등 보편적 게임 메커닉과 관련된 여러 아이디어를 검증했습니다.
- 스튜디오 최초로 헥사곤 맵이 구현·테스트되어 다양한 유형의 게임 세계를 빠르게 만들고 조합할 수 있게 되었습니다.
- 스튜디오 최초로 Steam Workshop을 통한 모드 지원이 추가되었습니다.
이 단계에 대한 자세한 내용은 다음 글에서 확인할 수 있습니다: https://clarusvictoria.com/blog/almost-ten-years-of-search
4.2.3. 단계 2. 현실 세계 게임플레이(개발 중)
Next Run 프로젝트는 많은 보편적 게임 아이디어를 시험했지만, 조건부 세계 법칙을 가진 판타지 설정에 한정되어 있습니다. 2단계에서는 자연 및 사회적 패턴을 가진 현실 세계의 모델링으로 전환할 예정입니다. 이 단계의 목표는 현실 세계의 논리와 자연·사회적 패턴에 기반한 현실적인 게임플레이 토대를 구축하는 것입니다.
구현할 특징:
- 사회의 진화: 동물과 함께 살며 같은 생존 규칙을 따르던 원시 인간에서 최초의 문명이 나타나기까지.
- 타일 생태계와 생물군계: 굶주림, 이동, 자원 경쟁. 식물, 동물, 지형이 인간의 생존에 직접적인 영향을 줍니다.
- 미리 정의된 스크립트가 아니라 게임 규칙의 결과로 발생하는 상황과 이벤트. 예: 자원 부족이 집단 간 충돌이나 포식자 공격을 유발.
- 유닛 행동 자동화 또는 수동 제어 — 플레이어의 선택. 공통 행동 규칙을 통한 그룹 제어 포함. 적극적인 플레이와 관찰 모두 가능.
- 개별 캐릭터 또는 그룹으로 플레이 가능.
- 한 지도에서 여러 플레이어가 경쟁.
- 이전 Clarus Victoria 게임에서 익숙한 기술 트리의 복귀.
- 설정 가능한 게임 세계: 지도 크기, 시대, 기후, 지역 특성.
- 에이전트 모델의 초기 버전.
- 가능한 세계 배경: 석기 시대와 청동기 시대.
4.2.4. 단계 3. 의미 기반 아키텍처(계획)
Nexus 프로젝트의 위험을 줄이기 위한 핵심 단계 중 하나는 게임 아키텍처의 의미 기반으로 전환하는 것입니다(3.3–3.5절 참조).
이 단계에서는 모든 시스템이 기본 수준에서 최소 기능으로 도입됩니다:
- 게임 세계 엔티티를 설명하는 방식으로서의 의미 트리플.
- 인터프리터.
- 고전 ECS에서 의미 ECS로의 전환.
- 새로운 아키텍처의 기본 규칙.
- 가능한 세계 배경: 초기 문명 중 하나.
게임플레이 메커닉 관점에서는 이 단계에서 새로운 복잡성이 도입되지 않을 것으로 예상됩니다. 주요 과제는 이미 검증된 해결책과 메커닉을 새로운 아키텍처 기반으로 옮기는 것입니다.
4.2.5. 단계 4. 에이전트 모델(계획)
이 단계에서는 2단계에 도입하기엔 위험하다고 판단되는 중요한 시스템을 구현할 것으로 예상됩니다. 이는 에이전트 모델에서 주체를 깊이 있게 다루는 것을 의미합니다. 2단계가 기반을 마련하면, 4단계에서 에이전트가 완전히 구현됩니다. 게임 아키텍처는 더 복잡한 현실 세계 과정을 지원하기 시작하여, 2단계보다 높은 복잡도의 사회를 모델링할 수 있게 됩니다.
구현할 특징:
- 완전한 에이전트 행동 모델: 엔티티가 목표, 상태, 동기를 가짐.
- 실행 보장이 없고 현재 상태와 맥락에 따라 달라지는 요청·명령 시스템.
- 세계의 풍부함 증가, 더 복잡한 시스템과 객체 로직.
- 주체별 개별 인벤토리, 물류 체인, 운송 시스템.
- 플레이어가 복잡한 모드를 만들 수 있도록 게임 로직의 일부를 Lua로 옮김.
- 가능한 세계 배경: 고대 세계.
4.2.6. 단계 5. 추상화와 LOD(계획)
의미 아키텍처와 복잡해지는 게임 세계는 플레이어 장치의 계산 요구를 높입니다. 이 단계에서는 플레이어의 활동 범위 밖에 있는 엔티티를 활성 시뮬레이션에서 제외하기 위한 추상 규칙이 도입될 것으로 예상됩니다(3.7 항목 참조). 이는 게임 세계를 부하 증가 없이 훨씬 더 복잡하게 만들고, 저사양 및 모바일 기기에서도 실행할 수 있게 합니다. 단계 구현 순서는 개발 과정에서 조정될 수 있습니다.
4.2.7. 단계 6+. Nexus 엔진 핵심 기능(계획)
1–5단계는 Nexus의 기본 기능을 구성합니다. 6단계 이후 개발은 엔진 확장, 스케일링 기능, 세부 요소 및 2·3절에 설명된 콘텐츠 추가로 이동합니다.
이 단계에서 다음 영역을 개발·구현할 예정입니다:
- 시간과 공간 스케일링, 디테일 수준과 추상화.
- 네트워크 플레이.
- 게임 시나리오 및 구성 생성.
- 1인칭부터 글로벌 규모까지 다양한 시각화 모드 지원.
- 플레이 스타일과 몰입 수준에 따른 적응형 인터페이스와 사운드.
- 2·3절에 설명된 추가 기능.
4.2.8. Nexus 1.0(계획)
Nexus 1.0의 출시 시점은 2·3절에 설명된 핵심 아이디어와 기능의 기본 구현을 달성했는지에 의해 결정됩니다.
5. 도전 과제
5.1. 높은 계산 복잡성
도전: 많은 트리플을 포함한 의미 아키텍처는 실시간 실행에 너무 무겁고, 사용 가능한 하드웨어에서 스케일링되지 않을 수 있습니다.
해결: 이는 추상화 규칙과 LOD로 해결됩니다. 플레이어가 어느 정도 상호작용하는 엔티티만 계산됩니다. 자세한 내용은 3.7항을 참조하세요. 세계의 의미적 표현이 모든 게임 질의를 논리 추론으로 처리한다는 뜻은 아닙니다. 자주 쓰이는 연산에는 직접 데이터 구조와 캐시된 결과가 사용됩니다.
5.2. 흐릿한 게임플레이 초점
도전: Nexus의 보편성은 플레이어가 무엇을 하고 있는지 결정해야 하는 상황을 만들며, 명확한 게임플레이 초점과 목적감이 사라질 수 있습니다. 무엇이든 가능하지만 왜 하는지 불분명할 수 있습니다.
해결: Nexus는 고정된 목표를 요구하지 않습니다. 방향은 시나리오나 세계의 논리, 플레이어의 역할에 의해 형성됩니다. 보편성은 구조의 부재를 의미하지 않습니다 — 세계 자체가 규모를 제한합니다. 플레이어는 자신의 역할에 맞는 수준의 제어와 정보만 받습니다. 예를 들어 플레이어가 통치자라면 수천 개 마을을 직접 관리할 필요가 없습니다 — 보좌관과 장관이 그 일을 합니다.
5.3. 미완성 프로젝트의 위험
도전: Nexus의 규모와 복잡성 때문에 프로젝트가 오랫동안 개발에 머물며 명확히 고정된 완성 상태에 도달하지 못할 가능성이 있습니다. 외부에서는 AAA급 프로젝트처럼 보이고, 막대한 자금과 대규모 팀이 필요하다고 인식될 수 있습니다.
해결: Nexus는 연속적 단계와 정기적 출시, 구체적 결과를 통해 하나의 제품으로 발전합니다. 각 단계는 프로젝트를 1.0에 더 가깝게 만듭니다. 개발은 “긴 프로토타입”이 아니라, 완료된 중간 버전과 검증 가능한 결과를 갖춘 지속적 진전입니다. 성공 기준과 플레이어 피드백은 프로젝트를 의도된 방향으로 유지하는 데 도움이 됩니다.
5.4. 디버깅과 로직 제어의 어려움
도전: 의미 아키텍처와 인터프리터는 논리 연쇄와 추론을 디버깅하는 복잡도를 높여 개발, 밸런싱, 세계 동작 제어를 어렵게 만들 수 있습니다.
해결: 의미 논리를 디버깅하는 어려움은 아키텍처의 부수 효과가 아니라 본질적인 부분으로 간주됩니다. Nexus에서는 인과 연쇄, 추론 출처, 상태에 대한 제어가 기본 요구사항으로 내장되어 있습니다. 설명 가능성과 관찰 가능성이 없으면 이러한 세계 모델은 관리할 수 없기 때문입니다.
5.5. 초기 초점 부재의 위험
도전: 초기 단계에서 Nexus 개념이 너무 넓어 명확한 MVP를 만들기 어렵고, 특정 타깃 대상에 대한 관심을 테스트하기도 어렵습니다. 이는 게임 가치 검증 이전에 아키텍처에 자원을 투자할 위험을 높입니다.
해결: Clarus Victoria는 10년 넘게 다져 온 틈새와 독자층이 있습니다. 별도의 추상적 MVP 대신, 명확하고 익숙한 게임플레이를 가진 독립 프로젝트를 활용합니다. 새로운 프로젝트마다 이 게임플레이가 점차 확장되고 복잡해지며 Nexus 1.0으로 다가갑니다. 성공 기준은 플레이어 피드백과 결과가 개발 방향에 부합하는지 여부입니다.
문서 마지막 업데이트: 18.01.2026
