Nowe funkcje Godot 4.7 ujawnione: Kulisy aktualizacji wydajności w wersjach Dev3 i Dev4

Każdy niezależny deweloper tworzący grę wieloosobową zna ten dokładny moment, w którym jego kod sieciowy zaczyna generować fantomowe desynchronizacje i nieprzewidywalne zacięcia fizyki. Spędzasz tygodnie na budowaniu spójnej pętli rozgrywki, tylko po to, by uświadomić sobie, że synchronizacja stanu przez niestabilne połączenie wymaga zupełnie innego inżynieryjnego podejścia. Wraz z niedawnym wydaniem wersji testowych (snapshots) Dev3 i Dev4, główni współtwórcy silnika przesuwają granice, a zrozumienie tych nowych funkcji Godot 4.7 jest kluczowe dla studiów planujących harmonogramy produkcji.

Godot 4 nieustannie pnie się w górę od czasu masowego przepisania swojego rdzenia. Podczas gdy stabilne wydania są fundamentem produkcji, wersje rozwojowe – a w szczególności przeskok z Dev2 do nowo wydanych Dev3 i Dev4 – oferują przejrzysty wgląd w to, gdzie leżą priorytety architektoniczne silnika. Dla deweloperów technicznych te aktualizacje to nie tylko listy zmian (patch notes); to wczesne ostrzeżenia, by dostosować swoje potoki sieciowe, renderowania i zarządzania pamięcią.

W tej dogłębnej analizie rozpakujemy techniczne realia aktualizacji projektu, dowiemy się, jak wykorzystać GDScript do tworzenia autorytatywnego serwera w trybie wieloosobowym, oraz dlaczego ciągła ewolucja silnika wymaga mądrzejszego podejścia do infrastruktury backendowej.

Dekodowanie cyklu wydawniczego Godota: Co tak naprawdę oznaczają wersje Dev

Migracja gry będącej w fazie produkcji do wersji rozwojowej to skalkulowane ryzyko. Snapshot "Dev" w nomenklaturze Godota oznacza, że nie nastąpiło jeszcze zamrożenie funkcji (feature-freeze). API może ulec zmianie, zachowania węzłów (nodes) mogą zostać zmodyfikowane, a nieudokumentowane regresje są praktycznie gwarantowane.

Jednak ignorowanie tych kompilacji oznacza ignorowanie trajektorii rozwoju silnika. Przejście do Godot 4.7 jest silnie skoncentrowane na stabilizacji ogromnych dodatków wprowadzonych w wersjach od 4.3 do 4.6. Obserwujemy wyraźny zwrot w kierunku profilowania wydajności, deterministycznych zachowań fizyki i usprawnionej synchronizacji w trybie wieloosobowym.

Dla samodzielnego dewelopera lub małego zespołu głównym problemem zazwyczaj nie jest pisanie logiki gry – jest nim odkrycie, dlaczego scena, która działa w 144 FPS na lokalnej maszynie, nagle spada do 45 FPS po zainstancjonowaniu w sieci, lub dlaczego pauzy odśmiecania pamięci (garbage collection) powodują mikro-przycięcia podczas intensywnych sekwencji walki. Aktualizacje pojawiające się w tych wersjach deweloperskich bezpośrednio celują w wąskie gardła podczas przechodzenia przez drzewo węzłów oraz w wewnętrzne alokatory pamięci.

Prawdziwy koszt aktualizacji silnika

Aktualizacja wersji silnika w połowie procesu tworzenia gry zazwyczaj kosztuje zespół od dwóch do trzech tygodni dedykowanego czasu na refaktoryzację. Węzły stają się przestarzałe (deprecated), warstwy fizyki są redefiniowane, a przepływy pracy kompilacji shaderów ulegają zmianie.

Oceniając nowe funkcje Godot 4.7, musisz zestawić obiecany wzrost wydajności z tym długiem refaktoryzacyjnym. Jeśli twój obecny projekt w dużym stopniu opiera się na niestandardowych modułach C++ (GDExtension), musisz upewnić się, że twoje łańcuchy budowania są przygotowane na zaktualizowane nagłówki. Jeśli pracujesz wyłącznie w GDScript, ryzyko jest mniejsze, ale nadal musisz rygorystycznie przetestować swoje powiązania RPC (Remote Procedure Call).

