한 번 재 보고 계획을 버렸다

스테이지 데이터를 어떻게 담을지 정하는 자리였다. plist 로 두는 것과 코드에 박아 넣는 것과 바이너리로 묶는 것이 있었다. 셋 중 하나를 골라야 했다.

Open Table of contents

셋을 놓고 이야기가 길어졌다

코드에 박아 넣는 쪽이 가장 빠를 것이라는 쪽이 있었다. 그러면 데이터를 고칠 때마다 다시 빌드해야 한다는 쪽도 있었다.

한 시간을 이야기했는데 결론이 안 났다. 양쪽 다 근거가 짐작이라 서로를 설득할 수단이 없었다.

셋을 다 만드는 대신 plist 쪽만 만들어 시간을 쟀다. 그때 판에는 시계가 따로 없어서 gettimeofday 로 앞뒤를 찍었다.

load = 18 ms

dictionaryWithContentsOfFile() 로 읽었다. 스테이지 60개 전부에 18밀리초였다. 빠르기가 문제가 아니었던 것이다. 한 시간 동안 무엇이 빠른지 이야기했는데 셋 다 눈에 안 띌 만큼 빨랐다.

빠르기가 안 갈리니 다른 것으로 정했다. 고칠 때 다시 빌드해야 하는지를 봤다. 기획이 직접 고칠 수 있는지도 봤다. 파일 내용이 밖에서 보이는지가 셋째다.

plist 는 XML 이라 앞의 둘이 좋고 마지막이 나쁘다. 그때 만드는 것이 혼자 하는 게임이라 내용이 보이는 것은 크게 문제가 아니었다. 고치기 쉬운 것이 가장 필요했고 대전이 들어가면 다시 본다고 적어 뒀다.

이 방식을 쓰면서 하나 걸린 것이 있다. APK 안에 든 assets 는 fopen 으로 못 연다. CCFileUtils::getFileData() 를 거쳐야 하고 그 제약이 방식 선택에도 걸린다.

60개에서 빠르다고 1,000개에서도 빠른 것은 아니다. 그래서 늘려서도 재 봤다.

60개    18 ms
200개   60 ms
1000개  284 ms

1,000개면 눈에 띈다. 스테이지가 몇 개까지 늘어날지 물어보니 200개 정도라는 답이 왔다. 지금 값과 늘어날 값을 둘 다 재고 얼마나 늘어날지는 물어서 받는다.

잰 값과 판단 근거를 적어 뒀다. 몇 달 뒤 스테이지가 180개가 됐을 때 다시 쟀다. 54밀리초로 계산과 맞았고 방식을 바꿀 이유가 없다는 것을 숫자로 확인했다.

재는 데 20분이 걸렸고 그 20분이 한 시간짜리 이야기를 끝냈다. 논쟁이 길어지면 재 볼 수 있는 것인지 먼저 봐야 했다.