하나의 요청으로 네 가지 AI 게임 제작 도구를 비교하는 방법

게임 제작 도구는 스크린샷만이 아니라 직접 플레이할 수 있는 게임, 수행할 수 있는 변경, 보관할 수 있는 프로젝트를 기준으로 선택하세요. 공정한 비교는 동일한 작은 제작 요청에서 출발해 외형을 평가하기 전에 플레이어에게 보이는 같은 규칙을 확인합니다. 수작업, 요금제 제한, 실제 내보내기 내용도 기록합니다. 이 제안된 테스트는 기존 비교에서 이름이 언급된 SEELE AI, Rosebud AI, GDevelop, Buildbox 네 도구를 다룹니다. 이 초안에는 통제된 실행이나 내보내기 검사 결과가 없었습니다. 따라서 결과와 추천은 보류 상태입니다. 점수, 관찰된 기능 차이, 승자 모두 없습니다. 아래에서는 이후의 비교가 선택 문제에 정직하게 답할 수 있도록 무엇을 실행하고 보존할지 정의합니다.

공통 제작 요청과 통제 조건

모든 실행에 데스크톱 브라우저, 고정된 화면 영역, 같은 입력 장치를 사용하세요. 도구를 열기 전에 허용할 요금제, 지출 상한, 개입 한도, 중단 조건을 정합니다. 계정 등급, 날짜, 표시되는 도구 버전, 실제 비용을 기록하세요. 한 작업 과정에 시각적 편집이 필요하다면 프롬프트 수가 같아도 노력이 같다고 가정해서는 안 됩니다.

Lantern Delivery라는 한 화면의 2D 탑다운 브라우저 게임을 만들어 주세요. 독창적인 배달원과 단순한 오리지널 배경을 사용합니다. WASD 또는 방향키로 이동합니다. 움직이는 위험 요소 하나를 피하면서 랜턴 다섯 개를 수집합니다. 수집한 개수와 45초 타이머를 표시합니다. 위험 요소에 닿거나 시간이 끝나면 시도가 종료됩니다. 다섯 개를 모두 모으면 승리합니다. 눈에 보이는 설명과 다시 시작 기능을 포함합니다. 게임 전체에서 같은 배달원과 아트 방향을 유지합니다. 라이선스가 있는 캐릭터나 다운로드한 저작권 보호 이미지는 사용하지 마세요.

이는 생성된 결과가 아니라 사양으로 다루세요. 테스트에서는 처음 움직일 때 타이머를 시작하고, 어느 쪽으로 끝나든 입력을 멈추며, 다시 시작할 때 모든 상태를 복원합니다. 인터페이스가 요청을 직접 받을 수 없다면 해당 도구의 고유한 작업 과정으로 어떻게 구현하는지 기록하세요. 한 후보에게 추가 설정을 조용히 허용하거나 더 완성된 템플릿으로 대체하지 마세요.

완성해야 할 네 후보의 기록

SEELE AI: 프롬프트 이후 인계물 확인하기

SEELE는 자연어로 게임 장면, 에셋, 게임플레이 코드를 만드는 과정을 설명합니다. 이 비교에서 중요한 질문은 해당 과정이 지정된 Lantern Delivery 게임 흐름을 만들고 같은 프로젝트에서 통제된 변경을 지원하는지입니다. 이용 가능한 제작 과정에 변경하지 않은 요청을 제공하고, 원래 요청, 응답 기록, 처음 접근한 빌드, 계정 조건을 보관하세요.

제품 소개만으로 소스 접근, 엔진 호환성, 로컬 실행 성공을 추론하지 마세요. 실제 인계물을 살펴보고 형식을 기록합니다. 추가 설명이나 수정이 필요하면 시도 횟수와 내용을 기록하고 보존한 뒤 방패 변경으로 진행하세요. 나중에 유용한 추천을 하려면 관찰된 플레이 가능성, 수정 노력, 재현성을 독자의 필요와 연결해야 합니다. 현재 그런 관찰이 없으므로 이 후보에 점수나 우위를 부여하지 않습니다.

Rosebud AI: 실제 제작 및 수정 경로 기록하기

테스트한 Rosebud AI 계정에서 이용 가능한 작업 과정으로 공통 요청을 실행하세요. 초기 입력 형식, 필요한 설정, 접근 가능한 빌드를 얻기까지 필요한 모든 개입을 기록합니다. 요금제 조건은 최신 공식 문서를 확인하되 문서의 주장과 평가자가 관찰한 내용은 구분하세요. 이 초안은 현재 어떤 기능이나 내보내기 형식이 제공되는지 확정하지 않습니다.

