빌드 및 런타임 아키텍처가 구체화됩니다.

"틀을 그릴 수 있다"에서 "건축물이 형태를 잡는다"로

첫날에 "브라우저에서 픽셀을 올바르게 그릴 수 있습니까?"라고 대답했다면 오늘은 다음 질문인 그림의 출처에 대한 대답입니다. 게임에서 실제로 움직이는 것은 ECS(Entity–Component–System)라는 세계 모델입니다. 모든 캐릭터, 소품 및 카메라는 "엔티티"이며 위치, 모양 및 동작은 "컴포넌트"와 "시스템"에 의해 결정됩니다. 렌더링은 있지만 월드 모델이 없는 경우 엔진은 단지 그리기 도구일 뿐입니다. 월드 모델은 있지만 렌더링이 없으면 월드는 보이지 않는 상태로 유지됩니다. 오늘의 관통 라인은 이 두 부분을 연결하고 전체적인 빌드 및 런타임 아키텍처, 프런트엔드 셸 및 여러 기본 에이전트 기능을 지원하는 것입니다. 따라서 "대화를 통해 게임 생성" 체인의 모든 링크가 형성되기 시작합니다.

ECS⇔렌더 브릿지: 세상과 화면을 연결

이날 가장 중요한 단계는 ECS 세계와 렌더러를 연결하는 첫 번째 작업 버전을 제작하는 것이었습니다. 이것이 해결하는 것은 단순해 보이지만 근본적으로 근본적입니다. 세상에는 위치, 방향, 메시, 재질과 같은 구성 요소를 운반하는 "엔티티"가 있습니다. 렌더러는 화면의 어느 위치와 어떤 형태로 그릴지 어떻게 알 수 있습니까? 브리지는 변환 채널입니다. 각 프레임은 월드 모델의 상태를 렌더러가 이해하는 그리기 명령으로 변환합니다. 이를 통해 움직이는 물체를 세계에 배치하면 그림 코드를 직접 작성하지 않고도 화면에 실제로 나타나고 움직일 수 있습니다. 이는 엔진이 "관련되지 않은 두 개의 하위 시스템"에서 "회전하는 하나의 전체"로 전환되는 전환점입니다. 나중에 "물체를 놓으면 화면에 나타납니다"라는 경험은 모두 오늘 연결된 다리로 거슬러 올라갑니다.

이중 구현 벤치마크: 성능 척도

엔진의 중요한 경로에는 무언가를 구현하는 두 가지 이상의 방법이 있는 경우가 많으며, 각 방법에는 고유한 속도와 장단점이 있습니다. 오늘은 "이중 구현 벤치마크" 조사를 구축했습니다. 동일한 작업을 두 가지 다른 방식으로 수행하고 실제 비용을 나란히 측정하는 것입니다. 가치는 어느 쪽이 단일 경주에서 승리했는지가 아니지만 그 성능은 더 이상 추측에 의존하지 않습니다. "이런 식으로 작성하는 것이 더 빠를 수 있다"는 직감은 동일한 척도를 사용하여 그 자리에서 측정할 수 있으므로 실제로 더 느린 영리해 보이는 결정을 피할 수 있습니다. 장기적으로 발전하고 모든 종류의 장치에서 실행되도록 설계된 엔진의 경우 "객관적으로 성능을 비교하는 방법"을 먼저 설정하는 것은 모든 향후 최적화에 심판을 할당하는 것과 같으므로 빠르거나 느린 것은 그 뒤에 증거가 있습니다.

Studio 프런트엔드 쉘이 탄생했습니다.

이날 획기적인 일도 일어났습니다. Studio 프런트엔드 셸이 처음으로 대략적인 형태를 갖추게 된 것입니다. 그때까지 모든 기능은 엔진과 명령줄 측에 있었습니다. 그러나 최종 사용자가 실제로 직면하는 것은 그들이 열고, 채팅하고, 오른쪽에 있는 사진을 볼 수 있는 웹 인터페이스입니다. 이날 세워진 초기 쉘은 앞으로 나올 채팅 패널, 미리보기 창, 다양한 작업대를 위한 '골격적인 시작점'이다. 아직은 아무것도 없지만, 제품이 '능력의 더미'에서 '사용 가능한 형태'로 수렴되기 시작한다는 것이 의미가 있습니다. 한쪽에는 더욱 견고한 엔진 기반이 있고 다른 한쪽에는 모양이 갖춰지기 시작하는 인터페이스가 있습니다. 앞으로 몇 주에 걸쳐 두 개가 Studio에 도킹됩니다.

