Od pierwszej linijki do 60 FPS: jak budować wydajność gry już podczas produkcji

60 FPS nie jest magicznym przełącznikiem aktywowanym tuż przed premierą. To rezultat setek małych, świadomych decyzji podejmowanych codziennie: od architektury kodu, przez formaty tekstur, po plan pracy zespołów. Ten przewodnik pokazuje, jak dobrze zoptymalizować grę podczas tworzenia poprzez spójny proces, praktyki inżynierskie i decyzje artystyczne, które naturalnie prowadzą do stabilnego czasu klatki.

Dlaczego optymalizacja od pierwszego dnia ma znaczenie

Optymalizacja to nie kosmetyka na końcu. To sposób myślenia, który redukuje ryzyko techniczne, obniża koszty i daje zespołowi kontrolę nad doświadczeniem gracza. Im wcześniej zdefiniujesz standardy i budżety, tym mniej zaskoczeń czeka cię na etapie integracji i certyfikacji.

Koszt przeróbek kontra koszt projektowania

Przebudowa kluczowego systemu renderowania lub AI w późnej fazie to tygodnie pracy, regresje i napięcia w harmonogramie. Zaprojektowanie go pod kątem cache-friendly, łatwego profilowania i skalowania w górę oraz w dół – to godziny lub dni. Różnica w całkowitym koszcie projektu jest olbrzymia.

Wczesne budżety redukują ryzyko scope creep.
Małe eksperymenty na prototypach ujawniają wąskie gardła tanio i szybko.
Świadome kompromisy artystyczne i designerskie zapobiegają „nieskończonym” wymaganiom.

Mit „zoptymalizujemy na końcu”

„Na końcu” zwykle oznacza: bez pełnych danych, pod presją czasu, bez przestrzeni na zmiany systemowe. Lepiej rozłożyć wysiłek na etapy i już od preprodukcji mieć odpowiedź na pytanie, jak dobrze zoptymalizować grę podczas tworzenia bez poświęcania jakości wrażeń.

Ustal budżet wydajności i metryki od początku

Bez metryk nie ma optymalizacji. Potrzebujesz docelowej płynności, budżetu czasu klatki i standardów pomiaru, aby każda decyzja miała kontekst.

Cel płynności i budżet czasu klatki

Dla 60 FPS na platformach docelowych czas klatki wynosi ~16,67 ms. Rozdziel ten budżet na CPU i GPU i traktuj jak kontrakt zespołowy.

CPU main thread: 4–6 ms (logika gry, AI, fizyka, przygotowanie renderingu).
GPU: 6–8 ms (geometria, cieniowanie, postprocess).
Bufor bezpieczeństwa: 1–3 ms na nieprzewidziane skoki.

Na platformach mobilnych budżety bywają ciaśniejsze ze względu na termiczny throttling i limity energii, więc planuj progi jakości i dynamikę skalowania (dynamic resolution, poziomy efektów, gęstość tłumu).

Metryki jakości animacji i płynności

Średni i medianowy frametime – nie wystarcza sam FPS.
1% i 0,1% low – ujawniają mikroprzycięcia.
Stabilność czasu klatki – brak pików podczas streamingu i kompilacji shaderów.
CPU vs. GPU bound – diagnoza, który podsystem jest dominujący.

Platformy docelowe i konfiguracje testowe

Zdefiniuj klasy sprzętu (PC min/zalecana, generacje konsol, profile mobilne). Zadbaj o stałe banki testowe i CI z benchmarkami scen, aby wykrywać regresje w czasie, a nie podczas „locku na premierę”.

Architektura zorientowana na dane: szybkość jako cecha projektu

Wysoka wydajność nie wynika z pojedynczej sztuczki, ale z architektury, która dobrze układa dane i pracę wątku.

Data-Oriented Design i ECS

Zamiast mieszania danych i logiki w obiektach (OOP), rozważ Data-Oriented Design i Entity Component System:

SoA zamiast AoS – przechowywanie pól w osobnych, zwartch buforach poprawia trafienia w cache i umożliwia wektorowe operacje SIMD.
Iteracje po ciągłych blokach pamięci – lepszy prefetching i mniejsze skoki gałęzi.
Systemy bez wirtualnych wywołań – mniej nieprzewidywalności w przepływie sterowania.

Job system i wielowątkowość

