SOLO PROJECT · 2026.07 — 진행 중

증강 요트 다이스

클래식 요트 다이스의 족보 규칙 위에 증강 55종을 얹은 2인 대전 게임입니다. 웹 실시간 멀티플레이로 룰을 다듬었고, 지금은 같은 룰을 Unity 6 3D 테이블탑(Tessera)으로 옮기고 있습니다. 기획부터 구현까지 혼자 맡았습니다.

기획시스템 설계개발

PHASE 1 · PHASE 2

2026.07.01 첫 커밋 이후 커밋 110개. 1·6·9턴마다 증강 3택 1을 고르는 2인 대전이고, 클래식 4인전도 지원합니다. 6자리 PIN으로 방을 만들어 바로 붙는 실시간 멀티플레이입니다.

김예찬 기획 · 시스템 설계 · 개발 (1인)
증강 카드 55종, 서버 권위 구조, 주사위 연출 동기화, Unity 이식 구조

KEY DECISIONS

핵심 판단 3건

카드 기획, 서버 권위 구조, 주사위 결과 동기화. 눌러서 펼쳐 보세요.

01요트 다이스 위에 증강 55종을 얹었다

상황: 클래식 요트 다이스는 족보 규칙이 명확하다. 이 규칙 위에 판마다 전략이 달라지는 시스템을 얹고 싶었다.
결정: 게임을 3개 페이즈로 나눠 1턴, 6턴, 9턴에 증강을 무작위 3택 1로 고르게 했다. 증강은 퀘스트, 사보타주 등 5가지 타입, 총 55종이다.
이유: 페이즈가 뒤로 갈수록 변동폭이 큰 하이 리스크 하이 리턴 옵션이 나오게 해, 후반 역전 여지를 남겼다.
한계: 페이즈별 점수 변동 상한은 명세서에 "추후 검토 필요"로 남아 있다. 55종의 밸런스를 통계로 검증한 자료는 없다.

04점수 판정을 서버가 소유한다 (릴레이에서 권위 서버로)

상황: 초기에는 클라이언트가 계산하고 서버는 메시지를 중계했다. 증강 선택 동기화, 2P 모달이 강제로 닫히는 레이싱, 3인 이상 기권 오인과 3P 승리 역전 같은 상태 불일치 버그가 7월 하순에 반복해서 나왔다.
대안: 클라이언트 판정과 릴레이를 유지하면서 버그를 하나씩 고치는 방식.
결정: 턴, 점수, 증강 규칙을 서버가 판정하는 권위 서버로 옮겼다(8/1). 클라이언트는 표현만 맡고, 클라이언트가 보낸 결과값은 믿지 않는다.
이유: 실시간 대전에서 두 클라이언트의 상태가 갈라지지 않게 하려는 것이다.
한계: 계획 문서 기준으로 서버 통합 테스트는 매치메이킹 2인 흐름만 보장했고, 일반 로비 3·4인 검증은 추가로 필요했다.

05주사위 결과: 값 선결정과 회전 보정 대신 서버 확정 프리셋 재생

상황: 서버가 주사위 값을 먼저 뽑고, 클라이언트는 별도 물리를 돌렸다. 그래서 실제로 멈춘 면과 서버 값이 어긋날 수 있었다.
검토한 대안: (A) 서버 값에 맞춰 마지막에 주사위를 돌려 보정한다. 결과를 조작하는 것처럼 보여 제외했다. (B) 서버가 고정 스텝 물리로 결과를 정한다. 계획서와 로컬 구현, 자동 검증까지 마쳤다. (C) 서버가 결과와 프리셋(미리 시뮬레이션한 궤적)을 확정하고 클라이언트는 재생만 한다.
결정: C안, 프리셋 베이킹을 채택했다. 서버가 결과값, 프리셋 번호, 시작 시각을 확정해 보내고 두 클라이언트가 같은 프레임부터 재생한다.
이유: 서버 CPU 비용, 물리 결과의 재현·동기화 불안, 구현 복잡도와 일정 때문이다.
한계: 서버 물리는 비공개 canary의 CPU 검증 전에 접어서 실제 비용을 측정하지 못했다. 계획서에는 온라인 수동 확인도 남아 있다.

BACK