성능을 설계한다는 것은 게임을 구축하는 동안 일부 모범 사례를 따르는 것을 의미합니다. 개발 프로세스 후반에 성능 문제를 찾아서 수정하는 것과 비교할 때, 초기 단계에서 성능을 염두에 두고 설계하는 것은 많은 시간과 노력을 절약할 수 있습니다.
저사양 기기
저사양 기기, 특히 모바일 기기는 메모리 제한이 심각하며 메모리 부족(OOM) 오류로 인해 충돌이 발생하기 쉽습니다:
저사양 기기를 지원하고 싶다면 적어도 하나의 "기준" 기기를 선택하고, 게임을 이를 대상으로 테스트하며, 프레임 속도와 메모리 사용량에 주의를 기울여야 합니다. 게임에서 문제 영역을 찾으면 해당 영역을 사용하여 기기의 한계를 파악하십시오.
예를 들어 Render (ShiftF2)와 Summary (ShiftF2) 디버그 통계를 활성화하여 게임을 테스트할 수 있습니다. 특히 혼잡한 지역에서 프레임 속도가 떨어지기 시작하면 Draw (scene) 수치를 검토하여 게임이 기준 기기에서 잘 실행되기 위해서는 1,000개의 드로우 호출 및 1,000,000개의 삼각형 이하로 유지해야 한다는 것을 알 수 있습니다.
또는 Developer Console (F9)을 검토하여 메모리 사용량이 약간 높은 것을 알 수 있으며, 스트리밍을 활성화하지 않으면 그렇다는 것을 알 수 있습니다. 기기 한계에 대한 명확한 이해는 게임을 계속 구축하는 동안 그 한계 내에서 유지하는 데 도움이 될 수 있습니다.
Roblox Studio의 기기 에뮬레이터는 화면 비율과 컨트롤을 확인하는 데 유용하지만, 메모리 사용량에 대해서는 정확하지 않습니다. Studio에서 게임을 테스트하면 서버와 클라이언트가 동시에 실행되어 메모리 사용량이 상당히 높습니다.
Roblox는 기기의 모든 메모리에 접근할 수 없습니다. 운영 체제 및 기타 애플리케이션에 필요한 메모리 양이 있습니다.
보다 일반적으로, 다양한 기기에서 테스트하면 다양한 그래픽 품질 수준에서 게임이 시각적 및 성능 기대치를 충족하는지 확인하는 데 도움이 될 수 있습니다. 저사양 모바일 기기에 대한 게임 최적화를 어떻게 생각할 수 있는지에 대한 보다 자세한 예는 실제 빌딩 및 스크립팅 최적화를 참조하십시오.
스트리밍 및 텔레포트
인스턴스 스트리밍은 Roblox가 3D 콘텐츠를 동적으로 로드하고 언로드하는 기능을 제공하며, 특히 더 큰 장소에서 대부분의 장소에 대해 훌륭한 옵션입니다. 스트리밍은 참가 시간을 개선하고, 메모리 사용량을 줄이며, 프레임 속도를 증가시킵니다.
예를 들어 Workspace.EnableSLIMAvatars를 활성화하고 월드 모델의 LevelOfDetail 속성을 SLIM으로 설정하면, 소셜 공간과 혼잡한 이벤트를 포함한 세계를 만들 수 있으며, 이는 다양한 기기 성능 범위에서 시각적으로 populated된 상태를 유지합니다. 자세한 정보는 성능 개선을 참조하십시오.
큰 장소를 더욱 관리하기 쉬운 장소로 나누고 텔레포테이션을 사용하여 플레이어를 이동시키는 것을 고려하십시오. 이 접근 방식은 초기 참가 시간을 줄일 수 있지만, 플레이어가 장소 간에 텔레포트할 때는 추가 참가 시간이 발생합니다. 메모리 사용량에 대한 이점은 장소의 크기와 스트리밍을 활성화했는지 여부에 따라 다릅니다.
성능 고려사항을 무시하더라도, 여러 장소를 보유하는 것이 개발 프로세스를 간소화할 수 있으며, 특히 게임에 새로운 콘텐츠를 정기적으로 추가하거나 더 큰 팀의 일원인 경우에 그렇습니다.
재료 및 중복
내장 재료는 커스터마이징된 텍스처보다 훨씬 적은 메모리를 사용하지만, 예술적 비전에 맞지 않을 수 있습니다. 게임의 핵심이 되는 텍스처에 대한 메모리 예산을 절약하기 위해 가능한 한 재료를 사용하십시오.
자산을 만들 때, 패키지로 변환하십시오. 패키지를 작업 흐름에 포함시키면 서로 다른 ID를 가진 중복 자산으로 인한 일반적인 문제를 피하는 데 도움이 됩니다.
투명도
- 0(보임)과 1(숨김) 이외의 투명도 값을 피하십시오. 부분 투명도를 사용할 때는 높은 투명도 중복(overdraw)를 피하는 데 특히 주의해야 합니다.
스크립팅
가능한 경우, 프레임 단위 계산이 아니라 이벤트 기반 코드를 작성하십시오. 60 FPS에서 각 프레임의 총 예산은 16.67 밀리초(ms)입니다. 사소해 보이는 프레임 단위 계산조차도 그 예산의 상당 부분을 사용할 수 있습니다.
장시간 실행되는 코드를 관리 가능한 청크로 나누는 방법을 찾으십시오. 코드의 일부분이 실행하는 데 100 ms가 걸리고 매 프레임마다 실행한다면, 게임은 10 FPS로만 실행될 수 있습니다. 그렇지 않고 60 FPS로 실행되는 게임에서 매 초마다 코드의 실행을 결정한다면, 59개의 프레임이 16.67 ms 후에 도착하고, 하나는 100 ms 후에 도착해 버퍼링이 발생할 수 있습니다.
대신 코드를 어떻게 나눌 수 있는지 살펴보십시오. 매 프레임마다 5 ms의 작업을 수행하고 task.wait()를 사용하며, 60 FPS를 유지하면서 매 20 프레임마다 완료된 계산을 수행할 수 있습니다. 멀티스레딩, 때로는 Parallel Luau라고도 불리며, 도움이 될 수 있습니다.
RBXScriptConnection:Disconnect() 메서드를 사용하여 이벤트가 발생할 때 불필요하게 함수 호출이 되지 않도록 하십시오.
값을 필요할 때마다 같은 메서드를 호출하지 마십시오. 메서드를 한 번 호출하고 값을 저장한 후 필요에 따라 나중에 덮어쓰십시오.
모든 것을 ReplicatedStorage에 저장하지 마십시오. 클라이언트는 이 컨테이너에 있는 모든 것을 로드합니다. 대신 클라이언트가 접근할 필요가 없는 것은 ServerStorage를 사용하십시오.