Wykorzystaj job system do równoległego przetwarzania: culling, aktualizacja animacji, generowanie LOD, przygotowanie komend renderingu. Drobne, samowystarczalne zadania ograniczają zależności i poprawiają skalowanie na CPU z wieloma rdzeniami.

Bez blokad tam, gdzie to możliwe – struktury lock-free lub read-mostly.
Frame allocator – szybkie, tymczasowe alokacje per klatka.
Deterministyczny przepływ – łatwiejsze profilowanie i powtarzalność wyników.

Projektując architekturę w ten sposób, naturalnie wiesz, jak dobrze zoptymalizować grę podczas tworzenia, zanim jeszcze zaczną powstawać kosztowne systemy kontentu.

Pipeline zasobów: kontrola rozmiarów i jakości od źródła

Najlepszy kod nie uratuje gry, jeśli assety są zbyt ciężkie. Pipeline zasobów to pierwsza linia obrony przed spadkami wydajności.

Tekstury: formaty, miple i streaming

Formaty kompresji – BC1–BC7 na PC i konsolach, ASTC/ETC2 na mobile. Zrezygnuj z RGBA8 tam, gdzie to zbędne.
Mipmapping i anisotropic filtering – zmniejsza aliasing i koszty próbkowania w odległości.
Streaming tekstur – priorytety ładowania na podstawie widoku kamery, budżet VRAM i fallbacki jakościowe.
Atlasowanie i texture arrays – mniej przełączeń stanów i draw calli.

Geometria: LOD, instancing, merge

Siatki LOD – generowane proceduralnie lub ręcznie, z uwzględnieniem siluet i materiałów.
Instancing i batching – redukcja draw calli dla wielu kopii tego samego modelu.
Łączenie statycznych obiektów – mniejsze koszty cullingu i zarządzania sceną.
Ogranicz liczbę materiałów na mesh – każdy materiał to potencjalny osobny draw call.

Audio i wideo

Kompresja – Vorbis/Opus dla długich ścieżek, ADPCM dla krótkich efektów.
Streamowanie długich nagrań z dysku, a nie trzymanie w pamięci.
Limity polifonii i priorytety kanałów.

Shadery i warianty

Prekompilacja i cache PSO – eliminacja stuttera związanego z kompilacją w runtime.
Redukcja permutacji – unikanie eksplozji wariantów przez wspólne ścieżki i define’y.
Stałe bufory i uporządkowane bindy – mniejsze koszty CPU i lepsza kompatybilność z konsolami.

Renderowanie bez zadyszki: od cullingu do postprocessu

Backend renderera powinien minimalizować koszt draw calli, przerzuty stanów i niepotrzebne pikselowanie.

Batching, instancing i redukcja draw calli

Instancing – przesyłaj transformacje jako macierze lub bufory instancji, renderując setki obiektów jednym wywołaniem.
Batching statyczny – łącz nieruchome elementy w większe bloki, by ograniczyć overhead CPU.
Sortowanie według materiałów – minimalizuj zmiany pipeline’u i koszt synchronizacji GPU.

Culling: frustum, occlusion, HZB

Frustum culling – podstawowy, ale krytyczny; wykonuj na CPU lub GPU.
Occlusion culling – hi-z lub portal systems w gęstych scenach miejskich i wnętrzach.
Distance i size culling – nie renderuj obiektów niewidocznych percepcyjnie.

Oświetlenie i cienie

Light baking i light probes dla statycznych elementów – dynamiczne światła zachowaj dla gameplayu.
Shadow cascades – rozsądne limity, filtrowanie i rozkład odległości.
Forward+, clustered – alternatywy dla pełnego deferred w scenach z wieloma punktowymi światłami.

Postprocess i rekonstrukcja

Tonemapping i bloom – lekkie i spójne; unikaj overdrawu.
TAA, DLSS, FSR, XeSS – skalery rozwiązań pozwalają zbalansować rozdzielczość i płynność.
SSR, SSAO, DOF – kontroluj jakość, promienie i próbki; włączaj adaptacyjnie na mocniejszych konfiguracjach.

W praktyce to zestaw dźwigni jakościowych – profile graficzne i automatyczne skalowanie – które pomagają utrzymać target, a jednocześnie dają spójny obraz.

Fizyka, animacja i AI: kontrola kosztów symulacji

Symulacja to często największy konsument CPU. Plan jej kosztu jest nawet ważniejszy niż efektów wizualnych, bo bezpośrednio wpływa na responsywność.

