Czym jest silnik gry wideo? Przepytaliśmy polskich devów

Śledząc zapowiedzi nowych wysokobudżetowych gier, coraz częściej zwracamy uwagę na to, na jakim silniku będzie powstawał dany tytuł. Znając trochę branżę, już po samej nazwie engine’u możemy wstępnie określić, czego spodziewać się po danej produkcji. Przykładowo Frostbite EA kojarzy się dziś z problemami technicznymi, Creation Bethesdy trąci myszką w każdym aspekcie, Snowdrop Ubisoftu zachwyca szczegółowo odtwarzanymi miastami, a po demonstracjach możliwości Unreala 5 mamy nadzieję, że gry w końcu pokażą next-genową jakość. Słowo „silnik” – kiedyś oznaczające kluczowy element napędowy wielu maszyn – jakoś wyjątkowo dobrze przyjęło się również w informatyce. Tyle że tutaj ma szersze znaczenie.

Silnik programistyczny to kompleksowa platforma czy też szablon do tworzenia aplikacji. Wykorzystywany jest nie tylko w branży gier. Swoje engine’y mają także przeglądarki internetowe czy bazy danych, ale te najbardziej znane nazwy dotyczą właśnie gier. Silnik składa się z wielu elementów odpowiedzialnych za działanie takich rzeczy jak fizyka i kolizje obiektów, efekty dźwiękowe, kod sieciowy, skrypty, animacje, zachowanie sztucznej inteligencji. Może także zawierać moduł renderowania grafiki. Do sprawnej pracy z silnikiem przeznaczone są dedykowane narzędzia programistyczne.

Taki gotowy zestaw pozwala znacznie uprościć i przyspieszyć tworzenie wielu składowych gry, niejednokrotnie wykorzystując ponownie sprawdzone już fragmenty kodu. Dzięki temu redukowane są koszty, liczba błędów lub chociażby czas potrzebny do ukończenia projektu. Oczywiście gotowy silnik nie jest lekiem na wszelkie bolączki procesu powstawania gry i nie zawsze wszystko przebiega zgodnie z planem. My jako odbiorcy znamy tylko ten końcowy efekt – jak gra prezentuje się i działa, zwykle na jakimś silniku. „Od kuchni” wygląda to zupełnie inaczej.

A jak konkretnie? Co stanowi największą zaletę oraz wadę silników gier? Kiedy warto stworzyć swoją platformę od podstaw, a kiedy wykorzystać gotowy produkt? Informacji zasięgnęliśmy u samego źródła, czyli zapytaliśmy o to programistów z kilku znanych polskich studiów: Techlandu, Flying Wild Hog, Frozen Districtu, Frozen Way i Destructive Creations.

Unreal Engine 5 zapowiada konkretny skok jakościowy w wyglądzie i możliwościach przyszłych gier.

Swój czy na licencji?

GOL: Jedną z ciekawszych decyzji, które zapadają jeszcze przed rozpoczęciem konkretnych prac programistycznych, jest sam wybór silnika. Niektóre studia przeznaczają sporo czasu i pieniędzy na stworzenie własnej platformy. Inne, nawet te całkiem duże, sięgają po gotowe, popularne rozwiązania dostępne na rynku, takie jak chociażby Unreal Engine. Techland przy dwóch częściach Dying Lighta korzystał z własnych silników: Chrome-6 i C-Engine. Twórcy Shadow Warriora przy trzeciej części zrezygnowali z własnego Road Hog Engine’u i przesiedli się na znany produkt Epica – Unreal 4. Jakie powody stoją za takimi wyborami? Kiedy opłaca się zaczynać wszystko od zera?

Grzegorz Rdzany (Flying Wild Hog): Patrząc na to czysto budżetowo, tworzenie własnego silnika zazwyczaj jest droższe niż licencjonowanie gotowego rozwiązania. Zwłaszcza jeśli spojrzy się na to w kontekście jednego, dwóch projektów. Ale jest kilka czynników, które powodują, że skupienie się na swojej technologii niekiedy wydaje się bardziej opłacalne. Przede wszystkim własna technologia pozwala na dużo większą swobodę w realizacji naszych pomysłów. Komercyjne silniki z racji tego, że muszą być w pewnym stopniu uniwersalne, bywają w niektórych aspektach nieoptymalne albo wręcz brakuje im specyficznych rozwiązań, które chcielibyśmy mieć w swojej grze. To powoduje, że i tak trzeba silnik dostosowywać do swoich potrzeb.

