본문으로 건너뛰기

게임을 만들면서 찾은 것

도구 보고변환에서 나온 것이고, 적용 기록은 제가 규격을 잘못 읽은 것입니다. 이 문서는 셋째 갈래입니다 — 표를 읽어 실제로 게임을 돌렸을 때 드러난 것.

이 갈래가 따로 있는 이유가 있습니다. 변환은 끝까지 돌았고, 생성 C#은 컴파일되었으며, 값도 시트대로였습니다. 그런데도 게임은 돌지 않았습니다 — 지역 2가 열리지 않아 첫 지역에서 끝나는 상태였습니다. 그 종류의 결함은 변환의 어느 검사에도 걸리지 않습니다.

#무엇상태
1완성률을 적을 Requirement 변종의 부재고쳤습니다 — 변종을 더했습니다
2종 단위 조각과 재화로 적힌 비용고쳤습니다 — 상수셋에 두었습니다
3뺄셈으로 읽은 DefenseFactor 와 무력해지는 방어읽는 법을 정했습니다
4bonus_factor 의 단위 — 배수가 아니라 증분읽는 법을 정했습니다
5각성 직후의 능력치 하락 구간열려 있습니다 — 밸런스 결정 대기
6서버 표 EncounterTable 과 단독 실행정하고 적었습니다

1. 완성률을 적을 Requirement 변종의 부재

무엇이 일어났나. 기획서 11.3 은 지역 해금을 「수호자 격파 · 기록부 완성률 N%」로 정했습니다. 그런데 Requirement 의 변종은 넷이고 완성률을 적을 자리가 없습니다.

변종주어
LevelRequirement그 개체
CodexRequirement그 개체
ItemRequirement플레이어
StageRequirement플레이어

데이터는 가장 가까운 것으로 적었습니다 — CodexRequirement(codex_state=Recorded). 하지만 그 변종은 주어가 필요합니다. 각성에서는 각성할 개체가 주어이고, 지역 해금에는 주어가 없습니다.

왜 문제인가. 클라이언트가 그 조건을 평가할 수 없습니다. 「어느 종이 기록되어야 하는가」가 어디에도 적혀 있지 않으므로, 만족한 것으로 볼 수도 만족하지 않은 것으로 볼 수도 없습니다. 자동 플레이 검사는 수호자를 넘었는데 다음 지역이 열리지 않는다로 이것을 검출했습니다.

어떻게 고쳤나. 변종을 하나 더했습니다.

/// 기록부 완성률. 기획서 11.3 의 지역 해금이 이것을 요구합니다 — 「기록 이상인 행의 비율」
/// 이고 주어가 없습니다.
struct CodexCompletionRequirement extends Requirement @5
field percent int (min=1, max=100)

그리고 RequirementEntry 의 지역 해금 행을 기획서 11.3 의 표대로 다시 적었습니다 — 소금해안은 완성률 요구가 없고, 재의 화구 25% · 서릿능선 40% · 잠긴 신전 60% 입니다.

이것이 다형 레코드의 값입니다. 변종을 더하는 것이 컬럼 하나 더하는 것으로 끝났고, 다른 변종을 쓰는 114행은 한 칸도 움직이지 않았습니다.

2. 종 단위 조각과 재화로 적힌 비용

무엇이 일어났나. 기획서 5.4 는 울림 조각을 종 단위로 정했습니다 — 「이미 동행 중인 종을 다시 발견하면 그 종의 울림 조각으로」. ShardRewardmonster_id 를 듭니다.

그런데 MonsterAwakening.costsCost 이고 currency_id 를 듭니다. Currencyshard 행이 있으므로 표기는 성립하지만, 그 재화는 종이 없습니다.

왜 문제인가. 조각을 400개 들고 있는데 각성 화면이 「울림 조각 10 부족」이라고 적습니다 — 지급은 종별 잔량으로 들어가고 비용은 전역 잔량에서 나가기 때문입니다.

어떻게 고쳤나. 어느 재화가 종 단위인지를 상수셋에 두었습니다.

:const CollectionConst
ShardCurrency string shard 조각의 재화 식별자. 이 재화의 비용은 종 단위로 치릅니다

코드는 CollectionConst.ShardCurrency 를 읽습니다. 재화 이름이 코드에 고정되지 않는 것이 요점입니다 — 이름을 바꾸면 시트에서 따라갑니다.

3. 뺄셈으로 읽은 DefenseFactor 와 무력해지는 방어

무엇이 일어났나. 기획서 9.3 의 식은 이렇습니다.

피해 = (공격 × 스킬 배수 - 방어 × 방어계수) × 상성 배수 × 치명 배수

DefenseFactor 는 만분율 60 입니다. 1단 와일드링의 방어가 32이므로 빼지는 값이 0.19 입니다. 방어가 피해에 아무 영향을 주지 않습니다.

