모양 및 허용 범위 확인
id, width, height, tiles, spawn, exits, entities처럼 레벨에 필요한 필드를 정의하세요. 크기가 게임의 지원 범위 내 양의 정수인지, 타일 배열의 항목 수가 width × height와 정확히 일치하는지, 각 타일이 알려진 유형을 사용하는지 확인하세요. 엔티티 좌표가 그리드 안에 있는지 검증하고 문, 열쇠, 스위치, 목표에 고유 ID를 요구하세요. 값이 숫자인지만 확인해서는 충분하지 않습니다. NaN과 유사하거나 범위를 벗어난 값은 명시적으로 거부하세요.
선택 필드와 필수 필드를 분리하세요. 생략된 장식 팔레트에는 기본값을 지정할 수 있지만, 퍼즐 설계를 바꿀 수 있다면 누락된 생성 지점이나 출구를 조용히 만들어내지 마세요. levels[2].entities[4].x와 같은 경로로 오류를 반환하면 콘텐츠 작성자가 문제가 있는 필드를 빠르게 찾을 수 있습니다.
관계 및 재생 가능한 불변성을 확인하세요.
구조적 검증 후 교차 필드 규칙을 확인합니다. 잠긴 모든 문은 기존 키를 참조해야 합니다. 모든 필수 키는 문 앞에서 접근할 수 있어야 합니다. 출구는 단단한 타일 안에 있어서는 안 됩니다. 생성 지점에서 경로 검색을 실행하고 게임의 이동 규칙에 따라 필요한 목표에 도달할 수 있는지 확인하세요. 적이나 움직이는 플랫폼이 액세스에 영향을 미치는 경우 간단한 그리드 경로를 주장하는 대신 보다 구체적인 유효성 검사기를 사용하거나 플레이스루 테스트를 통해 전체 레벨을 해결할 수 있음을 증명합니다.
안전하게 실패하고 유효성 검사기 자체를 테스트하세요.
MDN에 따르면 JSON이 유효하지 않을 때 JSON.parse는 SyntaxError를 발생시킵니다. 따라서 파싱 실패와 스키마 실패를 별도로 처리하세요. 개발 중에는 정확한 파일과 위반된 규칙을 보고합니다. 플레이어용 빌드에서는 일부 데이터만으로 시작하지 말고, 이미 검증된 대체 레벨을 불러오거나 레벨을 사용할 수 없다고 명확히 표시하세요. 필드 누락, 잘못된 참조, 막힌 경로, 작지만 유효한 레벨에 대한 테스트 사례를 유지하세요. 유효한 사례는 검증기가 모든 입력을 거부하는 문제를 막아 줍니다.
게임 레벨 데이터 검증 관련 질문
성공적인 JSON.parse가 레벨 파일을 신뢰하기에 충분합니까?
아니요. 구문 분석은 게임별 모양, 범위, 참조 또는 해결 가능성 규칙이 아닌 구문을 확인합니다. 레벨을 게임플레이 코드에 전달하기 전에 각각의 유효성을 검사하십시오.
게임이 유효하지 않은 레벨을 자동으로 복구해야 합니까?
안전하고 명확한 기본값에만 해당됩니다. 누락된 목표나 경로를 수리하여 설계가 변경되는 경우 레벨을 거부하고 결함을 숨기는 대신 알려진 대체 방법을 사용하십시오.
추가 읽을거리
오래된 정보를 발견하셨나요? 수정 사항 제보