Fizyka: fixed timestep i broadphase

Stały krok symulacji (np. 60 Hz) i interpolacja wizualna zapobiegają niestabilności.
Broadphase – spatial partitioning (BVH, oktree, grid) minimalizuje liczbę par w kolizjach.
Warstwy kolizji – ogranicz kolizje tylko do koniecznych grup.
Substepping selektywny – tylko dla obiektów krytycznych.

Animacja: CPU czy GPU

GPU skinning dla tłumów, CPU dla postaci gameplayowych z interakcją.
Kompresja klatek i additive layers zmniejszają koszty pamięci i blendów.
Retargeting offline tam, gdzie możliwe, zamiast w runtime.

AI: LOD zachowania

Różne częstotliwości aktualizacji – NPC poza ekranem aktualizuj rzadziej.
Proste modele decyzyjne dla odległych jednostek, pełny plan dla tych blisko gracza.
Navmesh – inkrementalne aktualizacje zamiast pełnych rebake’ów.

Pamięć i alokacje: eliminuj długi ogon pauz

Stabilność pamięci i brak niekontrolowanych alokacji to klucz do uniknięcia mikroprzycięć.

Strategie alokacji

Arena i pool allocators – przewidywalne koszty, brak fragmentacji.
Frame i stack allocators – natychmiastowe zwalnianie per klatka.
Wstępna rezerwacja buforów i ring-buffery dla strumieniowanych danych.

GC i środowiska zarządzane

Unity: incremental GC, unikanie alokacji w update, pooling obiektów.
Unreal: inteligentne UPROPERTY i rozdział lifetime’u, minimalizacja ticków per actor.
Analiza alokacji – narzędzia profilerów pamięci, markerowanie hot-pathów.

Wykrywanie wycieków i fragmentacji

Telemetry i sentinel allocations – szybkie wykrywanie anomalii.
Testy soak – długie sesje gry z logowaniem przyrostów pamięci.

Takie praktyki są fundamentem, kiedy zastanawiasz się, jak dobrze zoptymalizować grę podczas tworzenia z myślą o płynności nawet po wielu godzinach rozgrywki.

Streaming świata i I/O: brak zacięć podczas eksploracji

Otwarte światy i bogate sceny wymagają inteligentnego strumieniowania, by uniknąć pauz w ruchu kamery.

Planowanie strumieniowania

Podział na chunki z metadanymi priorytetów (widoczność, bliskość, ważność gameplayowa).
Prefetch na podstawie przewidywania ruchu kamery i ścieżki gracza.
Budżet I/O – równoważenie między dyskiem, CPU dekompresji i VRAM.

Zapobieganie stutterowi

Shader warming i cache pipeline state – brak kompilacji w trakcie rozgrywki.
Async loading – wątki I/O i dekompresja w tle, bez blokowania głównego wątku.
Pipeline zasobów – deterministyczne formaty i aligny, by minimalizować koszt deserializacji.

Sieć i synchronizacja: płynność w multiplayerze

W grach sieciowych wydajność to także spójność i przewidywalność stanu przy zmiennej przepustowości.

Prediction, interpolation, rollback

Client-side prediction i korekcja błędów minimalizują opóźnienia wejścia.
Interpolacja stanów obiektów ogranicza teleporcje i jitter.
Rollback dla gier wymagających synchronizacji klatek i precyzji.

Oszczędność pasma

Delta i bitpacking – wysyłaj tylko zmiany, z ciasnym formatem danych.
Priorytetyzacja – istotne dla gracza informacje mają pierwszeństwo.
Rate limiting i adaptacja do strat pakietów.

Narzędzia i profilowanie: od hipotezy do dowodu

Profilowanie to metoda naukowa: stawiasz hipotezę, mierzysz, zmieniasz, weryfikujesz. Bez tego łatwo optymalizować nie to, co trzeba.

Proces profilowania

Wejściowy benchmark – scena referencyjna dla porównań.
Markerowanie – nazwy sekcji CPU/GPU, tagi assetów, identyfikatory podsystemów.
Wąskie gardła – definiuj je liczbowo, nie „na oko”.
AB testy – porównuj zmiany z kontrolą, loguj rezultaty.

Narzędzia praktyczne

