《매스워(Math War)》를 만들면서 게임의 모습을 여러 번 바꿨다. 움직이는 캐릭터와 몬스터에서 시작해 수학 문제와 보상을 연결하고, 스마트폰 화면과 발열을 점검하고, 로비도 다시 만들었다.
그렇게 게임의 형태가 갖춰지자 새로운 질문이 생겼다. “이 게임을 실제로 다른 사람들이 플레이할 수 있는 곳에 올리려면 무엇을 준비해야 할까?”
여러 웹게임 플랫폼을 검토한 끝에 첫 목표로 정한 곳이 Poki였다. 이번 글은 Google Antigravity를 활용해 Poki 제출을 준비하며 화면과 보상 체계를 바꾸고 별도 빌드를 만든 기록이다. 실제 제출, 플레이테스트, 심사 통과나 정식 출시를 마쳤다는 이야기는 아니다.
왜 Poki를 첫 번째 목표로 정했을까?
HTML5 웹게임은 앱 설치 없이 브라우저에서 실행할 수 있지만, 만들었다고 해서 사람들이 자동으로 찾아오는 것은 아니다. 혼자 개발하는 입장에서는 게임을 어디에 공개하고 이용자의 반응을 어떻게 확인할지도 중요했다.
개발 당시 itch.io, CrazyGames, GameDistribution과 Poki 등 여러 선택지를 살펴봤다. Poki에 관심을 갖게 된 이유 중 하나는 실제 이용자의 플레이를 보고 개선할 수 있는 테스트 방식이었다.
Poki의 현재 테스트 안내에 따르면 플레이테스트 한 번에 실제 이용자의 플레이 영상 10개를 제공한다. 이후 Player Fit 테스트에서는 500명의 플레이 시간을 확인하고 평균 3분 이상, 3분 이상 플레이 비중 25% 이상을 건강한 초기 지표로 제시한다. 이는 자동 심사 통과나 출시를 보장하는 수치가 아니며, 단계마다 별도의 검토가 있다.
직접 게임을 만들고 플레이할 때 놓친 부분을 다른 사람의 시선으로 확인하고 싶었다. 그래서 Poki를 첫 목표로 삼았다.
기존 웹게임을 그대로 제출할 수는 없었다
기존 일반 웹게임 로비에는 영웅 선택, 영구 강화, 전투 디오라마와 브랜드 오프닝, 게임 설명과 언어 전환 등 여러 요소가 있었다. 앞서 로비를 개선할 때는 게임의 특징을 눈으로 보여주는 것이 목표였다. Poki 버전에서는 처음 방문한 사람이 망설이지 않고 플레이를 시작할 수 있게 하는 데 더 무게를 뒀다.
일반 웹게임은 유지하고 별도의 Poki 빌드를 만들었다. 프로젝트의 MATHWAR_PLATFORM 설정으로 같은 게임을 바탕으로 첫 화면과 일부 UI를 구분했다. 요구사항을 Google Antigravity에 전달하고 실제 파일과 실행 화면을 확인하며 다시 수정하는 방식으로 진행했다.
첫 번째 수정 — 로비에서 설명을 덜어냈다
v27 작업에서는 언어 전환, 브랜드 오프닝 다시보기, 전투 디오라마와 개발용 버튼 등을 Poki 첫 화면에서 숨겼다. 영웅 선택과 영구 강화도 처음부터 모두 보여주지 않도록 했다. 대신 게임 제목과 짧은 설명, 큰 PLAY 버튼을 중심에 배치했다.
Blast monsters. Solve math. Power up! 몬스터를 처치하고, 수학 문제를 풀고, 강해진다는 뜻이다. 긴 설명을 읽기보다 버튼을 누르고 직접 경험할 수 있게 만들고자 했다. 재방문자의 영웅 선택과 강화 기능을 위한 구조도 남겼다.
앞서 공들여 만든 디오라마를 첫 방문 화면에서 숨긴 것은 디자인이 잘못돼서가 아니다. 일반 웹게임과 플랫폼 제출용 첫 화면의 목적이 달랐기 때문이다.
두 번째 수정 — 복잡한 유물 이름을 숫자 보상으로 바꿨다
초기 보상에는 다양한 유물과 긴 아이템 이름이 등장했다. RPG의 분위기를 만들 수 있지만 처음 접하는 플레이어가 무엇이 얼마나 좋아졌는지 바로 이해하기는 어려웠다. 영문으로 바꿀 때는 긴 아이템 이름과 설명도 번역해야 했다.
v28에서는 보상을 Gold, ATK, DEF, Score라는 네 가지 수치로 단순하게 보여주는 방향으로 바꿨다. 골드와 점수, 공격력과 방어력의 변화를 읽기 쉽게 드러내려는 선택이었다. 개발 기록에는 방어력 능력치와 피해 감소 처리를 추가해 표시되는 보상이 실제 전투 성장에 연결되도록 한 과정이 남아 있다.
세 번째 수정 — 도박을 떠올리게 하는 용어를 바꿨다
수학 퀴즈에는 현재 보상을 받거나 다음 배율에 도전하는 선택이 있다. 개발 당시에는 이 구조를 설명하는 데 카지노를 연상시키는 용어가 사용되기도 했다.
v29 기록에는 ‘DOUBLE OR NOTHING’을 ‘MATH STREAK’로, ‘JACKPOT’을 ‘MAX BONUS’로 바꾸고 선택 버튼도 CHALLENGE와 CLAIM 중심으로 정리한 내용이 나온다. 이는 표현을 바꾼 개발 과정이지 플랫폼의 심사 적합성을 보장하는 결과는 아니다.
네 번째 수정 — 퀴즈 화면에서 글을 줄였다
영문과 숫자 보상으로 바꾼 뒤에도 퀴즈 화면의 설명은 복잡했다. v29 화면에서는 보상과 추가 도전 안내가 반복되고 버튼 안 문장도 길었다. 제한시간이 있는 문제를 풀 때 설명을 읽느라 시간을 쓰게 만들고 싶지 않았다.
문제 풀이 화면 — 수식과 타이머에 집중
v30~v31에서는 중복된 규칙과 안내 문장을 줄이고 수식, 선택지, 타이머와 현재 보상 배율에 집중하도록 구성했다. 지금 무엇을 해야 하는지 먼저 보이게 하려는 의도였다.
추가 도전 화면 — 선택지를 두 개로
문제를 맞힌 뒤 플레이어는 현재 보상을 받거나 더 큰 배율에 도전한다. 이 선택을 긴 문장 대신 CHALLENGE 4X와 CLAIM 2X처럼 짧은 버튼으로 정리했다. 필요한 정보를 남기면서 판단하기까지의 부담을 줄이고 싶었다.
보상을 문장 대신 네 칸의 카드로 보여줬다
보상 결과도 문장으로 길게 나열하는 대신 골드, 점수, 공격력, 방어력을 네 칸으로 구분했다. 플레이어가 어떤 변화를 얻었는지 숫자를 비교하기 쉽게 보여주려는 목적이었다.
처음 로비부터 퀴즈와 결과 화면까지 같은 질문이 반복됐다. 지금 플레이어에게 필요한 정보는 무엇일까? 기능을 전부 동시에 보여주기보다 필요한 순간에 보여주는 쪽으로 정리했다.
마지막에는 작은 언어 표시 오류도 점검했다
영문을 기본값으로 바꾸는 것만으로 모든 순간에 영어가 표시되는 것은 아니었다. 개발 기록에는 퀴즈 진입 직후 타이머에 한글 ‘초’가 잠깐 나타났다가 영어로 바뀌던 문제와 이를 ‘s’ 표시로 정리한 작업이 남아 있다.
당시 최종 QA의 독립적인 실행 결과는 현재 확인하지 못했다. 모든 언어 표시 오류를 완전히 제거했다고 단정하기보다 실제 실행 화면을 다시 검수할 필요가 있다.
그렇게 만들어진 약 91KB 제출 준비 파일
여러 차례 수정한 끝에 일반 웹게임과 영문 버전, Poki 전용 실행 파일을 따로 보관했다. 확인된 파일은 일반 HTML 343,933바이트, 영문 HTML 343,974바이트, Poki HTML 343,886바이트이며, Poki ZIP은 91,045바이트다. ZIP에는 index.html이 들어 있다.
파일이 작다고 게임의 재미나 기술적 완성도가 보장되는 것은 아니다. ZIP을 만들었다는 사실도 Poki의 모든 기술 요건을 충족했거나 플랫폼에 제출했다는 뜻은 아니다.
실제 제출 전에 남은 확인
현재 Poki의 제출 안내는 게임 소개와 함께 로그인 없이 접근 가능한 플레이 빌드 또는 영상 링크, 실제 게임 화면 3장을 요청한다. 개발자 플랫폼에서의 빌드 업로드와 테스트는 별도의 접근 권한과 절차를 확인해야 한다.
공식 요구사항은 데스크톱·모바일·태블릿 대응, 16:9 캔버스에 맞춘 확장, 시크릿 모드의 저장소 예외 처리, 외부 요청 제한 등을 명시한다. 세로형으로 설계한 현재 게임의 화면비와 기기별 표시는 별도 검증이 필요하다. 별도 스플래시 화면과 외부 링크는 제거하고 스튜디오 로고는 로딩 화면에 둘 수 있다는 정책도 확인해야 한다.
보관된 Poki 빌드에서는 Poki SDK 이벤트 호출을 확인하지 못했다. 공식 문서는 Web Fit 테스트와 출시에 SDK 연동을 요구하며, 게임 시작·중단과 광고 이벤트를 올바른 시점에 처리하도록 설명한다. Poki Inspector 검사 결과도 확인되지 않았다. SDK 연동과 실제 기기·시크릿 모드 테스트, 외부 요청 및 화면비 검토가 제출 전 후속 과제다.
지금까지 확인된 성과는 제출을 준비하기 위한 빌드와 ZIP을 만들었다는 것이다. 실제 제출이나 플레이테스트 결과는 아직 확인되지 않았다.
Google Antigravity로 개발하면서 마지막까지 느낀 점
이번 프로젝트는 Google Antigravity를 중심으로 진행했다. 전투와 수학 문제를 만들고, 모바일 오류를 수정하고, 로비와 제출 준비 화면을 바꾸는 과정에서 지시를 실제 파일 수정과 실행 결과로 빠르게 연결하는 능동성이 인상적이었다.
하지만 하나의 기능을 빠르게 수정하는 것과 게임 전체에 미치는 영향을 검수하는 일은 달랐다. 기능을 추가하며 로비가 복잡해졌고 PC와 스마트폰에서 다르게 보이는 문제도 있었다. 무엇을 유지하고 줄일지 판단하고 직접 플레이하며 확인하는 과정은 계속 필요했다.
이는 객관적인 성능을 확정하는 평가가 아니라 이번 프로젝트의 사용 경험이다. 앞으로 Codex와 Claude Code를 실제 작업에 활용하면서 능동적인 실행, 여러 파일을 함께 다루는 방식과 전체 프로젝트 검수 능력도 비교해 보려고 한다.
첫 게임 개발일지를 마치며
2026년 10월 26일, 집에서 혼자 H5 게임을 만들 수 있을지 궁금하다는 질문으로 시작했다. 규칙을 정하고 코드를 작성하고 오류를 고치는 일을 반복하며 실행 가능한 게임과 Poki 제출 준비 빌드까지 만들었다.
앞으로 플랫폼의 기술 요구사항을 충족하는지, 처음 보는 이용자가 게임을 이해하는지, 수학과 슈팅을 결합한 방식이 재미있는지는 실제 검증이 필요하다. 여섯 편은 게임의 성공을 증명하는 기록이 아니라 AI를 활용해 혼자 게임을 만들며 무엇을 선택하고 어떤 문제에 부딪혔는지 남긴 기록이다.
AI가 구현을 빠르게 도왔지만 직접 실행하고 결과를 판단해 다시 수정하는 과정은 여전히 중요했다. 실제 제출과 테스트 결과가 확인되면 후속 글 《매스워》 Poki 도전 그 후 — 실제 제출과 플레이테스트 기록으로 이어갈 생각이다.
《매스워》 개발일지 1~6편 — 여기까지가 첫 번째 제작 기록이다.
답글 남기기