Walka z koszmarem desynchronizacji w trybie wieloosobowym

Tworzenie gier wieloosobowych to w gruncie rzeczy ćwiczenie z ukrywania opóźnień (latency). Kiedy gracz naciska przycisk skoku, lokalny klient musi natychmiast przewidzieć ten skok, jednocześnie prosząc serwer o pozwolenie. Jeśli serwer się nie zgodzi – być może dlatego, że gracz został w rzeczywistości ogłuszony przez przeciwnika ułamek sekundy wcześniej – klient musi siłą skorygować pozycję gracza, co skutkuje irytującym wizualnym efektem "gumowej taśmy" (rubber-banding).

Godot 4 wprowadził węzły MultiplayerSynchronizer i MultiplayerSpawner, które wyabstrahowały wiele powtarzalnego kodu wymaganego do replikacji stanu. Jednak domyślna synchronizacja rzadko wystarcza w szybkich, rywalizacyjnych grach. Potrzebujesz szczegółowej kontroli nad tym, jakie dane są wysyłane, jak często są wysyłane i czy wymagają niezawodnych (reliable), czy zawodnych (unreliable) kanałów transportowych.

Wdrażanie ruchu autorytatywnego dla serwera

Klasycznym błędem popełnianym przez niezależnych deweloperów jest ufanie klientowi. Jeśli twój klient dyktuje serwerowi swoją własną pozycję, złośliwi gracze po prostu zmodyfikują swojego klienta, aby teleportować się po mapie. Serwer musi być ostatecznym autorytetem.

Oto praktyczne, gotowe do produkcji podejście do wdrożenia ruchu autorytatywnego dla serwera z przewidywaniem po stronie klienta (client-side prediction) w GDScript. Ten wzorzec zapewnia, że ruch wydaje się responsywny, jednocześnie zapobiegając podstawowym oszustwom typu speed hack.

extends CharacterBody3D

# Konfiguracja trybu wieloosobowego
@export var player_id := 1

# Stałe ruchu
const SPEED := 5.0
const JUMP_VELOCITY := 4.5

# Śledzenie stanu do rekoncyliacji (korekty)
var unacknowledged_inputs := []
var latest_server_state := {}

func _ready() -> void:
    # Ustawienie autorytetu sieciowego na ID gracza
    set_multiplayer_authority(player_id)
    
    # Jeśli jesteśmy serwerem, przetwarzamy fizykę normalnie
    # Jeśli jesteśmy klientem, tylko przewidujemy i czekamy na nadpisanie przez serwer
    if not is_multiplayer_authority() and not multiplayer.is_server():
        set_physics_process(false)

func _physics_process(delta: float) -> void:
    if is_multiplayer_authority():
        # Przechwytywanie wejścia (input)
        var input_dir := Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down")
        var input_state := {
            "tick": Engine.get_physics_frames(),
            "dir": input_dir,
            "jump": Input.is_action_just_pressed("ui_accept")
        }
        
        # Zastosuj lokalnie dla natychmiastowej reakcji (Przewidywanie)
        _apply_movement(input_state, delta)
        
        # Zapisz wejście do potencjalnej późniejszej korekty
        unacknowledged_inputs.append(input_state)
        
        # Wyślij do serwera w celu walidacji
        rpc_id(1, "_receive_client_input", input_state)

# Zawodne (unreliable) RPC jest tutaj kluczowe, aby zapobiec przeciążeniu sieci.
# Utracone wejścia zostaną skorygowane przez autorytatywne aktualizacje stanu z serwera.
@rpc("any_peer", "call_remote", "unreliable")
func _receive_client_input(input_state: Dictionary) -> void:
    # TYLKO PO STRONIE SERWERA
    if not multiplayer.is_server():
        return
        
    var sender_id = multiplayer.get_remote_sender_id()
    if sender_id != player_id:
        # Odrzuć nieautoryzowane fałszowanie wejścia
        push_warning("Player %s attempted to spoof input for player %s" % [sender_id, player_id])
        return
        
    # Zastosuj wejście na serwerze
    _apply_movement(input_state, get_physics_process_delta_time())
    
    # Rozgłoś zwalidowany stan do wszystkich klientów
    var new_state = {
        "tick": input_state.tick,
        "pos": global_position,
        "vel": velocity
    }
    rpc("_receive_server_state", new_state)

