Pamięć absolutna czy absolutne minimum? Czy 32 GB RAM w PS6 będzie wystarczające dla nowoczesnych gier w 4K?

Ubóstwiamy cyferki. W branżowym dyskursie to właśnie teraflopy pełnią rolę waluty ostatecznej. Licytujemy się na liczbę rdzeni, taktowanie zegarów i surową moc obliczeniową układów GPU, traktując je niczym fetysz. Tymczasem prawdziwy dramat rozgrywa się zazwyczaj na zapleczu, w cieniu tych błyszczących specyfikacji. Mowa o pamięci operacyjnej – komponencie, który od dekad jest dla inżynierów i deweloperów tym, czym dla maratończyka jest pojemność płuc. Możesz mieć najsilniejsze nogi świata (czytaj: potężne GPU), ale jeśli nie dostarczysz im tlenu (danych) w odpowiednim tempie, padniesz twarzą w asfalt na dziesiątym kilometrze. Pamięć w świecie konsol nigdy nie była sexy. Nie sprzedaje się jej na pudełkach tak łatwo jak „8K” czy „120 FPS”. Jest jednak fundamentalnym bottleneckiem, o który rozbijały się marzenia wizjonerów od czasów pierwszego PlayStation.

Obecna generacja konsol, z jej „magicznymi” dyskami SSD i zunifikowanymi 16 GB pamięci GDDR6, miała być końcem ery wąskich gardeł. Pamiętacie te obietnice? Koniec ekranów ładowania, natychmiastowy dostęp do assetów, pełna wolność twórcza. Rzeczywistość, jak to ma w zwyczaju, szybko zweryfikowała te marketingowe slajdy. Nastał czas Unreal Engine 5. Okazało się, że fotorealistyczne tekstury, miliardy trójkątów w systemie Nanite i dynamiczne oświetlenie Lumen to wygłodniałe bestie, które te 16 gigabajtów połykają na przystawkę. W efekcie, zamiast rewolucji, coraz częściej oglądamy festiwal kompromisów: agresywny upscaling, szarpanie animacji i tekstury, które wciąż potrafią doczytać się na naszych oczach, burząc immersję równie skutecznie, co błąd krytyczny aplikacji. Developerzy, zamiast tworzyć nowe światy, znów spędzają bezsenne noce na walce o każdy megabajt, upychając dane kolanem.

A przecież technologiczny wyścig dopiero nabiera tempa. Stoimy u progu zmiany paradygmatu, w którym deweloperzy chcą porzucić tradycyjną rasteryzację na rzecz pełnego Path Tracingu - świętego graala grafiki, wymagającego trzymania w pamięci gigantycznych struktur danych opisujących geometrię całego świata. W kuluarach coraz głośniej mówi się, że PlayStation 6 i kolejny sprzęt Microsoftu celują w 32 GB zunifikowanej pamięci RAM. Na papierze brzmi to jak solidny, dwukrotny wzrost. W praktyce może się okazać, że to krok zbyt konserwatywny, wręcz zachowawczy, by udźwignąć ciężar nieskompresowanych tekstur i symulacji fizycznych o skali, jakiej dotąd nie widzieliśmy. Zanim jednak wybiegniemy w przyszłość, musimy zrozumieć, dlaczego pamięć w konsolach to temat tak cholernie skomplikowany i dlaczego proste porównania do pecetów prowadzą w tym przypadku na techniczne manowce.

Dlaczego konsola to nie PC

Aby zrozumieć, dlaczego deweloperzy narzekają na 16 GB pamięci, musimy najpierw zburzyć pewien mit. W świecie PC panuje segregacja rasowa podzespołów. Mamy pamięć RAM dla procesora - to taki roboczy magazyn na logikę gry, fizykę i system operacyjny. Osobno mamy VRAM (GDDR) na karcie graficznej - ekskluzywna przestrzeń dla tekstur i shaderów. Komunikacja między tymi dwoma światami odbywa się przez szynę PCIe. Choć z roku na rok coraz szybsza, wciąż pozostaje ona „autostradą”, na której mogą tworzyć się korki, gdy próbujemy przerzucić gigabajty danych z dysku, przez CPU, do karty graficznej. To architektura marnotrawna, bo często te same dane muszą być dublowane w obu rodzajach pamięci.