기준 버전을 플레이할 수 있게 되면 동일한 방패 요청을 보내기 전에 보관합니다. 수정이 기존 프로젝트를 바꾸는지, 배달원과 규칙과 맵이 유지되는지 기록하세요. 인계 단계에서는 테스트한 과정이 실제로 제공하는 산출물을 확인하고 호스팅된 링크를 ‘소스 코드’라고 부르지 마세요. 한 계정에서 접근할 수 없다는 것은 해당 요금제의 관찰 결과이지 제품이 그 기능을 전혀 제공하지 않는다는 증거가 아닙니다. 이 글을 위해 Rosebud 생성, 수정, 내보내기를 실행하지 않았습니다.

GDevelop: 에디터 작업을 드러내기

현재 GDevelop 작업 과정을 대화형 생성기의 복사본이라고 가정하지 말고 테스터에게 실제로 제시되는 방식대로 평가하세요. 요청을 구현하는 데 필요한 장면 구성, 이벤트 편집, 에셋 준비, 템플릿 선택을 기록합니다. 보조 제작 기능이 있다면 그 입력과 출력을 수동 작업과 함께 보관하세요. 이 글은 현재의 해당 옵션이나 요금제 조건을 검증하지 않았습니다.

편집 가능한 이벤트 구조는 비주얼 에디터 사용자에게 적절한 인계물일 수 있습니다. 직접 작성한 스크립트 디렉터리와 다르다는 이유만으로 배제해서는 안 됩니다. 반대로 에디터 프로젝트만으로 공유된 브라우저 빌드가 작동한다고 증명할 수도 없습니다. 기준 버전, 통제된 이벤트 또는 프로젝트 변경, 플레이 검사, 실제 내보내기 내용을 각각 기록하세요. 이후 비교는 이 과정의 노력과 결과를 보여 줘야 하며 ‘노코드’라는 명칭만으로 불이익이나 보상을 주어서는 안 됩니다. 여기에는 GDevelop 테스트 결과가 없습니다.

Buildbox: 프로젝트 편집과 게시된 결과 구분하기

테스트한 Buildbox 계정의 실제 작업 과정으로 Lantern Delivery를 구현하고, 필요한 설정과 템플릿에서 유래한 동작을 문서화합니다. 게시나 내보내기 옵션을 설명하기 전에 현재 문서와 계정 조건을 확인하세요. 다른 도구의 프롬프트 인터페이스, 파일 구성, 로컬 실행 지침이 여기에도 적용된다고 가정하지 마세요. 수동 준비를 포함해 평가 가능한 첫 프로젝트 리비전을 보관합니다.

방패 변경에 대해서는 보호를 구현하는 편집 가능한 로직이나 프로젝트 차이와 함께 기준 규칙이 그대로 남았다는 증거를 기록하세요. 실제 제공된 내용에 따라 에디터 프로젝트, 호스팅 빌드, 컴파일된 산출물, 소스 파일 중 무엇을 인계받았는지 정확히 구분합니다. 대상이나 내보내기에 접근할 수 없다면 테스트한 요금제와 관찰된 정확한 제한을 명시하세요. 그러면 이후 독자가 자신의 필요에 따라 작업 과정을 판단할 수 있습니다. 현재 Buildbox 빌드, 수정, 인계물은 하나도 검사되지 않았으며 기능에 대한 결론을 내릴 근거가 없습니다.

같은 플레이, 편집, 인계 검사 수행하기

먼저 설명, 두 가지 이동 방식, 한 번만 수집되는지, 위험 요소와의 접촉, 랜턴 다섯 개로 승리, 시간 초과, 각 종료 후 재시작을 테스트합니다. 새로 불러온 뒤 반복하세요. 각 검사를 통과, 실패, 미검사로 표시하고 빌드 리비전을 첨부합니다. 실패를 포함한 중단 없는 녹화를 보관하세요. 페이지가 응답하거나 장면이 매력적으로 보이는 것만으로 게임 흐름 전체를 검사한 것은 아닙니다.

다음으로 통제된 변경 하나를 적용합니다. 위험 요소와의 접촉을 정확히 한 번 흡수하고 수집 시 사라지는 방패 아이템을 추가합니다. 보호가 활성 상태인지 표시하세요. 배달원 아트, 맵, 컨트롤, 랜턴 수, 타이머, 재시작은 유지합니다. 재시작 전에 두 번째 방패가 나타나지 않도록 명시하세요. 수집, 처음 보호받는 접촉, 다음 보호받지 못하는 접촉, 보호 중 시간 초과, 재시작 시 복원을 테스트합니다. 모든 기준 검사를 다시 실행하세요. 코드, 이벤트 또는 다른 검사 가능한 프로젝트 산출물 등 네이티브 리비전 차이를 저장합니다.

