Rapid prototyping은 증거를 찾는 것입니다. 새로운 플레이어가 목표를 이해 할 수 있습니까? 핵심 행동은 또 다른 의미있는 결정을 만들 수 있습니까? 브라우저는 올바른 배달 표면입니까? AI는 구현 및 자산 탐험을 단축 할 수 있지만 올바른 질문을 선택할 수 없습니다.
아래 계획은 Elseland의 20 게임 AI-native 워크플로우에서 사용되는 동일한 작은 루프 원리에서 시작되며, 2 일 프로토 타입으로 압축됩니다.
빠른 요약
핵심 요약
- 코드나 예술을 생성하기 전에 한 플레이어를 강제로 하는 것이 좋습니다.
- 익숙한 컨트롤, 좁은 콘텐츠 세트 및 루프 작동까지 위주자 자산을 사용합니다.
- 첫날에 생산형 버전을 만들고 재생합니다.
- 증거와 이동, 개정, 또는 결정으로 끝 - 미검토되지 않은 기능의 더미.
시간 0–4: 시험 정의
플레이어 판타지, 하나의 핵심 동사, 목표, 손실 또는 완료 조건, 제어, 지원 뷰 포트 및 다른 주를 단화 할 증거를 작성합니다. 행동으로 루프를 그릴, 피드백, 상태 변경, 다음 결정.
1개의 장르를 선택하고 이차 시스템을 제거하십시오. 경기 3 시험은 1개의 널 및 3개의 목표가 있을지도 모릅니다; 활동 시험은 1개의 경기장, 1개의 적 및 1개의 공격을 필요로 할지도 모릅니다.
시간 4-12 : 회색 상자 루프 구축
입력, 상태, 피드백, 재시작 및 임시 모양과 텍스트를 가진 기본 응답 레이아웃을 구현합니다. 작은 검토 가능한 모듈에 생성 된 코드를 유지하고 테스트 또는 합격 체크를 따르십시오.
연마 전에 생산 빌드 경로에서 게임을 실행합니다. 개발 서버는 루트, 자산 및 수출 문제를 숨길 수 있습니다.
시간 12–24: 국가 읽기
플레이어, 목표, 위험, 보상 및 상호 작용 상태를 구별하기 위해 필요한 자산 만 추가하십시오. 생성 된 개념을 초안으로 사용하고 스타일 제약을 좁은 유지합니다.
데스크탑과 작은 뷰포트에 루프를 재생합니다. 불참한 입력, 보이지 않는 상태 변경, 깨진 재시작 행동 및 큰 프레임 드롭을 수정하여 내용을 추가합니다.
시간 24–36: 신선한 선수와 테스트
코치없이 시작하려면 플레이어에게 문의하십시오. 처음 의도적 행동, 첫 번째 혼란, 첫 번째 실패, 재시작 행동 및 목표의 설명에 기록 시간. 특정 수정으로 관찰을 켜십시오.
이 블록을 사용하지 마십시오 개념을 방어. 프로토 타입은 플레이어와 아이디어를 파괴하는 곳을 노출하는 존재한다.
시간 36–48: 안정화 및 결정
죽은 기능을 제거하고, 첫 분을 수정, 키보드 또는 터치 입력을 적용 가능한, 유효 메타 데이터 및 공공 경로로 수정, 다시 구축. 문서 알려진 제한 및 자산 검증.
루프가 준비되면 관련 Elseland 카테고리에서 게임을 비교하고 계속할 것인지 결정하거나, 저하를 수정하거나 실험을 아카이브합니다.
구체적인 48시간 Prototype 일정
일주일에 한 번 연속 코딩 세션으로 주말을 치료하는 대신 6 개의 검토 블록을 사용합니다. 시간 0–4는 hypothesis와 루프를 정의합니다. 4-12는 회색 상자를 생산합니다. 12-20은 생산 빌드 및 반응형 입력을 설정합니다. 20–28는 필수 예술과 소리 만 추가합니다. 28–38은 신선한 플레이어 테스트를 실행합니다. 38–48은 첫 분, 문서 증거를 수정하고 결정합니다.
각 구획의 끝에, 재생할 수 있는 건축 및 대답 1개의 질문을 저장하십시오. 회색 상자가 시간 12에 의해 이해되지 않는 경우에, 예술과 비교하지 마십시오. 생산 건축이 시간 20에 의해 이동할 수 없는 경우에, 내용 다변화의 앞에 범위를 감소시킵니다.
| 의논문 | 필수 증거 | 아직 추가하지 마십시오 |
|---|---|---|
| 혜포시스 | 한 개의 루프와 하나의 measurable 질문 | 경제, lore, 진도 |
| 회색 상자 | 입력, 의견, 국가, 재시작 | 최종 예술 세트 |
| 생산 모양 | 빌드, 경로, 응답 뷰포트 | 더 많은 수준 |
| Fresh-player 테스트 | 관찰된 comprehension 및 실패 | 개발자 설명 |
| 의약 | 이동, 재개, 또는 정지 합리적 | 의논하기 |
Evidence Ledger를 유지하십시오.
모든 변경에 대해, 가정, 가장 작은 테스트, 관측 및 결정 기록. 생성 된 코드 및 자산은 출력 볼륨을 만들 수 있으므로, ledger는 불확실한 감소에 초점을 맞춘 팀을 유지.
스크린 샷, 짧은 녹음, 콘솔 및 성능 추적 및 직접 플레이어 인용 또는 행동을 사용하십시오. 결정이 멈추거나 방향을 변경할 때 결정이 발생할 때 프로토 타입이 성공적입니다.
- Assumption: 일하는 개념에 대한 진실해야 할 일
- 시험: 그것을 드러내는 가장 작은 playable 상황
- 증거: 행동, 측정, 또는 재현성 결함
- 결정: 유지, 개정, 제거, 또는 조사
- 소유자 및 다음 게이트 : 누구의 행동과 리뷰 될 것
48시간 플랜 슬립을 복구
루프가 숨겨진 시스템을 포함했기 때문에 범위 슬립은 통합 검토없이 생성 된 코드가 허용되거나, 예술은 카메라와 상태가 안정적이기 때문에 시작됩니다. 피드백을 절단하기 전에 콘텐츠를 잘라, 재시작 또는 기본 액세스 가능성.
MDN의 브라우저 게임 재료 및 Phaser 문서는 성숙한 플랫폼을 설명하지만 프레임 워크 선택은 범위를 제어를 대체 할 수 없습니다. 도구를 미리 준비하면 팀은 프로토 타입에 도입 된 세련된 스택을 통해 신속하게 구축 할 수 있습니다.
| 증상 | 자주 묻는 질문 | 다음 체크 |
|---|---|---|
| 시간 12와 루프는 불완전합니다 | Hypothesis 또는 피드백은 약합니다 | 이차 시스템 및 재 테스트 제거 |
| dev에서만 동작합니다. | 루트 또는 자산은 dev 행동에 달려 있습니다. | 광택의 앞에 고침 생산 경로 |
| 모바일 컨트롤 실패 | 데스크톱 입력 | 지원되는 입력 및 재설계 UI를 선택하십시오. |
| 생성됨의 부호는 brittle입니다 | 큰 비건 변경 | 수축 모듈 및 합격 시험을 추가 |
| Playtest 수익률 만 | 집중된 질문 | 작업 기반 관측 |
48시간 브라우저 Prototype 정의
프로토 타입은 전체 콘텐츠, 수익화, 계정 시스템 또는 시각적 광택이 필요하지 않습니다. 신선한 플레이어가 개발자가 경험을 운영하지 않고 신뢰할 수있는 증거를 생산 할 수있는 충분한 안정성을 필요로합니다.
최종 빌드 및 원장을 생각이 중지하더라도 보관하십시오. 재사용 가능한 컨트롤, 상태 패턴, 자산 규칙 및 실패한 가정은 명확하게 문서화 할 때 미래 프로토 타입을 단축 할 수 있습니다.
- 1명의 선수 직면 hypothesis 및 반복 가능한 반복은 문서화됩니다.
- 입력, 피드백, 승리 또는 실패, 및 개발자 개입없이 재시작 작업.
- 생산 빌드 및 공공 노선 작업 지원된 viewport 크기.
- 필수 상태는 위주권 또는 한정된 최종 자산으로 읽을 수 있습니다.
- Fresh-player 관측은 선택된 질문에 답합니다.
- 알려진 결함, 자산 검증, 측정, 그리고 다음 결정은 기록됩니다.
48시간 브라우저 게임 Prototype에 대해 1차 소스 설정
우리의 증거 지하실은 MDN 게임 개발, 8 월 20, 2026에 액세스. 우리는 문서화 된 행동, 용어, 또는 제약을 수립하기 위해 사용-엘세랜드의 워크플로나 결론에 따라 소스 endorses 주장하지. 검토 하에서 실제적인 지분은 생산 모양 브라우저 경로, 하나의 반복 플레이어 루프, 신선한 플레이어 관찰 및 서면 이동/반/정 결정입니다.
이 차이는 E-E-A-T에 중앙입니다. 첫 번째 페이지는 형식, 도구, 플랫폼, 모델 또는 게임 팀 공개적으로 문서를 설정할 수 있습니다. 특정 자산이 빠르고 접근 가능하고 합법적으로 명확하고 재미 또는 생산 독서인지 입증 할 수 없습니다. 이러한 결론은 개별 관찰, 측정, 전문가 검토 또는 실제 프로젝트에 묶여있는 플레이어 증거가 필요합니다.
이 항목에 대한 결정은 프로토 타입이 forty-eight 시간 내에 가장 위험한 제품 질문에 대한 답변을 의미합니다. 다음 관측은 장식 인용보다 오히려 검토 가능한 생산 기록으로 공식 참조를 켭니다.
| Evidence 층 | 지원할 수 있는 것 | 혼자 지원할 수 없는 것 |
|---|---|---|
| 공식 소스 | 문서화 기능, 규칙, 형식, 또는 게시된 디자인 컨텍스트 | 프로젝트별 품질 또는 범용 성능 |
| 프로젝트 측정 | 이름 짓는 행동, 장면, 장치, 또는 샘플 | Unmeasured 플랫폼 또는 미래의 버전 |
| 인간 검토 | 사용성, 시각, 편집 및 생산 판단 | 법적인 특정 또는 인구 수준 선수 행동 |
| 관련 기사 | 누가 무엇을 승인, 언제, 어떤 증거와 | 입력 또는 규칙 변경 후 영구적 인 준수 |
- 1. 넓은 게임 비전보다는 한 가지 불확실한 플레이어 행동을 선택합니다. 자산과 함께 결과를 저장하거나 식별자를 구축하여 다른 검토자는 결론을 재현 할 수 있습니다.
- 2. 관찰 가능한 증거를 생성할 수 있는 가장 작은 반복을 건설하십시오. 자산을 가진 결과를 저장하거나 식별자를 건설하십시오 그래서 다른 검토자는 결론을 재현할 수 있습니다.
- 3. 실제 로딩, 입력, 뷰포트, 배포 제약 초기. 자산과 함께 결과를 저장하거나 식별자를 구축하기 때문에 다른 검토자는 결론을 재현 할 수 있습니다.
- 4. hypothesis 유효성에서 분리된 실시 완료. 자산을 가진 결과를 저장하거나 식별자를 건설하기 위하여 다른 검토자는 결론을 재현할 수 있습니다.
48시간 브라우저 게임 Prototype에 대한 필드 검토 프로토콜
첫 번째 백악 출력이 존재하고 워크플로를 스케일링하기 전에이 프로토콜을 사용하십시오. 하나의 터치되지 않은 기본, 하나의 후보 개정 및 하나의 deliberately stressed case를 유지하십시오. 스트레스를 받으면 주제의 가능성이 실패 모드 - 찾기 장면, 극단적 인 포즈, 작은 화면 놀이, 특이한 입력 또는 해제 - easiest 성공 사례를 반복해야합니다.
가능한 한 실제 배달 상황에 대한 리뷰를 실행하십시오. 도구 또는 모델 버전, 소스 파일, 설정, 대상 장치 또는 엔진, 날짜 및 검토자를 캡처하십시오. 작업이 외부 서비스에 따라 달라지면 응답 또는 동일한 출력을 대신 수출 된 artifact를 기록하면 나중에 다시 생성 될 수 있습니다.
유용한 검토는 결정과 다음 행동으로 끝납니다. "좋아요"는 문이 아닙니다. 후보자가 패스를 통과하는 상태는 경계 예외, 요구 개정 또는 거부해야합니다; 그 상태와 다음 체크의 소유자 뒤에 증거를 식별하십시오.
| 관련 상품 | 의약 | 다음 작업을 필수 |
|---|---|---|
| 의 특징 | 모든 정의된 시각, 기술 및 방출 문은 증거에 의해 지원됩니다 | 검토 된 artifact를 동결하고 빌드에 연결 |
| 조건부 통행 | 알려진 제한은 경계가 없고 의도한 사용은 불가하지 않습니다. | 재검토를 위한 예외, 소유자 및 방아쇠를 문서화하십시오 |
| 의논하기 | 방향은 비싸지 만 1 개 이상의 게이트가 지원되지 않습니다. | 한 개의 제어 변수를 변경하고 영향을받는 체크를 반복 |
| 의제휴 | 이 약관은 적용된 약관 및 약관에 적용됩니다. | 기록 보존 및 다른 접근 방식을 선택하십시오. |
- 저하와 멸망 관측을 작성합니다. 체크 전에 예상 결과를 기록 한 다음 관찰 된 결과와 그 후 예외를 첨부하십시오.
- 가장 작은 완전한 시작-action-feedback-result-retry 루프를 정의합니다. 체크 전에 예상 결과를 기록하고, 관찰 된 결과와 그 후 예외를 첨부하십시오.
- 파울리티가 질문에 영향을 미치지 않는 위주 콘텐츠를 사용합니다. 체크 전에 예상 결과를 기록한 다음 관찰 결과와 그 이후에 예외를 붙입니다.
- 시험 키보드, 포인터, 접촉, 크기, 재부하, 실패 회복. 검사의 앞에 예상한 결과를 기록하고, 그 후에 관찰한 결과 및 어떤 예외든지 붙드십시오.
- 코치 및 기록 행위없이 새로운 선수를보십시오. 체크 전에 예상 결과를 기록 한 다음 관찰 된 결과와 그 후 예외를 첨부하십시오.
- 결정과 그것을 지원하는 증거로 끝. 체크 전에 예상된 결과를 기록, 그 후에 관찰된 결과 및 어떤 예외를 그 후에 붙드십시오.
이 AI 게임 창조 가이드의 전문가 해석 및 한계
이 가이드는 가장 강력한 결론을 내릴 수 있습니다. 조건부 생산 권고: 프로젝트와 일치할 때 워크플로우를 사용하며 결정에 대한 재방문에 필요한 증거를 유지합니다. 우리는 보편적 인 모델 품질, 플레이어 선호, 법적 정리 또는 공식 스크린 샷에서 성능, 공급자 예 또는 단일 성공적인 자산을 사용하지 않습니다.
48시간 브라우저 게임 프로토타입이 창의적인 판단과 구현 세부 사항을 교차했기 때문에 경험 문제. 실제 리뷰는 소스를 편집하고 결과를 통합하고, 재생에서 테스트하고, 릴리스 후 유지하고, 권리 또는 정책 질문에 응답해야합니다. 좁은 전문가의 손 오프는 종종 그 책임이 충족 될 때만 나타나는 문제를 놓습니다.
출판 또는 배송 전에, 현재 소스와 정확한 빌드에 대한 반복 시간 감지 체크. 보존 날짜 증거, 평가 방법을 공개, 및 편집 인섭에서 측정 된 결과를 구별. 그 기록은 미래의 검토자가 퇴출 할 수없는 자신감있는 결론보다 더 가치가있다.
| Claim 유형 | 편집 치료 |
|---|---|
| 문서화 | MDN 게임 개발에 대한 링크 및 액세스 날짜 포함 |
| 결과의 관찰 | 건축, 환경, 표본 및 방법 이름 |
| 전문 심판 | 상태 기준, 검토 역할, 및 거래 |
| 출항 또는 예측 | 그것을 명시적으로 표시하고 증거가 변경 될 수 있는지 설명 |
- A forty-eight-hour 프로토 타입은 보존, 경제, 콘텐츠 스케일을 검증할 수 없습니다.
- 폴란드어는 comprehension를 개량할 수 있고 또한 약한 핵심 반복을 마칠지도 모릅니다.
- 친절한 내부 검사자는 기본적으로 대표적인 증거가 아닙니다.
- 기술 데모는 플레이어 결정에 노출하지 않는 제품 테스트가 아닙니다.
자주 묻는 질문
AI는 48 시간 안에 브라우저 게임을 건설 할 수 있습니까?
AI는 범위, 합격 기준 및 인간적인 검토가 명확할 때 좁은 시제품을 가속할 수 있습니다. 생산 읽는 게임은 보통 디자인, 시험, 내용, 권리 검토 및 폴란드어를 필요로 합니다.
48시간 프로토타입은 무엇을 포함해야 하나요?
한 이해 루프, 입력, 읽기 쉬운 피드백, 완료 또는 실패 상태, 재시작, 응답 레이아웃, 그리고 선택된 질문에 응답하기 위해 충분한 계측 또는 관측.
코딩 전에 예술을 생성해야 합니까?
방향을 정의하기 위해 충분한 참고 예술만 사용하십시오. 회색 상자 루프를 먼저 구축하십시오. 프로토 타입은 자산 생산 확장 전에 상호 작용을 증명합니다.
어떻게 계속 결정합니까?
원래 hypothesis와 함께 재생 테스트 증거를 비교: comprehension, 반복된 참여, 기술적인 feasibility, 차별화, 그리고 다음 uncertainty의 비용.
48시간 프로토타입에서 먼저 절단해야 하나요?
콘텐츠 볼륨, 이차 모드, 진행, narrative 지점, 옵션 설정 및 핵심 루프, 피드백, 재시작, 또는 테스트에 필요한 증거를 절단하기 전에 스포크 광택을 잘라. 프로토 타입이 답변하는 질문을 보존합니다.
빠른 프로토 타입은 게임 엔진 또는 일반 웹 API를 사용해야합니까?
스택을 사용하여 팀은 선택된 루프에 가장 빠르고 디버그 할 수 있습니다. 익숙한 프레임 워크는 입력, 장면, 오디오, 자산 로딩을 제공 할 수 있습니다. 작은 DOM 또는 캔버스 프로토 타입은 좁은 상호 작용을 위해 더 간단 할 수 있습니다.
초기 프로토 타입에 몇 가지 재생 테스트가 필요합니까?
몇 가지 신선한 선수는 주요 comprehension 및 제어 실패를 노출 할 수 있지만 샘플은 시장 예측이 아닙니다. 더 넓은 수요 또는 유지 질문에 대한 품질 진단 및 설계에 대한 초기 세션을 사용합니다.
프로토 타입 제작을 만드는 것은 무엇입니까?
그것은 실제 빌드 경로, 경로, 뷰 포트, 입력 방법, 자산 로딩, 및 충분한 오류 처리 배포 제약을 공개. 그것은 여전히 임시 예술과 작은 콘텐츠 세트를 사용할 수 있습니다.
출처 및 추가 자료
- MDN 게임 개발
Mozilla의 브라우저 게임 개발을위한 기본 학습 및 플랫폼 참조.
- Phaser 시작하기
Phaser HTML5 게임 프레임 워크의 공식 개요.
- Git worktree 문서
평행한 시제품 변화가 필요할 때 고립된 작업 감독을 위한 공식 참고.
다음 단계