Konsole odrzuciły ten model na rzecz zintegrowanej architektury pamięci (tzw. UMA - Unified Memory Architecture). Wnętrze PlayStation 5 czy Xboxa Series X przypomina wielki, wspólny stół, przy którym siedzą zarówno CPU, jak i GPU. Nie ma tu podziału na „moje” i „twoje”. Jest jedna, szybka pula pamięci, do której oba układy mają bezpośredni dostęp. To rozwiązanie genialne w swojej prostocie. Gdy procesor skończy obliczać fizykę zniszczenia ściany, nie musi pakować tych danych i wysyłać ich „pocztą” do karty graficznej. On po prostu wskazuje palcem: „Hej, GPU, dane leżą pod adresem 0x00F1, bierz i rysuj”. Fachowo nazywa się to "zero-copy sharing". To właśnie dzięki temu trikowi konsole z 16 GB RAM potrafią wyświetlić światy, które na PC dławiłyby się nawet przy 24 gigabajtach, gdyby nie były idealnie zoptymalizowane.

Ale nie ma róży bez kolców. Decyzja o użyciu pamięci graficznej jako pamięci systemowej to inżynieryjny kompromis, który ma swoją cenę:

• Problem opóźnień. Pamięć GDDR jest niczym wąż strażacki (tak obrazowo) - ma potężną przepustowość, świetnie nadaje się do lania ogromnymi strumieniami danych (tekstury 4K), ale jest fatalna, gdy trzeba precyzyjnie napełnić kieliszek. Procesor główny (CPU), który operuje na małych, losowych porcjach danych (skrypty AI wrogów, logika questów), nienawidzi wysokich opóźnień pamięci GDDR. Twórcy muszą więc stawać na rzęsach, by układać dane w pamięci w sposób liniowy, przyjazny dla tej specyfiki, co jest koszmarem optymalizacyjnym
• Brak elastyczności. W pececie, gdy brakuje ci RAM-u, idziesz do sklepu i dokładasz nowe kostki. W konsoli pula jest zamknięta i współdzielona. Jeśli graficy zaszaleją i wrzucą tekstury zajmujące 12 GB, a system operacyjny zarezerwuje swoje 3 GB, to programistom od gameplayu zostaje nędzny gigabajt na całą resztę gry. Zaczyna się wtedy brutalna walka wewnątrz studia deweloperskiego o zasoby - dźwiękowcy kłócą się z grafikami, a programiści fizyki z animatorami. Trzeba więc w doskonały sposób zarządzać tymi zasobami, analizując możliwości i robiąc użytek z każdego megabajta. 

Zrozumienie tej architektury jest kluczem do pojęcia, dlaczego 32 GB w nadchodzących konsolach może być potencjalnie tak istotne dla rozwoju gier. To być albo nie być dla złożoności świata przedstawionego. Bo w tej architekturze pamięć to nie tylko magazyn, ale przestrzeń robocza, która determinuje, jak skomplikowaną symulację (a nie tylko ładny obrazek) jesteśmy w stanie przeprowadzić w czasie rzeczywistym, zanim gracz zdąży mrugnąć okiem.

Od magicznych buforów do architektonicznej schizofrenii

Historia optymalizacji gier konsolowych wcale nie przypomina spokojnej ewolucji, lecz raczej kronikę walki partyzanckiej z ciągłym niedoborem. Jeśli spojrzymy wstecz, nie zobaczymy liniowego postępu, ale serię radykalnych eksperymentów inżynieryjnych, które zmuszały deweloperów do pisania kodu bezpośrednio na warstwie sprzętowej, z pominięciem jakichkolwiek ułatwień, na które mogą sobie pozwolić twórcy gier na komputery osobiste.

Doskonałym przykładem tej inżynieryjnej brawury jest PlayStation 2. Z dzisiejszej perspektywy specyfikacja legendarnej „Czarnulki” brzmi komicznie - konsola oferowała zaledwie 32 megabajty pamięci operacyjnej i mikroskopijne 4 megabajty pamięci wideo. Jakim cudem na tak ograniczonych zasobach udało się uruchomić Gran Turismo 4 w rozdzielczości 1080i? Sekret tkwił w unikalnej architekturze układu graficznego oraz zastosowaniu wbudowanej pamięci o niezwykle wysokiej przepustowości. Choć bufor ramki był śmiesznie mały, oferował on transfer danych na poziomie 48 gigabajtów na sekundę. W roku 2000 była to prędkość wręcz kosmiczna, podczas gdy ówczesne pecety dławiły się przy wartościach kilkukrotnie niższych.

