언리얼 엔진 5 문서가 에픽 디벨로퍼 커뮤니티로 이전되었습니다

Scalability (엔진 퀄리티)는 단순한 그래픽 세팅이 아니라, 타깃 플랫폼을 선택하는 것이고, 아트, 게임플레이, 사운드, AI, 기타 여러가지 시스템을 해당 플랫폼에 맞도록 결정하는 것입니다. 콘솔의 경우 플랫폼이 고정되어 있으니 꽤나 쉬운 부분입니다. 하지만 PC 의 경우, 다양한 장비 조합 갯수때문에 하나의 하드웨어 사양에 집중하기가 불가능합니다.

여기서 Scalability (엔진 퀄리티) 옵션이 등장합니다만, 트윅 작업의 필요 여부를 따지기 전에 제작하려는 어플리케이션이 선택한 최소 사양에서 실행될 것인지를 확인하기 위해 각 개발자가 할 수 있는 일이 많이 있습니다.

일반

각각의 머신마다 퍼포먼스/메모리/퀄리티 특성이 각기 다른데, 다음과 같습니다:

• 하드 디스크 크기/응답시간/대역폭

• 메인 메모리 크기/응답시간/대역폭, 64 비트가 아닌 32 비트로 실행하면 이 제약이 더욱 심해집니다.

• CPU (메인 프로세서 하나 이상, 하이퍼 스레딩, SSE 기능, 분기 예측)

• GPU (메모리, 멀티 GPU, 대역폭, 기능, 공유 메모리)

• 해상도 (최근의 노트북은 해상도는 높지만 GPU 는 느립니다.)

보통은 그래픽을 조절하는 것이 게임플레이에 큰 영향이 없는 방식입니다. 플레이어는 일반적인 퀄리티 개념으로 만족하지만, 소수는 옵션 메뉴로 가서 직접 조정을 하기도 합니다. 옵션 화면은 보통 옵션의 양이나 당혹스러운 이름 투성이로 어리둥절하기 마련입니다. 그 중에 중요하면서도 득과 실이 명확한 다수의 결정사항을 플레이어가 제어할 수 있도록 해 주는 옵션이 있습니다:

• 초당 프레임 수

• 해상도

• 이미지 퀄리티

• 모션 블러

• 텍스처 디테일

• 깜빡임 (안티에일리어싱)

• 배터리 수명

아티스트와 디자이너

언리얼 엔진은 콘텐츠 제작자의 손에 많은 능력을 주고 있으며, 거기에는 책임이 따릅니다. 퍼포먼스와 메모리 요구치는 콘텐츠의 양과 질에 직결되는 부분이며, 매우 복잡한 문제입니다:

• 콘텐츠는 보통 타깃 하드웨어 없이 제작됩니다.

• 하드웨어 속성 조합이 복잡합니다 (메모리는 적지만 빠르다든가, GPU 는 빠르지만 CPU 가 느리다든가).

• 엔진 코드가 아직 개발중에 있어 최적화가 콘텐츠 부분에서 이루어져야 합니다.

• 새로운 하드웨어와 드라이버의 등장으로 판도가 바뀝니다.

• 제한된 개발 시간때문에 최적화할 시간이 부족합니다.

• 이러한 부분에 대한 관리를 위해서는, 적절한 관례를 세워 두는 것이 최선입니다:

  • 예산을 짜고 점검합니다 (트라이앵글/오브젝트/머티리얼/라이트 수, 텍스처/메시/사운드 메모리 등).

  • 게임플레이에 관련되지 않은 콘텐츠에는 Scalibility (퀄리티 세팅) 옵션을 추가, 여러가지 높고 낮은 세팅으로 테스트해 봅니다.

    • 예: 저사양에서는 잡동사니 오브젝트를 숨기고, 단순한 머티리얼 셰이딩과 오브젝트 레벨 오브 디테일을 사용합니다.

  • 플레이어 능력을 제한시킵니다.

    • 예: 시야를 가린다든가, 임의의 복잡한 건물을 짓지 못하게 한다든가, 파괴를 제한시킵니다.

  • 퍼포먼스 특성을 이해합니다.

    • 예: 포인트 라이트가 여럿인 다수의 다이내믹 오브젝트, 메시 파티클 vs 스프라이트 파티클.

  • 여러가지 성분을 비슷한 비율로 섞습니다 (일부 하드웨어는 일정한 기능에서만 느릴 수 있습니다). 안좋은 점: 머티리얼이 단순한 다수의 오브젝트, 소수의 오브젝트에 머티리얼이 복잡한 다수의 라이트.

  • 엔진 프로파일링 툴에 대해 이해합니다.

QA

퀄리티 세팅 폭이 넓으면 QA 시간이 더욱 많이 들어갑니다. 좋은 관례를 세워 두면 도움이 됩니다:

• 저사양/추천사양/고사양 명세서를 작성합니다.

• 폭넓은 조합에서 테스트합니다 (저/중/고CPU, 저/고 CPU, 저/고 메모리).

• 재현가능한 씬에 퍼포먼스 레벨을 정의합니다.

