ForgeAX는AI 기반 개인 게임 스튜디오. 우리는 게임 제작의 장벽이 AI에 의해 재정의되고 있다고 믿습니다.
우리의 비전은 직접적입니다:더 작은 팀이 AI를 사용하여 훨씬 더 큰 규모의 게임이 필요했던 게임을 만들 수 있습니다.제작자를 대체하는 것이 아니라 '아이디어'와 '플레이 가능한 게임' 사이의 무거운 엔지니어링과 제작을 AI에 넘기는 것입니다.
우리가 있는 곳
현재 단계는AI를 통해 아이디어를 플레이 가능한 게임으로 전환: PBR 렌더링, 물리 및 골격 애니메이션을 다루는 엔진을 사용하여 이미 스튜디오에서 플레이 가능한 FPS, ARPG, 서바이벌 및 슈팅 게임 데모를 만들 수 있습니다. 우리는 배송 가능한 품질을 향해 이 단계를 계속 다듬어 나갈 것입니다.
오픈 소스
ForgeAX 도구 계층은 다음과 같이 라이센스가 부여됩니다.아파치 라이센스 2.0— 누구나 자유롭게 포크하고, 사용하고, 상업적으로 빌드하고, 재배포할 수 있습니다. 우리는 이것이 커뮤니티가 함께 구축할 수 있는 공개 프로젝트가 되기를 바랍니다. 참조라이센스 페이지.
소규모 팀이 더 큰 게임을 만들 수 있도록 하세요.
스튜디오에서는 채팅을 통해, 비주얼 편집기에서 직접 작업하고 (나중에) 이미지 및 비디오와 같은 입력을 사용하여 Forge라는 AI 리드에게 원하는 게임을 설명합니다. 계획을 세우고 필요할 때 전문 하위 에이전트(게임 플레이, 디자인, 아트…)를 데려온 다음엔진 코드 자체를 작성합니다., 결과를 라이브 브라우저 미리보기로 핫 리로드합니다.
그 아래에는 두 개의 사내 재단이 있습니다.AI의 관점에 맞게 재설계된 엔진(AI가 읽고 쓰고 오류를 이해할 수 있도록)AI를 정확하고 검증 가능한 결과로 유지하는 개발 루프(요구사항 입력, 재생 가능한 출력 출력, 모든 단계 관찰 및 추적 가능)
7단계 루프
엔진 내부의 모든 기능은 동일한 파이프라인(요구 사항 입력, 작업 결과 출력, 각 단계에서 읽을 수 있는 기록)을 거칩니다.
- 요구사항 — 승인 기준과 함께 무엇을 빌드할지 명시합니다.
- 연구 — 설문조사 기록, 제약 조건 및 옵션.
- 계획 — 전략을 설정하고 이를 작업별로 세분화합니다.
- 구현 — 코드를 작성하고 테스트합니다.
- 검증 — 독립적인 점검; 빨간색은 병합을 차단합니다.
- 판단 — 인간이 최종 결정을 내립니다.
- 완료 — 통과하면 병합합니다.
오케스트레이터 및 하위 에이전트
"오케스트레이터"는 상태 시스템을 구동하여 각 단계에서 파견할 하위 에이전트를 결정하고 해당 출력을 확인합니다. 하위 에이전트는 자체 컨텍스트에 따라 역할이 전문화됩니다. 인간은 요구사항 명시와 결과 검토라는 두 가지 지점에서만 판단을 주입합니다.
"괜찮아 보이는데"가 빠져나가는 일이 없습니다.
검증에는 두 개의 AI 게이트가 있습니다. 하나는 AI 사용자의 관점에서 문서와 API를 정적으로 스캔하여 "약속되었지만 구현되지 않음"을 포착합니다. 다른 하나는 실제로 격리된 샌드박스에서 데모를 실행하고 스크린샷을 캡처한 후 다시 확인하여 "녹색 테스트, 검은 화면 테스트"를 방지합니다.
시간이 지나면서 점점 안정되죠
각 기능 이후에 발생하는 마찰은 파이프라인 자체를 업그레이드하는 피드백으로 캡처됩니다. 다음 기능은 향상된 버전을 자동으로 사용합니다. 즉, 파이프라인이 자체 출력을 제공하고 더욱 스마트해집니다.
결과: AI는 "데모급" 코드가 아닌 인간이 대신할 수 있는 검증되고 재생 가능한 기능을 생성합니다.
대부분의 게임 엔진 API는 인간을 위해 작성되었습니다. AI가 코드를 작성하는 사람이 되면 엔진은 달라져야 합니다.
ForgeAX의 핵심 아이디어는 간단합니다. 사용자가 게임을 설명하고 AI가 엔진 코드를 작성하는 것입니다. "그저 다른 저자"처럼 들리지만 실제로 기존 엔진은 AI에 우호적이지 않습니다. 독자가 인간처럼 문서를 읽고, 추측하고, 맥락을 채우는 것으로 가정합니다.
우리의 입장은 무뚝뚝합니다. AI는 엔진의 첫 번째 사용자입니다. "AI에게 친화적"이 "인간에게 친화적"과 충돌할 때 AI가 승리합니다. 다음은 몇 가지 구체적인 결과입니다.
1 · 하나의 진실 소스, 나머지는 파생
사실은 정확히 한 곳에서 정의됩니다. 다른 모든 것은 그것에서 파생됩니다. 예를 들어 구성 요소 필드는 스키마에 인라인으로 존재합니다. 검사기, 디버거 및 도구는 소스를 파악하고 추측하는 대신 스키마를 읽습니다. AI는 볼 수 있는 곳이 한 곳뿐이기 때문에 곳곳에 흩어져 있는 관례를 "기억"할 필요가 없습니다.
2 · AI가 이해하고 복구할 수 있는 오류
오류는 단순히 '던지는' 인간의 문장이 아닙니다. 우리는 폐쇄형 오류 코드 세트를 사용하며, 각각은 구조화된 "무엇/왜/복구 방법" 정보를 전달합니다. AI에 오류가 발생하면 예외 텍스트를 신비주의로 취급하는 대신 다음에 무엇을 변경해야 할지 알고 있습니다.
3 · '화면을 본다'가 아닌 구조화된 데이터
렌더링 버그의 가장 어려운 부분은 "화면에서 잘못 보인다"는 것입니다. 인간은 모니터를 응시할 수 있습니다. AI는 할 수 없습니다. 따라서 엔진은 그리기 호출, 바인딩, 렌더링 대상, 파이프라인 상태 등의 렌더링 호출 프레임을 캡처하여 N번째 그리기에서 오프라인으로 읽고, 재생하고, 전체 상태를 검사할 수 있습니다. 시각적인 문제는 AI가 '읽을 수 있는' 데이터가 됩니다.
4 · 서로를 확인하는 두 가지 구현
렌더 레이어에는 단일 인터페이스 뒤에 두 개의 백엔드 구현(WebGPU 및 Wasm 구현)이 있습니다. 나란히 렌더링됩니다. AI가 엔진 API를 오용하는 순간 다른 백엔드는 즉시 분기되어 문제를 표면화합니다. 이는 사람의 검토를 기다리는 것보다 훨씬 빠릅니다.
이러한 디자인은 하나의 척도를 공유합니다. 독자(인간 또는 AI)가 머릿속에 담아두어야 하는 개념이 적을수록 좋습니다. API의 자체 일관성이 높고 로컬 색인 생성이 가능할수록 AI가 올바른 작업을 수행하는 빈도가 높아지고 인간이 인계받기가 더 쉬워집니다.
"AI 네이티브"는 슬로건이 아닙니다. "AI의 관점에 맞게 다시 실행"하는 일련의 긴 결정입니다. 우리는 문서와 향후 게시물에서 더 많은 내용을 풀어볼 것입니다.