Własna technologia jest też zazwyczaj dużo lepiej znana i rozumiana przez deweloperów na niej pracujących, więc łatwiej im implementować nieszablonowe rozwiązania. Jeśli jakaś firma specjalizuje się w określonym typie gier i ma zestaw swoich unikatowych rozwiązań do nich, to utrzymywanie własnej technologii może w dłuższej perspektywie okazać się bardziej opłacalne, zwłaszcza gdy ma się do tego odpowiednie zaplecze osobowe i finansowe.

Dzięki własnemu silnikowi Techland mógł stworzyć mechanikę parkouru oraz walki tak, jak sobie to zaplanował. Na ogólnie dostępnych silnikach w Dying Lighta 2 grałoby się zupełnie inaczej.

Patryk Czajka (Frozen Way): Unity i Unreal Engine są elastyczne i oferują wiele gotowych funkcjonalności, ale przez to posiadają też wiele elementów niepotrzebnych lub niepasujących do specyficznych wymagań konkretnej gry. Deweloperzy, tworząc własny silnik, implementują tylko potrzebne rozwiązania, co sprawia, że nie są ograniczeni na późniejszym etapie prac. Kreowanie gry w gotowym uniwersalnym silniku jest prostsze, ale często wymaga kompromisu.

Jarosław Zieliński (Destructive Creations): Raczej niewiele nowych firm tworzy własne silniki, tylko używa tych dostępnych. A w przypadku „starych” jest to kwestia ewolucji firmy. Jeszcze z dwanaście lat temu za licencję na Unreal Engine 3 i możliwość wydania na nim gry trzeba było zapłacić jakieś okropne setki tysięcy dolarów. Przez brak sensownych i tanich alternatyw własne silniki były traktowane przez firmy jak skarb. Trochę tych firm przetrwało, często dalej tworzą na swoim „techu” rozwijanym przez lata. Jednak widać tendencję do odchodzenia od tego, teraz dużo taniej i wygodniej jest zapłacić za gotowy silnik, niż opracować własny. W ogóle nie opłaca się robić swojego silnika. Przynajmniej nie jako firma robiąca własne gry.

Kris Krej (Frozen District): Nie tworzy się ich już. Nawet tu, w Polsce, mamy liczne przykłady firm, które przenoszą się z własnych silników na Unreal lub Unity (np. Wiedźmin 4 na Unreal, Layers of Fear na Unity), mimo że autorzy obu tytułów mają własne silniki. O zespole, który pracował na którymś z tych silników i postanowił przerzucić się z powrotem na własny, nie słyszałem.

Przechodząc na Unreal 4, twórcy Assetto Corsa Competizione mogli znacznie poprawić jakość oprawy graficznej w porównaniu z poprzednią odsłoną cyklu powstałą na ich własnym silniku.

Jaka gra, taki silnik

GOL: W niektórych przypadkach wybór silnika nie jest podyktowany wyłącznie kwestiami finansowymi. Wpływa na to rodzaj, gatunek gry, jaką się tworzy, bo niektóre platformy bardziej nadają się do konkretnego typu rozgrywki niż inne. Najlepiej wiedzą chyba o tym studia tworzące swoje gry na silniku Frostbite, przeznaczonym pierwotnie dla sieciowej strzelanki FPP Battlefield. A co o tym sądzą devowie?

Łukasz Burdka (Techland): Silniki gier mają różne możliwości i każdy nadaje się najbardziej do określonego typu gry. Silniki do gier TPP, FPP, strategii czy gier sportowych kładą nacisk na inne zestawy funkcjonalności. [...] Fakt, że różne silniki nadają się do różnych rodzajów gier, to bardziej kwestia specjalizacji niż ograniczeń. To tak jak z samochodami. Samochód terenowy, rajdowy oraz bolid F1 są technologicznie przystosowane do zupełnie innych zadań i trudno porównywać je ze sobą. W przypadku silników gier systemy, które wchodzą w ich skład, są dedykowane określonym typom produkcji. Przykładowo strategia czasu rzeczywistego nie potrzebuje w silniku wsparcia dla wiarygodnych animacji albo mimiki twarzy, ale cenny byłby tu rozbudowany system sztucznej inteligencji.