@rpc("authority", "call_remote", "unreliable")
func _receive_server_state(server_state: Dictionary) -> void:
    # TYLKO PO STRONIE KLIENTA
    if is_multiplayer_authority() or multiplayer.is_server():
        return
        
    # Przyciągnij do pozycji serwera (Korekta)
    # W prawdziwej grze należałoby to zinterpolować, aby ukryć przeskok
    global_position = server_state.pos
    velocity = server_state.vel
    
    # Usuń potwierdzone wejścia
    unacknowledged_inputs = unacknowledged_inputs.filter(func(input): return input.tick > server_state.tick)

func _apply_movement(state: Dictionary, delta: float) -> void:
    # Standardowa logika kontrolera postaci Godota zastosowana do określonego ładunku stanu
    if not is_on_floor():
        velocity.y -= 9.8 * delta

    if state.jump and is_on_floor():
        velocity.y = JUMP_VELOCITY

    var direction := (transform.basis * Vector3(state.dir.x, 0, state.dir.y)).normalized()
    if direction:
        velocity.x = direction.x * SPEED
        velocity.z = direction.z * SPEED
    else:
        velocity.x = move_toward(velocity.x, 0, SPEED)
        velocity.z = move_toward(velocity.z, 0, SPEED)

    move_and_slide()

Ten skrypt rozwiązuje podstawowy problem autorytatywnego ruchu. Wykorzystując „zawodne” (unreliable) wywołania RPC dla stałych strumieni danych, takich jak pozycja i wejście, zapobiegamy zapychaniu się bazowej kolejki sieciowej i powodowaniu katastrofalnych opóźnień. Nowe aktualizacje silnika nadal udoskonalają sposób zarządzania tymi wewnętrznymi kolejkami RPC, czyniąc serwery o wysokim tickrate znacznie bardziej opłacalnymi i stabilnymi.

Profilowanie wydajności: Ucieczka od wąskiego gardła GDScript

GDScript to niezwykle produktywny język, ale jego dynamiczna natura wiąże się z pewnym pułapem wydajności. Kiedy przetwarzasz setki encji w pętli _physics_process, narzut związany z typami wariantowymi (variant types) i dynamicznym wyszukiwaniem metod może zmniejszyć liczbę klatek na sekundę o połowę.

Jednym z najbardziej podstępnych zabójców wydajności w Godocie jest alokacja pamięci w czasie działania programu (runtime). Instancjonowanie nowego węzła lub tworzenie nowego złożonego słownika w każdej klatce uruchamia alokator pamięci silnika. Z czasem prowadzi to do fragmentacji i skoków obciążenia związanych z odśmiecaniem pamięci – co objawia się zauważalnymi zacięciami podczas rozgrywki.

Pula obiektów (Object Pooling): Obowiązkowa architektura

Aby ominąć te alokatory, musisz zaimplementować pulę obiektów (Object Pooling). Zamiast wywoływać queue_free() i instantiate() podczas rozgrywki, prealokujesz ogromną tablicę obiektów podczas ekranów ładowania i po prostu przełączasz ich stany widoczności oraz przetwarzania.

Wyobraź sobie strzelankę typu bullet hell. Jeśli boss wystrzeliwuje 500 pocisków na sekundę, dynamiczne instancjonowanie 500 węzłów Area2D zmiażdży twój procesor.

Oto jak zbudować solidną pulę obiektów w GDScript:

extends Node
class_name BulletPool

@export var bullet_scene: PackedScene
@export var pool_size: int = 1000

var _available_bullets: Array[Node] = []
var _active_bullets: Array[Node] = []

func _ready() -> void:
    # Prealokuj wszystkie obiekty przed rozpoczęciem gry
    for i in range(pool_size):
        var bullet = bullet_scene.instantiate()
        
        # Całkowicie wyłącz pocisk
        bullet.process_mode = Node.PROCESS_MODE_DISABLED
        bullet.visible = false
        
        # Dodaj do drzewa sceny, ale pozostaw w uśpieniu
        add_child(bullet)
        _available_bullets.append(bullet)

