Dlaczego właśnie Unreal Engine i co jest potrzebne na start
Unreal Engine na tle innych silników gier
Unreal Engine to jeden z trzech najpopularniejszych silników gier obok Unity i Godota. Dla początkującego kluczowe jest nie to, który silnik jest „najlepszy”, ale który lepiej pasuje do sposobu nauki i rodzaju projektów, jakie chcesz tworzyć.
Unreal Engine wyróżnia się kilkoma cechami, które są szczególnie korzystne na pierwszy projekt:
Świetna grafika „out of the box” – bez skomplikowanych konfiguracji można uzyskać bardzo dobre efekty wizualne. To motywuje na starcie, bo prototyp wygląda od razu „jak z gry”.
Blueprints – wizualny system skryptowy, który pozwala budować logikę gry bez pisania kodu C++. Dla osób bez doświadczenia programistycznego to duży plus.
Gotowe szablony – First Person, Third Person, Top Down i inne, zawierające już podstawowe sterowanie, kamerę i postać. Zamiast walczyć z konfiguracją, możesz od razu budować poziom.
Silne wsparcie dla 3D – Unreal jest szczególnie dobry do gier 3D, akcji, FPS, przygodówek, ale sprawdzi się też w prostych projektach 2D/„pseudo 2D”.
W porównaniu:
Unity – lżejszy, świetny do 2D i mobile, opiera się głównie na C#. Bardziej elastyczny, ale wymagający od początku programowania tekstowego.
Godot – open source, lekki, świetny na słabsze komputery, dobra krzywa nauki, ale mniejszy ekosystem i inny „feeling” pracy niż w komercyjnych silnikach AAA.
Jeśli chcesz nauczyć się narzędzia, które jest używane w dużych studiach, zależy ci na wizualnej jakości i nie boisz się trochę cięższego narzędzia – Unreal Engine jest bardzo dobrym wyborem na start.
Sprzęt i system – co jest naprawdę potrzebne
Unreal Engine jest wymagający sprzętowo, szczególnie w wersji UE5 z Lumenem i Nanite. Da się jednak pracować na słabszych maszynach, jeśli od początku ustawisz rozsądne parametry.
Minimalna konfiguracja, przy której da się sensownie uczyć:
CPU: 4 rdzenie (np. i5 lub Ryzen 5 poprzednich generacji)
RAM: absolutne minimum 8 GB, ale 16 GB to realne minimum komfortu
GPU: karta z obsługą DirectX 11 / 12 (nawet starsze GTX-y, nowsze integry radzą sobie „na styk”)
Dysk: SSD (HDD bardzo mocno spowalnia pracę), wolne 50–200 GB na silnik + projekty
System: Windows 10/11 64-bit. UE działa także na macOS i Linuxie, ale większość tutoriali i przykładów zakłada Windows.
Na słabszej maszynie trzeba liczyć się z tym, że:
silnik będzie uruchamiać się długo (pierwsze włączenie szczególnie),
pierwsza kompilacja shaderów po włączeniu projektu może zająć kilka minut,
konieczne będzie obniżanie ustawień jakości i wyłączanie zbędnych efektów w edytorze.
Uwaga: przy pracy na laptopach gamingowych zwróć uwagę na tryb zasilania i to, czy system korzysta z dedykowanej karty GPU, a nie zintegrowanej – w przeciwnym razie Unreal Engine będzie działał dramatycznie wolno.
Konto Epic Games i ekosystem Unreal Engine
Do pobrania Unreal Engine potrzebne jest konto Epic Games. To samo konto, które działa z Fortnite czy sklepem Epic Games Store. Rejestracja jest darmowa. Po zalogowaniu z poziomu Epic Games Launcher masz dostęp do kilku elementów ekosystemu:
Unreal Engine – instalacja i zarządzanie wersjami silnika.
Marketplace – sklep z assetami: modelami 3D, materiałami, shaderami, pluginami, systemami AI itp. Część jest płatna, ale jest też dużo darmowych zasobów.
Sample Projects – gotowe projekty pokazowe (shooter, RPG, efekt wizualny, demo technologiczne), na których można się uczyć i podglądać rozwiązania.
Dokumentacja i Learn – oficjalne tutoriale, kursy wideo, przykłady. To najlepsze źródło, jeśli chcesz sięgnąć głębiej poza prosty prototyp.
Tip: przynajmniej raz przejrzyj zakładkę „Free” w Marketplace. Sporo darmowych paczek (szczególnie te oznaczone jako „Epic Games Content”) ma jakość komercyjną i świetnie nadaje się do nauki i prototypowania.
UE4 vs UE5 – którą wersję wybrać na pierwszy projekt
Obecnie Epic mocno stawia na Unreal Engine 5, ale UE4 nadal jest używany w wielu komercyjnych projektach. Dla początkującego najważniejsze różnice to:
UE4 – bardziej „dojrzały”, stabilny, mniej wymagający sprzętowo. Mniej jednak nowoczesnych systemów (Lumen, Nanite).
UE5 – najnowszy, bardzo dobry workflow dla artystów, nowoczesne oświetlenie Lumen, Nanite dla geometrii o wysokim detalu. Nieco cięższy dla sprzętu, część funkcji wciąż się zmienia między kolejnymi wersjami.
Dla pierwszego, prostego projektu warto zainstalować UE5 w stabilnej wersji (release). Powody:
większość nowych materiałów edukacyjnych dotyczy już UE5,
Lumen daje świetny efekt oświetlenia bez żmudnego bake’owania,
projekt stworzony teraz łatwiej będzie rozwijać w przyszłości.
Wyjątek: jeśli masz naprawdę słabą maszynę albo chcesz korzystać z konkretnego, starszego pluginu dostępnego tylko dla UE4 – możesz zacząć od UE4. W przeciwnym razie UE5 jest rozsądniejszym wyborem długoterminowym.
Instalacja Unreal Engine i pierwsze uruchomienie
Pobranie i instalacja Epic Games Launcher
Podstawą jest Epic Games Launcher – centralne narzędzie do instalowania i aktualizowania Unreal Engine.
Praktyczna sekwencja kroków:
Wejdź na stronę Unreal Engine i pobierz Epic Games Launcher dla swojego systemu.
Zainstaluj launcher, wybierając lokalizację na dysku SSD (zdecydowanie lepsza wydajność).
Po instalacji zaloguj się na konto Epic Games albo je utwórz.
Przejdź do zakładki „Unreal Engine” → „Biblioteka”.
W sekcji „Silniki” zobaczysz przycisk „+ Dodaj wersję”. Kliknij go, wybierz najnowszą stabilną wersję Release (unikaj na start wersji Preview) i dopiero wtedy kliknij „Zainstaluj”.
Wybór wersji silnika i konfiguracja lokalizacji
Przy instalacji Epic Games Launcher zapyta, gdzie zainstalować pliki silnika. Unreal Engine zajmuje sporo miejsca – jedna wersja może mieć kilkadziesiąt GB. Dodatkowo projekty też rosną w miarę pracy. Dlatego sensownie jest:
Wybrać dysk SSD, na którym masz co najmniej 100 GB wolnego miejsca.
Oddzielić lokalizację silnika (np. D:UnrealEnginesUE_5.x) od lokalizacji projektów (np. D:UnrealProjects).
Tip: trzymaj projekty na osobnym folderze – łatwiej jest później robić kopie zapasowe i przenosić projekty między komputerami, bez konieczności przenoszenia całego silnika.
Tworzenie pierwszego projektu – wybór szablonu
Po zainstalowaniu kliknij przycisk „Uruchom” przy wybranej wersji silnika. Po pierwszym starcie może pojawić się inicjalizacja i kompilacja shaderów – to normalne.
Następnie zobaczysz ekran startowy z zakładką „New Project” / „Nowy projekt”. Kluczowe decyzje na pierwszy projekt:
Szablon:
Third Person – bardzo dobry na początek; daje postać z kamerą za plecami, skokiem i prostą fizyką.
First Person – FPS z widocznymi rękami i bronią, dobry jeśli celujesz w strzelankę.
Top Down – kamera z góry, dobra baza pod RPG lub proste gry taktyczne.
Blueprint lub C++:
Na pierwszy projekt wybierz Blueprint. Pozwoli ci to skupić się na edytorze i logice gry, a nie na konfiguracji środowiska C++.
Platforma docelowa:
Na początek zaznacz Desktop / Console oraz „Maximum Quality”. Później można to zmienić w ustawieniach jakości.
Starter Content:
Zaznacz włączenie Starter Content. Daje to zestaw podstawowych meshów, materiałów, dźwięków – bardzo przydatny przy nauce.
Na końcu wpisz nazwę projektu (np. UE5_PierwszyProjekt), wybierz lokalizację folderu i kliknij „Create”. Unreal Engine utworzy całą strukturę projektu i wczyta domyślną mapę.
Ustawienia projektu a typowe problemy przy starcie
Przy pierwszym uruchomieniu mogą pojawić się błędy związane z środowiskiem programistycznym. Nawet jeśli projekt jest Blueprintowy, Unreal lubi mieć dostępne niektóre komponenty:
Visual Studio / Build Tools – na Windows warto zainstalować Visual Studio (Community) z workloadem „Desktop development with C++” albo przynajmniej Visual Studio Build Tools. Bez tego część operacji (np. kompilacja C++ w przyszłości) może się wykrzaczać.
Aktualne sterowniki GPU – szczególnie przy kartach Nvidii i AMD. Stare sterowniki potrafią powodować crashe przy uruchamianiu Viewportu.
DirectX i .NET – system zazwyczaj ma je wgrane, ale czasem pomocna jest reinstalacja DirectX Runtime ze strony Microsoftu.
Jeśli Unreal Engine zamyka się bez komunikatu przy ładowaniu, sprawdź w logach (folder Saved/Logs w projekcie), czy nie ma informacji o braku bibliotek C++ lub problemach z GPU.
Źródło: Pexels | Autor: UMUT 🆁🅰🆆
Interfejs Unreal Engine – orientacja w edytorze
Najważniejsze okna: Viewport, World Outliner, Details, Content Browser
Po otwarciu projektu zobaczysz główne okno Unreal Editor. Niezależnie od wersji, rdzeń interfejsu jest podobny.
Viewport – centralne okno sceny 3D. Tu widzisz swój poziom i wszystkie elementy gry. W nim poruszasz się kamerą, wybierasz obiekty i edytujesz je wizualnie.
World Outliner – lista wszystkich aktorów (obiektów) aktualnie umieszczonych na aktywnej mapie. Ułatwia wyszukiwanie i organizację, szczególnie gdy w poziomie jest kilkaset elementów.
Details – panel właściwości wybranego obiektu. Po zaznaczeniu czegoś w Viewporcie (np. ściany, światła, postaci) w „Details” można zmieniać położenie, skalę, materiał, logikę, komponenty itd.
Content Browser – przeglądarka assetów projektu. To tutaj widać foldery projektu (Blueprinty, materiały, meshe, dźwięki, mapy). Z tego okna przeciągasz assety do Viewportu i tworzysz nowe zasoby.
Toolbar – górny pasek przycisków: Play (uruchomienie gry), Save All, Build, dostęp do ustawień projektu i różnych narzędzi.
Tip: jeśli jakieś okno przypadkowo zamkniesz, przywrócisz je z menu Window → wybierając odpowiedni panel (Content Browser, World Outliner itd.).
Nawigacja w Viewport – sterowanie kamerą i skróty
Sprawne poruszanie się w Viewporcie to podstawa pracy w Unreal Engine. Standardowe sterowanie (domyślne, w stylu edytorów 3D):
Przytrzymanie Prawy przycisk myszy (PPM) + W, A, S, D – lot kamery jak w grze FPS.
Scroll myszy – przybliżanie/oddalanie (w trybie orbity wokół obiektu).
PPM + klawisze Q/E – ruch w górę/dół.
F – wyśrodkowanie widoku na zaznaczonym obiekcie (bardzo przydatne przy pracy na większych scenach).
W prawym górnym rogu Viewportu znajduje się suwak Camera Speed – prędkość poruszania się kamery. Na małych scenach warto ją zmniejszyć, na dużych – zwiększyć, żeby nie „pełzać” po poziomie.
Uwaga: Unreal ma dwa główne tryby widoku: Perspective (perspektywa) i ortho (Front, Top, Side). Na początku trzymaj się perspektywy; widoki ortho przydają się przy bardziej precyzyjnym level designie.
Po lewej stronie zwykle znajduje się panel „Place Actors”, a u góry Viewportu pasek z trybami edycji:
Po lewej stronie zwykle znajduje się panel „Place Actors”, a u góry Viewportu pasek z trybami edycji: Select, Landscape, Foliage, Modeling (plus ewentualnie inne, zależnie od zainstalowanych pluginów). Na start najczęściej korzystasz z pierwszego z nich, ale dobrze od razu wiedzieć, do czego służą pozostałe.
Select (Selection / Select Mode) to podstawowy tryb pracy. Możesz w nim:
zaznaczać aktorów w Viewporcie i World Outlinerze,
przesuwać, obracać i skalować obiekty za pomocą gizma (trzy kolorowe osie X/Y/Z),
korzystać z różnych narzędzi zaznaczania – pojedyncze kliknięcie, zaznaczanie prostokątem, filtrowanie po typie aktora.
Po przejściu w inny tryb, np. Landscape, łatwo wrócisz do normalnej pracy jednym kliknięciem w ikonę „Select”.
Landscape służy do tworzenia i rzeźbienia terenu (heightmapa – siatka punktów z informacją o wysokości). W tym trybie możesz:
zakładać nowy teren o zadanej rozdzielczości i rozmiarze świata,
rzeźbić góry, doliny, wygładzać krawędzie,
malować różne warstwy materiałów (np. trawa, skała, śnieg) po jednej powierzchni.
Uwaga: duży landscape potrafi szybko „zjeść” wydajność i pamięć. Na pierwsze próby lepiej tworzyć mniejsze mapy – np. małą wyspę zamiast całego kontynentu.
Foliage to tryb malowania roślinności i obiektów powtarzalnych (tzw. instancje meshów). Dodajesz do listy kilka meshów (np. drzewa, krzaki, trawy, kamienie), ustawiasz gęstość, losową skalę i rotację, a potem malujesz nimi po terenie jak pędzlem. Daje to:
zdecydowanie szybsze rozmieszczanie dużej ilości obiektów niż ręczne stawianie,
lepszą wydajność dzięki instancjonowaniu (silnik renderuje wiele kopii tego samego obiektu w jednym wywołaniu GPU).
Tip: nie przesadzaj z gęstością na słabszym sprzęcie – gęsty las z wysokopoligonowymi drzewami szybko obniży FPS.
Modeling w UE5 to zestaw narzędzi do prostej edycji geometrii bezpośrednio w silniku. Możesz tworzyć podstawowe bryły (bloczek, cylinder, sfera), ciąć je, wycinać otwory (Boolean), wygładzać krawędzie, a nawet generować proste UV (współrzędne do mapowania tekstur). To dobre rozwiązanie na:
prototypy poziomów, zanim grafik przygotuje docelowe modele,
proste „whiteboxy” – bryłowe wersje pomieszczeń, korytarzy, przeszkód.
Jeśli znasz już klasyczny system BSP/Geometry Brushes z wcześniejszych wersji Unreal, Modeling Mode w dużej mierze go zastępuje, dając przy tym większą kontrolę nad siatką.
Gdy oswoisz się z tymi trybami, dużo łatwiej będzie przejść do tworzenia pierwszej sceny, ustawiania światła i późniejszej logiki w Blueprintach. Kombinacja sprawnego poruszania się w Viewporcie, świadomego użycia trybów edycji i porządku w Content Browserze przekłada się na tempo pracy znacznie bardziej niż znajomość pojedynczych, „efektownych” funkcji.
Place Actors – dodawanie obiektów do sceny
Dopóki nic nie stoi w poziomie, nie ma z czym pracować. Panel Place Actors (zwykle po lewej) to magazyn podstawowych elementów, które można przeciągać do Viewportu.
Najczęściej używane kategorie na start:
Basic – proste bryły (Cube, Sphere, Cylinder), Player Start, Point Light, pusta aktor-klasa „Actor”. Idealne do prototypowania układu poziomu.
Lights – różne typy świateł: punktowe, kierunkowe, reflektory (Spot Light), sky light.
Visual Effects – prosty dym, ogień, cząsteczki (particle system / Niagara). Na początku wystarczą gotowe efekty ze Starter Content.
Volumes – obszary o specjalnym zachowaniu: Blocking Volume (blokuje ruch postaci), Trigger Volume (wyzwalacz pod logikę), Post Process Volume.
Aby dodać obiekt, przeciągnij go z listy bezpośrednio do Viewportu albo do World Outlinera (wtedy pojawi się w środku sceny lub na domyślnej pozycji). Ułóż go przy pomocy gizma (Move/Rotate/Scale – skróty W, E, R).
Ustawiając obiekty, korzystaj z przyciągania do siatki (Grid Snapping – ikona magnesu w górnym pasku Viewportu). Na początek dobre wartości to 10–50 jednostek; ułatwia to budowę prostych, równych korytarzy czy pomieszczeń.
Transformacje: precyzyjne ustawianie pozycji, rotacji i skali
Każdy aktor w scenie ma transformacje: pozycję, rotację i skalę. Można je zmieniać zarówno gizmem w Viewporcie, jak i cyfrowo w panelu Details.
Location – położenie w przestrzeni (X, Y, Z). Wpisywanie równych wartości (np. 0, 0, 0) ułatwia ustawianie ważnych elementów dokładnie w środku sceny.
Rotation – obrót w stopniach. Dla ścian korytarza często używa się kątów 0, 90, 180, 270 – zachodzi wtedy „snapowanie” do siatki wizualnie i logicznie.
Scale – skalowanie. Utrzymuj jednolite proporcje (np. 1.0, 1.0, 1.0 lub 2.0, 2.0, 2.0), żeby uniknąć nienaturalnego rozciągania modeli.
Przy większych scenach pomocne bywa przełączanie przestrzeni transformacji: World vs Local (ikona globusa we Viewporcie). W trybie World osie X/Y/Z są stałe względem świata, w Local – obracają się razem z obiektem.
Struktura projektu i porządek w Content Browser
Domyślne foldery i dlaczego nie mieszać wszystkiego w jednym
Nowy projekt ma zwykle kilka predefiniowanych folderów (np. Content, StarterContent). Jeśli od początku wrzucisz wszystko „luzem” do jednego miejsca, po tygodniu trudno cokolwiek znaleźć. Działa tu ta sama zasada co przy kodzie – struktura ma ułatwiać nawigację i współpracę.
Prosty, uniwersalny szkielet dla małego projektu:
Content/Maps – wszystkie poziomy (pliki .umap).
Content/Blueprints – logika gry (Blueprinty aktorów, interakcji, UI).
Content/Materials – materiały i ich instancje (Material Instance).
Content/Textures – osobno surowe tekstury.
Content/Audio – dźwięki (Sound Cue, Sound Wave).
Content/UI – widgety interfejsu (UMG), fonty.
Przy większych projektach foldery da się rozbić jeszcze bardziej (np. Blueprints/Gameplay, Blueprints/UI), ale taki prosty szkielet wystarcza na długo.
Tworzenie i przenoszenie assetów bez psucia referencji
Content Browser pozwala tworzyć nowe assety prawym przyciskiem myszy → Create (np. Blueprint Class, Material, Level). Kluczowe jest to, żeby:
tworzyć je od razu w docelowym folderze (mniej bałaganu),
jeśli przenosisz istniejący asset, robić to wewnątrz Content Browsera (przeciągając lub używając „Move To”), a nie w eksploratorze systemu.
Unreal zapisuje referencje (powiązania) między assetami po ścieżkach wewnętrznych. Jeśli ruszysz pliki z poziomu Windowsa, można te powiązania zerwać. Content Browser potrafi je poprawnie zaktualizować, o ile operacje odbywają się w nim.
Uwaga: przy przenoszeniu dużych folderów korzystaj z opcji Fix Up Redirectors in Folder (PPM na folderze). Czyści to wewnętrzne przekierowania (redirectory) i zapobiega późniejszym błędom przy budowaniu gry.
Nazewnictwo assetów – konwencje, które oszczędzają nerwy
Przy kilku plikach nazwy nie mają znaczenia. Przy kilkuset stają się krytyczne. Prosta, często używana konwencja to prefiksy według typu assetu, np.:
BP_ – Blueprint (np. BP_Door, BP_Enemy),
SM_ – Static Mesh (np. SM_Wall_Short),
MI_ – Material Instance (np. MI_Wall_Concrete),
M_ – bazowy materiał (np. M_Master_Wall),
T_ – tekstura (np. T_Wall_Albedo),
WBP_ – widget UI (np. WBP_MainMenu),
LVL_ lub bez prefiksu – mapy (np. LVL_Prototyp).
Dzięki temu Content Browser filtruje typy assetów niemal jak IDE klasy w kodzie. Wpisanie „BP_” od razu pokazuje wszystkie Blueprinty, „SM_” – wszystkie meshe.
Zapisywanie i wersjonowanie – Save, Save All i autosave
Unreal odróżnia zapis sceny (mapy) od zapisu assetów. Dlatego w Toolbarze są dwie ważne opcje:
Save Current – zapisuje aktualny poziom (mapę),
Save All – zapisuje wszystkie zmienione assety i poziomy.
Przy pierwszych próbach warto co jakiś czas ręcznie klikać Save All. Autosave bywa pomocny, ale nie zawsze łapie wszystko w najwygodniejszym momencie (zwłaszcza przy ciężkich projektach). Jeśli projekt będzie rozwijany dłużej, dołącz prosty system kontroli wersji (np. Git) – Unreal ma wbudowaną integrację z Perforce, ale do Gita działa bardzo dobrze zewnętrzny klient.
Pierwszy poziom: tworzenie prostej sceny grywalnej
Tworzenie nowej mapy i ustawienie jako domyślnej
Zaczyna się od pustej przestrzeni. W Content Browserze utwórz nową mapę: PPM w folderze Maps → Level. Nazwij ją np. LVL_TestArena i otwórz dwuklikiem.
Aby Twoja mapa ładowała się przy uruchomieniu gry:
wejdź w Edit → Project Settings,
przejdź do zakładki Maps & Modes,
w polu Editor Startup Map wybierz LVL_TestArena,
w polu Game Default Map również wybierz tę samą mapę.
Dzięki temu po kliknięciu Play gra będzie startować z Twojego poziomu, a nie z domyślnego przykładu.
Dodawanie Player Start i prostego „placu zabaw”
Żeby w ogóle móc zagrać, scenie trzeba wskazać, skąd wystartuje gracz. Z panelu Place Actors → Basic przeciągnij Player Start na poziom. Ustaw go kilka jednostek nad powierzchnią, żeby postać nie zacięła się w geometrii.
Następnie zbuduj prostą arenę z klocków:
z kategorii Basic przeciągnij Cube, użyj gizma Move/Scale, aby z niego zrobić podłogę (np. skala 10–20 w X i Y, 1 w Z),
dodaj cztery kolejne kostki jako ściany, obróć i przesuń tak, aby stworzyć prosty pokój lub platformę,
dodaj kilka mniejszych klocków jako przeszkody / podesty do skakania.
Nie chodzi o wygląd, tylko o minimalny układ, po którym można biegać i skakać. Jeśli w projekcie wybrano szablon „First Person” albo „Third Person”, kliknięcie Play od razu pozwoli przetestować ruch postaci po tym układzie.
Kolizje – kiedy postać „przelatuje” przez geometry
Jeśli po naciśnięciu Play postać wpada pod podłogę albo przechodzi przez ścianę, problemem są kolizje. Dla prostych brył (Cube, Cylinder) Unreal generuje je automatycznie. Problemy częściej pojawiają się przy meshach z Static Mesh Editor.
jeśli nic nie widać, dodaj prostą kolizję, np. Add Box Simplified Collision.
Prosta bryła kolizji często jest lepsza niż bardzo szczegółowa – wydajność i stabilność fizyki będą wyższe, a gracz nie utknie na niewidocznych „wypustkach”.
Testowanie poziomu: tryb Play i podstawowe opcje
Przycisk Play w Toolbarze ma kilka wariantów działania. Na start najprzydatniejsze są:
Selected Viewport – gra uruchamia się w tym samym oknie, w którym projektujesz. Naciśnij Esc, by wrócić do edycji.
New Editor Window (PIE) – gra startuje w osobnym oknie. Wygodne, gdy chcesz jednocześnie patrzeć na scenę i rozgrywkę (np. na dwóch monitorach).
Prędkość gry (Game Speed) można zwolnić w konsoli (~) komendą slomo 0.5 – przydaje się przy debugowaniu skoków, kolizji czy animacji. Aby wrócić do normalnego czasu, użyj slomo 1.
Źródło: Pexels | Autor: Anete Lusina
Światło, materiały i atmosfera sceny
Typy świateł: Directional, Point, Spot, Sky Light
Oświetlenie w Unreal Engine wpływa nie tylko na widoczność, lecz także na klimat i czytelność sceny. Podstawowe typy świateł:
Directional Light – nieskończone źródło światła, symuluje słońce. Kierunek światła zależy od rotacji aktora, nie od jego pozycji.
Point Light – światło punktowe świecące we wszystkich kierunkach (np. żarówka, kula energii). Parametr Attenuation Radius określa, jak daleko sięga.
Spot Light – reflektor świecący stożkiem (latarka, reflektor sceniczny). Ma parametry kąta, intensywności i zasięgu.
Sky Light – zbiera światło z nieba/otoczenia i rozprasza je jako oświetlenie globalne (ambient). Bez niego cienie bywają zbyt czarne.
Na prostą scenę z „dziennym” oświetleniem wystarczą:
jedno Directional Light,
jeden Sky Light,
Sky Atmosphere i Exponential Height Fog dla lepszej głębi i koloru nieba (często już są w domyślnej scenie).
Dynamiczne vs statyczne światło (Movable / Stationary / Static)
Każde światło ma parametr Mobility:
Static – w pełni „wypalone” (baked) do lightmap. Nie porusza się, nie rzuca dynamicznych cieni ruchomym obiektom. Bardzo wydajne.
Stationary – pozycja stała, ale intensywność i kolor mogą się zmieniać. Rzuca dynamiczne cienie dla postaci, a odbicia są częściowo baked.
Movable – w pełni dynamiczne, może się poruszać i zmieniać wszystkie parametry. Najbardziej elastyczne, ale kosztowne wydajnościowo.
Na początek najprościej potraktować to jak suwak jakości vs wydajności. Prosta zasada: jeśli światło się rusza (latarka, pocisk, ognista kula) – ustaw Movable. Jeśli stoi w miejscu, ale ma reagować np. na przełącznik (światło w pokoju, latarnia uliczna) – Stationary. Elementy całkowicie statyczne, które nigdy się nie zmienią (światło dzienne w małej scenie, lampy dekoracyjne w tle) spokojnie mogą zostać Static i trafić do bake’a.
Materiał w Unreal to mały shader opisujący, jak powierzchnia reaguje na światło. W najprostszej wersji pracujesz z trzema kluczowymi wejściami: Base Color (kolor powierzchni bez światła), Metallic (0 – dielektryk, np. plastik, drewno; 1 – metal) oraz Roughness (0 – lustro, 1 – bardzo matowa powierzchnia). W praktyce: błyszcząca stal to Base Color w odcieniu szarości, Metallic blisko 1 i niskie Roughness, a asfalt – Metallic 0 z wysokim Roughness.
Do szybkiego prototypowania wystarczy jeden ogólny materiał, z którego zrobisz kilka instancji materiałów (Material Instance). Bazowy materiał może mieć parametry (Scalar i Vector Parameters) dla koloru i chropowatości, a instancje zmienią tylko ich wartości. Dzięki temu jednym kliknięciem podmieniasz wygląd całej klasy obiektów bez rekompilacji shaderów. Uwaga: nie kopiuj materiałów przez duplikację bez powodu – instancje są znacznie lżejsze w utrzymaniu.
Fog, post-process i szybkie „podkręcanie” klimatu
Nawet bardzo prosta scena zyskuje, gdy dodasz mgłę i post-process. Exponential Height Fog nadaje odległym obiektom lekką mgiełkę i separuje plany (foreground/background), co poprawia czytelność. Gęstość i kolor mgły ustawisz w jego parametrach – chłodny, lekko niebieski odcień daje poranek, ciepły pomarańczowy sugeruje zachód słońca lub stylizowaną scenę.
Drugi mocny element to Post Process Volume. Po dodaniu do sceny ustaw Infinite Extent (Unbound), żeby efekty działały wszędzie. W środku znajdziesz m.in. ekspozycję (Auto Exposure), nasycenie kolorów (Color Grading), Bloom, Vignette. Na start dobrze jest ograniczyć automatyczną ekspozycję (np. wąski zakres min/max brightness), bo domyślne „pompowanie” jasności często przeszkadza przy prototypowaniu. Subtelne podbicie kontrastu i lekkie ściemnienie sceny potrafi zrobić ogromną różnicę bez ruszania świateł.
Blueprints – logika gry bez programowania
Event Graph, Tick i myślenie „zdarzeniami”
Blueprinty to wizualne skrypty, które reagują na zdarzenia (events). W każdym Blueprintcie znajdziesz zakładkę Event Graph – tam lądują nody startowe takie jak Event BeginPlay (wywoływany raz przy starcie aktora) czy Event Tick (wywoływany co klatkę). Zamiast pisać „w pętli sprawdzaj X”, myślisz raczej: „gdy coś się stanie, wykonaj sekwencję akcji”.
Tip: nie nadużywaj Event Tick w pierwszych projektach. Kusi, żeby wszystko tam sprawdzać, ale to najszybsza droga do niepotrzebnego obciążenia. Dużo lepiej zareagować na konkretne eventy (np. wejście w trigger, naciśnięcie klawisza, zakończenie animacji) niż odpytywać stan świata co klatkę.
Prosty Blueprint: otwierane drzwi na triggerze
Dobry pierwszy eksperyment to drzwi, które otwierają się, gdy gracz podchodzi. W Content Browserze utwórz Blueprint Class → Actor i nazwij go np. BP_Door. W zakładce Components dodaj Static Mesh jako drzwi oraz Box Collision jako strefę wykrywania. Box ustaw tak, aby obejmował obszar przed drzwiami.
Przejdź do Event Graph i dodaj logikę:
Zaznacz Box Collision, w Details znajdź sekcję Events i kliknij przy OnComponentBeginOverlap oraz OnComponentEndOverlap, aby wygenerować nody zdarzeń.
Na BeginOverlap sprawdź, czy Other Actor to gracz (np. Cast To twoja klasa postaci lub sprawdzenie tagu), a jeśli tak – ustaw zmienną IsDoorOpen na true i wywołaj animację otwarcia.
Na EndOverlap w analogiczny sposób ustaw IsDoorOpen na false i zawołaj animację zamknięcia.
Do samego ruchu drzwi użyj Timeline. Dodaj komponent Timeline w Blueprintcie, otwórz go i stwórz pojedynczy Float Track z wartościami od 0 do 1 w czasie 1–2 sekund. W Event Graph podłącz Play Timeline do otwierania, a Reverse do zamykania. W trakcie odtwarzania Timeline wartość float służy jako współczynnik interpolacji (0 – zamknięte, 1 – otwarte). Na wyjściu Update użyj noda Lerp (Rotator) lub Lerp (Vector), żeby płynnie przejść z pozycji/rotacji zamkniętej do otwartej i ustawiaj transform komponentu drzwi funkcją SetRelativeRotation lub SetRelativeLocation.
Jeśli chcesz, żeby drzwi reagowały na przycisk, a nie samą obecność gracza, dodaj do projektu prostą mapę wejść (Project Settings → Input). Zdefiniuj akcję, np. Interact, przypisz jej klawisz E, a w Blueprintcie gracza obsłuż Input Action Interact. Gdy akcja się wywoła, zrób krótkiego trace’a (np. Line Trace By Channel) do przodu od kamery i sprawdź, czy trafiasz w aktora typu BP_Door. Jeśli tak, zawołaj na nim event otwierający/zamykający (np. zdefiniuj w drzwiach Custom Event ToggleDoor oznaczony jako Call In Editor lub Public i wywołuj go z gracza).
Takie proste drzwi łączą kilka kluczowych elementów: kolizję, komponenty, eventy, Timeline i komunikację między Blueprintami. Gdy to działa stabilnie, łatwo rozbudować system: dodać dźwięk otwierania (Audio Component), opóźnienie zamknięcia, blokadę na klucz, a nawet prosty interfejs pokazujący „Naciśnij E, aby otworzyć”. Od tego poziomu kolejne interaktywne obiekty – przyciski, windy, skrzynki z lootem – składa się już z tych samych klocków.
Pierwszy projekt w Unreal Engine nie musi wyglądać jak gotowa gra; ważniejsze, by przejść cały podstawowy cykl: stworzyć poziom, poukładać assety, ustawić światło, nadać prostym obiektom materiały i dodać choć odrobinę logiki w Blueprintach. Po kilku takich iteracjach edytor przestaje być „magiczną czarną skrzynką”, a zaczyna przypominać zestaw narzędzi, w którym wiesz, po co sięgasz i dlaczego dany element działa w określony sposób.
Zmienne, funkcje i porządek w Blueprintach
Nawet w małym projekcie Blueprinty szybko puchną. Kilka prostych zasad na start oszczędzi sporo nerwów, gdy coś przestaje działać.
Najpierw zmienne. Każdą nową warto nazwać tak, by po miesiącu nadal było jasne, co robi. Popularny schemat to prefiks typu i „celu”, np. bIsDoorOpen dla boola (b – boolean), CurrentHealth dla liczby, TargetActor dla referencji. Domyślne NewVar_0 prędzej czy później zemści się debugowaniem po nocy.
Drugie narzędzie to funkcje i makra. Jeśli powtarzasz ten sam zestaw nodów w trzech miejscach, wyciągnij go do funkcji (zakładka Functions w lewym panelu Blueprinta). Funkcja przyjmuje wejścia, zwraca wynik i nie ma dostępu do Event Graphu. Dobrze się nadaje do czystych obliczeń lub pobierania danych: na przykład przeliczenie procenta życia z aktualnych i maksymalnych punktów HP. Makra (zakładka Macros) są bardziej elastyczne – mogą mieć wiele punktów wejścia i wyjścia, ale używaj ich raczej do „kontrolowania przepływu” (branchowanie, powtarzanie wzorców), nie do wszystkiego.
Kiedy Event Graph zaczyna wyglądać jak talerz spaghetti, zwykle brakuje Sequence, Reroute Node i Comment:
Sequence pozwala odpalić kilka gałęzi logiki po kolei zamiast robić łańcuch nodów z jednego pinu Exec.
Reroute Node (prawy klik na przewodzie → Reroute Node) porządkuje kabelki i ułatwia śledzenie przepływu.
Tip: gdy coś nie działa, pierwszy krok debugowania to Print String i obserwacja, który fragment logiki się w ogóle wykonuje. Dopiero później zaglądaj w szczegóły.
Komunikacja między Blueprintami: cast, eventy i interfejsy
Drzwi reagujące na gracza to klasyczny przykład potrzeby komunikacji między Blueprintami. Najprostsze podejście to Cast To – mając referencję do aktora (np. wynik overlapa albo trace’a), używasz noda Cast To BP_Door i po udanym castowaniu wołasz funkcję lub event na drzwiach. Działa, ale mocno uzależnia jedną klasę od drugiej.
Lepszy krok w stronę elastyczności to Blueprint Interfaces. Tworzysz nowy Blueprint Interface z abstrakcyjną funkcją, np. Interact z parametrem typu Actor (kto zainicjował interakcję). Następnie implementujesz ten interfejs w klasach, które mają reagować: drzwi, dźwignia, skrzynia. Każda klasa Blueprint dostaje własną implementację funkcji Interact, ale gracz nie musi znać ich typu – wykonuje po prostu „Interact na tym, w kogo trafił trace”.
Do jednokierunkowej komunikacji (np. guzik, który informuje windę, że ma ruszyć) możesz użyć także Event Dispatchers. Winda ma dispatcher typu „OnButtonPressed”, a przycisk, po naciśnięciu, wywołuje go na referencji windy. Dobre rozwiązanie, gdy wiele obiektów słucha jednego źródła zdarzeń.
Stan gry i prosta logika: życie, punkty, warunki wygranej
Po opanowaniu pojedynczych interakcji kolejnym logicznym krokiem jest globalny stan gry: punkty, liczba zebranych obiektów, stan misji. W Unreal dobrym miejscem na takie dane jest Game Mode oraz Game Instance.
Game Mode (Blueprint klasy GameModeBase lub GameMode) zarządza logiką konkretnej rozgrywki: jaką klasę postaci użyć, jaki HUD, jak reagować na śmierć gracza. Logika „jeśli zebrałeś 5 kluczy – otwórz wyjście” może żyć właśnie tutaj. Game Instance jest persistent – nie resetuje się przy zmianie mapy. Tam możesz przechowywać dane między poziomami, np. wynik punktowy czy odblokowane levele.
Prosty przykład: system punktów za zbieranie obiektów.
W Game Mode dodaj zmienną Score typu int i funkcję AddScore, która przyjmuje wartość i dodaje ją do Score. W środku możesz też wywołać event odświeżający UI.
W Blueprintcie monety (np. BP_Coin) obsłuż overlap z graczem. Po wykryciu gracza pobierz aktualny Game Mode (nód Get Game Mode, potem Cast To twoja klasa) i wywołaj AddScore z określoną wartością, a następnie zniszcz monetę (DestroyActor).
W HUD lub Widget Blueprint w funkcji Tick UI (albo przez event dispatchera) aktualizuj tekst wyświetlający wynik na podstawie Score z Game Mode.
Gdy punktów osiągniesz określoną liczbę, Game Mode może zawołać funkcję wygranej: zatrzymać sterowanie, odpalić animację kamery, przejść do innej mapy lub wyświetlić ekran „You Win”. Taka struktura skaluje się lepiej niż przechowywanie wszystkich danych w postaci gracza.
Źródło: Pexels | Autor: FOX ^.ᆽ.^= ∫
Prosta rozgrywka: zbieranie obiektów i cel gry
Pickup – uniwersalny obiekt do zbierania
Dobrym „pierwszym projektem” jest scena, w której gracz zbiera obiekty na czas. Wspólny szablon to Pickup – aktor, który reaguje na dotknięcie przez gracza i wywołuje określoną akcję (dodanie punktów, życia, amunicji).
Najprostsza implementacja:
Nowy Blueprint Class → Actor, np. BP_Pickup.
Komponenty: Static Mesh (model obiektu) oraz Sphere Collision albo Box Collision do wykrywania wejścia gracza.
W kolizji – OnComponentBeginOverlap z prostą logiką: sprawdź, czy Other Actor to gracz; jeśli tak, wywołaj funkcję OnPickedUp (może być Event Dispatcher albo custom event) i zniszcz aktora.
W praktyce dobrze od razu pomyśleć o rozszerzalności. Zamiast twardo wbijać logikę „dodaj 1 punkt”, wystaw parametr PickupType (enum, np. Score, Health, Ammo) i Value (ile dodać). W Event Graph zrób Switch on PickupType i w zależności od typu wykonaj odpowiednią gałąź. Dzięki temu ten sam Blueprint posłuży jako moneta, apteczka i nabój – różnią się tylko wartościami w Details.
Lekki feedback: obrót, świecenie, dźwięk
Nawet prosty pickup powinien „mówić”, że można go zebrać. Kilka drobiazgów robi sporą różnicę:
Obrót w miejscu – w Event Tick lub przez Timeline zwiększaj rotację wokół osi Z o stałą wartość. Przy małej liczbie pickupów możesz użyć Tick, przy większej lepiej przejść na animację w Material lub prosty Rotating Movement Component.
Świecący materiał – lekki emissive kolor (np. material parameter EmissivePower) sprawia, że obiekt jest widoczny nawet w ciemniejszych miejscach.
Dźwięk przy podniesieniu – w momencie zbierania odpal Play Sound at Location lub dołącz Audio Component do aktora i wywołaj Play.
Uwaga: przy większej liczbie podobnych obiektów lepiej zbudować jeden ogólny materiał + instancje materiałów, niż używać zupełnie osobnych shaderów. Unreal szybciej poradzi sobie z batchowaniem takich draw calli.
Mając już pickupy, możesz zbudować prostą pętlę rozgrywki. Dwa bazowe warianty:
Zbierz wszystkie obiekty – Game Mode trzyma liczbę TotalPickups i CollectedPickups. Przy starcie poziomu (Event BeginPlay) możesz przeliczyć wszystkie aktory klasy BP_Pickup (Get All Actors Of Class) i zapisać wynik w TotalPickups. Za każdym podniesieniem pickupa wywołuj w Game Mode funkcję RegisterPickupCollected, która zwiększa CollectedPickups i sprawdza, czy CollectedPickups >= TotalPickups. Jeśli tak, odpal funkcję wygranej.
Zbieraj jak najwięcej na czas – Game Mode ma zmienną RemainingTime. W Event Tick Game Mode odejmuj DeltaSeconds, a po zejściu do zera zatrzymuj sterowanie i pokazuj wynik. Dla optymalizacji możesz użyć Timer zamiast logiki w Tick (nód Set Timer by Function Name lub Set Timer by Event).
W obu przypadkach UI (Widget Blueprint) odświeża teksty na podstawie wartości z Game Mode: „Zebrane: X/Y” albo „Czas: 00:30”. Sterowanie czasem i punktami w jednym miejscu (Game Mode) ułatwia rozszerzenie projektu o kolejne poziomy czy warunki.
Uproszczony interfejs (UI) w UMG
Widget Blueprint: licznik punktów i czasu
UMG (Unreal Motion Graphics) to system tworzenia UI w edytorze. Na start wystarczy pojedynczy Widget Blueprint z dwoma tekstami i prostym bindem do danych.
Tworzenie podstawowego HUD-u:
Utwórz Widget Blueprint typu User Widget, np. WBP_HUD.
W zakładce Designer przeciągnij z palety element Text na Canvas. Ustaw kotwicę (Anchor) w górnym lewym rogu, pozycję np. 20, 20. Drugi Text umieść pod nim.
W zakładce Graph dodaj referencje do Game Mode i ewentualnie do Game Instance, żeby móc odczytać aktualne wartości punktów i czasu.
Do aktualizacji tekstu masz dwie drogi:
Bindy – zaznacz Text, w Details przy polu Text kliknij Bind → Create Binding. Powstanie funkcja, w której możesz pobrać aktualny wynik i złożyć stringa. W małym projekcie jest to szybkie rozwiązanie, choć przy wielu elementach UI bindy potrafią generować dodatkowe wywołania.
Manualne odświeżanie – Game Mode, po zmianie punktów, woła funkcję wewnątrz widgetu (np. UpdateScoreDisplay), która na Text ustawia SetText z nową wartością. Czytelniejsze, gdy UI robi się bardziej złożone.
Wyświetlenie HUD-u w grze odbywa się w dwóch krokach w klasie gracza lub kontrolera:
W BeginPlay utwórz widget (Create Widget, wybierz WBP_HUD) i zapisz go do zmiennej.
Dodaj go do ekranu (Add to Viewport) i ewentualnie ustaw input mode na Game Only lub Game and UI w zależności od wymagań.
Komunikaty i proste ekrany końcowe
Poza stałym HUD-em przydają się chwilowe komunikaty: „Zebrano wszystkie obiekty”, „Koniec czasu”, „Naciśnij R, aby zrestartować”. Najprościej zbudować dodatkowy Widget Blueprint, np. WBP_EndScreen z dużym tekstem i przyciskiem lub ikonką restartu.
Gdy warunek wygranej/przegranej się spełni (w Game Mode), możesz:
Utworzyć i dodać do Viewportu widget końcowy.
Zablokować sterowanie gracza (Disable Input na Player Controllerze).
Zmienić Input Mode na UI-only i pokazać kursor myszy.
Restart sceny to zwykle Open Level z nazwą aktualnej mapy. Jeśli twoje statystyki (czas, punkty) żyją w Game Instance, możesz je odczytać w ekranie końcowym i wyświetlić np. „Nowy rekord” czy „Poprzedni najlepszy wynik”.
Rozszerzanie projektu: proste wrogie AI
Pasywny patrol bez Behavior Tree
Do pierwszego kontaktu z AI nie potrzebujesz od razu Behavior Tree. Wystarczy prosty Blueprint przeciwnika z komponentem Pawn lub Character i wbudowanym ruchem.
Przykładowy schemat patrolu między punktami:
Utwórz aktora BP_EnemyPatrol na bazie Character (dzięki temu dostajesz kapsułę kolizji i ruch).
W scenie rozstaw Target Pointy (Actor → Target Point) w miejscach, po których ma chodzić przeciwnik.
W Blueprintcie przeciwnika dodaj tablicę (Array) PatrolPoints typu Target Point. Możesz wypełnić ją w Details dla każdego wroga osobno, przeciągając referencje do punktów z poziomu.
Dodaj zmienną CurrentPatrolIndex (integer), która będzie wskazywać aktualny punkt docelowy w tablicy.
Logika ruchu może opierać się na prostym systemie „jedź do punktu, po dojściu wybierz kolejny”:
W Event BeginPlay sprawdź, czy tablica PatrolPoints ma elementy. Jeśli tak, wywołaj własne wydarzenie, np. GoToNextPatrolPoint.
W GoToNextPatrolPoint pobierz element z PatrolPoints[CurrentPatrolIndex], użyj noda AI MoveTo (lub Simple Move to Actor na Player Controllerze AI) i ustaw go jako Target Actor.
Po zakończeniu ruchu (Event On Success z AI MoveTo albo manualne sprawdzenie odległości w Ticku) zwiększ CurrentPatrolIndex (modulo długość tablicy, żeby wrócić na początek) i ponownie wywołaj GoToNextPatrolPoint.
Najwygodniej jest użyć komponentu AIController przypisanego tej postaci. Wtedy w samym wrogu trzymasz tylko punkty patrolu, a logiką ruchu zajmuje się kontroler. Przy małym projekcie możesz też zrezygnować z osobnego kontrolera i użyć prostego Simple Move to Location z poziomu Blueprintu przeciwnika – będzie mniej klas do ogarnięcia.
Jeśli w którymś momencie patrol ma się zatrzymać (np. kiedy wróg wykryje gracza), wystarczy wywołać na kontrolerze Stop Movement. W połączeniu z timerem możesz wtedy dodać krótki „postój” w punkcie (wróg podchodzi do Target Point, zatrzymuje się na 1–2 sekundy, po czym dostaje kolejną komendę GoToNextPatrolPoint).
Proste wykrywanie gracza i reakcja
Do podstawowego „widzenia” gracza wystarczy komponent kolizji lub prosty system z odległością. W lekkich projektach dobrze sprawdza się połączenie komponentu Pawn Sensing z prostą logiką Blueprint:
Dodaj do przeciwnika komponent Pawn Sensing i ustaw parametry: Sight Radius, Peripheral Vision Angle itp.
Podłącz event On See Pawn – jeśli wykrytym Pawnem jest gracz, ustaw flagę bIsChasingPlayer na true i zacznij go gonić (AI MoveTo na aktora gracza).
Gdy gracz zniknie z pola widzenia (np. upłynął czas od ostatniego wykrycia), możesz po krótkiej zwłoce wyzerować bIsChasingPlayer i wrócić do patrolu wywołując GoToNextPatrolPoint.
Alternatywnie da się oprzeć całość tylko na kolizji: wokół przeciwnika umieszczasz Sphere Collision, reagujesz na OnComponentBeginOverlap i jeśli w strefę wejdzie gracz, wróg przełącza się w tryb pościgu. To mniej realistyczne niż system widzenia, ale znacznie szybsze w konfiguracji i w małym prototypie zupełnie wystarcza.
W momencie „złapania” gracza (np. overlap z kapsułą kolizji postaci) możesz wywołać w Game Mode funkcję porażki: zatrzymaj sterowanie, pokaż ekran końcowy, odtwórz dźwięk. Mechanizm jest ten sam, co przy warunkach przegranej na czas – zmienia się tylko to, co wyzwala zdarzenie.
Integracja AI z istniejącą pętlą gry
Żeby wrogowie dobrze „wkleili się” w resztę projektu, przyda się kilka drobnych połączeń. Przeciwnik może np. reagować na dźwięk zbierania przedmiotu, wejście gracza w określony obszar albo przekroczenie limitu czasu. W prostym wariancie wystarczy, że Game Mode wysyła do wszystkich przeciwników event (np. OnGameOver), a oni zatrzymują ruch i przełączają się na bezczynność.
Dobrze działa prosty protokół komunikacji między Game Mode a AI: wrogowie podpinają się pod kilka zdarzeń (np. OnGameStart, OnGameOver, OnPlayerSpotted), a Game Mode w odpowiednich momentach je wyzwala. Dzięki temu nie rozlewasz logiki „co się dzieje po przegranej” po wielu Blueprintach, tylko przeciwnicy reagują na wspólne sygnały. Przy większym chaosie w projekcie wystarczy wtedy uporządkować właśnie Game Mode, zamiast szukać losowych Disable Input czy Stop Movement rozsianych po całej scenie.
Przykładowy przepływ: gracz traci wszystkie życia → Game Mode ustawia zmienną bIsGameOver na true → woła na wszystkich wrogach event OnGameOver (np. przez Get All Actors of Class na starcie i przechowywanie tablicy referencji) → każdy wróg zatrzymuje ruch, wyłącza wykrywanie gracza i odtwarza animację „znudzenia” albo „wygranej”. Ten sam schemat możesz wykorzystać przy starcie rundy (AI czeka w miejscu, aż Game Mode wyśle OnRoundStart).
Ciekawym rozszerzeniem jest spięcie AI z UI. Kiedy przeciwnik zauważy gracza, na HUD-zie może mignąć prosta ikonka alarmu, a po zneutralizowaniu wszystkich wrogów pojawia się napis „Strefa bezpieczna”. Technicznie to tylko kilka dodatkowych eventów: wróg w chwili wykrycia gracza zgłasza się do Game Mode, a ten przekazuje sygnał do HUD-u, który włącza lub wyłącza odpowiednie widgety. Logika pozostaje rozproszona tylko tam, gdzie faktycznie coś się dzieje (AI, Game Mode, HUD), ale przepływ danych jest jasny.
Jeżeli taki prototyp zacznie się rozrastać, naturalnym kolejnym krokiem jest przejście na Behavior Tree, Blackboard i bardziej rozbudowane stany AI. Wszystkie proste mechanizmy z powyższych przykładów – patrol, pościg, zatrzymanie po przegranej – da się wtedy przenieść 1:1 do nowych narzędzi, bez wyrzucania dotychczasowej logiki w błoto.
Mając za sobą konfigurację projektu, prostą scenę, pierwszy HUD, podstawową logikę w Blueprintach i działające, choć proste AI, masz już szkielet gry akcji – od wejścia do poziomu aż po ekran końcowy. Dalszy rozwój to już głównie iteracje: doszlifowanie sterowania, materiałów, świateł, UI i zachowania przeciwników. Każda z tych warstw korzysta z tych samych fundamentów, które właśnie zbudowałeś.
Najczęściej zadawane pytania (FAQ)
Jaki sprzęt jest potrzebny, żeby zacząć pracę z Unreal Engine 5?
Do nauki Unreal Engine 5 wystarczy średniej klasy komputer: czterordzeniowy procesor (np. i5 / Ryzen 5 starszej generacji), 16 GB RAM i karta graficzna z obsługą DirectX 11/12. Na 8 GB RAM da się uruchomić silnik, ale kompilacja shaderów i praca w edytorze będą mocno ociężałe.
Kluczowy jest dysk SSD – instalacja silnika plus kilka projektów potrafi zająć 50–200 GB i na HDD wszystko będzie działało bardzo wolno. Systemowo najlepiej sprawdza się Windows 10/11 64-bit, bo pod tę platformę powstaje większość tutoriali i przykładów.
Czy Unreal Engine jest dobry dla początkujących, czy lepiej zacząć od Unity?
Unreal Engine jest jak najbardziej wykorzystywalny na start, szczególnie jeśli interesuje cię 3D, gry akcji, FPS-y albo projekty nastawione na wysoką jakość grafiki. Dostajesz szablony z gotowym sterowaniem, system Blueprints (wizualne skrypty) i dobre efekty wizualne „z pudełka”, więc szybko widzisz rezultaty.
Unity bywa lepszym wyborem, gdy celujesz głównie w 2D, gry mobilne i preferujesz programowanie w C#. Unreal jest cięższy sprzętowo i bardziej „AAA” w charakterze, ale jeśli chcesz poznać narzędzie często używane w dużych studiach, to bardzo sensowna inwestycja czasu.
UE4 czy UE5 – którą wersję Unreal Engine wybrać na pierwszy projekt?
Dla nowej osoby najczęściej najlepszym wyborem jest UE5 w stabilnym wydaniu (Release), bo właśnie pod tę wersję powstaje większość aktualnych kursów i dokumentacji. Dostajesz nowoczesne systemy jak Lumen (globalne oświetlenie w czasie rzeczywistym) i Nanite, dzięki czemu łatwiej uzyskać dobry obraz bez skomplikowanego bake’owania.
UE4 ma sens, jeśli masz bardzo słaby komputer albo musisz użyć konkretnego pluginu dostępnego tylko dla tej linii silnika. Jest trochę lżejszy i bardzo dojrzały, ale z perspektywy nauki na przyszłość UE5 daje lepszą ścieżkę rozwoju projektów.
Jakie konto jest potrzebne, żeby pobrać Unreal Engine i skąd go ściągnąć?
Potrzebujesz darmowego konta Epic Games – tego samego, którego używa się do Fortnite czy Epic Games Store. Rejestracja odbywa się na stronie Epic, później logujesz się tym kontem w aplikacji Epic Games Launcher.
Unreal Engine pobierasz wyłącznie przez Epic Games Launcher: po instalacji launchera przechodzisz do zakładki „Unreal Engine” → „Biblioteka”, klikasz „+ Dodaj wersję” i wybierasz najnowszą stabilną wersję Release. Dopiero potem wskazujesz lokalizację na dysku SSD i uruchamiasz instalację.
Jaki szablon projektu wybrać w Unreal Engine na pierwszy raz?
Na start najlepiej sprawdzają się gotowe szablony z widokiem postaci, bo nie musisz ręcznie konfigurować kamery i sterowania. Dobre wybory to:
Third Person – kamera za plecami postaci, skakanie, prosta fizyka, uniwersalna baza pod wiele typów gier 3D;
First Person – widok z oczu, dłonie i broń, dobry punkt wyjścia pod FPS;
Top Down – kamera z góry, sensowna baza pod proste RPG-i czy gry taktyczne.
Dla początkujących rozsądnym zestawem jest: szablon Third Person, tryb Blueprint (zamiast C++), platforma Desktop/Console i włączony Starter Content, który daje podstawowe modele, materiały i dźwięki do szybkiego prototypowania.
Czy da się uczyć Unreal Engine bez znajomości programowania w C++?
Tak. Unreal ma system Blueprints, czyli wizualne skrypty, w których logikę gry budujesz z „klocków” połączonych liniami. Na pierwszy projekt spokojnie wystarczy Blueprint – pozwala zrozumieć przepływ logiki, zdarzenia, zmienne, bez konieczności walki z konfiguracją C++ i kompilatorem.
W praktyce wielu twórców przez długi czas robi pełne prototypy (a czasem nawet całe gry indie) wyłącznie w Blueprintach. C++ staje się potrzebne głównie przy bardzo złożonych systemach, optymalizacji i pracy w większych zespołach.
Co zrobić, gdy Unreal Engine bardzo długo się uruchamia lub kompiluje shadery?
Długi start i wolna kompilacja shaderów na pierwszym projekcie są normalne, szczególnie na słabszym sprzęcie. Można jednak trochę to okiełznać: obniż jakość podglądu w edytorze (np. tryb „Medium” w viewport), zamknij zbędne okna i wyłącz efekty, których nie używasz w scenie.
Upewnij się też, że projekt i silnik są na dysku SSD, a na laptopie używana jest dedykowana karta GPU, a nie zintegrowana. Częsty scenariusz: po podłączeniu zasilacza system przełącza się na mocniejszą kartę i nagle Unreal zaczyna działać dużo płynniej.
Najważniejsze wnioski
Unreal Engine jest szczególnie sensownym wyborem, gdy zależy na jakości grafiki, pracy w 3D i narzędziu używanym w dużych studiach, a nie przeszkadza cięższy silnik i większe wymagania sprzętowe.
Blueprints (wizualne skrypty) oraz gotowe szablony projektów pozwalają początkującym szybko złożyć działający prototyp bez pisania kodu C++, co przyspiesza naukę logiki gry.
Do komfortowej pracy z Unreal Engine praktyczne minimum to 4‑rdzeniowy CPU, 16 GB RAM, GPU z DirectX 11/12 i SSD; na słabszym sprzęcie trzeba liczyć się z długimi czasami ładowania i koniecznością cięcia jakości w edytorze.
Ekosystem Epic Games (Launcher, Marketplace, projekty sample, sekcja Learn) dostarcza kompletny zestaw narzędzi, materiałów edukacyjnych i gotowych assetów, dzięki czemu nie trzeba wszystkiego tworzyć samodzielnie.
Unreal Engine 5 jest domyślnym wyborem na pierwszy projekt: ma najwięcej aktualnych materiałów, nowoczesne systemy Lumen i Nanite oraz lepszą perspektywę rozwoju projektu niż UE4.
UE4 nadal ma sens przy bardzo słabym sprzęcie lub konieczności użycia starszych pluginów, ale w każdym innym scenariuszu uczenie się od razu UE5 oszczędza późniejszej migracji.
Instalację Unreal Engine zawsze najlepiej wykonywać przez Epic Games Launcher na dysku SSD, wybierając stabilne wydanie (Release), a nie wersje Preview, które częściej sprawiają problemy początkującym.
