삐에로의 지식창고

개요 넥토리얼 대비로 CS 기본기를 다시 훑는 중이다. 멀티스레드는 이론 정리 - < 프로세스, 스레드, 데드락 >와 이론 정리 - < 임계 영역과 스레드 풀 >에서 이미 두 번 정리해뒀던 주제라, 이번엔 가볍게 복습만 하고 넘어갈 생각이었다. 그래서 방식을 조금 바꿔봤다. 눈으로 읽는 대신 말로 설명해봤다. 읽으면 다 아는 내용인데, 입 밖으로 꺼내니 속도가 확 달라진다.. 크게 세 종류로 갈렸다. 그대로 나오는 것 — Mutex가 하는 일, 임계 영역, 컨텍스트 스위칭 비용. 여기는 예전 정리가 잘 버텨줬다 잠시 잊고 있던 것 — 알고는 있었는데 바로 안 나오는 것들. Loc... Read More

개요 15편에서 좀비 수에 뚜껑을 씌워 최악의 경우를 예산 안에 넣었다. 그런데 그건 원래 하려던 게 아니었다. 원래 목표는 오브젝트를 매번 새로 만들고 부수는 대신 만들어둔 걸 돌려쓰는 것이었다. 14편에서 잰 값에는 그게 겨냥하는 비용이 안 나왔는데, 나는 그게 조건을 잘못 잡아서라고 생각했다. 그래서 조건을 다시 설계해서 한 번 더 갔다. 그리고 이 편에서 네 번째 가설까지 틀린다. 마지막엔 재고 있던 값이 게임과 아무 상관 없는 값이었다는 걸 알게 된다. 이번 글이 답할 질문. 값이 안 변한다는 것은 무엇을 뜻하는가? 1. 조건을 또 바꾼 이유 돌려쓰기가 줄이려는 비용이 뭔지부터 다시 ... Read More

개요 14편에서 얻은 결론은 비용을 결정하는 건 좀비 마리 수가 아니라 얼마나 몰려 있느냐였다. 682마리에서 753마리 사이에 프레임 시간이 다섯 배로 뛰었다. 그러면 답은 둘 중 하나다. 몰리지 않게 하거나, 애초에 그만큼 안 만들거나. 앞의 것부터 검토했고, 보고 나서 접었다. 뒤의 것을 골라 상한을 넣었다. 그리고 마지막에 실제로 플레이해봤더니 그 상한이 걸릴 일이 없었다. 이번 글이 답할 질문. 최악의 경우를 막는 장치는 그 경우가 오지 않으면 무의미한가? 1. 먼저 나온 제안을 기각했다 멘토 역할로 쓰는 AI가 먼저 낸 안은 거리 기반 회수였다. 화면 밖으로 멀어진 좀비를 걷... Read More

개요 13편에서 좀비가 몇 마리 살아 있는지를 세는 값을 만들었다. 화면에 숫자 하나 띄우려던 거였는데, 그게 이 편에서는 자(尺)로 쓰인다. 원래 계획에 최적화 항목이 하나 있었다. 오브젝트를 매번 새로 만들고 부수는 대신 만들어둔 걸 돌려쓰는 것, 그리고 매 프레임 생기는 쓰레기 메모리를 없애는 것이다. 계획서에서 이 항목만 특별했다. 다른 항목은 “됐다/안 됐다”로 끝나는데 이건 전후를 숫자로 남길 수 있는 유일한 항목이라, 마감에 쫓겨도 이건 지키자고 못을 박아뒀었다. 그래서 오늘은 그 숫자를 재러 갔다. 그리고 세 번 세운 가설이 전부 틀렸다. 이번 글이 답할 질문. 계획한 최적화가 측정에 의... Read More

개요 12편에서 하루치 이야기를 여섯 편으로 나눠 마무리했다. 그날의 결론은 이름이 설계 결함을 알려줬다는 거였다. 이번 편은 그 다음 날 이야기다. 시작은 별거 아니었다. 화면에 남은 시간이랑 좀비가 몇 마리인지 띄우는 것. 딱 그거였는데, 끝에 가서는 그 숫자를 누가 가지고 있어야 하는가를 정하고 있었다. 그리고 이번에 방향이 틀렸다고 알려준 건 이름이 아니었다. 아무도 안 쓰는 인자 하나였다. 이번 글이 답할 질문. 화면에 숫자를 띄우는 일이 왜 소유권 문제가 되는가? 1. 남은 시간 — 소수점을 초로 바꾸는 일 타이머가 들고 있는 남은 시간은 297.4183... 같은 소수다. 화면... Read More

개요 11편까지 해서 하루치 이야기를 다섯 편에 나눠 썼다. 이번 편이 마지막이고, 앞에서 다 못 담은 것들을 모았다. 모아놓고 보니 공통점이 하나 있었다. 넷 다 처음 잡은 방향이 틀렸던 것이고, 그걸 알려준 게 매번 달랐다. 어떤 건 이름이 알려줬고, 어떤 건 화면이 알려줬고, 어떤 건 아무도 안 알려줘서 한참 헤맸다. 이번 글이 답할 질문. 방향이 틀렸다는 것은 무엇을 통해 드러나는가? 1. 게임이 끝나게 만들기 이날 아침까지 이 게임은 끝나지 않는 상태였다. 좀비가 나오고 때리면 죽는데, 이기는 것도 지는 것도 없다. 원래 계획에는 게임 오버만 있고 이기는 조건이 없었다. 보스를 이번 ... Read More

개요 지난 편에서 웨이브 표를 ScriptableObject로 만들었다. 카드도 그렇게 만들었다. 그런데 사실 이걸 오늘 처음 써봤다. 이름만 보면 “스크립트로 만들 수 있는 객체”인데, 그게 무슨 뜻인지 감이 안 왔다. 클래스면 그냥 클래스지 왜 따로 이름이 붙어 있나 싶었다. 만들어보니 손은 금방 익었다. 끝까지 안 잡힌 건 다른 쪽이었다. 그래서 이걸 언제 쓰는 게 맞나. 일반 클래스나 구조체로 두면 안 되는 이유가 뭔지가 계속 걸렸다. 이번 글이 답할 질문. 값을 어디에 둘지 정할 때 무엇을 보고 정하는가? 1. 스탯을 어디에 둘까 — 후보 셋 카드를 먹으면 공격력, 공격속도, 공격범위... Read More

개요 지난 편까지 체력바와 쿨타임 바를 붙였다. 이제 게임이 시작하고, 끝나고, 화면에 상태가 보인다. 그런데 5분 내내 좀비가 같은 간격으로 같은 수만큼 나온다. 1분째나 4분째나 똑같다. 난이도 곡선이 없으니 5분을 버티는 게 아니라 그냥 5분이 지나가는 것에 가깝다. 원래 일요일에 하려던 웨이브 테이블을 당겨왔다. 만드는 것 자체는 표 하나에 시간·간격·마릿수를 적어두고 때 되면 갈아끼우는 것뿐인데, 그 “때 되면”을 누가 재느냐에서 한참 걸렸다. 이번 글이 답할 질문. 게임에서 시간을 세는 곳은 몇 군데여야 하는가? 1. 코루틴을 안 썼다 — 시계가 둘이면 어긋난다 주기적으로 뭔가 하는... Read More