Kris Krej (Frozen District): Nie widziałbym sensu w tym, aby na Unreal Enginie robić grę, która nie będzie wykorzystywać jego możliwości graficznych. W efekcie nie widzę celu, żeby robić na UE karcianki lub proste graficznie gry logiczne. Mam wrażenie, że im więcej kodu trzeba napisać samemu, tym bardziej Unity wydaje się zachęcające.

Unreal Engine 4 okazał się niezwykle uniwersalnym narzędziem. Powstały na nim gry z przeróżnych gatunków, w tym również nieco nietypowe Trek to Yomi.

Xibuk: (Frozen District): Unreal był pierwotnie silnikiem projektowanym do tworzenia gier typu multiplayer FPS. Obecnie jest to dużo mniej odczuwalne niż kiedyś, jednak wciąż można zauważyć zaszłości dawnego trendu. Unity pozwala na tworzenie skomplikowanych koncepcji programistycznych, które stosunkowo łatwo utrzymywać. W UE również jest to oczywiście możliwe, lecz zapewne trudniejsze.

GOL: A czy istnieje w ogóle silnik naprawdę uniwersalny – do wszystkiego?

Xibuk: (Frozen District): Moim zdaniem stworzenie uniwersalnego silnika nie jest możliwe. Taka idea wydaje się kusząca, bo wtedy zgarniamy cały rynek, jednak „kobyły” tego typu bardzo szybko tracą swoją uniwersalność, gdy chcemy zrobić na nich coś bardziej specjalistycznego, skomplikowanego. Inne podejście stosuje się np. do gier typu RTS, inne do gier FPS. Inaczej renderujemy, tworzymy logikę. Silniki uniwersalne okupują swoją wszechstronność skomplikowanymi edytorami, długimi czasami budowania projektu czy wagą samego projektu startowego.

Kris Krej (Frozen District): W mojej opinii silniki już są bardzo uniwersalne. Nie wiem, czy pójście dalej byłoby możliwe i potrzebne. Jeśli chciałbym na Unreal Enginie pisać grę tekstową działającą jako strona html, byłby to niewiarygodnie dziwny pomysł. To trochę tak, jakbyśmy zastanawiali się, dlaczego nie można zrobić jednego uniwersalnego noża: do rozsmarowywania masła i precyzyjnych operacji chirurgicznych. Może i można, tylko po co?

Grzegorz Rdzany (Flying Wild Hog): Teoretycznie jest możliwe, ale chyba jeszcze nikt tego nie dokonał, bo wymagałoby to ogromnego wysiłku, doskonałej architektury i olbrzymiej dyscypliny przy implementacji. Wydaje się też, że nie byłoby to opłacalne. Problem w tym, że różne typy gier mają różne wymagania co do poszczególnych systemów silnika. Jedne potrzebują wyświetlić bardzo dużo animowanych obiektów, ale o względnie niskiej szczegółowości (jak np. strategie), a inne mniej obiektów, ale za to o wysokim poziomie detali (np. gry FPP). W jednych gracz porusza się względnie wolno (gry z pieszym bohaterem), a w innych bardzo szybko (np. wszelkiego rodzaje gry wyścigowe). Tych parametrów i ich skrajnych wartości są setki, o ile nie tysiące. Pogodzenie ich w ramach jednej technologii to nie lada wyzwanie. Zazwyczaj prościej jest po prostu zastosować różne silniki do różnych grup potrzeb.

Anthem to do dziś jeden z najgłośniejszych przykładów złego wyboru silnika do planowanych mechanik gry.

Kiedy silnik niedomaga...

GOL: Skoro nie ma silników w pełni uniwersalnych, zapewne podczas tworzenia większości gier pojawia się problematyczna kwestia braku jakiejś istotnej funkcjonalności, niemożności dodania planowanej mechaniki. Wtedy albo zaczyna się okres szczególnie wytężonej pracy, albo szukania kompromisów, co – niestety – może oznaczać rezygnację z ciekawych i nowatorskich pomysłów.