• 시간에 따른 변화를 문서화 및 교류시킵니다.

• 특정 부분만 끄는 것은 퍼포먼스 이슈를 고립시켜 확인할 수 있는 강력한 방법입니다. (예: show 콘솔 명령)

• 최저 퀄리티 세팅으로 실행했을 때, 예상보다 훨씬 좋아보이는 부분이 있습니다. 그 부분은 엔진 퀄리티 세팅이 안되어 있을 수 있습니다 (그런 부분을 고친다는 것은 더 많은 플레이어가 게임을 즐길 수 있다는 뜻입니다).

• 엔진 퀄리티 세팅의 활용도를 테스트합니다: 혼동되거나 잘못된 것을 발견하면 보고해 주세요.

• 유저 인터페이스는 언제든 알아볼 수 있고 정상 작동해야 합니다. 낮은 해상도에다 최저 퀄리티 세팅으로 읽을 수 없는 폰트나 화면 밖으로 빠져나가는 부분이 있는지 확인해 보세요.

• 특정 퀄리티 세팅 레벨(예를 들어 "낮음")에서만 발생하는 부작용이 있다면, (그림자의 경우 "그림자 퀄리티" 를 조절하는 방식으로) 이슈를 추가로 고립시켜 볼 수 있고, 실제 콘솔 변수 세팅을 (Scalability.ini) 살펴볼 수도 있습니다.

• 퍼포먼스를 계량화시키는 방법을 알아야 합니다 (stat fps, stat unit, ...). ms(밀리세컨드)는 fps 보다 유용합니다 (10fps 빠르다 하는 것 보다는 5ms 빠르다 하는 것이 의미가 있습니다).

• 일부 노트북에는 GPU 가 여러개 있습니다 (예: 배터리 저장용 Intel HD4000 내장 그래픽 칩셋과 퍼포먼스용 NVIDIA 580m). 기본적으로 빠른 GPU 에서 실행시키고 싶겠지만, 둘 다 테스트하는 것이 최선입니다 (드라이버 세팅을 사용해서 변경할 수 있습니다). 배터리로 실행될 때는 느린 것이 선택되거나, 심지어 실행시간에 바뀔 수도 있습니다.

프로그래머

다른 플레이어의 그림자가 일찍 보이거나 프레임 수가 높은 플레이어는 반응 시간이 빨라지는 이점을 누릴 수 있습니다. 허용된 퀄리티 세팅 안에서라면 치트가 아니겠지만, 일부 퀄리티 세팅은 치트에 악용될 수가 있습니다. 콘솔 변수로 해당 퀄리티 세팅에 필요한 값 보다 더 넓은 범위의 값을 제공할 수도 있고, 콘솔 변수의 조합으로 문제가 생길 수도 있습니다. 일부 멀티플레이어 게임에서는 서버 관리자가 문제의 소지가 있는 세팅을 덮어쓸 수 있도록 하여 모든 플레이어에게 동등한 기회를 제공하는 방식으로 그러한 문제를 해결하고 있습니다.

예: 풀밭 깊숙히 숨는 것이 좋은 게임플레이 전술이 될 수 있습니다. 그러나 먼 거리에서 풀밭이 렌더링되지 않도록 한다면, 숨으려는 플레이어는 굉장히 불공평하다 느낄 수 있습니다.

이상적이라면 퀄리티 세팅은 게임플레이에 영향을 끼치면 안될 것입니다.

리드, 프로듀서, 매니저

매니저나 리드가 알아야 할 부분이라면? 폭넓은 하드웨어를 지원하는 게임을 개발하는 것은 힘이 드는 일입니다. 시간과 QA 인력이 많이 소모됩니다. 좋은 관례를 세워두면 도움이 됩니다:

• 프로젝트 개발 초기에 저사양과 추천사양을 정의해 둡니다.

• 대부분의 플레이어는 옵션 메뉴를 사용하지 않기에 "자동" 감지 기능이 중요합니다. 이 기능을 제대로 활용하기 위해서는 많은 반복 테스팅이 필요합니다.

• 퀄리티 세팅 범위를 좁히면 개발이 편해집니다 (안좋은 예: 고사양 PC 에서 저사양 모바일까지).

• 모든 (코드, 디자인, 아트 등) 부분에 있어 예비 저사양 머신을 준비해 두면 도움이 됩니다. 밸런싱 작업을 할 때는 보통 퀄리티 세팅을 추가하기 보다는 최적화를 하는 것이 낫습니다.

• 퍼포먼스는 퀄리티 세팅의 한 부분이지만, 안정성에도 영향을 끼칠 수 있습니다. 예를 들어 저사양에서 메모리가 부족한 경우, 고해상도 텍스처 옵션을 아예 탈락시켜 버리는 것이 최선일 수 있습니다.

• 저사양용 퀄리티 세팅이란 더 많은 플레이어가 게임을 플레이할 수 있도록 한다는 뜻입니다. 고사양용 퀄리티 세팅이란 특히나 스크린샷 또는 테스트에서 게임이 더 나아보이게 만든다는 뜻입니다.