Na początku 2026 Unity wrzuciło High Definition Render Pipeline w tryb utrzymaniowy, co spadło na nieufność ciągnącą się od opłaty runtime z 2023 roku, a internet zapełnił się poradnikami o migracji. Ja idę w drugą stronę, więc powiedzmy sobie precyzyjnie, ile to jest warte, zanim przeczytasz cokolwiek dalej.
Co faktycznie zrobiłem i czego nie pamiętam
Używałem Godota poważnie. Zrobiłem w nim grę 3D, w którą zagrali znajomi i powiedzieli, że to dobry kierunek — i to jedyna zewnętrzna ocena, jaką ten projekt kiedykolwiek dostał. Nie wydałem w nim niczego komercyjnie. Potem wróciłem do Unity i już zostałem.
Nie pamiętam dokładnie, której wersji używałem. To ma znaczenie, bo Godot wypuścił realne poprawki na przynajmniej jedną z rzeczy, o które się odbiłem, a artykuł podający dwuletnie wspomnienie jako dzisiejszą nowinę zasługuje na komentarze, które dostanie. Dlatego układ jest taki: co czułem, potem co jest dziś faktycznie udokumentowane, a na końcu czy to odczucie przeżywa zderzenie z drugą częścią.
Odczucie: „ten silnik trzyma mnie na podstawach"
Zdanie, które bym ci wtedy podał, brzmiało: Godot ogranicza mnie do podstawowych projektów. Nie przyszło żadnego konkretnego dnia. Narastało, a dwa warunki pamiętam wyraźnie: przyszło po długim czasie i wraz z rosnącą liczbą plików.
Zapamiętaj te dwa warunki, bo okazują się całym wyjaśnieniem — i nie są w ogóle stwierdzeniem o suficie silnika.
Tarcie pierwsze: dwie osoby, jeden projekt
To było najgorsze z trzech i to, które wtedy rozumiałem najsłabiej. Praca nad jednym projektem z kolegą była ciężka w sposób, którego nie umiałem nazwać, więc wrzuciłem to do szufladki „jesteśmy niezorganizowani". Nie byliśmy, a przynajmniej nie tylko.
Sceny Godota są tekstem, co zwykle sprzedaje się jako przewaga nad Unity w kontroli wersji i w zasadzie nią jest. Problem siedzi poziom niżej. Identyfikatory wewnątrz tych plików nie były generowane deterministycznie między maszynami. Dwie osoby dodające zasób do tej samej sceny mogą obie dostać wygenerowany identyfikator, w tej samej linii, a git nie ma jak tego pogodzić inaczej niż konfliktem.
I wtedy zamyka się druga połowa pułapki. Typowa rada przy skonfliktowanym pliku sceny brzmi
nie naprawiać go w edytorze tekstu — bo ręczna edycja .tscn to częsty
sposób na scenę, która przestaje się wczytywać. Zalecana droga to otworzyć projekt i wprowadzić
zmianę ponownie przez edytor. Czyli: format tekstowy, którego tekstu nie radzi się edytować.
Dowód, że to nie byliśmy tylko my
Istnieją dedykowane, zewnętrzne sterowniki scalania dokładnie do tego — narzędzia, które czytają pliki scen tak jak silnik i scalają węzły oraz zasoby po tożsamości, a nie po numerze linii, same przydzielając identyfikatory na nowo. Nikt nie pisze sterownika scalania dla gita do problemu, który nie występuje.
Wymowna jest też praktyczna rada krążąca w społeczności: ustalcie, kto pracuje nad którą sceną, i dzielcie sceny na mniejsze, żeby rzadziej na siebie wpadać. To obejście przez koordynację, a koordynacji dwuosobowy projekt po godzinach ma najmniej.
I tu jest część, która czyni to uczciwym. Godot się tym zajął. W styczniu 2025, w wersji
4.4, silnik dodał dedykowane pliki .uid, a zespół opisał publicznie rozumowanie —
w tym to, że jedna centralna baza identyfikatorów została odrzucona właśnie dlatego, że
„podlegałaby częstym konfliktom scalania w systemach kontroli wersji". Projektowali przeciwko
temu problemowi świadomie.
Jest lepiej, nie ma go zupełnie. Ta sama zmiana wprowadza nowy sposób na przegraną:
jeśli pliki .uid nie zostaną zacommitowane, referencje psują się po sklonowaniu
projektu. Więc jeśli wybierasz dziś silnik dla zespołu, to jest jedyny obszar, który
przetestowałbym przez jedno popołudnie, zamiast ufać mojemu doświadczeniu albo changelogowi.
Tarcie drugie: różnica w assetach to rząd wielkości
Moje wspomnienie było dosadne: w porównaniu z Unity assety nie istnieją. Jako sformułowanie jest to niesprawiedliwe, a jako skala — mniej więcej trafne.
| Najczęściej podawana wielkość | |
|---|---|
| Unity Asset Store | około 70 000–80 000 pozycji |
| Godot Asset Library | około 3 000 pozycji |
Czyli dwadzieścia do dwudziestu pięciu razy, zależnie od tego, kto liczy i co uznaje za asset. Ekosystem Godota mniej więcej podwoił się od wersji 4, więc kierunek jest dobry, choć dystans duży.
Zastrzeżenie waży tu jednak więcej niż sam współczynnik, a większość porównań je pomija: duża część tego, czego solowy twórca naprawdę potrzebuje, jest niezależna od silnika. Modele, tekstury, dźwięk i fonty z itch.io albo OpenGameArt importują się do obu i nie obchodzi ich, co wybrałeś. Ta luka tak naprawdę nie dotyczy grafiki.
Gdzie ta różnica naprawdę boli
Przy narzędziach specyficznych dla silnika. Rozszerzenia edytora, pomocniki inspektora, systemy zapisu, frameworki dialogowe, edytory maszyn stanów, narzędzia do pipeline'u buildów — czyli kategoria, w której albo kupujesz godzinę, albo spędzasz weekend. Tam czuje się dwudziestopięciokrotność.
Co od razu mówi, kogo to dotyka najmniej: jeśli i tak zamierzałeś pisać własne systemy, ten współczynnik kosztuje cię bardzo mało. Jeśli planowałeś składać z gotowców — kosztuje dużo.
Tarcie trzecie: gdzie naprawdę siedzi luka w 3D
Pamiętam, że 3D było walką. Czego nie umiałbym wtedy powiedzieć, to które 3D, a to rozróżnienie jest tu rzeczą wartą zabrania.
Godot 4 renderuje nowoczesne 3D porządnie. Materiały PBR, globalne oświetlenie, mgła wolumetryczna — stylizowane i średniej skali 3D jest pokryte przekonująco, a kto mówi ci, że Godot nie umie w 3D, pracuje na wspomnieniach z Godota 3.
To, co porównania konsekwentnie opisują jako dojrzewające, to konkretna lista, a każda pozycja na niej dotyczy skali, a nie możliwości:
- Poziomy szczegółowości i occlusion culling — rzeczy, które sprawiają, że scena nie kosztuje tyle, na ile wygląda.
- Streaming dużych światów i współrzędne wielkiej skali.
- Zaawansowane narzędzia do terenu oraz globalne oświetlenie czasu rzeczywistego na najwyższej półce.
- Duża liczba świateł, gdzie porównania zwykle stawiają Unity przed Godotem, gdy scena rzuca wiele cieni.
Zauważ, czym ta lista nie jest. Nie jest listą „Godot nie umie renderować". To lista rzeczy, które nie mają żadnego znaczenia, dopóki projekt nie urośnie, a potem mają ogromne. Mała scena nie potrzebuje occlusion cullingu. Poziom testowy nie potrzebuje streamingu.
Czyli mój wniosek był błędny, a kształt tej pomyłki jest użyteczny
Zestaw te trzy rzeczy z dwoma warunkami, które zapamiętałem: przyszło po długim czasie i gdy plików przybywało.
| Tarcie | Kiedy jest niewidoczne | Kiedy gryzie |
|---|---|---|
| Konflikty scen | Jedna osoba, mało scen | Dwie osoby, wspólne sceny, dużo plików |
| Ekosystem assetów | Gdy i tak piszesz własne systemy | Gdy zaczynasz chcieć kupować czas |
| 3D przy skali | Małe sceny, poziomy testowe | Więcej świateł, większy świat, streaming |
Wszystkie trzy są niewidoczne na starcie i wszystkie trzy przychodzą wraz ze wzrostem. Czyli to, czego doświadczyłem, nie było sufitem na możliwości silnika. To były trzy niezależne koszty, z których każdy skaluje się z wielkością projektu, przychodzące razem — a od środka trzy rzeczy robiące się trudniejsze naraz są nie do odróżnienia od ściany.
Uczciwa korekta mojego własnego zdania brzmi więc tak: Godot nie trzymał mnie na podstawach. Doszedłem do rozmiaru, przy którym jego słabsze miejsca się sumują, będąc jednocześnie dwuosobowym zespołem bez procesu, po stronie 3D — czyli w dokładnym przecięciu wszystkich trzech. Solowy twórca robiący grę 2D nie spotkałby żadnego z nich.
Dlaczego w ogóle prostuję siebie publicznie
Bo „silnik cię ogranicza" jest nie do obalenia i łatwo się roznosi, a powtarzałbym to latami, gdyby nikt nie kazał mi sprawdzić. Trzy sprawdzalne stwierdzenia są dla kogoś, kto wybiera dzisiaj, znacznie bardziej użyteczne niż mój wniosek kiedykolwiek był — i wskazują na inne decyzje.
Jak wybierałbym dzisiaj
Nie przez czytanie porównań, łącznie z tym. Przez odpowiedź na trzy pytania o twój projekt, bo każde odpowiada jednemu tarciu powyżej:
- Czy więcej niż jedna osoba będzie edytować te same sceny? Jeśli tak, poświęć jedno popołudnie na przetestowanie scalania, zanim zaangażujesz rok. Niech dwie maszyny dodadzą węzeł do tej samej sceny, skonfliktuj to celowo i rozwiąż. Cokolwiek się dowiesz, bije moje wspomnienie i changelog.
- Czy 3D robi się ciężkie? Dużo świateł rzucających cień, duży świat, streaming. Jeśli tak, tam luka się poszerza. Jeśli twoje 3D jest stylizowane i przestronne, a nie ogromne, to nie jest czynnik.
- Będziesz kupować czy pisać? Jeśli plan zakłada składanie z istniejących systemów, rząd wielkości w katalogu to różnica w harmonogramie, a nie w upodobaniach.
Jeśli wszystkie trzy odpowiedzi są małe, Godot jest świetnym wyborem, a rzeczy, za które się go chwali, są prawdziwe: zero niepokoju licencyjnego, malutki plik, sceny tekstowe, które naprawdę pasują do gita, i język do nauczenia w kilka dni. Żadne z moich tarć nie dotyka solowego projektu 2D, a to jest większość pierwszych projektów.
Wróciłem do Unity z powodów specyficznych dla tego, co buduję teraz: symulacji z dwudziestoma kilkoma gęstymi ekranami danych, 1624 testami automatycznymi i ekosystemem narzędzi, na którym mocno polegam. To argument o moim projekcie, a nie o silnikach, i wolę dać ci pytania niż swoją odpowiedź.
Pytania, które ludzie zadają
Dlaczego niektórzy wracają do Unity po próbie z Godotem?
U mnie trzy tarcia, żadne dotyczące języka ani edytora: współpraca z drugą osobą nad wspólnymi scenami, ekosystem assetów mniejszy o rząd wielkości, i luka w 3D niewidoczna na początku, rosnąca ze złożonością sceny. Godot poprawił od tego czasu pierwszą z tych rzeczy, więc sprawdź stan obecny, zamiast traktować czyjekolwiek wspomnienie, także to, jako nowinę.
Czy Godot jest zły dla zespołów?
Nie zły, ale historycznie niewygodny w jednej konkretnej rzeczy, która najmocniej uderza
w małe zespoły. Identyfikatory scen i zasobów nie były generowane deterministycznie między
maszynami, więc dwie osoby ruszające tę samą scenę mogły skonfliktować tę samą linię,
w formacie, którego nie radzi się edytować ręcznie, bo to często psuje scenę. Godot 4.4
dodał dedykowane pliki .uid w styczniu 2025, a zespół opisał rozumowanie wprost.
Istnieją zewnętrzne sterowniki scalania napisane pod ten problem, co samo jest dowodem, że
był realny.
Jak duża jest biblioteka assetów Godota wobec Unity?
Mniej więcej o rząd wielkości: najczęściej podawane liczby to około trzy tysiące pozycji wobec siedemdziesięciu tysięcy lub więcej, czyli dwadzieścia do dwudziestu pięciu razy, zależnie od liczenia. Uczciwe zastrzeżenie: duża część tego, czego potrzebuje solowy twórca, jest niezależna od silnika — modele, tekstury, dźwięk i fonty z itch.io czy OpenGameArt importują się do obu. Luka gryzie przy narzędziach specyficznych dla silnika i rozszerzeniach edytora, gdzie albo kupujesz godzinę, albo spędzasz weekend.
Czy Godot ogranicza do małych albo podstawowych projektów?
Nie i to jest twierdzenie, które najbardziej chcę sprostować, także u siebie, bo sam w nie wierzyłem. Godot 4 obsługuje stylizowane i średniej skali 3D przekonująco. W tyle zostają rzeczy mające znaczenie dopiero przy skali — poziomy szczegółowości, occlusion culling, streaming dużych światów, duża liczba świateł rzucających cień. Ponieważ ta luka jest niewidoczna wcześnie i przychodzi ze wzrostem, od środka czuje się dokładnie jak sufit na ambicje, choć jest sufitem na skalę w jednym obszarze.
Godot czy Unity w 2026?
Odpowiedz na trzy pytania o swój projekt zamiast czytać porównania. Czy więcej niż jedna osoba będzie edytować te same sceny? Czy scena 3D robi się ciężka — dużo świateł, duży świat, streaming? Będziesz kupować systemy czy je pisać? Jeśli wszystkie trzy odpowiedzi są małe, Godot jest świetnym wyborem, a jego przewagi licencyjne i rozmiarowe są prawdziwe. Tarcia z tego artykułu nie dotykają solowego projektu 2D.
Czy wrzucenie HDRP w tryb utrzymaniowy przez Unity to zmienia?
Zmienia rachunek dla najwyższej półki, a nie dla większości czytających porównania silników. Jeśli twój plan zależał konkretnie od HDRP, to prawdziwy powód do ponownej oceny i poradniki o migracji zalewające internet są kierowane do ciebie. Jeśli jesteś solowym twórcą albo małym zespołem robiącym coś stylizowanego, ma to bardzo niewiele wspólnego z tym, który silnik pasuje do twojego projektu — i warto zauważyć, jak dużo obecnej treści zakłada inaczej.