Patryk Czajka (Frozen Way): Możemy podjąć próbę napisania własnego rozwiązania lub użycia zewnętrznej paczki czy plug-inu. Jeśli nie jesteśmy w stanie zrealizować tego w ten właśnie sposób, uciekamy się do stworzenia wątku na forum i pozostajemy z nadzieją, że potrzeba zostanie zauważona, tj. dostaniemy odpowiednią liczbę „upvote’ów”, a twórcy silnika zdążą naprawić lub zaimplementować potrzebną funkcjonalność do kolejnego razu, gdy będzie nam ona potrzebna. Dopóki to nie nastąpi, pozostaje lekka zmiana mechaniki w grze. Tworzenie gier to kompromis, jednak należy zdać sobie sprawę, że silnik to jedynie podstawa, narzędzie do realizacji projektu, a nie gra.

Grzegorz Rdzany (Flying Wild Hog): Mamy zazwyczaj kilka opcji. Najbardziej oczywista, to stworzenie brakującej funkcji samemu – i tak też często robimy. Staramy się to jednak robić w taki sposób, aby nie utrudnić sobie późniejszych aktualizacji silnika. Innymi możliwościami są: znajdowanie w UE Marketplace gotowych rozwiązań spełniających nasze potrzeby, wykorzystanie middleware’ów i bibliotek innych firm lub też ustalenie, czy w planach rozwoju silnika pojawi się kiedyś taka funkcja, i dopasowanie naszych planów projektowych tak, aby na nią zaczekać.

Kris Krej (Frozen District): Możemy dorobić tę funkcję, zrezygnować z części projektu, która jej wymaga, lub zmienić silnik – w tej właśnie kolejności!

Panie, ten typ tak ma!

GOL: Obecność lub brak jakiejś funkcjonalności w silniku gry pozwala stworzyć na tej podstawie szybką listę wad i zalet konkretnej platformy. Do tego dochodzi jeszcze stopień skomplikowania danego silnika – niektóre są łatwe do nauczenia, wprowadzania własnych rozwiązań, inne mniej. Jak to wygląda w przypadku najpopularniejszych na rynku – Unity i Unreal Engine’u?

Patryk Czajka (Frozen Way): Unreal Engine jest skomplikowany dla programistów, natomiast łatwy dla artystów. Unity opisałbym jako trudny w pracy dla artystów, natomiast przystępny dla programistów do pewnego poziomu.

Kris Krej (Frozen District): Do zalet Unity na pewno należy to, że prototypuje się w nim bardzo szybko, silnik można łatwo rozwijać samemu, tworząc własne narzędzia edytora, no i jest stosunkowo „lekki” – zadziała bez problemu na przeciętnym laptopie. Jest też bardzo popularny na rynku – łatwo znaleźć ekspertów, łatwo znaleźć rozwiązania większości problemów, które można napotkać. Wady to z kolei brak sensownego generatora postaci, podczas gdy Unreal wprowadza dedykowany MetaHuman Creator, oraz nie najlepiej wyglądające oświetlenie.

Zaletą silnika Unity jest „lekkość” i niskie wymagania sprzętowe. Valheim nie dość, że działa płynnie, to jeszcze zajmuje bardzo mało miejsca na dysku, jak na dzisiejsze standardy.

Xibuk (Frozen District): Dodatkowo dużą zaletą korzystania z Unity jest możliwość pisania kodu w wysokopoziomowym języku programowania C#, który w porównaniu z językiem C++ w UE jest znacznie wygodniejszy w użytkowaniu. Słabe strony Unity to brak możliwości edycji kodu silnika. Środowisko pracy bardziej sprzyja programistom, kosztem komfortu grafików czy designerów.

Valdur (Frozen District): Wady Unity? Wolno rozwijana obsługa DirectX 12 i ray tracingu. Dodatkowo w obecnym czasie wiele kluczowych komponentów, takich jak networking, rendering czy UI, jest realizowanych na kilka sposobów, z których jedne są jeszcze w fazie wstępnej, a drugie już przestarzałe.

