같은 숫자를 세 곳에 적어 두고 있었다

최대 소지 개수를 99로 바꿨는데 어떤 화면에서는 여전히 50에서 막혔다.

Open Table of contents

세 곳에 있었다
한 곳에서 받아 오게 했다
경계를 넘길 때 걸렸다
남은 하드코딩과 확인
정리

세 곳에 있었다

게임 로직과 Java 화면과 서버 응답 검사 셋에 같은 값이 적혀 있었고 나는 첫 번째만 고쳤다.

C++와 Java 와 서버 설정에 각각 있으니 grep 으로도 한 번에 안 잡혔다. 언어가 다르면 같은 값이라도 적는 방식이 달라진다.

각 층에서 확인이 필요한 것은 맞다. 실제로 담을 때와 담기 전에 안내할 때와 조작된 요청을 막을 때 각각 확인이 있어야 한다. 문제는 확인이 셋인 것이 아니라 값이 각자 적혀 있는 것이었다.

한 곳에서 받아 오게 했다

서버가 값을 주고 앱이 켤 때 JSON 으로 받아 두고 그것을 쓰게 했다. Java 쪽도 같은 값을 본다.

int GameConfig::maxPotion() {
    return s_config.getInt("max_potion", 99);
}

서버에 못 붙었을 때를 위해 기본값을 뒀다. 기본값이 서버 값과 다를 수 있는데 그건 받아 온 뒤에 맞춰진다. 기본값을 안 두면 오프라인에서 앱이 안 돌아가므로 못 받아 왔을 때 어떻게 할지가 같이 정해져야 했다.

경계를 넘길 때 걸렸다

C++와 Java 사이에 값을 넘기는 것을 만들었는데 처음에 안 됐다. FindClass 가 빈 값을 돌려줬다. 게임 스레드에서 부르면 못 찾고 메인에서 부르면 찾는다.

나중에 JNI 문서를 보니 그대로 적혀 있었다. 직접 만든 스레드에는 앱 쪽 스택이 없어서 FindClass 가 시스템 클래스 로더를 쓴다. 앱 클래스는 거기 없다. 문서가 준 길은 셋이었고 JNI_OnLoad 에서 미리 찾아 두는 것이 가장 간단했다. 나는 ClassLoader 를 잡아 두고 loadClass 를 직접 부르는 쪽으로 했는데 손이 더 갔다.

남은 하드코딩과 확인

한 곳에서 받아 오게 바꿨어도 실제로 같은지 확인이 필요해서 개발 빌드에서 켤 때 두 값을 비교하게 했다. 어긋나면 그 자리에서 멈춘다.

숫자가 박힌 자리도 다시 찾았다.

$ grep -rn "\b99\b\|\b50\b" --include=*.cpp --include=*.java . | grep -i "count\|max\|limit"

두 곳이 더 나왔다. 화면에 몇 개까지라고 글자로 적어 둔 곳과 시험용 코드였다. 글자로 적은 것도 값에서 만들게 바꿨다. 문구 안의 숫자도 같은 값이다.

정리

같은 값이 여러 곳에 적혀 있으면 한 곳만 고치게 된다
층마다 확인이 필요한 것은 맞다
문제는 확인이 여럿인 것이 아니라 값이 각자 적혀 있는 것이다
한 곳에서 받아 오게 하고 나머지는 그것을 본다
못 받아 왔을 때 어떻게 할지 같이 정한다
FindClass 는 직접 만든 스레드에서 시스템 클래스 로더를 쓴다
JNI_OnLoad 에서 미리 찾아 두는 것이 가장 간단하다
화면에 글자로 적은 숫자도 값에서 만든다