Unity: Profiler, Frame Debugger, Burst Inspector, DOTS analysis.
Unreal: Insights, stat unit, stat GPU, RenderDoc integracja, r.ConsoleVariables do szybkich testów.
GPU: PIX, Nsight, Radeon GPU Profiler, Xcode Instruments.
Frame capture: RenderDoc do analizy draw calli i overdrawu.

Metryki, które warto śledzić codziennie

Frametime p95 – 95 percentyl czasu klatki.
Draw calls na klatkę i czas przygotowania komend na CPU.
Koszt cieni – liczba kasad i pikseli w shadow maps.
Alokacje per klatka – dążymy do zera na gorących ścieżkach.
Streaming misses – braki w VRAM i fallbacki jakościowe.

Bezpośrednie, regularne pomiary uczą zespół, jak dobrze zoptymalizować grę podczas tworzenia, bo każdy widzi wpływ zmian na liczby, nie tylko na wrażenie.

Proces w produkcji: budżety, CI i Definition of Done

Wydajność musi być wpisana w proces wytwórczy, a nie pozostawiona dobrej woli.

Budżety per funkcja i feature gates

Każdy task ma budżet CPU/GPU i pamięć, testowany na buildzie.
Gate’y jakości – feature nie przechodzi, jeśli pogarsza p95 powyżej progu.
Rollback procedury – odwracalne integracje i szybkie disable flagi.

CI/CD i testy regresji

Automatyczne benchmarki na farmie urządzeń docelowych.
Alerty przy spadkach p95, wzroście draw calli, wzroście alokacji.
Artefakty profilera do wglądu w PR-ach (captury, raporty).

Współpraca interdyscyplinarna

Tech art jako łącznik
Design świadomy kosztów systemów (np. destrukcja, gęstość NPC).
QA performance z planem scen krawędziowych: deszcz, noc, tłum, walka.

Takie praktyki sprawiają, że pytanie, jak dobrze zoptymalizować grę podczas tworzenia, ma konkretną odpowiedź w dokumentach procesu i narzędziach, a nie tylko w deklaracjach.

Skalowanie jakości: od low-end do high-end

Skalowalność to nie tylko suwaki w menu, ale aktywne dostosowanie gry do budżetów urządzenia.

Profile jakości i automatyczna adaptacja

Presety z definicją LOD-ów, cieni, postprocessu, odległości rysowania.
Dynamic Resolution Scaling na podstawie bieżącego frametime’u.
Opcje konfiguracyjne z sensownymi opisami i restartless zmianami, gdzie to możliwe.

Funkcje opcjonalne

RT refleksy i cienie – wyłączalne, z pathami fallbackowymi SSR/Shadow Maps.
Tłum i dekoracje – skalowanie density i jakości animacji.

Antywzorce i jak ich unikać

Wiedza o tym, co szkodzi, jest równie ważna jak dobre praktyki.

„Premature optimization” bez danych – optymalizuj pod metryki, nie intuicję.
Nieograniczone ticki – każdy Actor czy Component nie musi aktualizować się co klatkę.
Alokacje w hot-path – stringi, listy, LINQ w update’ach na silnikach zarządzanych.
Eksplozja wariantów shaderów – brak kurateli nad define’ami i materiałami.
Brak LOD/streamingu – wszystko zawsze w najwyższej jakości.
Wspólne zasoby bez ownershipu – wycieki i fragmentacja.
„Zoptymalizujemy na końcu” – odkładanie problemów z wydajnością na ostatnią chwilę.

Przykładowa checklista na sprint

Bazowy benchmark zaktualizowany i porównany do poprzedniego buildu.
Brak wzrostu p95 frametime’u powyżej ustalonego progu.
Zero nowych alokacji w hot-path (update, render prepare, physics step).
Weryfikacja LOD i cullingu na nowych assetach.
Testy stutteru w scenach ze streamowaniem.
Shader cache zaktualizowany i brak kompilacji w runtime na trasie testowej.

Case study w pigułce: jak zbić frametime o 3 ms

Załóżmy, że benchmark pokazuje 20,5 ms na docelowej konsoli (cel: 16,67 ms). Podejście iteracyjne:

Diagnoza: GPU bound, 8,9 ms na cienie, 6,1 ms na postprocess, wysokie koszty SSR.
Zmiany: ograniczenie kasad do 3, filtr PCF 3x3, SSR quality -1, włączenie half-res AO.
Wynik: 17,4 ms. Nadal powyżej celu.
Dalsze zmiany: light baking statycznych lamp, skrócenie zasięgu dynamicznych, optymalizacja sortowania draw calli.
Wynik: 16,5 ms, stabilne 60 FPS, brak istotnej utraty jakości subiektywnej.

