"끝에 최적화"는 프로젝트가 인증에서 죽는 방식입니다. 성능 예산(콘텐츠가 만들어지기 전에 합의된 프레임 시간과 메모리 상한)은 최적화를 위기에서 일상 점검으로 바꿉니다. 폴리곤이 아니라 밀리초를 예산하고, 프레임을 파이처럼 나누고, 세 고정 카메라에서 측정하고, 작업이 일어나는 곳에 숫자를 보이게 하고, 장면이 빨개지면 비용 대비 효과 순서로 레버를 당기세요. 이 글은 전체 시스템을, 당신이 적응시킬 수 있는 시작 숫자와 함께 줍니다.
비스타는 늘 청구서입니다: 최대 드로 거리, 화면에 한꺼번에 모든 시스템, 활성화된 모든 LOD 링. 이 뷰를 예산하세요. 복도는 스스로 알아서 합니다.
폴리곤이 아니라 프레임 시간을 예산하라
폴리곤 예산은 유물이다: 현대 GPU는 날것의 삼각형보다 훨씬 먼저 드로 콜, 오버드로, 그림자, 메모리 대역폭에 질식한다. 당신이 실제로 측정하는 것을 예산하라: 시스템별, 뷰별 밀리초.
60 fps 게임은 프레임당 16.6 ms를 갖는다; 30 fps에서는 33.3 ms. 그것이 전체 예산이며, 모두가 나눈다: 게임플레이, 물리, AI, VFX, UI, 환경. 환경의 조각은 렌더링·게임플레이와의 협상이다. 하지만 그것은 숫자여야 한다, 합의되고 적힌. 안 그러면 어떤 장면이 "너무 비싼가"에 대한 모든 논의는 취향과 연차로 무너진다. 프레임 시간 옆에, 그것을 묶는 양에 상한을 주라:
- 뷰당 드로 콜(GPU가 포화하기 훨씬 전에 CPU를 묶는다),
- 스트리밍 존당 텍스처와 메시 메모리(스트리밍하느냐 끊기느냐를 정하는 숫자),
- 뷰 안의 그림자를 드리우는 라이트,
- 오버드로 핫스팟: 식생과 VFX가 늘 그 용의자.
정확한 상한은 플랫폼과 엔진에 달렸지만, 상한을 갖는다는 규율이 당신이 출시할 모든 프로젝트로 옮겨지는 것이다. 틀릴 수 있는 숫자가, 논쟁밖에 못 하는 감을 이긴다.
프레임을 파이처럼, 밀리초로 나눠라
각 부서에 조각을 줘라(게임플레이, VFX, UI, 환경). 그다음 환경 조각을 다시 나눠라: 지형, 식생, 소품, 물. "이 숲은 너무 비싼가?"가 객관적 질문이 된다.
60 fps 타이틀을 위한 실행 가능한 시작 분할, 프로젝트별로 재협상: 환경 총 6~8 ms, 그중 지형 ~1.5, 식생 ~2~2.5, 소품과 구조물 ~1.5, 물과 대기 ~1. 요점은 이 정확한 숫자가 아니다. 숲이 2.5 ms 조각에 대해 4 ms를 측정할 때, 대화가 "누구 탓인가" 대신 "어느 레버를 당기는가"가 된다는 것이다.
조각은 과잉 최적화에 대해서도 방어한다. 그것은 진짜이고 비싼 실패다. 자기 조각보다 한참 아래에 앉은 시스템은 여유를 품질에 쓰라는 초대이지, 지킬 트로피가 아니다. 조각 없는 팀은 가장 목소리 큰 엔지니어가 알아챈 것을 최적화하는 경향이 있는데, 그건 좀처럼 진짜 병목이 아니다: 파이 차트가 밀리초가 실제로 어디로 갔는지 말해 준다.
세 고정 카메라에서 측정하라
평균이 아니라 최악의 현실적 뷰를 예산하라: 맵당 세 고정 "예산 카메라"를 골라(최악 비스타, 가장 빽빽한 전투 공간, 가장 붐비는 실내) 매번 정확히 거기서 측정하라.
무작위 플라이스루는 무작위 숫자와 반증 불가능한 논쟁을 낳는다. 고정 카메라는 추세선을 낳는다: 같은 뷰를 주간으로 측정하면, 회귀가 언제 어디에 착지했고 누구에게 물어야 하는지 정확히 보여 준다. 최악의 비스타가 주역을 받을 자격이 있는 것은 그것이 모든 것을 한꺼번에 쌓기 때문입니다: 최대 드로 거리, 모든 LOD 링, 지형·물·하늘을 동시에. 비스타에서 예산을 지키는 맵은 거의 어디서나 지킨다; 복도는 당신에게 아부하고, 비스타는 진실을 말한다.
카메라 위치를 맵에 저장해 누구나 정확한 샷을 재현하게 하라. "어떤 각도에서 내 머신에선 잘 돈다"는 데이터가 아니다; "예산 카메라 2가 최소 사양에서 9.2 ms, 지난주 7.8에서 상승"은 용의자가 있는 버그 리포트다.
작업이 일어나는 곳에 예산을 보이게 하라
위키 속 예산은 죽었다: 그것은 세트 드레싱 중의 스탯 오버레이, 콘텐츠 머지 전 상한에 대한 점검, 그리고 베이크가 인스턴스 수를 넘길 때의 경고로 산다.
아티스트는 피드백이 즉각적일 때 예산을 기꺼이 맞추고, 작업 출시 석 달 뒤에 버그 티켓으로 올 때 원망한다. 도구 쪽은 여기서 조용하지만 결정적으로 중요하다: 스캐터와 블렌딩이 엔진 네이티브 프리미티브로 베이크할 때(Numivo가 하듯 평범한 인스턴스 메시와 foliage), 당신의 기존 프로파일러가 그것에 대해 화장 없는 진실을 말하고, 숫자를 흐리는 플러그인 런타임 없이, 모든 표준 레버(컬 거리, LOD, 인스턴스 수)가 변경 없이 적용된다. 블랙 박스를 통해서만 잴 수 있는 예산은 당신이 조용히 신뢰를 멈출 예산이다.
붙는 리뷰 주기
세 예산 카메라의 주간 캡처(5분), 콘텐츠 머지에서 자동 상한 점검, 그리고 상한 자체의 월간 리뷰: 예산은 추정이고, 정직한 개정이 조용한 위반을 이긴다.
- 주간: 스탯을 켠 채 세 카메라를 스크린샷; 프레임 시간과 메모리를 공유 시트에 기록. 추세는 한 달 안에 나타나고, 스파이크는 특정 주의 작업을 가리킨다.
- 머지 시: 자동 점검이 장면을 상한과 비교한다. 빨간 숫자는 대화를 열지, 빌드를 깨지 않는다: 목표는 인식이지 관료주의가 아니며, 하드 블록은 사람들에게 점검을 속이도록 가르친다.
- 월간: 조각 자체를 재검토하라. 프로젝트 중반 현실은 늘 프리프로 추측과 다르다; 예산을 공공연히 조정하는 것이 신뢰성을 지킨다. 모두가 조용히 무시하는 예산은 없느니만 못하다, 팀에 상한이 연극이라고 가르치니까.
숫자가 빨개질 때
비용 대비 효과 순서로 레버를 당겨라: 먼저 컬 거리와 그림자 설정(몇 분, 거대한 승리), 그다음 LOD와 임포스터, 그다음 인스턴스 수, 그리고 마지막에야 아트 그 자체.
최적화는 트리아지이지 철거가 아니다. 아트를 마지막에 허물어라: 예산 초과 비스타의 대부분은 플레이어가 볼 수 있는 무언가를 지워야 하기 훨씬 전에, 보이지 않는 설정 변경으로 초록으로 돌아온다.
비싼 실수는 곧장 "나무 절반을 지워라"로 뛰는 것이다. 밀도는 가장 보이는 레버이고 보통 가장 싸지 않다: 2 ms 초과한 비스타는 보통 그림자 거리와 컬 거리 튜닝만으로 초록으로 돌아오는데, 둘 다 플레이어에게 보이지 않는다. 콘텐츠 삭제가 최후 수단인 것은 바로 플레이어가 볼 수 있는 유일한 레버이기 때문; 사다리에서 그 위 모든 단은 아트 관점에서 공짜다. 사다리를 내려가면 밀리초를 회수하면서 룩을 보존하고; 아래에서 올라가면 공짜 승리를 시도하기도 전에 게임을 더 못생기게 만든다.
훔칠 만한 현장 수치
- 60 fps의 프레임: 16.6 ms, 환경은 보통 6~8 ms를 협상한다
- 실행 가능한 환경 하위 분할: 지형 1.5 / 식생 2~2.5 / 소품 1.5 / 물과 대기 1 (ms)
- 맵당 예산 카메라: 3(비스타, 전투, 실내), 맵에 저장
- 주간 측정 비용: ~5분; 가치: 논쟁 대신 추세선
- 빨간불에서 레버 순서: 컬링 → 그림자 → LOD → 인스턴스 → 아트
미니 FAQ
환경 예산은 누가 소유하나요? 이름 붙은 한 사람(보통 테크 아티스트)이 측정을 소유한다; 상한은 렌더링과 공동 소유. 소유자 없는 예산은 한 달 안에 민담으로 부패한다, "모두가 책임"은 아무도 측정하지 않는다는 뜻이니까.
동적 시간대에서 예산은 어떻게 작동하나요? 각 카메라에서 가장 예쁜 게 아니라 최악의 조명 조건을 측정하라. 길게 비껴 드리우는 그림자의 새벽은 흔히 정오의 두 배가 든다; 정오에만 지켜지는 예산은 반쪽 예산이고, 플레이어는 비싼 시간을 찾아낸다.
작은 인디 프로젝트에 이 전부가 필요한가요? 축소하되, 없애지 말라. 한 예산 카메라, 한 상한(최소 사양 머신의 프레임 시간), 주간 점검. 5분 습관이 마지막 달을 구하는 것입니다. 팀 규모와 무관하게 실패 모드는 동일하다: 비용을, 고치기 비쌀 때 발견하기.
메모리 대 프레임 시간은요? 그것들은 다른 실패 모드를 가진 다른 예산이다: 프레임 시간은 FPS를 떨어뜨리고, 메모리는 스트리밍을 끊김이나 크래시로 떨어뜨린다. 둘 다 예산하라; 콘솔에서 메모리가 흔히 더 단단한 상한이고, 그냥 나쁘게 느껴지는 게 아니라 인증을 떨어뜨리는 게 그쪽이다.
예산은 예술성에 대한 제한이 아니다: 아름다운 장면이 플레이어가 실제로 가진 하드웨어에서 60 fps로 여전히 아름답게 보이는 이유다. 성능을 공유 설계 제약으로 대하는 팀은 그것을 최종 보스로 대하는 팀보다 더 예쁜 게임을 출시한다.