Wymuszało to jednak na twórcach stosowanie karkołomnych sztuczek. Ze względu na mikroskopijną pamięć wideo, nie dało się w niej trzymać wszystkich tekstur jednocześnie. Programiści musieli strumieniować grafiki z głównej pamięci w czasie rzeczywistym, podmieniając je w locie, czasami nawet w trakcie rysowania pojedynczej klatki obrazu. Wymagało to perfekcyjnej synchronizacji mechanizmu bezpośredniego dostępu do pamięci. Błąd w kodzie rzędu milisekundy nie skutkował zwykłym spadkiem płynności, ale całkowitym rozsypaniem się wyświetlanego obrazu.

Zupełnie inną filozofię przyjął Microsoft przy projektowaniu pierwszego Xboxa, który stał się brutalnym pokazem siły i protoplastą dzisiejszych standardów. To tutaj po raz pierwszy w masowej skali zastosowano architekturę zunifikowaną. Konsola posiadała 64 megabajty pamięci, którą układ graficzny i procesor centralny dzieliły między sobą dynamicznie. Co ciekawe, pierwotne plany zakładały zaledwie połowę tej wartości. Deweloperzy, w tym zespoły odpowiedzialne za przenoszenie gier z komputerów, zagrozili jednak, że przy 32 megabajtach sprzęt będzie martwy już na starcie. Decyzja o podwojeniu pamięci była kosztowna, ale kluczowa dla sukcesu platformy. Bez tych dodatkowych megabajtów tak rozbudowane tytuły jak The Elder Scrolls III: Morrowind byłyby technicznie niemożliwe do zrealizowania. Elastyczność tej architektury pozwoliła twórcom przesuwać granice - gra wyścigowa mogła zabrać więcej zasobów na tekstury, podczas gdy rozbudowane RPG alokowało pamięć na bazy danych obiektów i statystyki.

Po tym okresie względnej normalizacji nadeszła era PlayStation 3, która dla wielu inżynierów stała się prawdziwą ścianą płaczu. Sony, w pogoni za teoretyczną wydajnością procesora Cell, zdecydowało się na architekturę dzieloną, co w praktyce okazało się technologiczną schizofrenią. Konsola dysponowała łącznie 512 megabajtami pamięci, ale została ona podzielona na dwa sztywne, hermetyczne silosy: szybką pamięć dla procesora oraz osobną kość dla układu graficznego. Brak unifikacji oznaczał, że zasoby nie mogły płynnie przepływać między podzespołami. Jeśli gra potrzebowała niewielu zasobów graficznych, ale ogromnej mocy obliczeniowej dla logiki świata, pamięć wideo leżała odłogiem, podczas gdy pamięć systemowa dusiła się, wyrzucając błędy o braku zasobów.

Sytuację pogarszała specyfika samego procesora. Rdzenie pomocnicze nie miały bezpośredniego dostępu do głównej pamięci w tradycyjnym sensie. Każdy z nich posiadał zaledwie 256 kilobajtów własnej pamięci lokalnej. Programiści musieli ręcznie zarządzać kopiowaniem fragmentów kodu i danych do tych malutkich buforów, przetwarzać je i odsyłać z powrotem. Brak automatycznego zarządzania spójnością pamięci podręcznej sprawiał, że proces tworzenia gier na ten sprzęt przypominał układanie puzzli w rękawicach bokserskich. To właśnie dlatego gry wydawane na wiele platform jednocześnie, jak Bayonetta czy Skyrim, działały na sprzęcie Sony zauważalnie gorzej, borykając się z problemami wydajnościowymi, których nie znała konkurencja.

Dopiero ósma generacja konsol przyniosła powrót do rozsądku, choć nie obyło się bez ofiar. Przejście na architekturę x86 i zunifikowaną, szybką pamięć rzędu 8 gigabajtów wydawało się rajem dla deweloperów, ale ten miesiąc miodowy trwał krótko. Szybko okazało się, że apetyt rośnie w miarę jedzenia. Wzrost rozdzielczości do standardu 4K sprawił, że bufory ramki oraz dane niezbędne do nowoczesnych technik renderingu zaczęły zajmować gigabajty przestrzeni, ponownie spychając pamięć operacyjną do roli zasobu deficytowego, o który trzeba walczyć w każdej linijce kodu.

Windy, mgła i ciche restarty

