작동하는 게임 흐름에서 시작해 진행 상황의 신뢰성 높이기
방치형 게임에는 페이지를 열어 둔 동안 증가하는 카운터 이상의 것이 필요합니다. 플레이어는 새로고침 후에도 구매한 업그레이드가 유지되고, 돌아왔을 때 합리적인 진행 보상을 받으며, 이후 업데이트가 자신의 노력을 지우지 않기를 기대합니다. 저장, 오프라인 정산, 호환성을 각각 별도의 동작과 검사로 다루세요.
이 작업 과정은 기존에 생성하거나 테스트한 프로젝트가 아닌 설명용 온실 디자인의 연장입니다. 클릭하면 가상 코인을 얻고 구매한 정원사는 한 명당 초당 코인 한 개를 생산합니다. 다음 정원사 가격은 ceil(10 × 1.15^n)이며 n은 이미 보유한 인원입니다. 작동하는 획득·구매 흐름에서 시작하세요. 로컬 저장소와 클라우드 저장을 혼동하지 않으면서 저장 계약을 정의하고, 상한이 있는 복귀 보상을 계산하며, 이후 한 번의 수정 동안 진행 상황을 보존합니다.
게임이 기억해야 할 내용 지정하기
코드를 요청하기 전에 저장 계약을 작성하세요. 최소 버전에는 스키마 버전, 현재 코인 잔액, 정원사 수, 구매한 업그레이드, 수익을 이미 정산한 시점이 포함됩니다. 생산 속도 규칙은 업그레이드 정의와 함께 보관하세요. 파생 상태의 모순되는 복사본이 아니라 표시 잔액의 근거가 되는 구매 내역을 저장합니다.
개발 중 읽기 쉬운 저장 요약을 요청해 게임 상태와 저장된 상태를 비교하세요. 진단 출력에 개인 정보가 노출되지 않도록 합니다. 로컬 저장과 계정 기반 저장도 구분하세요. 브라우저 저장소는 브라우저 프로필에 속하며 지워질 수 있습니다. 기기 간 진행 공유, 안전한 경쟁 잔액, 플레이어가 사이트 데이터를 삭제한 뒤의 복구를 보장하지 않습니다.
다음과 같이 범위를 제한해 요청합니다.
코인, 정원사, 구매한 업그레이드, 마지막 정산 시각을 위한 버전 관리 로컬 저장을 추가해 주세요. 플레이 가능한 화면을 보여 주기 전에 상태를 복원합니다. 불러온 값을 검증하세요. 저장이 없으면 새 게임을 시작합니다. 저장이 유효하지 않다면 불가능한 잔액을 조용히 만들지 말고 복구 동작을 설명하세요. 기존 아트와 획득 규칙은 변경하지 마세요.
의미 있는 구매 후에 저장하고 게임에 필요하다면 주기적 저장도 정의하세요. 페이지 종료 이벤트에만 의존하지 마세요. 브라우저나 기기가 기대한 마지막 이벤트를 전달하지 않고 종료될 수 있습니다.
명확한 상한을 두고 부재 보상 한 번만 계산하기
오프라인 진행은 보통 플레이어가 돌아왔을 때 보상을 계산하는 것을 뜻합니다. 브라우저가 닫힌 후에도 게임 스크립트가 계속 실행될 필요는 없습니다. 투명한 규칙은 다음과 같습니다.
보상 = 대상 저장 생산 속도 × min(max(복귀 시각 − 마지막 정산 시각, 0), 8시간)
구현 전에 대상 속도의 의미를 정하세요. 이 단순한 디자인에서는 떠날 때 저장된 정원사와 업그레이드의 생산 속도입니다. 기본 정산이 작동할 때까지 복잡한 시뮬레이션은 미룹니다.
예상값 확인을 위해 각각 초당 코인 한 개를 생산하는 정원사 두 명은 통제된 10분 동안 1,200코인을 벌게 됩니다. 예시 상한 아래에서는 10시간 떠나 있어도 8시간만 사용합니다. 실행 기록의 예상값으로 이 계산을 사용하세요.
진행 보상을 지급한 뒤에는 새로고침해도 같은 부재 시간에 보상을 다시 지급하지 않도록 게임이 정산 상태를 업데이트해야 합니다. 사용한 시간과 지급한 보상을 보여 주는 복귀 메시지를 요청하세요. 계속 실행되는 서버가 있다고 암시하지 말고 계산된 보상으로 설명합니다.
계산 예시: 오프라인 보상
이 예시들은 고정 생산 속도와 가상 코인을 가정하고, 표시된 경우 2시간 상한을 사용합니다. 테스트한 게임의 측정 결과가 아니라 예상 계산입니다.
| 상황 | 계산 | 예상 보상 |
|---|---|---|
| 정원사 1명, 10분 부재 | 초당 코인 1개 × 600초 | 가상 코인 600개 |
| 정원사 2명, 30분 부재 | 초당 코인 2개 × 1,800초 | 가상 코인 3,600개 |
| 정원사 1명, 3시간 부재, 2시간 상한 | 초당 코인 1개 × min(10,800, 7,200)초 | 가상 코인 7,200개 |
| 정산 직후 새로고침 | 이미 정산한 구간을 다시 계산하지 않는다. | 그 구간의 추가 코인 0개 |
저장과 시간 정산을 따로 테스트하기
먼저 알고 있는 금액을 벌고 정원사 한 명을 구매한 뒤 새로고침합니다. 잔액과 구매 내역이 유지되는지 확인하세요. 다음으로 브라우저를 닫고 시간을 측정하며 기다렸다가 돌아옵니다. 시작 상태, 실제 경과 시간, 관찰된 보상, 최종 상태를 기록하세요. 즉시 새로고침하고 같은 보상이 반복되지 않는지 확인합니다.
긴 구간은 제어 가능한 테스트 시계를 사용하고 정상 경로는 실제로 닫았다가 돌아와 확인하세요. 음수 경과 시간, 비현실적으로 긴 구간, 빈 저장, 손상된 저장을 테스트합니다. 결과를 보기 전에 각각 어떻게 동작해야 하는지 명시하세요. 음수 구간은 이미 얻은 통화를 차감해서는 안 됩니다. 긴 구간은 상한을 우회해서는 안 됩니다.
기기의 로컬 시간은 플레이어가 변경할 수 있습니다. 경과 시간의 범위를 제한하면 명백한 오류를 막는 데 도움이 되지만 로컬 경제가 변조에 안전해지는 것은 아닙니다. 경쟁 또는 유료 경제에는 별도의 권위 있는 정산 및 보안 설계가 필요합니다.
복귀 테스트 표
| 행동 | 예상 동작 | 검사 실패 시 |
|---|---|---|
| 업그레이드 구매 후 새로고침 | 저장된 잔액과 구매한 업그레이드가 함께 복원된다. | 어떤 필드가 언제 저장됐는지 살펴본다. |
| 측정한 시간 후 복귀 | 보상이 문서화된 속도와 시간 상한을 따른다. | 저장된 정산 타임스탬프, 속도, 경과 시간을 비교한다. |
| 복귀 보상 직후 새로고침 | 같은 구간에 보상이 두 번 지급되지 않는다. | 보상과 함께 정산 타임스탬프가 갱신되는지 확인한다. |
| 다른 브라우저나 기기에서 열기 | 명시된 로컬 또는 계정 기반 저장 방식에 맞게 동작한다. | 기기 간 동기화 메커니즘이 있는지 확인한다. |
| 규칙 변경 후 이전 저장 불러오기 | 구매 내역과 잔액이 문서화된 마이그레이션을 따른다. | 저장 버전과 마이그레이션 또는 복구 경로를 살펴본다. |
플레이어를 초기화하지 않고 이후 업그레이드하기
저장이 작동하면 작은 콘텐츠 변경을 요청합니다.
성장 계수 1.15를 유지하면서 향후 구매의 정원사 기본 가격을 코인 열 개에서 여덟 개로 변경해 주세요. 기존 코인, 정원사, 보유 업그레이드, 시각 요소, 오프라인 정산을 보존합니다. 현재 저장 데이터 버전을 지원하세요. 새 상태에 추가 필드가 필요하다면 이전 저장이 어떻게 마이그레이션되는지 보여 주세요.
이 요청을 하기 전에 실제 변경 전 저장과 작동하는 빌드를 보관하세요. 해당 저장을 수정 버전에 불러와 결과 잔액, 구매 내역, 생산 속도를 비교합니다. 새 필드를 추가할 때 이전 저장에 그 필드가 없다는 이유만으로 전체 상태가 버려져서는 안 됩니다. 경제를 변경하기 전에 이전 구매의 혜택을 유지할지 결정하세요.
업그레이드가 사라진다면 기능을 추가하기 전에 마이그레이션과 불러오기를 살펴봅니다. 새 버튼은 저장 호환성의 증거가 아닙니다.
범위를 제한한 상태 유지 수정에 SEELE 사용하기
SEELE는 프롬프트 중심으로 게임을 만들고 후속 변경을 요청하는 작업 과정을 제공합니다. 여기서 중요한 입력은 작동하는 경제와 구체적인 저장 계약이며, 원하는 결과는 불러오기와 정산 동작을 검사할 수 있는 수정 후보입니다. 마이그레이션이나 새로운 업그레이드를 요청하기 전에 가장 작은 상태 유지 변경을 요청하세요.
평가 중인 수정과 별도로 작동하는 빌드와 기준 저장을 보관합니다. 검사가 실패하면 불러오기, 복귀, 구매 중 어디에서 문제가 발생했는지를 포함해 정확한 상태 차이를 보고하세요. 제품 소개만으로 클라우드 저장, 안전한 시계, 마이그레이션 보장 또는 특정 로컬 저장 구현의 신뢰성이 입증되지는 않습니다.
복귀 결과가 납득된 후에만 계속하기
신뢰할 수 있는 방치형 게임은 숫자의 출처를 설명해야 합니다. 무엇이 보상을 생산했고, 어떤 부재 구간이 계산됐으며, 어떤 구매가 유지되는지입니다. AI의 도움으로 이런 규칙을 범위 제한해 변경하고 실행 중인 게임에서 각 변경을 판단하세요. 작동하는 저장을 더 긴 기능 목록과 맞바꾸지 마세요.
SEELE를 사용해 기존 프로젝트에 로컬 저장 하나와 상한이 있는 복귀 보상 하나를 요청하세요. 경제의 다른 변경을 요청하기 전에 작동이 확인된 버전을 보존합니다. 다음 목표는 더 큰 약속이 아니라 플레이어의 이전 진행 상황을 그대로 유지한 복귀 방문을 검증하는 것입니다.
자주 묻는 질문
오프라인 진행은 브라우저가 닫혀 있는 동안 게임이 실행된다는 뜻인가요?
반드시 그렇지는 않습니다. 흔한 방법은 상태와 정산 시각을 저장한 다음 다음 방문 때 보상을 계산하는 것입니다. 이를 통해 브라우저 프로세스를 계속 실행하지 않고도 오프라인 보상을 설계할 수 있습니다. 설명하기 전에 실제 구현을 확인하세요. 서버 측 시뮬레이션은 다른 아키텍처이며 로컬에서 계산한 보상으로 서버 실행을 암시해서는 안 됩니다.
브라우저 저장이 다른 기기로 옮겨지나요?
그렇다고 가정하지 마세요. 브라우저의 로컬 저장소는 보통 해당 브라우저 프로필과 사이트 저장소에 묶여 있습니다. 기기 간 저장에는 충돌 처리 및 개인 정보 관련 결정과 함께 명시적인 동기화 또는 계정 시스템이 필요합니다. 로컬 상태 유지 예시를 클라우드 저장 기능으로 제시하지 말고 테스트한 데모가 실제로 무엇을 사용하는지 알려 주세요.
사람들이 이미 플레이한 후에 업그레이드 가격을 바꿀 수 있나요?
네, 수정된 디자인이 기존 구매와 저장 상태를 어떻게 처리할지 정의한다면 가능합니다. 기준 저장을 보존하고 어떤 혜택을 유지할지 결정한 뒤 변경을 출시하기 전에 마이그레이션을 테스트하세요. 가격 목록을 단순히 덮어쓰는 것만으로 이전 진행 상황이 유효하다고 증명할 수는 없습니다. 동작이 아직 테스트되지 않았다면 성공한 업데이트가 아니라 요구사항으로 설명하세요.