func spawn_bullet(spawn_position: Vector2, direction: Vector2) -> Node:
    if _available_bullets.is_empty():
        push_error("Bullet pool exhausted! Increase pool size.")
        return null
        
    var bullet = _available_bullets.pop_back()
    
    # Ponownie zainicjuj stan pocisku
    bullet.global_position = spawn_position
    if bullet.has_method("set_direction"):
        bullet.set_direction(direction)
        
    # Obudź pocisk
    bullet.visible = true
    bullet.process_mode = Node.PROCESS_MODE_INHERIT
    
    _active_bullets.append(bullet)
    return bullet

func return_bullet(bullet: Node) -> void:
    if not bullet in _active_bullets:
        return
        
    # Uśpij pocisk z powrotem
    bullet.process_mode = Node.PROCESS_MODE_DISABLED
    bullet.visible = false
    
    _active_bullets.erase(bullet)
    _available_bullets.append(bullet)

Przenosząc obciążenie obliczeniowe ze zmiennej pętli rozgrywki do statycznej fazy ładowania, gwarantujesz płaski, przewidywalny profil pamięci. Podczas profilowania gry w edytorze Godot powinieneś zauważyć, że zużycie pamięci utrzymuje się na stałym poziomie, zamiast stale rosnąć i spadać. Sama ta technika może zmniejszyć wariancję czasu renderowania klatki z ~15 ms do stabilnych ~2 ms w grach z dużą liczbą pocisków.

Przepływy pracy renderowania i optymalizacja sceny

Choć wydajność backendu i logiki jest kluczowa, renderowanie pozostaje najbardziej widocznym wizualnie wąskim gardłem. Renderer Vulkan w Godot 4 jest potężny, ale wymaga celowej optymalizacji. Częstym błędem jest poleganie na tym, że silnik magicznie odrzuci niewidoczną geometrię (culling). Chociaż Godot ma doskonałe odrzucanie bryły widzenia (frustum culling), przesyłanie surowych danych wierzchołków do GPU nadal wymaga przygotowania po stronie CPU (draw calls - wywołania rysowania).

Aby temu zaradzić, deweloperzy muszą agresywnie wykorzystywać MultiMeshInstance3D dla powtarzalnej geometrii, takiej jak trawa, drzewa czy systemy tłumu. Standardowy MeshInstance3D wymaga unikalnego wywołania rysowania dla każdego obiektu. Jeśli masz las z 5000 drzew, to jest to 5000 wywołań rysowania – wystarczająco dużo, by sparaliżować układ graficzny średniej klasy.

Konwersja tych 5000 oddzielnych węzłów w pojedynczy MultiMeshInstance3D zmniejsza liczbę wywołań rysowania z 5000 do dokładnie 1. GPU jest niezwykle wydajne w rysowaniu tej samej siatki tysiące razy; to instrukcja CPU, aby to zrobić, powoduje wąskie gardło. W miarę jak Godot ewoluuje w cyklu życia wersji 4.x, potok zarządzania tymi partiami (batches) staje się coraz bardziej usprawniony, ale odpowiedzialność architektoniczna pozostaje po stronie dewelopera.

Dylemat infrastruktury backendowej

Przejdźmy do sedna problemu. Zoptymalizowałeś swoje pule obiektów, napisałeś czysty, autorytatywny dla serwera kod w GDScript, a twoja gra wieloosobowa działa bezbłędnie podczas testów na localhost.

Teraz chcesz ją wydać.

Nagle przestajesz być deweloperem gier; stajesz się inżynierem DevOps. Musisz skonfigurować serwery Linux. Musisz napisać system matchmakingu, który grupuje graczy według pingu i umiejętności. Potrzebujesz zautomatyzowanego systemu do dynamicznego uruchamiania dedykowanych instancji serwerów w oparciu o zapotrzebowanie graczy i wyłączania ich w celu oszczędzania pieniędzy, gdy liczba graczy spada. Potrzebujesz bezpiecznych baz danych dla ekwipunków graczy i tabel wyników, a wszystko to chronione certyfikatami SSL i warstwami łagodzącymi ataki DDoS.

Zbudowanie tego samemu wymaga skonfigurowania klastrów Kubernetes, systemów równoważenia obciążenia (load balancers), shardingu baz danych i menedżerów gniazd (sockets) w czasie rzeczywistym – to lekką ręką 4 do 6 miesięcy wyczerpującej pracy nad infrastrukturą, która nie ma absolutnie nic wspólnego z czynieniem twojej gry fajną.