Gdyby gracze wiedzieli, na jak cienkich linkach wisi stabilność ich ulubionych produkcji, prawdopodobnie baliby się wcisnąć przycisk startu. Optymalizacja pamięci w grach wideo rzadko przypomina uporządkowaną inżynierię; częściej jest to cyfrowa prestidigitacja, balansowanie na krawędzi katastrofy i kreatywna księgowość, której celem jest oszukanie oka odbiorcy. To, co my odbieramy jako spójny, żyjący świat, dla pamięci operacyjnej konsoli jest serią gorączkowych podmian danych, realizowanych w ułamkach sekund tuż poza polem widzenia kamery.

Najbardziej jaskrawym przykładem tej technicznej desperacji stały się słynne korytarze i windy. W czasach świetności trylogii Mass Effect czy wczesnych odsłon Gears of War, gracze często narzekali na przydługie sekwencje jazdy windą, podczas których postacie prowadziły niezobowiązujące pogawędki. Nie były to jednak zabiegi reżyserskie mające na celu budowanie więzi między bohaterami, lecz konieczność techniczna, pełniąca funkcję śluzy bezpieczeństwa. W momencie wejścia do windy, gra brutalnie wyrzucała z pamięci operacyjnej dane o poprzedniej lokacji, zwalniając miejsce na załadowanie kolejnej. Te klaustrofobiczne kabiny były jedynym sposobem, by ukryć przed graczem fakt, że konsola nie jest w stanie utrzymać w pamięci całego poziomu naraz. Dziś tę rolę przejęły charakterystyczne szczeliny w skałach, przez które Kratos czy Lara Croft przeciskają się nienaturalnie długo - to współczesny odpowiednik ekranu wczytywania, zamaskowany ładną animacją.

Jeszcze ciekawiej wyglądała walka o pamięć w otwartych światach. Starsze odsłony serii Grand Theft Auto słynęły z tego, że szybkie samochody czy samoloty były w nich sztucznie spowolnione lub wręcz niedostępne. Powód był prozaiczny: dysk twardy i pamięć operacyjna nie nadążały ze strumieniowaniem danych miasta. Gdyby gracz poruszał się zbyt szybko, wjechałby w pustą przestrzeń, zanim konsola zdążyłaby wczytać geometrię budynków i tekstury asfaltu. Ograniczenia sprzętowe stały się więc bezpośrednim ograniczeniem mechaniki rozgrywki. Z kolei w kultowym horrorze Silent Hill, wszechobecna, gęsta mgła nie była wcale genialnym pomysłem artystycznym, mającym budować atmosferę grozy. Była to techniczna zasłona dymna, dosłownie i w przenośni, pozwalająca drastycznie ograniczyć zasięg rysowania obiektów. Konsola nie musiała pamiętać i przetwarzać tego, co kryło się dziesięć metrów przed graczem, co pozwoliło zaoszczędzić bezcenne zasoby na bardziej szczegółowe modele postaci.

Prawdziwe legendy branży rodziły się jednak tam, gdzie deweloperzy decydowali się łamać zasady narzucone przez producentów sprzętu. Twórcy pierwszej części Crash Bandicoot na PlayStation dokonali rzeczy niemożliwej, tworząc własny system zarządzania pamięcią wirtualną, co teoretycznie było zabronione przez Sony. Andy Gavin, główny programista, napisał kod, który dynamicznie podmieniał 64-kilobajtowe bloki tekstur w pamięci, wykorzystując każdą wolną chwilę procesora. Było to działanie na granicy ryzyka - jeden błąd w adresowaniu pamięci mógł zawiesić konsolę, ale dzięki temu gra wyglądała znacznie lepiej niż cokolwiek innego na rynku.

Jednak palmę pierwszeństwa w dziedzinie inżynieryjnej brawury dzierży studio Bethesda i ich praca nad The Elder Scrolls III: Morrowind na pierwszego Xboxa. Gra była tak ogromna i skomplikowana, że przy dłuższych sesjach nieuchronnie dochodziło do wycieków pamięci. Zasoby nie były zwalniane poprawnie, co prowadziło do zapchania RAM-u i drastycznego spadku wydajności. Zamiast przebudowywać silnik gry, co zajęłoby lata, twórcy zastosowali fortel ostateczny. Zaimplementowali mechanizm, który wykrywał moment krytycznego zapchania pamięci. Gdy gracz widział na ekranie niewinny komunikat o wczytywaniu nowej lokacji, konsola w rzeczywistości dokonywała w tle cichego, pełnego restartu. System operacyjny uruchamiał się od nowa, czyszcząc całą pamięć RAM, a gra wznawiała działanie od ostatniego zapisu, jakby nic się nie stało. Był to reset sprzętowy zamaskowany jako element rozgrywki - dowód na to, że w walce o pamięć wszystkie chwyty są dozwolone.