Iteracje oparte na metrykach i szybkie A/B to esencja tego, jak dobrze zoptymalizować grę podczas tworzenia w realnych warunkach produkcyjnych.

Platformowe niuanse: PC, konsole, mobile

PC

Ogromna zmienność sprzętu – priorytetem jest skalowanie i dobre defaulty.
Driver stutter – prekompilacja PSO i shader prewarming minimalizują problem.
Wielordzeniowość – znaczenie dobrego job systemu i unikania wąskiego gardła na main thread.

Konsole

Stabilne API – mniejsza fragmentacja, ale twarde limity pamięci i VRAM.
Async compute – możliwość nakładania compute na grafikę, przy świadomym planowaniu.
Certyfikacja – wymagania stabilności i brak hitchy krytyczne dla akceptacji.

Mobile

Throttling i limity energii – krótkie piki są równie groźne co stałe obciążenie.
ASTC i tile-based GPUs – projektuj pod architekturę kafelkową i ogranicz overdraw.
Rozsądne UI – kosztowne shadery i efekty w warstwach UI potrafią zdominować budżet.

Włączanie jakości do designu: „performance-aware design”

Design może wspierać wydajność:

Inteligentne kadrowanie – unikanie ekstremalnych odległości widoku, które wymuszają wysokie koszty.
Rytm scen – naprzemienność gęstych i lekkich fragmentów zmniejsza średnie obciążenie.
Readability – uproszczone efekty często poprawiają czytelność i wydajność jednocześnie.

To kolejny praktyczny wymiar tego, jak dobrze zoptymalizować grę podczas tworzenia bez poświęcania frajdy i charakteru.

Komunikacja i dokumentacja: wiedza, która nie ginie

Styleguide assetów – limity tekstur, polycount, budowa materiałów, naming.
Playbook wydajności – gotowe procedury: jak profilować, jak zgłaszać regresję, jak weryfikować LOD/streaming.
Checklisty PR – pytania kontrolne o wpływ na CPU/GPU/VRAM.

Najczęstsze pytania i proste odpowiedzi

Czy zawsze warto celować w 60 FPS?

Jeżeli to core założenie doświadczenia, tak. Jeśli projekt jest kinowy lub strategiczny, rozważ cele jakościowe inne niż czysta płynność, ale miej profil 60 jako opcję na mocniejszych urządzeniach.

Czy optymalizacja oznacza gorszą grafikę?

Nie. Optymalizacja to wymiana kosztownych rozwiązań na mądrzejsze: lepsze LOD-y, baking światła, sensowny postprocess i skalowanie. Jakość postrzegana może wręcz wzrosnąć.

Jak często profilować?

Codziennie na buildach dziennych i przy każdym większym PR. Stały rytm pomiarów buduje dyscyplinę i szybko wykrywa regresje.

Podsumowanie: od pierwszej linijki do stabilnych 60 FPS

Wydajność to suma decyzji: architektura zorientowana na dane, job system, przemyślany pipeline assetów, renderer oszczędny w draw callach, symulacja z LOD zachowań, stabilna pamięć i strumieniowanie bez zacięć. Dodaj do tego proces: budżety, benchmarki, CI, oraz współpracę zespołów. Wtedy pytanie, jak dobrze zoptymalizować grę podczas tworzenia, ma jedną odpowiedź: konsekwentnie, liczbowo i od pierwszej linijki kodu. Tak powstaje gra, która nie tylko wygląda, ale i działa – płynnie, przewidywalnie i przyjemnie dla gracza.

Mini-plan działania na kolejny sprint

Ustal i udokumentuj budżety CPU/GPU oraz p95 frametime dla scen referencyjnych.
Włącz profilery do CI i generuj raporty na PR.
Ogranicz warianty shaderów i zbuduj cache PSO przed startem gry.
Przeprowadź przegląd LOD i cullingu dla nowych assetów.
Zaadresuj największe hotspoty z ostatniego benchmarku i powtórz test.

Ten cykl – hipoteza, pomiar, poprawka, weryfikacja – jest fundamentem tego, jak dobrze zoptymalizować grę podczas tworzenia i dowieźć stabilne 60 FPS bez heroicznych wysiłków w ostatnim tygodniu.