AI가 생성한 게임을 계속 개발할 수 있을까요?

브라우저에서 열리는 게임이라고 해서 반드시 계속 개발할 수 있는 프로젝트인 것은 아닙니다. 다음으로 확인할 질문은 다른 사람이 게임을 재현하고 규칙을 설명하며 기존 라운드를 망가뜨리지 않고 기능 하나를 추가할 수 있는가입니다. 스크린샷이나 코드를 편집할 수 있다는 설명 대신, 보존한 기준 버전과 범위를 좁게 지정한 확장으로 이를 테스트하세요. 이 글은 작은 별 수집 게임을 위한 재현 가능한 개발 지속성 테스트를 제시합니다. 실습을 완료한 보고서는 아닙니다. 이 초안에는 원본 프로젝트, 기준 버전 실행 결과, 확장 패치가 제공되지 않았습니다. 따라서 실제 결과에 관한 요건은 아직 충족되지 않았습니다. 이 절차로 부족한 증거를 수집하세요. 수용 기준을 SEELE 또는 생성된 프로젝트에 대한 검증 결과로 해석해서는 안 됩니다.

1. 프로젝트와 원래 규칙 정하기

범위가 정해진 테스트 조건 하나를 사용합니다. 데스크톱 브라우저 게임에서 방향키로 움직이고, 수집 가능한 별 다섯 개를 30초 안에 모두 모으면 승리하며, 시간이 끝나면 패배하고, 깔끔하게 다시 시작할 수 있어야 합니다. 이는 계획된 테스트 조건이지 기존 빌드가 아닙니다. 실제로 편집할 수 있는 프로젝트와 에셋, 의존성 정의, 시작 방법을 확보하세요. 표시되는 경우 생성기나 도구 버전을 기록하고, 프로젝트 리비전, 실행 환경, 브라우저, 운영체제도 기록합니다.

소스 파일과 호스팅된 미리보기 또는 컴파일된 번들을 구분하세요. 에셋 누락, 문서화되지 않은 의존성, 소스를 인계받을 수 없는 상황은 조용히 메울 빈틈이 아니라 기록할 발견 사항입니다. 제공된 프로젝트가 테스트 조건과 다르면, 비슷하게 범위가 제한된 확장을 선택하기 전에 기존 규칙을 문서화하세요. 나중의 변경이 원래 증거를 지우지 않도록 손대지 않은 복사본과 별도의 작업용 복사본을 보존합니다.

2. 수정하기 전에 기준 버전 재현하기

깨끗한 디렉터리에서 제공된 설정 지침을 따릅니다. 정확한 명령어, 설치 출력, 시작 로그, 브라우저 콘솔을 저장하세요. 익숙한 프레임워크와 비슷하다는 이유로 명령어를 만들어 내면 안 됩니다. 설정에 실패하면 오류를 보존하고 수행한 조치는 별도로 기록합니다. 평가자가 수정한 기준 버전은 수정된 기준 버전이지, 제공된 프로젝트가 조건 없이 성공했다는 뜻이 아닙니다.

네 가지 시나리오를 실행합니다. 별 하나를 수집하고 그 자리에 머무르기, 다섯 개를 모두 수집하기, 시간이 끝날 때까지 기다리기, 각 종료 후 다시 시작하기입니다. 별 하나가 한 번만 집계되는지, 종료 후 움직임이 멈추는지, 모든 라운드 상태가 복원되는지 확인하세요. 각 시나리오의 행동, 예상 결과, 관찰 결과, 리비전을 적습니다. 성공한 실행만큼 실패도 꼼꼼히 보존하세요.

3. 변경할 규칙 추적하기

이동, 접촉 감지, 수집 상태, 표시된 수치, 승리 판정을 연결하는 실제 코드나 편집 가능한 로직을 찾습니다. 메모에는 실제 파일명이나 이벤트 식별자를 사용하세요. 타이머를 누가 관리하고 어떤 초기화 동작이 타이머를 복원하는지 설명합니다. AI의 그럴듯한 설명만으로는 부족합니다. 프로젝트와 대조해 확인하세요.

