PuzzleVault는 HTML, CSS와 JavaScript로 브라우저에서 실행되는 퍼즐을 만듭니다. 각 페이지는 탐색 메뉴, 언어 선택, 결과 공유를 위한 공통 스크립트와 해당 게임의 규칙을 다루는 스크립트를 읽습니다. 어떤 보드는 Canvas에 직접 그리고, 어떤 게임은 실제 버튼과 문서 요소를 사용합니다. 규칙과 화면을 각각 살펴볼 수 있는 작은 게임 모음에 어울리는 구조입니다.
이 선택은 다른 개발 방식보다 언제나 빠르다는 선언이 아닙니다. 프레임워크로도 반응성과 접근성을 갖춘 게임을 만들 수 있습니다. 현재 PuzzleVault의 숫자 갱신, 조각 이동, 보드 그리기는 별도의 컴포넌트 프레임워크 없이 표현할 수 있습니다. 입력에서 다음 화면까지 어떤 일이 일어나는지 코드에서 직접 추적하기 쉽다는 점이 중요합니다.
1. 다운로드할 파일은 여전히 있습니다
게임을 열려면 HTML, 스타일, 스크립트와 필요한 번역 자료를 받아야 합니다. 연결 속도, 캐시, 기기 성능과 다른 리소스가 모두 준비 시간에 영향을 줍니다. 프레임워크 실행 코드를 추가하지 않는 것은 의존성을 하나 줄이는 선택이지, 로딩 시간이 사라진다는 뜻은 아닙니다. 각 파일이 지금 여는 페이지에 어떤 역할을 하는지 살피는 것이 실용적입니다.
예를 들어 NumVault의 추론 규칙은 전용 스크립트에 있습니다. 언어 선택과 공유는 공통 코드가 담당합니다. 공통 기능의 수정이 여러 게임에 적용될 수 있지만, 개발자는 중복 코드와 스크립트 실행 순서도 함께 관리해야 합니다.
2. 게임마다 다른 화면 도구를 고릅니다
PatternPop의 보드와 입체 패드는 Canvas로 그립니다. QuickCalc의 답은 실제 버튼으로 표시해 포커스와 선택 동작을 활용합니다. Canvas에서는 좌표 판정과 키보드 조작을 직접 구현해야 하고, 일반 문서 요소를 쓰는 화면에서는 배치와 스타일 갱신을 관리해야 합니다. 어느 쪽이든 실제 게임에 맞는 검증이 필요합니다.
requestAnimationFrame은 브라우저의 화면 갱신에 맞춰 작업을 예약하는 도구입니다. 일정한 프레임 수를 보장하는 기능은 아닙니다. 기기의 작업량, 화면 주사율과 백그라운드 탭 상태에 따라 실행 간격이 달라질 수 있습니다. 따라서 제한 시간이 있는 게임은 프레임 수 대신 실제 경과 시간을 계산해야 합니다.
3. 의존성이 적어도 유지보수는 필요합니다
현재 프로젝트는 게임 코드를 프레임워크 빌드 과정으로 묶지 않고 정적 파일로 제공할 수 있습니다. 배포할 파일을 살펴보기 쉽지만, 지연된 콜백 정리, 도전 링크 검증, 저장 실패 처리와 브라우저별 동작 확인은 여전히 애플리케이션의 몫입니다. 기본 브라우저 API를 쓴다는 이유로 코드가 영구히 수정 없이 동작하는 것은 아닙니다.
서비스 워커 캐시도 같은 주의가 필요합니다. 캐시된 파일은 재방문에 도움이 될 수 있지만, 동작이 바뀌면 이전 스크립트가 새 버전으로 교체되어야 합니다. 서로 다른 버전의 파일이 섞여 실행되지 않게 하는 과정은 첫 화면을 빨리 띄우는 것만큼 중요합니다.
4. 반응성은 실제 조작으로 확인합니다
좁은 화면, 터치, 키보드만 사용하는 상황과 모션 줄이기 설정을 함께 확인해야 합니다. 애니메이션 중 재시작하거나 다른 탭에 다녀온 뒤 시간제 게임으로 돌아오는 상황도 포함됩니다. 화면이 빠르게 그려져도 입력이 엉뚱한 칸으로 전달되면 만족스러운 플레이가 되기 어렵습니다.
배터리 사용량은 프레임워크 유무만으로 판단할 수 없습니다. 그리기 빈도, 효과 계산, 백그라운드 작업과 기기 자체가 영향을 줍니다. 불필요한 작업을 줄이고 조건을 정해 측정할 수는 있지만 이 글은 배터리나 로딩 속도의 실측 비교를 제시하지 않습니다. 이 구조를 선택한 이유는 게임과 함께 코드를 살펴보고 수정하며 검증하기에 적합하기 때문입니다.
PatternPop의 패드와 NumVault의 키패드를 번갈아 조작해 보세요. 화면을 만드는 도구는 달라도 다음 행동과 그 결과를 쉽게 이해할 수 있도록 한다는 목표는 같습니다.