마지막으로 플레이 가능한 링크, 컴파일된 빌드, 편집 가능한 프로젝트, 사람이 읽을 수 있는 소스를 구분합니다. 제공된 내보내기 결과물을 저장하고 살펴보세요. 깨끗한 디렉터리에서 문서화된 도구로 열거나 실행하면서 실제 명령어, 버전, 누락 에셋, 수동 수정 사항을 기록합니다. 다운로드 성공만으로 재현 가능한 프로젝트가 입증되지는 않습니다. 현재 문서를 관찰 결과와 함께 보관하되 테스트를 문서로 대체하지 마세요.

동등한 것끼리 비교하세요. 처음 접근 가능한 결과는 같은 단계의 결과와, 수정된 결과는 수정된 결과와 비교하고 개입 내용을 공개합니다. 초보자는 이해하기 쉬운 반복 작업과 작동하는 게임 흐름을, 개발자는 재현 가능한 소스를, 에디터 사용자는 검사 가능한 이벤트를 중시할 수 있습니다. 산출물이 나온 뒤에만 이런 절충점을 보고하세요. 시간과 크레딧 수치는 결과를 본 후 추정하는 대신 기록된 시작·종료 규칙이 필요합니다. 한 번의 실행은 제한된 사례 비교를 뒷받침할 수 있지만 일반적인 신뢰성 주장을 뒷받침하지는 못합니다.

증거 체크리스트: 완성된 결과 칸은 없습니다

• 후보별 계정 등급, 테스트 날짜, 표시 버전, 브라우저, 예산, 실제 개입 기록.
• 원래 요청, 기준 프로젝트 또는 빌드, 전체 승인 검사 녹화.
• 정확한 방패 요청, 변경 전후 리비전, 검사 가능한 변경, 회귀 관찰 결과.
• 실제 내보내기 또는 인계 산출물, 깨끗한 환경의 설정 기록, 관찰된 실행 결과.
• 요금제 또는 형식에 관한 모든 설명을 뒷받침하는 현재 공식 문서.
• 이 검사 이후에만 작성하는 도구별 발견 사항과 조건부 추천.

이 글에서 네 후보의 실행은 모두 아직 이루어지지 않았습니다. 체크리스트는 결과표가 아니라 수집 계획입니다. 보고할 수 있는 테스트된 순위, 가장 빠른 도구, 가장 저렴하게 완성된 게임 또는 검증된 내보내기 승자는 없습니다.

결론: 증거가 나올 때까지 추천 보류하기

유용한 비교는 어떤 도구가 가장 완벽해 보이는지가 아니라 테스트한 작업 과정 중 이어서 개발하려는 프로젝트에 맞는 것이 무엇인지 묻습니다. 공통 요청을 보관하고 받은 지원을 공개하며, 플레이 동작과 검사 가능한 인계물을 구분하세요. 이 초안은 승자를 선택할 수 없습니다. 네 번의 통제된 실행과 수정, 내보내기가 아직 없기 때문입니다. 접근과 필요한 예산이 승인되면 공통 Lantern Delivery 요청을 SEELE에서 사용하고 다른 후보에서도 변경 없이 반복하세요. 실패와 제한도 기록에 남깁니다. 그런 다음에야 가정된 순위가 아니라 관찰된 플레이 가능성, 편집 노력, 프로젝트 접근을 기준으로 선택지를 좁힐 수 있습니다.

자주 묻는 질문

내보내기 버튼이 있으면 편집 가능한 소스를 받을 수 있나요?

아니요. 내보내기 결과는 컴파일된 빌드이거나 특정 에디터용 프로젝트일 수 있습니다. 실제 산출물을 다운로드해 검사한 다음 문서화된 도구로 열거나 실행하세요. 계정 수준의 제한된 관찰을 제품 전체의 기능으로 오해하지 않도록 테스트한 요금제와 형식을 기록합니다.

공식 문서가 직접 해 보는 비교를 대체할 수 있나요?

아니요. 문서는 현재 기능이나 요금제에 관한 설명을 뒷받침할 수 있지만, 이 특정 게임이 제대로 작동했거나 방패 변경 후에도 유지됐다는 사실은 보여 줄 수 없습니다. 문서와 관찰 결과를 별도 메모에 보관하세요. 실행하지 않은 시나리오는 홍보 예시나 기능 목록에서 확신을 가져오는 대신 미검사로 표시합니다.

모든 후보에 정확히 같은 수의 프롬프트를 제공해야 하나요?

초기 요청과 변경 사양은 같게 하되 추가 지원과 수작업은 모두 공개하세요. 인터페이스마다 필요한 행동이 다를 수 있으므로 프롬프트 수만으로 노력을 공정하게 측정할 수 없습니다. 개입과 예산 한도를 미리 정하고 결과를 본 뒤 규칙을 조정하는 대신 기록을 보존하세요.