중복된 카운터나 서로 무관한 시스템에 흩어진 초기화 로직을 찾습니다. 이는 검토할 질문이지 나쁜 아키텍처의 자동적인 증거는 아닙니다. 실질적인 목표는 보너스 아이템을 어디에 넣을지, 기존 동작 중 무엇을 그대로 유지해야 할지 파악하는 것입니다. 패치를 요청하기 전에 불확실한 부분을 기록하세요.

4. 같은 프로젝트에 파란 보너스 별 하나 추가하기

기준 리비전을 저장한 다음 이 한 가지 변경을 요청합니다. 이 예시는 타이머에 주는 새 효과와 기존 수집 카운트를 의도적으로 분리합니다.

이 기존 게임에 파란 보너스 별 하나를 추가해 주세요. 진행 중인 라운드에서 처음 접촉하면 별을 제거하고 남은 시간에 3초를 더합니다. 일반 별 카운터를 늘리거나 별 다섯 개라는 승리 기준을 바꾸면 안 됩니다. 다시 시작하면 보너스 별이 복원됩니다. 끝난 라운드는 되살릴 수 없습니다. 이동, 일반 별, 시간 초과, 원래의 모든 종료 규칙을 유지해 주세요. 가능한 한 작은 패치를 제안하기 전에 실제로 영향을 받는 프로젝트 파일이나 이벤트를 식별하세요. 게임이나 무관한 에셋을 대체하지 마세요.

제안된 변경은 실행하기 전에 검토합니다. 변경된 파일이나 이벤트, 추가된 의존성, 구조 변경을 기록하세요. 무관한 하위 시스템이 바뀌었다면 이유를 물어봅니다. 파란 물체가 있는 새로운 독립 게임은 미리보기가 비슷하더라도 기준 버전을 이어서 개발했다는 증거가 아닙니다. 다른 검토자도 같은 리비전을 살펴볼 수 있도록 패치와 설명을 함께 보관하세요.

5. 기존 동작, 새로운 경계 조건, 롤백 재확인하기

모든 기준 시나리오를 반복합니다. 그런 다음 보너스 별을 한 번 수집하고 이전 위치에 머무르세요. 시간은 한 번만 늘어나고 일반 카운트는 바뀌지 않아야 합니다. 다시 시작해 별을 다시 수집하고 초기화를 확인합니다. 시간 종료 직전과 라운드가 끝난 뒤의 접촉도 확인하세요. 새 아이템이 종료된 라운드를 재개해서는 안 됩니다. 동시 이벤트가 결과에 영향을 줄 수 있다면 프레임 처리 순서에 관한 가정을 기록합니다.

확인이 실패하면 추가 수정을 요청하기 전에 실패한 리비전과 짧은 재현 절차를 저장하세요. 보존한 기준 버전으로 롤백하고 기준 시나리오 하나를 다시 실행합니다. 이 확인을 마친 뒤에야 롤백을 재현했다고 보고할 수 있습니다. 이 글에서는 성공한 패치, 회귀 없는 결과, 수정 소요 시간, 롤백 결과가 확인되지 않았습니다.

SEELE가 제공할 수 있는 것과 확인해야 할 것

SEELE는 장면, 에셋, 게임플레이 코드를 포함하는 자연어 기반 게임 제작 과정을 설명합니다. 따라서 작게 생성한 게임은 이 테스트의 적절한 출발점이 됩니다. 먼저 간단한 게임 요구사항을 입력한 다음 현재 과정이 실제로 무엇을 넘겨주는지 확인하세요. 플레이 가능한 결과물, 편집 가능한 프로젝트, 소스 파일, 기타 산출물은 서로 대체할 수 없습니다.

개발을 이어가는 단계에서는 기존 프로젝트의 맥락과 보너스 별 하나에 관한 요구사항을 제공하세요. 자연어로 수정하면 상태가 올바르게 유지될 것이라고 가정하지 말고 결과 변경 사항을 살펴봅니다. 프로젝트 접근 가능 여부, 엔진 호환성, 내보내기 세부 사항은 실제 계정과 결과물에서 확인해야 합니다. 제품 설명은 해당 과정을 시험해 볼 근거가 되지만, 이 프로젝트의 재현성, 아키텍처 또는 유지보수성을 입증하지는 않습니다.