Dlaczego szesnaście gigabajtów to nowa bieda

Gdy obecna generacja konsol wchodziła na salony, szesnaście gigabajtów pamięci operacyjnej w specyfikacji technicznej wyglądało na wartość sytą, bezpieczną i wystarczającą na lata. Przeskok z ośmiu gigabajtów poprzedniej generacji wydawał się solidny, wręcz luksusowy. Rzeczywistość branżowa okazała się jednak bezlitosna, a cyfrowa inflacja uderzyła w zasoby sprzętowe szybciej, niż ktokolwiek przypuszczał. To, co na papierze wyglądało na autostradę, w zderzeniu z nowoczesnymi silnikami graficznymi okazało się zaledwie drogą powiatową, na której regularnie tworzą się zatory.

Głównym winowajcą tego stanu rzeczy jest bezwzględna matematyka rozdzielczości 4K. Marketingowcy sprzedali graczom wizję ostrych jak brzytwa światów, zapominając dodać drobnym drukiem, ile to kosztuje. Tekstury w wysokiej rozdzielczości to najbardziej zachłanny element każdej gry. Aby powierzchnia kamienia, faktura skóry czy splot na ubraniu bohatera wyglądały realistycznie na dużym telewizorze, artysta musi przygotować materiały o gigantycznej objętości. Na komputerach osobistych ustawienia ultra często wymagają kart graficznych posiadających kilkanaście gigabajtów pamięci przeznaczonej wyłącznie na ten cel. Konsole muszą w swojej wspólnej puli zmieścić nie tylko te opasłe tekstury, ale również system operacyjny, logikę gry, dźwięk i fizykę. W efekcie deweloperzy stają przed wyborem: albo drastycznie kompresować dane, co kończy się charakterystycznym „mydłem” na ekranie, albo ciąć jakość tekstur obiektów drugoplanowych, które przy bliższym poznaniu straszą pikselozą rodem z minionej epoki.

Sytuację dramatycznie komplikuje technologia śledzenia promieni. Ray-tracing powszechnie kojarzony jest z ogromnym apetytem na moc obliczeniową układu graficznego, ale rzadziej mówi się o jego wilczym głodzie na pamięć. Aby konsola mogła w czasie rzeczywistym obliczyć, jak światło odbija się od powierzchni, musi przechowywać w pamięci operacyjnej kompletną strukturę geometrii całego widocznego świata. Drzewa, budynki, postacie - wszystko to musi być stale dostępne dla procesora, ułożone w specjalne, hierarchiczne struktury danych. To dodatkowe gigabajty, które trzeba wyrwać z i tak już napiętego budżetu pamięci. Włączenie zaawansowanego oświetlenia często odbywa się więc kosztem różnorodności świata lub jakości tekstur, bo kołdra jest po prostu za krótka.

Dlatego właśnie współczesne gry, mimo potężnych podzespołów, paradoksalnie cierpią na te same choroby, co ich poprzednicy. Widoczne doczytywanie się obiektów na oczach gracza nie zniknęło, a jedynie zmieniło formę. Szybkie dyski SSD potrafią błyskawicznie dostarczyć dane, ale wąskim gardłem stała się pojemność pamięci operacyjnej, która nie jest w stanie przyjąć ich wszystkich naraz. Twórcy ratują się agresywnymi technikami skalowania obrazu, generując grę w niższej rozdzielczości i sztucznie ją podbijając, byle tylko zmieścić się w limicie pamięci wideo. Szesnaście gigabajtów, które miało być gwarantem swobody, stało się dziś gorsetem, w którym nowoczesne silniki graficzne, takie jak Unreal Engine 5 ze swoim systemem wirtualnej geometrii, ledwo mogą złapać oddech.

Pułapka trzydziestu dwóch gigabajtów i prawo Parkinsona

W branżowych kuluarach coraz głośniej szepcze się o specyfikacji nadchodzącego PlayStation 6 i kolejnej maszyny Microsoftu. Najczęściej powtarzaną liczbą są trzydzieści dwa gigabajty zunifikowanej pamięci. Na papierze brzmi to dobrze. Przecież podwojenie zasobów względem obecnej generacji powinno teoretycznie rozwiązać wszystkie bolączki deweloperów i otworzyć wrota do fotorealizmu. Historia uczy nas jednak, że w świecie technologii podwojenie zasobów rzadko oznacza dwukrotny wzrost swobody twórczej. Częściej oznacza po prostu dwukrotnie większy bałagan.

