Przez ostatnie lata rozmowa o Unreal Engine skręcała głównie w stronę świetnej (choć powtarzalnej) grafiki i słabej optymalizacji. Nanite, Lumen, MetaHumans, ogromne światy, światło odbijające się od powierzchni tak, jak oczekuje tego oko – wszystko to budowało wrażenie, że przyszłość gier jest związana bezpośrednio z coraz to lepszą grafiką. Dziś coraz mocniej mam jednak wrażenie, że prawdziwa przyszłość gamedevu rozgrywa się w zupełnie innym miejscu i dlatego Unreal Engine 6 interesuje mnie nie jako kolejny silnik od ładniejszych scen, lecz jako próba przebudowy samego procesu robienia gier. Problem polega na tym, że Epic może przy okazji naruszyć coś, co przez lata było jedną z największych zalet Unreala – łatwość wejścia.
Blueprinty były przepustką do Unreala dla tysięcy twórców
Odkąd sam patrzę na silniki gier od strony praktycznej, Blueprinty zawsze wydawały mi się jednym z tych rozwiązań, które trudno docenić z zewnątrz. Gracz widzi bowiem finalny efekt, a programista może czasem kręcić nosem na wizualne grafy, splątane połączenia i logikę, która po kilku miesiącach prototypowania zaczyna przypominać mapę metra po awarii prądu. Tyle że dla wielu osób Blueprinty były czymś znacznie ważniejszym niż wygodnym narzędziem do składania zdarzeń. Były językiem wejścia.
Czytaj też: Programista w czasach sztucznej inteligencji. Spytałem w IBM, kim musi być dziś junior
Designer mógł opracować całą mechanikę bez proszenia programisty o każdą drobną zmianę. Programista mógł przygotować szkielet pod konkretną mechanikę i wyciągnąć logikę do funkcji stosowanych w Blueprintach. Level designer mógł podpiąć zdarzenie w lokacji. Artysta techniczny mógł szybko sprawdzić zachowanie obiektu, a solo developer mógł zrobić prototyp, zanim zderzył się z pełnym ciężarem C++. W zespołach Blueprinty stawały się pomostem między ludźmi, którzy myślą systemami, a ludźmi, którzy myślą kodem. Takie narzędzie nie tylko przyspiesza pracę. Ono zmienia, kto w ogóle może w tej pracy uczestniczyć.
Dlatego zapowiedź Unreal Engine 6 wywołuje tak duże emocje. Według najnowszych informacji Epic nie planuje nagłego wyrwania Blueprintów z pierwszej wersji UE6. Przeciwnie – Actors i Blueprinty mają być obecne we wczesnych wydaniach silnika. Dopiero później, a więc kiedy nowy framework dojrzeje, mają zostać zdeprecjonowane, a twórcy mają dostać narzędzia konwersji między starym i nowym podejściem. Oto więc w praktyce zaczyna się kilkuletnie wygaszanie sposobu pracy, na którym wychowała się ogromna część społeczności Unreal Engine.
Epic nie zabija Blueprintów jednym ruchem. Czy to dobra decyzja?
W takich tematach łatwo przesadzić i napisać, że “Blueprinty znikają”. Nie znikają. Przynajmniej nie teraz. Zostaną w UE6 Early Access i w początkowych wydaniach silnika. Epic celuje z Early Access w koniec 2027 roku, a pełna wersja UE6 ma pojawić się 12-18 miesięcy później. Oznacza to, że mówimy o procesie rozciągniętym na lata, a nie o aktualizacji, która jutro popsuje wszystkim projekty.
Właśnie ten długi horyzont jest jednak najciekawszy. Nagła zmiana byłaby brutalna, ale to długa migracja jest bardziej podstępna. Twórcy będą przez pewien czas żyć między dwoma światami. Stare projekty zostaną na UE5 albo wejdą w UE6 z Blueprintami. Nowe systemy będą rosnąć wokół Verse i Scene Graph. Dokumentacja, tutoriale, marketplace, edukacja i narzędzia zaczną powoli przesuwać się w stronę nowego modelu, a w którymś momencie pytanie nie będzie brzmiało “czy Blueprinty działają?”, lecz “czy warto jeszcze budować coś dużego w modelu, który Epic uznał za przejściowy?”.
Dla mnie właśnie tutaj tkwi sens mocnej tezy z tytułu. Unreal Engine 6 może zniszczyć najlepszą zaletę silnika nie dlatego, że Epic natychmiast usuwa Blueprinty, lecz dlatego, że zaczyna odbierać im wyjątkowy status. Blueprinty przestają być oczywistą odpowiedzią na pytanie “jak robić gameplay w Unreal Engine?”. Pozostają wspierane tu i teraz, ale przyszłość ewidentnie zaczyna być pisana gdzieś zupełnie indziej.
Verse nie jest nowym C++. Jest czymś bardziej strategicznym
Przechodząc dalej, czy naprawdę “Epic zastępuje C++ nowym językiem”. Nie. C++ nadal pozostaje niższym fundamentem silnika, natomiast Verse ma przejąć rolę głównego modelu programowania gameplayu. Różnica jest istotna, bo Epic Games nie próbuje po prostu zamienić jednego języka na drugi. Próbuje zmienić sposób, w jaki logika gry zachowuje się w dużych, trwałych, sieciowych światach.
Czytaj też: Gothic 1 Remake – przedpremierowe wrażenia z gry
Verse ma własne ambicje. Najważniejsza dotyczy transakcyjności. W uproszczeniu chodzi o taki model pracy, w którym zmiany stanu mogą być wykonywane jako transakcje, a podczas działania gry może je zatwierdzać, cofać i ponawiać, jeśli wymaga tego symulacja albo dystrybucja pracy między serwerami. Przy małej grze offline nie jest to nic wielkiego, ale przy ogromnym świecie online, w którym stan gracza, przedmiotów, ekonomii i zdarzeń musi być spójny, zaczyna to wyglądać jak próba rozwiązania problemu, którego Blueprinty nigdy nie miały rozwiązać.
Epic wspomina też o docelowym systemie, w którym kod gameplayu pisany w Verse może wyglądać tak, jakby działał na jednej maszynie, podczas gdy pod spodem silnik rozdziela pracę między wiele serwerów. Brzmi to imponująco, ale traktowałbym tę zapowiedź z ostrożnością. W dużych systemach sieciowych “automatyczne rozproszenie” jest jedną z tych obietnic, które wyglądają świetnie w opisie, a potem rozbijają się o opóźnienia, nietypowe przypadki, debugowanie i koszty utrzymania. Mimo tego kierunek jest zrozumiały. Epic buduje silnik nie tylko pod gry, ale pod żywe ekosystemy, bo wiadomo – mamy za mało gier pokroju Fortnite czy World of Warcraft.
Scene Graph pokazuje, że zmiana sięga głębiej niż język
Verse nie idzie sam. Drugim kluczowym elementem UE6 jest Scene Graph, czyli nowy framework gameplayowy budowany od podstaw na Verse. Dzisiejszy Unreal kojarzy się przede wszystkim z Actors, komponentami i Blueprintami. Nowy model ma przesunąć logikę w stronę encji, komponentów i bardziej modularnych struktur, które łatwiej współdzielić, przenosić i budować jako interoperacyjne elementy większych światów.
Na poziomie idei brzmi to sensownie, bo nowoczesne gry coraz częściej przypominają ogromne systemy zależności, a nie zbiór pojedynczych poziomów i obiektów. Potrzebują danych, komponentów, wersjonowania, współpracy, przenoszenia zasobów i pracy wielu osób naraz. Scene Graph może być zaś próbą uporządkowania tej warstwy w taki sposób, aby assety i zachowania były bardziej przenośne między projektami, co ułatwi cały proces np. tworzenia kontynuacji czy podobnych projektów.
Patrzę na to także przez pryzmat własnych doświadczeń z tworzeniem gier. Przy nawet niewielkim projekcie bardzo szybko okazuje się, że największym wrogiem nie jest brak pomysłu, tylko narastająca liczba zależności. Pisałem już o tym przy tworzeniu gry i zderzeniu prototypu z praktyką, choć teraz robię sobie przerwę od UE z projektem w Unity. Mały system wydaje się prosty, dopóki nie trzeba go zapisać, przenieść, rozbudować, przetestować, przetłumaczyć, zoptymalizować i utrzymać przez kolejne miesiące poprawek. Jeśli UE6 naprawdę ograniczy ten ciężar, to wielu twórców szybko zapomni o nostalgii za starym modelem. Jeśli jednak przeniesie chaos w nowe miejsce… no cóż. Wtedy Verse i Scene Graph staną się po prostu kolejną warstwą złożoności.
Największe ryzyko dotyczy dostępności, nie technologii
Nie mam problemu z tym, że Epic chce iść dalej. Gamedev nie może wiecznie opierać się na narzędziach zaprojektowanych dla innych czasów, innych skal produkcji i innych oczekiwań graczy. Problem zaczyna się wtedy, gdy postęp technologiczny zabiera dostępność, która wcześniej napędzała cały ekosystem.
Blueprinty były brzydkie w dużej skali, ale czytelne dla ludzi, którzy nie chcieli od razu stawać się programistami. Verse może być elegantszy, bardziej skalowalny i lepiej dopasowany do trwałych światów online, ale jeżeli zostanie podany jak klasyczny język kodu, to część użytkowników odbije się od ściany. Szczególnie dotyczy to edukacji, indyków, twórców prototypów i osób, które weszły w Unreal Engine właśnie dzięki wizualnemu skryptowaniu.
Wśród twórców już pojawił się spór o AI, Verse i przyszłość Blueprinty. Najostrzejsze komentarze są pewnie przesadzone, ale sam lęk nie jest absurdalny. Jeśli Epic przestanie rozwijać Blueprinty, a nowy model nie dostanie równie przystępnej warstwy pracy, Unreal Engine może stać się narzędziem potężniejszym, lecz mniej gościnnym. W branży, która już teraz odstrasza progiem wejścia, nie jest to byle drobiazg.
AI może pomóc, ale może też przykryć problem
Epic mocno wiąże UE6 z narzędziami model-assisted workflows. Unreal Engine 5.8 wprowadza eksperymentalny plugin Model Context Protocol, który pozwala podłączać modele takie jak Claude czy Gemini do projektów Unreal Engine. W przyszłości takie modele mają nie tylko odpowiadać na pytania, ale działać w kontekście projektu, automatyzować ręczne zadania, pomagać przy poziomach, rigach, cząsteczkach, oświetleniu czy analizie kodu.
Czytaj też: Programista dostał partnera. Spytałem u źródła, jak IBM Bob poprawia proces tworzenia oprogramowania
Ten kierunek pasuje do szerszej zmiany w komputerach i narzędziach twórczych. Podobny motyw widać przy komputerach budowanych wokół lokalnych agentów AI, gdzie sztuczna inteligencja przestaje być tylko chatbotem w przeglądarce, a zaczyna pełnić rolę warstwy roboczej między użytkownikiem, aplikacjami i danymi. W Unreal Engine taka warstwa może być szczególnie kusząca, bo silnik jest ogromnym środowiskiem pełnym powtarzalnych, żmudnych i trudnych do opisania czynności.
Mam jednak mieszane odczucia. AI może pomóc twórcom przejść z Blueprintów do Verse, analizować stare grafy, tłumaczyć zależności, sugerować migrację i wyłapywać błędy. Może też stać się wygodną zasłoną dymną. Jeśli podstawowe narzędzia migracji będą słabe, a Epic powie “asystent AI pomoże”, to wielu deweloperów słusznie się zirytuje. Model językowy nie zastąpi stabilnego workflow. Może go przyspieszyć, ale nie powinien być protezą dla niedokończonego narzędzia.
UE5.8 może stać się przystanią dla ostrożnych
W całej tej historii ważny jest jeszcze jeden szczegół. UE5.8 jest obecnie ostatnią planowaną dużą wersją Unreal Engine 5, choć Epic zostawia sobie furtkę na UE5.9, jeśli będzie potrzebna. To oznacza, że przez kilka lat wielu twórców będzie żyło w dość specyficznym zawieszeniu. UE6 będzie widoczne na horyzoncie, ale jeszcze niedojrzałe, a UE5.8 będzie stabilnym wyborem, ale z poczuciem, że główny kierunek rozwoju przesuwa się gdzie indziej.
W praktyce duże studia będą analizować ryzyko migracji bardzo chłodno. Projekt startujący dziś może wyjść na rynek już w epoce UE6, ale samo przejście na nowy framework w środku produkcji może być zbyt kosztowne. Mniejsze zespoły i twórcy solo prawdopodobnie jeszcze długo zostaną przy UE5, a to zwłaszcza jeśli ich workflow opiera się na Blueprintach, pluginach i znanych narzędziach. Nie zdziwiłbym się więc, gdyby UE5.8 stał się czymś w rodzaju bezpiecznej przystani dla projektów, które nie potrzebują Fortnite’owej przyszłości od pierwszego dnia.
Musimy pamiętać, że nadejście UE 6.0 nie oznacza, że stare wersje przestaną działać. Nie przestaną. Dziś ciągle projekty powstają na starych wersjach UE i nikt nie ma z tym problemu. Taki stan nie musi być zły. Silniki gier nie zmieniają się w rytmie smartfonów. Wiele produkcji latami siedzi na jednej wersji, bo stabilność jest ważniejsza niż nowość.
Źródła: Unreal Engine, Creative Bloq
