기획

설계 쪽이 왜 그렇게 정했나라면, 이건 정해진 것 자체다. 아래 값은 전부 기획서와 코드에 실제로 박혀 있는 값이다.

먼저 — 문서와 데이터가 두 달 갈라져 있었다

이 페이지를 원문으로 채우려고 저장소를 열었더니, 기획서가 게임보다 두 달 뒤처져 있었다.

	기획서	실제 데이터·코드
초식 개수	28초식 (7패턴 × 4)	44초식 (11패턴 × 4)
계열 선택	ZXCV 발경 키	마우스 + 1 / 2 / 3 / Shift

GDD가 6월 12일, 초식 데이터가 8월 12일이다. 늘어난 네 패턴은 ㄱ N ㄷ ◇. 신물만 26으로 문서·데이터·에셋 셋이 일치했다.

그래서 문서를 고쳤다 — 기획서 (GDD v0.6). 폐기된 조작을 걷어내고, 매트릭스를 CSV에서 다시 뽑고, v0.5 이후 구현된 파훼 체계를 §9.4로 새로 넣었다.

증거로 남겨 두는 쪽도 생각했는데 그게 틀렸다. 뒤처진 문서를 박제하면 다음 사람이 그걸 구현한다. 그래서 규칙을 하나 세웠다.

기획이 바뀌면 같은 작업 안에서 기획서도 고친다. 폐기된 것은 남겨두지 않고 지운다.

그리고 나는 그 개정에서 오진을 했다

고친 v0.6 초판에 이렇게 적었다 — “발경 키를 ZXCV에서 QWAS로 바꿨다.” 틀렸다.

코드에서 enum SkillKey { Q, W, A, S }를 보고 “키가 QWAS구나”로 읽은 것인데, Q는 키가 아니라 계열의 이름이었다. 정본은 따로 있었다.

층위	값	정본
플레이어가 누르는 것	마우스로 획을 긋고 1 · 2 · 3 · Shift로 계열 선택	Doors.InputHint
데이터가 부르는 이름	SkillKey.Q / W / A / S	enum SkillKey · CSV Key 열
폐기된 옛 설계	Z · X · C · V 발경	GDD v0.5

그러니까 「문서 ZXCV vs 코드 QWAS」는 드리프트가 아니라 층위가 다른 둘을 맞세운 오진이었다. 드리프트는 있었지만(ZXCV → 마우스+1/2/3), 내가 이름 붙인 그 드리프트는 아니었다.

제일 아픈 건 경고가 이미 있었다는 것이다. PROJECT_LOG 51번째 줄이 정확히 이렇게 적어 두었다.

키 이야기는 “문서 ZXCV vs 코드 QWAS”가 아니다 — 층위가 다른 둘을 맞세운 것이다.

나는 그 문단을 읽었고, 뒤 문장만 인용하고 앞 문장을 버렸다. 뒤 문장이 내 이야기에 맞았기 때문이다. 반증이 같은 문단 안에 있었는데 눈에 안 들어왔다.

그래서 §8.5에 규칙을 하나 더 박았다 — TC와 버그 리포트에 조작을 적을 땐 실제 입력을, 데이터를 가리킬 땐 식별자를 쓴다. 섞어 쓰면 같은 오진이 또 난다.

그리고 고치고 나서 문서 폴더 전체를 훑었더니, 문서 하나가 아니었다 — 21개 파일에 172건이었다.

갈래	처리
현행 사양 11개 (UI 시안·데이터시트·세력 트리…)	고친다
대외 공개 문구 3개 (스토어 페이지 등)	제일 급하다
과거 기록물 7개 (로그·QA 보고서)	고치지 않는다 — 그 시점의 사실이라 고치면 기록이 훼손된다

가운데 줄이 제일 아팠다. 스토어 문구에 「검(Z)·권(X)·장(C)·보(V)」가 그대로 있었다. 안 고치면 게임은 마우스+1/2/3으로 나가는데 상점 페이지는 없는 키를 안내한다 — 드리프트가 사내 문서를 넘어 손님한테 간다. 이 셋은 그날 갱신됐고 재검사에서 0건이 나왔다.

“기획서에 그렇게 적혀 있다”는 근거가 아니다. 데이터가 게임이고 문서는 데이터를 따라오는 것인데, 혼자 만들면 따라오는 쪽을 갱신할 사람이 나뿐이라 조용히 벌어진다. 이 페이지는 둘이 갈리면 데이터 쪽을 적는다.

계열은 넷이고, 각자 하나만 깬다

문파 넷 — 검문(劍門) · 권문(拳門) · 도문(道門) · 보문(步門). 도문은 이름과 달리 장(掌) 계열을 맡는다.

步 → 劍 → 拳 → 掌 → 步          (화살표 = 깬다)

외울 것이 16개가 아니라 4개다. 그리고 관계마다 한 줄짜리 이유가 코드에 문자열로 들어 있다.

파훼	이유
步가 劍을	칼은 닿아야 벤다. 그림자는 못 벤다
劍이 拳을	주먹이 닿기 전에 칼끝이 먼저 닿는다
拳이 掌을	장력은 피하는 게 아니라 뚫는 것
掌이 步를	장력은 면(面)이다. 물러설 자리가 없다