왜 문제인가. 역할 셋 중 하나가 「피해를 받는 자리」인데 그 능력치가 작동하지 않습니다.

어떻게 읽었나. 컬럼 설명이 「방어가 피해를 깎는 비율」입니다. 비율로 읽으면 방어 32가 19.2%를, 3단의 방어 101이 60.6%를 깎습니다 — 값의 크기가 그 읽기에 맞습니다.

피해 = 공격 × 스킬 배수 × (1 - min(방어 × 방어계수, 상한)) × 상성 배수 × 치명 배수

상한 80%는 코드에 있습니다. 없으면 고레벨에서 피해가 0이 됩니다. 기획서의 식을 고치거나 이 상한을 표로 내리는 것 중 하나가 남아 있습니다.

4. bonus_factor 의 단위 — 배수가 아니라 증분

무엇이 일어났나. 같은 표의 hp_factor · attack_factor · defense_factor 는 전부 만분율 배수이고 min=10000 제약이 붙어 있습니다. bonus_factor 는 10레벨마다 2000 이고 제약이 없습니다.

배수로 읽어 곱하면 10레벨마다 능력치가 5분의 1이 됩니다 — 1레벨 체력 420이 20레벨에서 61이 되었습니다.

어떻게 읽었나. 증분입니다. 1 + 2000/10000 을 곱합니다.

표기가 이것을 구별하지 못하는 것이 자리입니다. 두 컬럼이 같은 int 이고 같은 만분율인데 한쪽은 배수이고 한쪽은 증분입니다. min=10000 이 있고 없고가 유일한 표시입니다.

5. 각성 직후의 능력치 하락 구간

무엇이 일어났나. 기획서 7.3 이 이렇게 적었습니다.

각성 직후 능력치가 직전보다 낮아지는 구간을 만들지 않기 위해, 다음 단계의 1레벨 기준값을 직전 단계 상한 레벨의 실제 능력치보다 높게 배치합니다. 이 관계가 깨지면 각성이 손실로 인식되므로, 검증 규칙으로 검사합니다.

데이터는 그렇지 않습니다.

자리체력
sprout_deer_1 20레벨 · 공명 53,193
sprout_deer_2 1레벨 · 공명 51,096
sprout_deer_2 40레벨 · 공명 514,612

각성 직후 3분의 1로 떨어지고 12레벨에서 회복합니다.

검증 규칙은 다른 것을 검사하고 있습니다. MonsterAwakeningRules.cs 가 비교하는 것은 from.Base.Hpto.Base.Hp 입니다 — 둘 다 1레벨 기준값이므로 「다음 단계가 더 세다」까지만 봅니다. 기획서가 적은 「직전 단계 상한 레벨」과는 다릅니다.

열어 둡니다. 고치는 방법이 둘이고 어느 쪽인지는 밸런스 결정입니다.

고치는 방법드는 것
단계별 기준값을 상한 배수만큼 올립니다Monster 의 36행 × 기준값 6개, MonsterAwakening 의 증가치, 그리고 그 값을 쓰는 스테이지 난도
기획서 7.3 을 「일시적으로 낮아지되 곧 회복한다」로 고칩니다문장 하나. 지금 데이터가 그 모습입니다

자동 플레이 검사는 「각성이 결국 이득인가」만 실패로 봅니다 — 새 단계의 상한이 옛 단계의 상한보다 높아야 합니다. 일시적인 하락은 실패로 보지 않고 회복 레벨을 보고에 적습니다.

6. 서버 표 EncounterTable 과 단독 실행

EncounterTableside=s 로 선언되어 있습니다 — 「확률은 클라이언트가 알 필요가 없다」입니다. 이 게임은 단독 실행이므로 클라이언트가 굴립니다.

그대로 두었습니다. 선언을 고치면 그 선언이 무엇을 위한 것이었는지가 사라집니다. 대신 굴리는 자리(Sim/Expedition.cs)에 서버가 있는 프로젝트라면 이 함수가 서버에 있게 된다고 적어 두었습니다.


곁가지 — 각성을 강제하는 수호자

결함은 아니지만 적어 둘 만합니다. 첫 지역의 수호자는 39레벨 상대이고 1단의 레벨 상한은 GrowthConst.LevelCapStage120입니다. 그래서 1단만으로는 이길 수 없고, 각성해서 2단의 상한 40까지 올려야 넘어갑니다.

적의 레벨은 플레이어의 상한을 따르지 않습니다. GrowthCurve 가 모든 등급에서 70레벨까지 있으므로 계산은 됩니다. 상한은 플레이어 쪽 규칙입니다.

자동 플레이 검사가 이 벽을 실제로 넘습니다 — 막히면 탐사 · 육성 · 공명 · 각성을 하고 다시 도전합니다. 기획서 2.1 의 한 바퀴가 그대로 검사가 되었습니다.


EOD