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