-
유니티 학습 프로젝트 - < 16 > TOP NEW
개요 15편에서 좀비 수에 뚜껑을 씌워 최악의 경우를 예산 안에 넣었다. 그런데 그건 원래 하려던 게 아니었다. 원래 목표는 오브젝트를 매번 새로 만들고 부수는 대신 만들어둔 걸 돌려쓰는 것이었다. 14편에서 잰 값에는 그게 겨냥하는 비용이 안 나왔는데, 나는 그게 조건을 잘못 잡아서라고 생각했다. 그래서 조건을 다시 설계해서 한 번 더 갔다. 그리고 이 편에서 네 번째 가설까지 틀린다. 마지막엔 재고 있던 값이 게임과 아무 상관 없는 값이었다는 걸 알게 된다. 이번 글이 답할 질문. 값이 안 변한다는 것은 무엇을 뜻하는가? 1. 조건을 또 바꾼 이유 돌려쓰기가 줄이려는 비용이 뭔지부터 다시 ... Read More
-
유니티 학습 프로젝트 - < 15 > TOP NEW
개요 14편에서 얻은 결론은 비용을 결정하는 건 좀비 마리 수가 아니라 얼마나 몰려 있느냐였다. 682마리에서 753마리 사이에 프레임 시간이 다섯 배로 뛰었다. 그러면 답은 둘 중 하나다. 몰리지 않게 하거나, 애초에 그만큼 안 만들거나. 앞의 것부터 검토했고, 보고 나서 접었다. 뒤의 것을 골라 상한을 넣었다. 그리고 마지막에 실제로 플레이해봤더니 그 상한이 걸릴 일이 없었다. 이번 글이 답할 질문. 최악의 경우를 막는 장치는 그 경우가 오지 않으면 무의미한가? 1. 먼저 나온 제안을 기각했다 멘토 역할로 쓰는 AI가 먼저 낸 안은 거리 기반 회수였다. 화면 밖으로 멀어진 좀비를 걷... Read More
-
유니티 학습 프로젝트 - < 14 > TOP NEW
개요 13편에서 좀비가 몇 마리 살아 있는지를 세는 값을 만들었다. 화면에 숫자 하나 띄우려던 거였는데, 그게 이 편에서는 자(尺)로 쓰인다. 원래 계획에 최적화 항목이 하나 있었다. 오브젝트를 매번 새로 만들고 부수는 대신 만들어둔 걸 돌려쓰는 것, 그리고 매 프레임 생기는 쓰레기 메모리를 없애는 것이다. 계획서에서 이 항목만 특별했다. 다른 항목은 “됐다/안 됐다”로 끝나는데 이건 전후를 숫자로 남길 수 있는 유일한 항목이라, 마감에 쫓겨도 이건 지키자고 못을 박아뒀었다. 그래서 오늘은 그 숫자를 재러 갔다. 그리고 세 번 세운 가설이 전부 틀렸다. 이번 글이 답할 질문. 계획한 최적화가 측정에 의... Read More
-
유니티 학습 프로젝트 - < 13 > TOP NEW
개요 12편에서 하루치 이야기를 여섯 편으로 나눠 마무리했다. 그날의 결론은 이름이 설계 결함을 알려줬다는 거였다. 이번 편은 그 다음 날 이야기다. 시작은 별거 아니었다. 화면에 남은 시간이랑 좀비가 몇 마리인지 띄우는 것. 딱 그거였는데, 끝에 가서는 그 숫자를 누가 가지고 있어야 하는가를 정하고 있었다. 그리고 이번에 방향이 틀렸다고 알려준 건 이름이 아니었다. 아무도 안 쓰는 인자 하나였다. 이번 글이 답할 질문. 화면에 숫자를 띄우는 일이 왜 소유권 문제가 되는가? 1. 남은 시간 — 소수점을 초로 바꾸는 일 타이머가 들고 있는 남은 시간은 297.4183... 같은 소수다. 화면... Read More
-
유니티 학습 프로젝트 - < 12 > TOP NEW
개요 11편까지 해서 하루치 이야기를 다섯 편에 나눠 썼다. 이번 편이 마지막이고, 앞에서 다 못 담은 것들을 모았다. 모아놓고 보니 공통점이 하나 있었다. 넷 다 처음 잡은 방향이 틀렸던 것이고, 그걸 알려준 게 매번 달랐다. 어떤 건 이름이 알려줬고, 어떤 건 화면이 알려줬고, 어떤 건 아무도 안 알려줘서 한참 헤맸다. 이번 글이 답할 질문. 방향이 틀렸다는 것은 무엇을 통해 드러나는가? 1. 게임이 끝나게 만들기 이날 아침까지 이 게임은 끝나지 않는 상태였다. 좀비가 나오고 때리면 죽는데, 이기는 것도 지는 것도 없다. 원래 계획에는 게임 오버만 있고 이기는 조건이 없었다. 보스를 이번 ... Read More
-
유니티 학습 프로젝트 - < 11 > TOP NEW
개요 지난 편에서 웨이브 표를 ScriptableObject로 만들었다. 카드도 그렇게 만들었다. 그런데 사실 이걸 오늘 처음 써봤다. 이름만 보면 “스크립트로 만들 수 있는 객체”인데, 그게 무슨 뜻인지 감이 안 왔다. 클래스면 그냥 클래스지 왜 따로 이름이 붙어 있나 싶었다. 만들어보니 손은 금방 익었다. 끝까지 안 잡힌 건 다른 쪽이었다. 그래서 이걸 언제 쓰는 게 맞나. 일반 클래스나 구조체로 두면 안 되는 이유가 뭔지가 계속 걸렸다. 이번 글이 답할 질문. 값을 어디에 둘지 정할 때 무엇을 보고 정하는가? 1. 스탯을 어디에 둘까 — 후보 셋 카드를 먹으면 공격력, 공격속도, 공격범위... Read More
-
유니티 학습 프로젝트 - < 10 > TOP NEW
개요 지난 편까지 체력바와 쿨타임 바를 붙였다. 이제 게임이 시작하고, 끝나고, 화면에 상태가 보인다. 그런데 5분 내내 좀비가 같은 간격으로 같은 수만큼 나온다. 1분째나 4분째나 똑같다. 난이도 곡선이 없으니 5분을 버티는 게 아니라 그냥 5분이 지나가는 것에 가깝다. 원래 일요일에 하려던 웨이브 테이블을 당겨왔다. 만드는 것 자체는 표 하나에 시간·간격·마릿수를 적어두고 때 되면 갈아끼우는 것뿐인데, 그 “때 되면”을 누가 재느냐에서 한참 걸렸다. 이번 글이 답할 질문. 게임에서 시간을 세는 곳은 몇 군데여야 하는가? 1. 코루틴을 안 썼다 — 시계가 둘이면 어긋난다 주기적으로 뭔가 하는... Read More
-
유니티 학습 프로젝트 - < 9 > TOP NEW
개요 지난 편에서 카드 선택 창을 붙였다. 카드를 고르면 체력이 오르고 공격력이 오른다. 그런데 화면에는 그게 안 보인다. 체력이 100인지 120인지, 대시를 지금 쓸 수 있는지 없는지 전부 감으로 해야 한다. 그래서 체력바와 대시 쿨타임 바를 붙이는 게 이번 작업이었다. 붙이는 것 자체는 어렵지 않았다. 오래 걸린 건 “이미 있는 걸 그대로 쓰면 안 되나” 를 확인하는 쪽이었다. 이번 글이 답할 질문. 이미 있는 신호를 재활용해도 되는지 어떻게 판단하는가? 1. 피격 이벤트를 체력바에 재활용해도 되나 체력이 깎이는 순간을 알려주는 신호는 이미 있다. 맞았을 때 발화하는 OnDamaged다.... Read More