Grzegorz Rdzany (Flying Wild Hog): Na pewno w kontekście uczenia się jakiejkolwiek technologii istotny jest dostęp do szczegółowej i aktualnej dokumentacji, materiałów szkoleniowych, rozmiar społeczności skupionej wokół tej technologii, ilość dostępnych przykładów rozwiązań itd. Jeśli weźmiemy to wszystko pod uwagę, trzeba przyznać, że Unreal Engine jest jednym z przystępniejszych silników. Inne komercyjnie dostępne silniki też zapewniają sporo sensownego wsparcia nowym użytkownikom. Można by rzec, że najtrudniejsze do nauczenia są silniki robione na wewnętrzne potrzeby poszczególnych studiów.

Pomoc dzieli się na darmową i płatną

GOL: Przy własnym silniku studio zdane jest na własne siły i własnych specjalistów. Przy ogólnodostępnych rozwiązaniach można liczyć na pomoc wydawcy silnika, przykładowo firmę Epic. Jak zatem wygląda wsparcie dla devów? Na co mogą liczyć?

Grzegorz Rdzany (Flying Wild Hog): Epic ma dość obszerną dokumentację oraz sporo materiałów szkoleniowych. Dostępne jest także forum, na którym społeczność skupiona wokół UE pomaga sobie nawzajem. Jest też UDN – portal dedykowany posiadaczom licencji, na którym w trudniejszych przypadkach można otrzymać bezpośrednie wsparcie od inżynierów Epica.

To głównie od twórców zależy to, jak oryginalne będą ich produkcje – nawet jeśli powstają na tym samym silniku.

Patryk Czajka (Frozen Way): Dwie osoby z naszego zespołu rozmawiają aktualnie z deweloperem systemu Meta Sounds, na bieżąco rozwiązując problemy. Jest to możliwe dzięki istnieniu otwartego Discorda Unreal Engine’u, gdzie można takie osoby spotkać. Dużym wsparciem są kursy na oficjalnej stronie silnika. Niektóre z nich są darmowe, jednak istnieje opcja zapłacenia za wersję rozszerzoną. Rzecz, która nam się najbardziej podoba, to streamy deweloperów Unreal Engine’u, w trakcie których często poświęcają swój czas na pokazanie i promowanie projektów stworzonych przez społeczność.

Czy Unreal Engine 5 będzie rewolucją...

GOL: Czekamy na pierwsze gry na nowym silniku Epica – Unreal Enginie 5. Pokazywane do tej pory dema technologiczne zapowiadają iście next-genową grafikę, robiąc nadzieję na pewien skok technologiczny, którego w większości tytułów od wielu lat nie widać. Czy tak samo będzie z fizyką obiektów, zachowaniem sztucznej inteligencji? Przekonamy się z czasem. A czym piąta generacja Unreala zachwyciła profesjonalistów?

Jarosław Zieliński (Destructive Creations): UE5 to, w moich oczach, po prostu upgrade UE4. Równie dobrze mógłby nie mieć piątki w nazwie. To zupełnie nie ten poziom rewolucji, jaki miał miejsce pomiędzy „trójką” a „czwórką”. Epic „doszył” w UE5 kilka rzeczy, głównie z myślą o grach FPP/TPP. Rozwija też mocno narzędzia, które powodują, że silnik jest bardziej przystępny dla początkujących, uczących się jeszcze programistów. Zapewne będzie miał sporo nowych, „crashogennych” problemów, sporo nowych, niewystarczająco przetestowanych mechanik. Ale trzeba się na niego przesiadać, bo właśnie UE5 będzie dalej rozwijany przez Epic, a „czwórka” pójdzie w odstawkę.

Grzegorz Rdzany (Flying Wild Hog): W UE5 jest sporo nowości, które cieszą deweloperów. Oczywiście nowe błyskotki w renderingu, w postaci Lumena i Nanite’a, budzą wiele emocji, ale z naszej perspektywy warte uwagi są też zmiany w samych narzędziach, ich reorganizacja, poprawa stabilności i ergonomii, uproszczenie niektórych procesów. Do tego dochodzi nowy mechanizm zarządzania danymi i ich streamowania (World Partition), który powinien wreszcie zwiększyć możliwości budowania dużych otwartych światów.

Sequel przygód Senui ma zapewnić niesamowitą oprawę graficzną dzięki silnikowi Unreal Engine 5.