Istnieje spore ryzyko, że zadziała tu brutalne prawo Parkinsona, trawestowane na potrzeby informatyki: dane rozrastają się tak, aby wypełnić całą dostępną przestrzeń pamięci. Jeśli inżynierowie otrzymają do dyspozycji 32 gigabajty, naturalnym odruchem będzie poluzowanie rygorów optymalizacyjnych. Zamiast mozolnie kompresować tekstury i pisać skomplikowane systemy zarządzania zasobami, łatwiej będzie wrzucić do pamięci nieskompresowane pliki dźwiękowe czy modele o absurdalnie gęstej siatce geometrycznej, której gracz i tak nie zauważy. Zjawisko to obserwujemy już teraz na komputerach osobistych, gdzie gry zajmujące setki gigabajtów na dysku wcale nie oferują jakości uzasadniającej taką cyfrową otyłość. Większa pamięć w konsolach może paradoksalnie doprowadzić do ery cyfrowego niechlujstwa, gdzie surowa moc sprzętu będzie marnowana na maskowanie braku optymalizacji kodu.

Drugim aspektem jest nieunikniona presja marketingu na standard 8K. Nawet jeśli dla ludzkiego oka różnica między 4K, a 8K w typowym salonie jest dyskusyjna, producenci telewizorów i konsol będą potrzebowali nowego hasła reklamowego. Tekstury przygotowane pod taką rozdzielczość to matematyczna bestia - zajmują czterokrotnie więcej miejsca niż ich odpowiedniki w 4K. Jeśli branża pójdzie w tym kierunku, owe 32 gigabajty pamięci znikną w mgnieniu oka, skonsumowane przez zaledwie kilka kluczowych obiektów na ekranie. Do tego dochodzi ekonomia. Pamięć operacyjna, zwłaszcza w najnowszych, ultra-szybkich standardach, pozostaje jednym z najdroższych komponentów konsoli. Zamontowanie 64 gigabajtów wywindowałoby cenę sprzętu do poziomu nieakceptowalnego dla masowego odbiorcy. Stoimy więc przed wizją przyszłości, w której mimo postępu technologicznego, deweloperzy wciąż będą musieli żebrać o zasoby, bo ambicje artystyczne i marketingowe zawsze będą o krok przed możliwościami krzemu.

Błędne koło optymalizacji

Analizując ewolucję konsol od czasów skromnych megabajtów PlayStation 2 po gigabajtowe pakiety współczesności, wyłania się obraz niekończącej się gonitwy. Pamięć operacyjna pozostaje cichym bohaterem tego spektaklu - płótnem, na którym malowane są cyfrowe światy. Bez względu na to, jak szybki pędzel - czyli procesor graficzny - dostaną do ręki twórcy, jeśli płótno będzie zbyt małe, nigdy nie namalują kompletnego arcydzieła bez ciągłego zamalowywania poprzednich fragmentów.

Przez dekady ograniczenia te były motorem napędowym innowacji. To dzięki brakom pamięci powstały genialne systemy strumieniowania danych, sztuczki z mgłą czy dynamiczne ładowanie poziomów, które zdefiniowały język gier wideo. Dziś, gdy bariery te przesuwają się coraz dalej, tracimy nieco z tego inżynieryjnego romantyzmu na rzecz brut force - siłowego rozwiązywania problemów poprzez dokładanie kolejnych kości pamięci. Czy PlayStation 6 i nowy Xbox z 32 gigabajtami pamięci ostatecznie zakończą erę doczytywania się tekstur i kompromisów? Trudno w to uwierzyć. Natura tej branży nie znosi próżni. Każdy dodany gigabajt zostanie natychmiast zagospodarowany przez bardziej złożoną fizykę, gęstsze tłumy na ulicach wirtualnych miast czy jeszcze bardziej szczegółowe modele postaci. Pamięć operacyjna w konsolach to zasób, którego - podobnie jak pieniędzy - nigdy nie jest za dużo. Dla gracza pozostaje nadzieja, że w tej walce o cyferki nie zginie to, co najważniejsze: płynność rozgrywki i spójność świata przedstawionego. Bo ostatecznie nikt nie chce grać w specyfikację techniczną, tylko w dobrą grę.