이유 칸이 장식이 아니다. 이유 없는 상성표는 매번 표를 다시 봐야 하고, 이유가 있으면 한 번 듣고 안다.

그리고 새 어휘를 만들지 않았다. 플레이어는 이미 문을 고르고 획을 그어 초식을 낸다. 적의 초식을 같은 축 위에 세우니 파훼가 이미 아는 조작이 됐다 — 새 버튼도 새 규칙도 없다.

판정은 셋으로 갈리고, 가운데가 전부다

ClashResult.Broken → ScaleDamage = 0f    // 파훼 = 받는 피해 0
WrongDoorDamageScale             = 0.6f  // 틀린 문 = 60%
BreakCounterScale                = 2.0f  // 파훼 시 되받는 피해 2배
BreakStunSeconds                 = 1.6f  // 파훼 시 적 경직 1.6초

맞는 문으로 받으면 피해 0에 경직 1.6초 + 반격 2배가 따라온다. 틀린 문은 60%, 무대응은 정타.

가운데 칸이 이 표의 전부다. 오답을 정타와 같게 두면 아무도 시도하지 않고, 시도가 없으면 상성을 배울 기회 자체가 사라진다. 틀렸다고 판정 창이 닫히지도 않는다 — 전조가 남아 있으면 다시 낼 수 있다.

전조는 재서 정한 값이지 감으로 고른 값이 아니다

보스 한 기(흑사채주)의 8초식이 정본이다.

페이즈	초식	문	전조	피해
1	흑사출동 · 반월횡소	劍	1.10 · 1.30	22 · 25
2	독아권 · 흑린장 · 사행보	拳 掌 步	0.90 · 1.50 · 0.80	28 · 30 · 18
3	만사분류 · 칠보추혼	掌 步	1.40 · 0.95	34 · 26
절초	사왕단혼	劍	2.40	55

일반 초식은 0.80~1.50초(평균 1.14), 절초는 그 두 배인 2.40초. 절초는 3페이즈에서 22초에 한 번, 위력 2.2배로 온다.

절초만 유독 긴 이유가 있다. 0.5초로 죽이면 “못 봤다”고 하고, 2.4초를 주면 “알고도 못 했다”고 한다. 뒤쪽만이 다음 판에 다르게 하게 만든다.

드물어야 무공이다

등급	초식
卒 잡졸	없음 — 징집병. 칼은 들었지만 배운 적이 없다
兵 무사	없음 — 훈련은 받았으나 초식은 없다
將 두목	서명초식 1종 (劍·拳·掌 3종 중 하나)
보스	페이즈별 세트 + 절초

마흔 기가 몰려오는 전장에 마흔 개의 기수식이 빛나면 그건 정보가 아니라 소음이다.

두목의 초식은 난수가 아니라 개체 고유값(instanceID)으로 뽑는다. 부를 때마다 달라지면 “저 놈은 붉게 빛난다”를 배울 수 없다. 화면의 두목 셋은 서로 다르되, 각자는 끝까지 제 초식만 쓴다.

글자는 보스에게, 색은 전장에게

보스전은 일대일이라 표찰을 읽을 여유가 있다. 전장은 아니다. 그래서 전장에서는 몸이 문의 색으로 빛난다 — 붉으면 拳이고, 拳은 劍으로 깬다. 읽을 게 없고 보면 안다.

색약을 고려해 색상만이 아니라 명도까지 벌렸다: 劍 밝은 청백 → 拳 붉음 → 掌 금빛 → 步 어두운 녹빛. 아트 쪽 3층 구조를 깎지 않는 선에서다.

아직 안 정한 것 — 11건

스펙에서 제일 중요한 절이다. 안 정한 걸 안 적으면 정한 것처럼 보인다. 원문에 「결정 필요」·「미수정」·「보류」로 적힌 것이 11건이고, 그중 초식 체계에 직접 닿는 건 다섯이다.

• 마교 무공의 범위 — 원문이 “가장 중요”라고 적어 둔 것. 소수 추가 / 기존 초식 덮어쓰기 / 완전 별도 셋 중 미정
• 정↔마 전환 정책 — 자유 / 되돌릴 수 있되 대가 / 편도
• 마교 라인의 무게 — 빌드 선택지인가 서사 분기인가
• 1차 구현 대상 — 3종으로 시작할지, 보법 1종만 PoC 할지
• 전조 창 불일치 — 반격 창의 종료 시각을 시작 때 한 번 계산해서, 전조를 진행 중에 늘리면 반격 창만 먼저 닫힌다. 고치지 않고 두기로 한 것이고 재개 조건까지 적혀 있다 — “전조 길이를 실시간으로 조정하며 밸런싱하는 작업이 실제로 생길 때”

마지막 항목이 이 스펙에서 제일 정직한 줄이다. 버그를 알면서 안 고쳤고, 언제 고칠지를 적어 뒀다. 그리고 마교 쪽 문서는 부제 자체가 「검토용 제안서 — 구현 아님」이다.