Zasadniczo nie radzisz sobie z brakiem pamięci. Jedyną rozsądną opcją w oprogramowaniu tak dużym i złożonym, jak gra, jest jak najszybsze zawieszenie / potwierdzenie / zakończenie pracy w alokatorze pamięci (szczególnie w kompilacjach debugowania). Warunki braku pamięci są testowane i obsługiwane w niektórych podstawowych programach systemowych lub oprogramowaniu serwerowym w niektórych przypadkach, ale zwykle nie w innym miejscu.
Gdy masz górny limit pamięci, po prostu upewnij się, że nigdy nie potrzebujesz więcej niż tyle pamięci. Na przykład możesz zatrzymać maksymalną liczbę dozwolonych NPC na raz i po prostu przestać pojawiać się nowych nieistotnych NPC po osiągnięciu tego limitu. W przypadku niezbędnych NPC możesz albo zastąpić nieistotnych, albo mieć osobną pulę / limit dla niezbędnych NPC, o których projektanci wiedzą, że projektują wokół (np. Jeśli możesz mieć tylko 3 niezbędne NPCsa, projektanci nie umieszczą więcej niż 3 w obszar / fragment - dobre narzędzia pomogą projektantom zrobić to poprawnie, a testowanie jest oczywiście niezbędne).
Naprawdę dobry system przesyłania strumieniowego jest również ważny, szczególnie w grach z piaskownicą. Nie musisz przechowywać w pamięci wszystkich NPC i przedmiotów. Podczas poruszania się po częściach świata nowe fragmenty będą przesyłane strumieniowo, a stare fragmenty przesyłane strumieniowo. Będą to na ogół NPC i przedmioty, a także teren. Należy wziąć pod uwagę ograniczenia projektowe i inżynierskie dotyczące limitów przedmiotów, mając na uwadze, że co najwyżej X starych kawałków zostanie zachowanych, a proaktywnie załadowane Y nowych kawałków, więc gra musi mieć miejsce na wszystko dane fragmentów X + Y + 1 w pamięci.
Niektóre gry próbują poradzić sobie z sytuacjami braku pamięci przy podejściu dwuprzebiegowym. Pamiętając, że większość gier ma wiele zbędnych technicznie zbuforowanych danych (powiedzmy, stare fragmenty wspomniane powyżej), a przydział pamięci może zrobić coś takiego:
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)
Jest to ostatni krok do rozwiązania nieoczekiwanych sytuacji w wydaniu, ale podczas debugowania i testowania prawdopodobnie powinieneś natychmiast po prostu ulec awarii. Nie chcesz polegać na tego rodzaju rzeczach (szczególnie dlatego, że zrzucanie pamięci podręcznych może mieć poważne konsekwencje dla wydajności).
Możesz również rozważyć zrzucenie kopii niektórych danych w wysokiej rozdzielczości, na przykład możesz zrzucić poziomy tekstur mipmap w wyższej rozdzielczości, jeśli masz mało pamięci GPU (lub dowolnej pamięci w architekturze pamięci współdzielonej). Jednak zazwyczaj wymaga to dużo pracy architektonicznej.
Pamiętaj, że niektóre bardzo nieograniczone gry z piaskownicą można dość łatwo po prostu rozbić, nawet na PC (pamiętaj, że popularne 32-bitowe aplikacje mają limit 2-3 GB przestrzeni adresowej, nawet jeśli masz komputer z 128 GB pamięci RAM; 64- bit OS i sprzęt pozwala na jednoczesne działanie większej liczby 32-bitowych aplikacji, ale nie można nic zrobić, aby 32-bitowy plik binarny miał większą przestrzeń adresową). W końcu albo masz bardzo elastyczny świat gry, który będzie wymagał nieograniczonej przestrzeni pamięci do działania w każdym przypadku, albo masz bardzo ograniczony i kontrolowany świat, który zawsze działa idealnie w ograniczonej pamięci (lub coś gdzieś pomiędzy).