릴리스 지뢰 지도 제작 로그
지뢰 찾기형 Play를 운으로 여는 게임이 아니라 숫자, 깃발, 함께 열기 준비 표시를 읽는 1분 추론 퍼즐로 묶어 정리한 제작 로그입니다.
릴리스 지뢰 지도 열기 바로 하기지뢰 찾기는 억울하면 바로 끝난다
릴리스 지뢰 지도 열기는 지뢰 찾기형 Play다. 닫힌 칸을 열고, 숫자가 말하는 주변 지뢰 수를 읽고, 의심 칸은 깃발로 보류한다. 익숙한 규칙이지만 1분짜리 Play로 만들면 문제가 생긴다. 설명이 부족하면 운으로 찍는 느낌이 나고, 설명이 길면 시작하기 전에 지친다.
그래서 화면에서 숫자와 깃발의 관계를 빨리 읽게 만드는 쪽으로 잡았다. 숫자 주변 깃발 수가 맞을 때 함께 여는 흐름, 의심 칸을 바로 열지 않고 보류하는 흐름, 숫자가 말하는 안전 후보를 따라가는 흐름이 중요했다.
고친 기준
| 요소 | 왜 필요한가 | 확인한 것 |
|---|---|---|
| 깃발 보류 | 애매한 칸을 바로 열지 않게 한다 | 키보드와 마우스 모두 깃발 상태를 바꾸는지 |
| 숫자 주변 판단 | 지뢰 수와 열린 칸의 관계를 보여준다 | 숫자, 깃발, 닫힌 칸이 너무 비슷해 보이지 않는지 |
| 함께 열기 | 확실한 주변 칸을 한 번에 열게 한다 | 조건이 맞을 때만 열리는지 |
| 결과 문장 | 실패를 운이 아니라 판단으로 설명한다 | 숫자와 깃발을 맞추기 전 열었다는 원인이 보이는지 |
지뢰 찾기는 작은 화면에서 특히 어렵다. 숫자가 작고 칸이 많으면 모바일에서 바로 피곤해진다. 그래서 이 Play는 거대한 판보다 짧은 판, 빠른 판단, 분명한 실패 원인을 우선했다.
짧은 메모를 통합한 이유
깃발, 숫자 열기, 함께 열기 같은 변경은 개별 개발 메모로 남길 수 있다. 하지만 공개 목록에서 각각을 따로 보여주면 비슷한 제목이 반복된다. 방문자가 알고 싶은 것은 "이 지뢰 찾기 Play가 어떤 판단을 중심으로 만들어졌나"다. 그래서 짧은 메모는 아카이브 후보로 두고, 대표 글은 이 제작 로그로 바꾼다.
앞으로 더 볼 부분은 첫 실패의 설명이다. 지뢰를 밟았다는 말만 나오면 운처럼 느껴진다. 어떤 숫자 주변에서 깃발 수를 맞추지 않았는지, 왜 그 칸이 위험했는지 조금만 보여주면 다음 판이 더 납득된다.
보관 메모에서 남긴 판단
세 개의 보관 메모는 서로 다른 기능처럼 보이지만, 실제로는 같은 질문을 다룬다. 사용자가 닫힌 칸을 바로 열기 전에 "지금 이 칸은 확실한가, 보류해야 하는가, 숫자 칸을 다시 눌러도 되는가"를 판단할 수 있어야 한다는 질문이다.
| archive 메모 | 대표 글에서 흡수한 위치 | 남긴 이유 |
|---|---|---|
| `minesweeper-flag-note` | 깃발 보류 | 의심 칸을 기억에 맡기지 않고 보드 위에 내려놓는 문제 |
| `minesweeper-number-open-note` | 숫자 칸 재클릭 | 숫자를 읽은 뒤 손이 다음 확정 행동으로 이어지는 문제 |
| `minesweeper-chord-ready-note` | 주변 열기 준비 표시 | 다시 눌러도 되는 순간을 사용자가 머릿속으로만 계산하게 두지 않는 문제 |
이렇게 묶으면 글의 중심이 "기능 세 개를 추가했다"에서 "작은 지뢰 찾기에서 억울한 클릭을 줄이는 방법"으로 바뀐다. 깃발은 보류 장치이고, 숫자 칸 재클릭은 확정 행동이며, 준비 표시는 두 행동을 연결하는 신호다. 셋 중 하나만 있어도 규칙은 돌아가지만, 셋이 함께 있어야 짧은 판이 운 게임처럼 보이지 않는다.
| 보관 메모 묶음 | 그때 본 문제 | 대표 로그에서 남길 판단 |
|---|---|---|
| 깃발 조작 | 의심 칸을 머릿속으로만 기억해야 해서 작은 화면에서 실수가 늘었다 | 보류는 점수가 아니라 안전한 추론을 위한 화면 상태여야 한다 |
| 숫자 칸 다시 열기 | 숫자를 읽어도 다음 행동이 없어 칸을 하나씩 찍는 느낌이 남았다 | 숫자와 깃발 수가 맞으면 손이 확정 행동으로 이어져야 한다 |
| 준비 상태 표시 | 함께 열 수 있는 순간을 사용자가 다시 암산해야 했다 | 도움말은 정답 표시가 아니라 지금 가능한 행동의 상태 표시여야 한다 |
이 표는 짧은 개발 메모를 숨기려는 장치가 아니다. 공개 목록에서 세 글이 따로 보이면 "깃발을 넣었다", "다시 누르게 했다", "표시를 붙였다"처럼 작은 기능 추가만 남는다. 대표 로그에서는 그 세 변경을 하나의 제작 판단으로 접는다. 지뢰 찾기형 Play가 억울하게 끝나지 않으려면, 사용자가 확신 없는 칸을 보류하고 숫자 주변을 대조한 뒤 눌러도 되는 순간을 확인할 수 있어야 한다. 이 흐름이 살아야 짧은 판도 찍기 게임처럼 보이지 않는다.
짧은 판에서 깊이를 만드는 방법
지뢰 찾기형 Play는 판이 작아질수록 설명의 밀도가 중요해진다. 큰 게임에서는 사용자가 여러 번 실수하면서 규칙을 익힐 수 있지만, 1분짜리 Play에서는 첫 판에서 바로 납득해야 한다. 그래서 이 게임의 깊이는 칸 수를 늘리는 데 있지 않고, 숫자 하나가 주변 칸을 어떻게 제한하는지 눈에 들어오게 만드는 데 있다.
숫자 주변의 닫힌 칸, 이미 꽂은 깃발, 함께 열 수 있는 후보가 같은 화면 안에서 읽혀야 한다. 색만 바꾸면 접근성이 약하고, 설명만 붙이면 게임성이 약하다. 그래서 숫자와 칸의 간격, 깃발의 위치, 함께 열기 조건을 같이 본다. 실패했을 때도 단순히 “터졌다”가 아니라 “어떤 추론을 놓쳤는지”가 보여야 다음 판으로 이어진다.
너무 친절해지지 않는 선
지뢰 찾기형 퍼즐은 도움을 조금만 많이 주면 자동 풀이처럼 보인다. 모든 안전 칸을 빛내거나 다음 클릭을 그대로 알려주면 억울함은 줄어들지만, 사용자가 판단할 자리가 사라진다. 그래서 이 Play에서는 답을 표시하기보다 상태를 표시하는 쪽을 택했다.
깃발이 부족하면 아직 대기 상태라고 말한다. 깃발이 숫자와 맞으면 함께 열 준비가 됐다고 말한다. 깃발이 너무 많거나 틀렸다면 그 위험이 결과로 이어질 수 있게 둔다. 이 차이를 남겨야 "누르면 된다"가 아니라 "왜 지금 눌러도 되는지"가 보인다.
모바일에서도 같은 기준을 둔다. 작은 칸에서 길게 설명하면 보드가 밀리고, 너무 작은 아이콘만 두면 손가락 아래에서 사라진다. 그래서 깃발 표시, 현재 칸, 주변 강조, 준비 문구가 서로 다른 역할을 해야 한다. 색 하나에 모든 의미를 몰아넣지 않는 것도 이 때문이다.
다시 검증할 체크포인트
다음에 이 Play를 볼 때는 쉬운 판과 애매한 판을 나눠서 확인한다. 쉬운 판에서는 숫자 하나만 보고도 안전 칸이 열리는지 본다. 애매한 판에서는 깃발을 먼저 꽂아야 하는 이유가 보이는지 본다. 모바일에서는 깃발 조작과 열기 조작이 너무 비슷하게 느껴지지 않는지도 확인한다. 이 기준이 맞아야 짧은 지뢰 찾기가 운 게임이 아니라 작은 추론 퍼즐로 남는다.
- - 첫 안전 구역에서 숫자가 바로 읽히고, 닫힌 칸과 열린 칸이 헷갈리지 않는지 본다.
- - F 키, Shift 클릭, 우클릭으로 깃발이 바뀌고 깃발 칸이 실수로 열리지 않는지 확인한다.
- - 숫자 주변 깃발 수가 부족할 때는 함께 열리지 않고 대기 상태로 남는지 본다.
- - 깃발 수가 맞을 때 숫자 칸을 다시 눌러 주변 닫힌 칸이 함께 열리는지 확인한다.
- - 모바일에서는 열기와 깃발 조작이 너무 비슷하게 느껴지지 않는지, 준비 표시가 손가락에 가리지 않는지 본다.
- - 결과 화면에서는 지뢰칸을 밟았다는 사실보다 어떤 판단을 놓쳤는지가 먼저 남는지 확인한다.
읽고 나서 해볼 것