아이템 번호를 종류별로 나누기로 했다. 100번대는 소모품이고 200번대는 무기이고 300번대는 방어구다. 정리하고 보니 중간에 다른 것이 끼어 있었다.
Table of contents
Open Table of contents
규칙을 정하고 나서 확인했다
정하고 ItemId 목록을 훑으니 무기 대역에 퀘스트 아이템이 있고 방어구 대역에 이벤트 아이템이 있었다.
ITEM_QUEST_KEY = 250, // 무기 대역
ITEM_EVENT_HAT = 305, // 방어구 대역규칙을 정하기 전에 이미 쓰던 번호가 있었다. 새로 정한 규칙은 그것을 모른 채 만들어졌다.
옮길 수 있는지 봤다
번호를 바꾸면 저장 파일에 든 itemId 가 어긋난다. 250을 갖고 있는 사람은 퀘스트 열쇠를 갖고 있는데 그 번호를 무기로 바꾸면 그 사람이 무기를 갖게 된다.
이미 밖에 나간 앱이 있으니 못 옮긴다. 옮기려면 대응표와 옮기는 코드가 필요하다. 두 개 때문에 그것을 하기는 컸다.
규칙을 현실에 맞췄다
대역을 다시 나누고 예외를 적어 뒀다.
900~999 그 밖 (퀘스트·이벤트)
예외
250 퀘스트 열쇠 — 대역 규칙이 생기기 전에 배정됨. 옮기지 않는다
305 이벤트 모자 — 같은 이유예외가 있다는 것 자체를 적어 두면 다음 사람이 규칙이 안 지켜졌다고 보고 고치려 들지 않는다.
규칙은 사람이 지키는 것이라 확인하는 코드도 넣었다. CCFileUtils 로 plist 를 읽을 때 번호가 그 종류의 대역에 있는지 보고 아니면 CCAssert 로 걸리게 했다. 알려진 예외 둘은 그 검사에서 빼 뒀다. NDEBUG 로 빌드하면 이 검사는 사라지므로 개발 중에만 도는 장치다.
대역이 찰 때와 이유 기록
새 아이템 번호를 손으로 정하다 보니 겹치는 일이 있었다. 다음 번호를 적어 두는 파일을 두고 ItemId 가 겹쳤는지 확인하는 것도 CCAssert 로 넣었다.
100개씩 나눴는데 한 대역이 찼을 때 어디를 쓸지도 미리 정했다. 안 정해 두면 그때 급하게 아무 데나 넣는다. 지금 끼어 있는 250이 그렇게 생긴 것이었다.
왜 번호로 종류를 구분해야 하는지도 적었다. CCLOG 와 서버 응답 JSON 에 번호만 나오는 자리가 있어서 표를 안 봐도 대략 무엇인지 알려는 것이다. 이유가 있으면 나중에 그냥 순서대로 매기면 안 되느냐는 물음에 답할 수 있다.
정리
- 규칙을 정하기 전에 이미 쓰던 것이 있다
- 저장된 값은 못 옮긴다. 옮기려면 대응표와 옮기는 코드가 필요하다
- 못 옮기면 규칙에 예외를 적는다
- 예외를 적어 두면 다음 사람이 고치려 들지 않는다
- 사람이 지키는 규칙은
CCAssert로 개발 중에 걸리게 한다 NDEBUG빌드에서는 사라지므로 개발 중에만 도는 장치다- 대역이 찰 때를 미리 정한다. 안 정하면 그때 아무 데나 넣는다
CCLOG에 번호만 나오는 자리가 있으면 그것이 대역을 나눈 이유가 된다