실제 결론에 필요한 증거

• 원본 소스 또는 편집 가능한 프로젝트 아카이브, 필요한 에셋, 안정적인 기준 리비전.
• 실제 설정 지침, 환경 세부 사항, 명령어 출력, 시작 오류 또는 수정 사항.
• 기준 시나리오 기록과 승리, 패배, 재시작을 보여 주는 중단 없는 실행 증거.
• 실제 코드나 이벤트에 근거한 설명, 정확한 확장 요청과 검토 가능한 패치.
• 변경 전후 리비전, 회귀 및 경계 조건 확인 결과, 재현된 롤백.
• 해결되지 않은 실패를 포함하여 이 프로젝트와 이 확장에 한정된 결론.

결과를 뒷받침할 이 모든 산출물은 현재 없습니다. 보너스 별 변경이 성공하면 제한적인 개발 지속성 주장은 뒷받침할 수 있지만, 네트워크 기능, 저장 데이터 마이그레이션, 프로덕션 규모의 개발을 보장하는 것은 아닙니다. 불완전한 인계는 “AI 코드는 편집할 수 있다”는 일반적인 결론으로 대체하지 말고 보고서에 드러내야 합니다.

결론: 다음 변경의 증거부터 수집하기

검토와 회귀 검사를 통과하는 변경을 통해 개발 지속성을 판단하세요. 재현 가능한 프로젝트 자료로 시작하고, 원래 규칙을 보존하며, 예상하지 못한 수정이 눈에 띌 만큼 확장 범위를 작게 유지합니다. 이 초안은 방법을 제시할 뿐 빠진 결과를 제공하지 않습니다. 프로젝트, 패치, 실행 증거가 나올 때까지 실습에 근거한 유지보수성 판단은 불가능합니다. 다음 단계로 SEELE에서 작은 별 수집 게임 요구사항을 사용하고, 보너스 별을 요청하기 전에 실제 인계물을 보존하세요. 소스가 없거나 설정에 실패하면 중단하고 장애를 기록하며, 완성도 높은 미리보기를 개발 지속 가능성의 증거로 삼지 마세요.

자주 묻는 질문

호스팅된 미리보기로 게임의 유지보수성을 증명할 수 있나요?

아니요. 호스팅된 미리보기는 관찰 가능한 게임플레이를 보여 줄 수 있지만 소스의 완전성, 재현 가능한 설정, 코드 변경의 결과를 입증하지는 못합니다. 기록의 한 부분으로 활용하세요. 개발 지속성에 관한 주장을 하려면 편집 가능한 자료, 보존한 기준 버전, 검토 가능한 변경, 의도한 실행 환경에서의 회귀 검사도 필요합니다.

이 테스트를 하려면 프로그래머가 필요한가요?

프로그래머가 아니어도 플레이어에게 보이는 시나리오는 기록할 수 있지만, 소스와 의존성을 신뢰할 수 있게 검토하려면 프로젝트 언어나 편집기에 익숙한 사람이 필요합니다. 이 역할을 분리하세요. 자신감 있는 AI 설명이나 작동하는 첫 화면을 아키텍처 검토로 여기지 말고, 자격을 갖춘 검토자에게 실제 변경을 확인받으세요.

확장은 작동하지만 설정이 여전히 문서화되지 않았다면 어떻게 하나요?

완전한 인계가 아니라 부분적인 성공으로 보고하세요. 이미 설정된 환경에서 확장이 작동하더라도 새 개발자는 여전히 재현하지 못할 수 있습니다. 성공한 리비전을 보존하고 실제 사용한 설정 단계를 적은 다음, 제공된 자료부터 그 단계를 반복해 본 후에 프로젝트를 독립적으로 재현할 수 있다고 설명하세요.