일반적으로 메모리 부족을 처리하지 않습니다. 게임만큼 크고 복잡한 소프트웨어의 유일한 옵션은 가능한 빨리 (특히 디버그 빌드에서) 메모리 할당 기에서 충돌 / 어설 션 / 종료하는 것입니다. 메모리 부족 조건은 일부 핵심 시스템 소프트웨어 또는 서버 소프트웨어에서 테스트되고 처리되지만 경우에 따라 다른 곳에서는 처리되지 않습니다.
상단 메모리 캡이있는 경우에는 그보다 많은 양의 메모리가 필요하지 않도록하십시오. 예를 들어, 한 번에 최대 NPC 수를 유지하고 한도에 도달하면 새로운 비 필수 NPC 생성을 중지 할 수 있습니다. 필수 NPC의 경우 비 필수 NPC를 대체하거나 설계자가 알고있는 필수 NPC를위한 별도의 풀 / 캡을 가질 수 있습니다 (예 : 3 개의 필수 NPC를 보유 할 수있는 경우 설계자는 3 개 이상을 넣지 않습니다) 영역 / 청크-좋은 도구는 디자이너가이를 올바르게 수행하는 데 도움이되며 테스트는 물론 필수적입니다.)
샌드 박스 게임에는 특히 좋은 스트리밍 시스템이 중요합니다. 모든 NPC와 아이템을 메모리에 보관할 필요는 없습니다. 세계의 덩어리를 이동할 때 새로운 덩어리가 스트리밍되고 오래된 덩어리가 스트리밍됩니다. 여기에는 일반적으로 지형뿐만 아니라 NPC와 아이템도 포함됩니다. 이 시스템을 염두에두고 항목 제한에 대한 설계 및 엔지니어링 한도를 설정해야합니다. 최대 X 개의 오래된 청크가 유지되고 사전로드 된 Y 개의 새 청크가로드되므로 게임에는 모든 것을 유지할 수있는 공간이 있어야합니다. 메모리의 X + Y + 1 청크 데이터
일부 게임은 2- 패스 접근 방식으로 메모리 부족 상황을 처리하려고합니다. 대부분의 게임에는 기술적으로 불필요하게 캐시 된 많은 데이터 (예 : 위에서 언급 한 오래된 청크)가 있으며 메모리 할당은 다음과 같은 작업을 수행 할 수 있습니다.
allocate(bytes):
if can_allocate(bytes):
return internal_allocate(bytes)
else:
warning(LOW_MEMORY)
tell_systems_to_dump_caches()
if can_allocate(bytes):
return internal_allocate(bytes)
else:
fatal_error(OUT_OF_MEMORY)
이는 예기치 않은 릴리스 상황을 처리하기위한 마지막 조치이지만 디버깅 및 테스트 중에는 즉시 충돌해야합니다. 캐시를 덤프하면 성능에 심각한 영향을 줄 수 있기 때문에 이러한 종류의 내용에 의존하지 않아도됩니다.
예를 들어 GPU 메모리 (또는 공유 메모리 아키텍처의 메모리)가 부족한 경우 고해상도 밉맵 수준의 텍스처를 덤프 할 수 있습니다. 그러나 일반적으로 가치가 있기 위해서는 많은 건축 작업이 필요합니다.
매우 무제한적인 샌드 박스 게임은 PC에서도 쉽게 충돌 할 수 있습니다 (128 비트 RAM이 장착 된 PC가 64 개인 경우에도 일반 32 비트 앱의 주소 공간은 2-3GB로 제한됨을 기억하십시오) 비트 OS 및 하드웨어를 사용하면 더 많은 32 비트 응용 프로그램을 동시에 실행할 수 있지만 32 비트 바이너리가 더 큰 주소 공간을 갖도록하려면 아무것도 할 수 없습니다. 결국, 모든 경우에 무한한 메모리 공간이 필요한 매우 유연한 게임 세계가 있거나 항상 제한된 메모리 (또는 그 사이의 다른 곳)에서 완벽하게 작동하는 매우 제한적이고 통제 된 세계가 있습니다.