Właśnie dlatego istnieje Backend-as-a-Service (BaaS). Dzięki horizOn te złożone usługi backendowe są wstępnie skonfigurowane specjalnie dla deweloperów gier. Zamiast pisać niestandardową logikę matchmakingu i konfigurować instancje AWS EC2, integrujesz SDK i pozwalasz platformie zająć się orkiestracją serwerów, uwierzytelnianiem graczy i trwałością danych. Pozwala to na wydanie samej gry, a nie stosu technologicznego infrastruktury.

Przenosząc zarządzanie serwerami na platformę stworzoną z myślą o grach, odzyskujesz setki godzin potrzebnych na dopracowanie pętli rozgrywki i naprawę błędów.

5 najlepszych praktyk przy migracji do wersji deweloperskich Godot 4.7

Aktualizacja do wersji rozwojowej jest z natury niebezpieczna. Jeśli jesteś zdeterminowany, aby przetestować nowe funkcje Godot 4.7 w swoim obecnym projekcie, musisz przestrzegać surowej higieny wdrożeniowej, aby uniknąć uszkodzenia plików projektu.

1. Obowiązkowe tworzenie gałęzi (Branching): Nigdy nie otwieraj głównego folderu projektu w wersji Dev. Użyj Gita, aby utworzyć dedykowaną gałąź specjalnie do testowania aktualizacji. Jeśli projekt się zepsuje, możesz po prostu usunąć gałąź i wrócić do bezpiecznego stanu.
2. Ustalenie punktów odniesienia dla profilowania: Przed aktualizacją uruchom grę w Godot 4.3/4.6 i zanotuj średnie FPS, wywołania rysowania i zużycie pamięci w najbardziej obciążającej scenie. Porównaj dokładnie te same metryki w nowej wersji. Jeśli wydajność spadnie, znalazłeś regresję, którą możesz zgłosić opiekunom silnika.
3. Audyt konfiguracji RPC: Kod sieciowy jest często pierwszą rzeczą, która psuje się podczas aktualizacji silnika. Przeprowadź audyt każdej adnotacji @rpc. Upewnij się, że flagi niezawodności (reliable) i zawodności (unreliable) nadal zachowują się zgodnie z oczekiwaniami przy symulowanym opóźnieniu sieci.
4. Kompilacja niestandardowych szablonów eksportu: Jeśli budujesz serwer dedykowany, nie polegaj na standardowych szablonach eksportu. Skompiluj niestandardowe szablony typu headless z kodu źródłowego Godota, aby usunąć moduły audio i renderowania, drastycznie zmniejszając zużycie pamięci RAM przez serwer.
5. Wdrożenie testów automatycznych: Użyj frameworka takiego jak GUT (Godot Unit Test), aby napisać zautomatyzowane testy dla swojej matematyki i logiki stanu. Po zaktualizowaniu silnika uruchomienie tych testów natychmiast zasygnalizuje, czy zmieniły się wewnętrzne obliczenia silnika.

Patrząc w przyszłość: Droga do wersji stabilnej

Silnik Godot jest w całości napędzany przez społeczność, co oznacza, że tempo jego rozwoju jest bezpośrednio powiązane z deweloperami, którzy testują te wczesne wersje i zgłaszają problemy. Chociaż Dev3 i Dev4 to tylko kroki przejściowe, reprezentują one najnowocześniejsze osiągnięcia (bleeding edge) w dziedzinie tworzenia gier open-source. Dają one dyrektorom technicznym i samodzielnym deweloperom przewidywalność niezbędną do zaplanowania architektury na miesiące przed premierą stabilnej wersji.

Opanowując architekturę autorytatywną dla serwera, agresywnie pulując obiekty i rozumiejąc potok renderowania, gwarantujesz, że twoja gra będzie się skalować niezależnie od wersji silnika. A kiedy będziesz gotowy, by zaprezentować tę mocno zoptymalizowaną grę wieloosobową globalnej publiczności, upewnij się, że twój backend jest równie solidny, co kod klienta.

Gotowy na skalowanie swojej gry wieloosobowej bez tonięcia w zarządzaniu serwerami? Wypróbuj horizOn za darmo i skup się na tym, co robisz najlepiej: tworzeniu niesamowitych gier.

---

Źródło: Godot 4.7 Dev3 and Dev4 Released