에이전트는 명령 시스템을 확장합니다: 초안 + /컨텍스트

채팅 에이전트는 이날 "일반 대화에서 명령으로" 한 단계 나아갔습니다. 명령 시스템에 대한 설계 초안이 도착했고, /context 명령에 대한 사양이 먼저 고정되었습니다. 명령 시스템은 "AI와의 협업"에 예측 가능하고 재사용 가능한 단축키 세트를 제공합니다. 매번 우회적인 문장으로 빈번한 작업을 설명하는 대신 하나의 명령이 이를 정확하게 트리거합니다. 지정되는 첫 번째 명령인 /context는 긴 세션에서 가장 중요한 것, 즉 "현재 모델이 어떤 컨텍스트를 보유하고 있는지"를 정확하게 설명합니다. 명령 시스템의 형태와 첫 번째 명령을 먼저 설정한다는 것은 이후의 명령이 각각 고유한 방식으로 작성되어 충돌하는 대신 동일한 표준에서 성장할 수 있음을 의미합니다.

더욱 스마트해진 자동 압축: 도구별, 유휴 간격별

AI를 오랫동안 사용하면 축적된 컨텍스트가 더욱 길어져 대응 속도가 느려지고 비용이 증가합니다. 그러나 조잡한 압축은 유용한 정보를 버립니다. 오늘은 컨텍스트 압축에 두 가지 영리함을 추가했습니다. 하나는 "도구별로" 처리합니다. 다양한 도구의 결과는 다르게 중요하므로 일률적으로 적용하는 대신 도구별로 무엇을 다듬고 무엇을 유지할지 결정할 수 있습니다. 둘째, "유휴 간격으로" 트리거합니다. 결과를 기다리지 않을 때 창에서 압축을 수행하여 빠른 응답을 가장 원할 때가 아닌 눈치 채지 못할 순간에 비용을 숨깁니다. 함께 사용하면 방해를 최소화하면서 긴 세션을 계속 줄일 수 있습니다. "모델 컨텍스트를 관리하는 방법"에 대한 신중한 설명은 이 플랫폼이 처음부터 사물을 실제 엔지니어링으로 처리하는 부분입니다.

도구 및 터미널의 견고성: 가져오기, 키, 이벤트 버스

이날은 일상적인 사용이 옆으로 흘러가는 경향을 줄여주는 일련의 세부 사항도 정리했습니다. 웹 가져오기 도구의 두 모드 모두 더욱 안정적입니다. 딥 모드의 오류 메시지는 더 구체적이고 진단하기 쉬운 반면, 직접 모드는 자체적으로 추가 구성 요소를 설치하는 것이 금지되어 동작을 더 쉽게 제어할 수 있습니다. 터미널의 커서 이동(줄 시작/끝)이 더 명확한 키 라우팅으로 이동되어 초점과 키 입력이 더 정확하게 정렬됩니다. 이벤트 버스는 관찰자의 오류로 인해 눈덩이처럼 불어나는 새로운 오류가 발생하는 자체 증폭 루프를 수정했습니다. 이러한 문제가 발생하면 로그가 즉시 폭발하므로 소스에서 이를 차단하는 것이 중요합니다. 이들 중 어느 것도 화려한 새 기능이 아닙니다. 그것은 "사용하는데 거친 느낌이 들지 않는다"를 조금씩 조각하는 작업입니다.

더욱 쉬워진 설치 및 시작

목표는 "몇 분 안에 로컬에서 실행"이므로 설치 및 시작 경로가 울퉁불퉁할 수 없습니다. 오늘은 시작 흐름을 모듈로 재구성하고, 최신 패키지 관리자 버전과 호환되게 만들고, "런타임이 없을 때 대체 수단으로 자동 설치"를 추가하고, 정리 스크립트를 동일한 규칙에 맞춰 정렬했습니다. 비전문 개발자를 포함하여 더 많은 사람들이 시작하기를 원하는 플랫폼의 경우 "복제에서 사진 보기까지"의 경로가 더 원활할수록 기준이 낮아집니다. 해당 도로를 일찍 포장하면 나중에 잠재적으로 불쾌한 일련의 번거로움을 시도하려는 모든 사람을 구할 수 있습니다.