Nowy system symulacji fizycznej Chaos Physics ma wielki potencjał, ale wymaga jeszcze kilku iteracji, by osiągnąć dojrzałość, która pozwoli w pełni go wykorzystać. Warto też wspomnieć o MetaHuman. Nie jest to technologia zależna stricte od UE5, bo można jej też używać w projektach na UE4. Niemniej jest to imponujące rozwiązanie stworzone przez Epic i niewątpliwie sporo zmieni w przyszłych grach, dając szerszy i łatwiejszy dostęp do doznań o filmowej jakości.

Patryk Czajka (Frozen Way): Demo Matrixa zrobiło na nas wrażenie. W końcu udało im się w jednej prezentacji pokazać możliwości systemów Nanite, Lumen, MetaHuman i World Partition. Na razie MetaHuman uważamy za dobre narzędzie przykładowo do tworzenia filmów, a nie gier. Jesteśmy pod wrażeniem systemu Lumen, którego efektem jest niesamowicie realistyczne światło w czasie rzeczywistym, przy dobrej karcie graficznej i zachowaniu stabilnej liczby FPS-ów. Podobny efekt przynosi renderowanie obrazu w innym programie graficznym, klatka po klatce, więc jest się czym zachwycać. Nanite pozwala na tworzenie scen wręcz fotorealistycznych, daje to dużo swobody artystom, natomiast u nas w projekcie dobrze sprawdzi się do przyspieszenia etapu tworzenia modeli 3D i wprowadzania do nich poprawek.

Kris Krej (Frozen District): Nanite – podejście, dzięki któremu można wrzucić na scenę bardzo złożony model, a silnik sam „zwirtualizuje” jego geometrię tak, aby graczowi wyświetlał się z optymalną ilością szczegółów. To zapowiada się na niewiarygodne ułatwienie dla twórców gier.

Valdur (Frozen District): No i Lumen – dynamiczne oświetlenie bez potrzeby „wypiekania” map zawczasu sprawi, że światy staną się mniej statyczne, bardziej podatne na modyfikację przez graczy.

Łukasz Burdka (Techland): Cały czas obserwujemy trendy na rynku, ale w tej chwili jesteśmy zadowoleni z naszych rozwiązań.

...i czy popularność Unreala nie zaszkodzi grom?

GOL: Już teraz możemy zauważyć pewien trend w dominacji silnika Epica – Unreal Engine’u. Powstaje na nim mnóstwo produkcji i mimo wcześniejszych słów o tym, że tak naprawdę nie ma jednego, uniwersalnego silnika do wszystkich gatunków, to właśnie Unreal wydaje się mieć tutaj największy potencjał. Rodzi to pytanie, czy z czasem rynek nie będzie coraz bardziej „zalany” produkcjami opartymi na tym samym szablonie, z tymi samymi efektami, mechanikami? Czyli generalnie: czy Unreal Engine może w negatywny sposób zdominować rynek gier?

Xibuk (Frozen District): Sam silnik nie definiuje gry, jest to jedynie fundament. Nawet gry na tym samym silniku mogą różnić się stylem graficznym, funkcjonalnościami, gatunkami i wieloma innymi rzeczami. Nie uważam, by nawet kompletna dominacja UE na rynku miała spowodować ujednolicenie gier na nim tworzonych.

Patryk Czajka (Frozen Way): Nie martwiłbym się o to! Silnik to nie gra, a efekt końcowy zależy tylko od twórców. Oczywiście, tak zwane „asset flipy” będą wyglądały tak samo, ale to dotyczy każdego silnika.

Grzegorz Rdzany (Flying Wild Hog): Rzecz jasna, istnieje takie ryzyko. Ale trzeba przyznać, że od czasów UE3 dużo się w tym względzie zmieniło. Już UE4 pozwala na całkiem spory wpływ na ostateczny wygląd gier na nim powstających. UE5 powinien dostarczyć jeszcze więcej narzędzi do realizacji indywidualnego stylu artystycznego oraz unikatowych elementów rozgrywki. Więc raczej tutaj wiele będzie zależeć od samych twórców, ich pomysłowości i też znajomości technologii. Niektórzy będą robić rzeczy według „szablonu”, inni włożą w swoje gry więcej niepowtarzalnego charakteru.