25 KiB
Pytania egzaminacyjne o pracę magisterską
Temat pracy
"Porównanie wydajności i możliwości współczesnych silników gier komputerowych"
🎯 Pytanie 1: Cel i motywacja pracy
Pytanie
"Jaki jest cel Pana pracy magisterskiej i dlaczego wybrano akurat temat porównania silników gier?"
Odpowiedź wzorcowa
Celem pracy jest kompleksowe porównanie wydajności i możliwości współczesnych silników gier (Unity i Unreal Engine), ze szczególnym uwzględnieniem ich wpływu na proces tworzenia gier oraz końcową jakość produktu.
Motywacja:
- Praktyczna potrzeba - wybór silnika to kluczowa decyzja wpływająca na cały cykl życia projektu
- Brak obiektywnych porównań - większość istniejących materiałów ma charakter subiektywny lub marketingowy
- Dominacja rynkowa - Unity i Unreal wspólnie obsługują >70% globalnego rynku gier
- Reprezentatywność architektur - silniki reprezentują fundamentalnie różne podejścia (C# z GC vs C++ z ręcznym zarządzaniem pamięcią)
Praktyczne znaczenie:
- Pomoc deweloperom w świadomym wyborze narzędzi
- Dostarczenie obiektywnych danych wydajnościowych
- Analiza praktycznych aspektów pracy z silnikami
🎯 Pytanie 2: Metodologia badawcza
Pytanie
"Jaką metodologię badawczą zastosowano w pracy? Dlaczego wybrano takie podejście?"
Odpowiedź wzorcowa
Zastosowano metodologię mieszaną łączącą podejście ilościowe i jakościowe:
┌────────────────────────────────────────────────────────────────┐
│ METODOLOGIA BADAWCZA │
├────────────────────────────────────────────────────────────────┤
│ │
│ ILOŚCIOWA (Quantitative): │
│ ├── Testy wydajnościowe z NVIDIA Nsight Graphics │
│ ├── Pomiary FPS, CPU, GPU, pamięci RAM/VRAM │
│ └── Obiektywne metryki porównawcze │
│ │
│ JAKOŚCIOWA (Qualitative): │
│ ├── 8 wywiadów pogłębionych z deweloperami │
│ ├── Analiza dokumentacji i materiałów edukacyjnych │
│ └── Doświadczenia z implementacji porównawczej │
│ │
│ TRIANGULACJA ŹRÓDEŁ: │
│ └── Weryfikacja wniosków z wielu perspektyw │
└────────────────────────────────────────────────────────────────┘
Uzasadnienie podejścia mieszanego:
- Obiektywność - testy wydajnościowe eliminują subiektywizm
- Kontekst praktyczny - wywiady dostarczają perspektywy użytkowników
- Kompletność - sama wydajność nie determinuje jakości narzędzia
- Wiarygodność - triangulacja zwiększa pewność wniosków
🎯 Pytanie 3: Wybór gry testowej
Pytanie
"Dlaczego do testów wybrano gatunek bullet hell? Jakie to ma znaczenie dla wyników?"
Odpowiedź wzorcowa
Gatunek bullet hell (danmaku) to strzelanka, w której gracz mierzy się z setkami/tysiącami pocisków tworzących skomplikowane wzory.
Uzasadnienie wyboru:
| Aspekt | Dlaczego bullet hell? |
|---|---|
| Intensywność | Setki obiektów na ekranie → obciążenie renderingu |
| Pamięć | Ciągłe tworzenie/niszczenie pocisków → test GC vs ręczne |
| Fizyka | Kolizje gracz↔pociski → obciążenie systemu fizyki |
| Skalowalność | Łatwa kontrola obciążenia przez liczbę pocisków |
| Prostota | Prosta logika → fokus na wydajność, nie złożoność |
| Reprezentatywność | Typowa gra 2D indie → duży segment rynku |
Parametry gry testowej:
- Czas rozgrywki: 90 sekund
- Maksymalnie ~500 jednoczesnych pocisków
- 3 typy przeciwników z różnymi wzorami
- Object pooling dla eliminacji alokacji runtime
Znaczenie dla wyników: Gatunek wymusza stosowanie technik optymalizacyjnych (object pooling, spatial partitioning), których efektywność może różnić się między silnikami, co pozwala na rzeczywiste porównanie.
🎯 Pytanie 4: Różnice architektoniczne silników
Pytanie
"Jakie są fundamentalne różnice architektoniczne między Unity a Unreal Engine?"
Odpowiedź wzorcowa
┌─────────────────────────────────────────────────────────────────┐
│ PORÓWNANIE ARCHITEKTONICZNE UNITY vs UNREAL │
├─────────────────────────────────────────────────────────────────┤
│ │
│ UNITY: UNREAL ENGINE: │
│ ├─ Język: C# ├─ Język: C++ / Blueprints │
│ ├─ Pamięć: Garbage Collector ├─ Pamięć: Ręczne/Smart ptr │
│ ├─ Architektura: GameObject ├─ Architektura: Actor │
│ │ └─ Component │ └─ Component │
│ ├─ Natywne 2D: TAK ├─ Natywne 2D: NIE │
│ ├─ Kod źródłowy: częściowo ├─ Kod źródłowy: pełny │
│ └─ Rozmiar projektu: ~100 MB └─ Rozmiar projektu: ~1-2 GB │
│ │
│ FILOZOFIA: │
│ Unity: Prostota, dostępność Unreal: Moc, kontrola │
│ Mobile, indie AAA, fotorealizm │
└─────────────────────────────────────────────────────────────────┘
Kluczowe implikacje:
-
C# z GC vs C++:
- Unity: szybszy rozwój, możliwe GC spikes
- Unreal: maksymalna wydajność, większa złożoność
-
Krzywa uczenia:
- Unity: łagodna, przyjazna początkującym
- Unreal: stroma, wymaga znajomości C++
-
Specjalizacja:
- Unity: elastyczne, dobre dla różnych typów gier
- Unreal: zoptymalizowane pod FPS/AAA
🎯 Pytanie 5: Hipotezy badawcze
Pytanie
"Jakie hipotezy badawcze postawiono w pracy? Czy zostały potwierdzone?"
Odpowiedź wzorcowa
Hipotezy badawcze:
-
H1: "Silniki komercyjne oferują lepszą wydajność niż rozwiązania open source"
- Status: Nie dotyczy bezpośrednio (oba badane silniki są komercyjne z darmowymi wersjami)
-
H2: "Kompleksowość funkcjonalności wpływa negatywnie na wydajność"
- Status: Częściowo potwierdzona - Unreal z większą liczbą wbudowanych mechanizmów wymaga większych zasobów (rozmiar projektu, RAM), ale kompensuje to optymalizacjami niskopoziomowymi
-
H3: "Łatwość użycia jest odwrotnie proporcjonalna do możliwości konfiguracji"
- Status: Potwierdzona - Unity z łagodniejszą krzywą uczenia oferuje mniejszą kontrolę nad niskopoziomowymi aspektami; Unreal wymaga większego wysiłku, ale daje pełny dostęp do kodu źródłowego
Wnioski z hipotez:
- Trade-off między dostępnością a kontrolą jest realny
- Nie ma "lepszego" silnika - wybór zależy od kontekstu projektu
🎯 Pytanie 6: Wyniki wywiadów z deweloperami
Pytanie
"Jakie główne wnioski płyną z wywiadów z deweloperami gier?"
Odpowiedź wzorcowa
Przeprowadzono 8 wywiadów pogłębionych z deweloperami o zróżnicowanym doświadczeniu (1-10+ lat).
Kluczowe wnioski:
┌────────────────────────────────────────────────────────────────┐
│ WNIOSKI Z WYWIADÓW │
├────────────────────────────────────────────────────────────────┤
│ │
│ 1. DOKUMENTACJA: │
│ Unity: "dogłębna, szczegółowa, z przykładami" │
│ Unreal: "szkieletowa, praktycznie nieistniejąca" │
│ │
│ 2. MATERIAŁY EDUKACYJNE: │
│ Unity: więcej, lepszej jakości (Brackeys) │
│ Unreal: mniej, często nieaktualne, skupione na Blueprints │
│ │
│ 3. PRÓG WEJŚCIA: │
│ Unity: łagodniejszy, C# jako język wysokopoziomowy │
│ Unreal: wyższy, C++ rozszerzony o makra silnika │
│ │
│ 4. SPECJALIZACJA: │
│ Unity: uniwersalne narzędzie │
│ Unreal: zoptymalizowane pod FPS/gry akcji │
│ │
│ 5. KOMPILACJA: │
│ Unity: problemy z czasem przy dużych projektach │
│ Rozwiązanie: Assembly Definitions │
└────────────────────────────────────────────────────────────────┘
Wspólne problemy:
- Poradniki skupiają się na pojedynczych mechanikach, nie na architekturze
- Brak holistycznego podejścia do nauczania
🎯 Pytanie 7: Narzędzia profilowania
Pytanie
"Jakie narzędzia wykorzystano do testów wydajnościowych? Dlaczego akurat te?"
Odpowiedź wzorcowa
Główne narzędzie: NVIDIA Nsight Graphics
Uzasadnienie wyboru:
- Niezależność - zewnętrzne narzędzie, nie faworyzuje żadnego silnika
- Precyzja - niskopoziomowe metryki GPU
- Porównywalność - te same metryki dla obu silników
- Kompleksowość - analiza całego pipeline'u renderowania
Mierzone metryki:
| Kategoria | Metryki |
|---|---|
| Rendering | FPS, frame time, draw calls |
| GPU | Obciążenie, pamięć VRAM, shader performance |
| CPU | Obciążenie, czas na frame |
| Pamięć | RAM allocation, GC events (Unity) |
Dodatkowe narzędzia:
- Wbudowane profilery Unity i Unreal (dla kontekstu wewnętrznego)
- Monitoring systemu operacyjnego
🎯 Pytanie 8: Ograniczenia badań
Pytanie
"Jakie są ograniczenia przeprowadzonych badań? Co można by ulepszyć?"
Odpowiedź wzorcowa
Ograniczenia:
-
Zakres testów:
- Tylko jeden gatunek gry (bullet hell 2D)
- Brak testów 3D, VR, mobile
-
Środowisko:
- Jedna konfiguracja sprzętowa
- Brak testów na różnych platformach
-
Wersje silników:
- Wyniki specyficzne dla konkretnych wersji
- Silniki szybko się rozwijają
-
Próba wywiadów:
- 8 respondentów (ograniczona reprezentatywność)
- Głównie rynek polski
-
Subiektywność implementacji:
- Implementacja w obu silnikach przez jedną osobę
- Możliwa nieświadoma preferencja
Propozycje ulepszeń:
- Testy na większej liczbie gatunków gier
- Badanie na różnych platformach (mobile, konsole)
- Większa próba do badań jakościowych
- Współpraca z ekspertami od każdego silnika
🎯 Pytanie 9: Praktyczne rekomendacje
Pytanie
"Jakie praktyczne rekomendacje dla deweloperów wynikają z pracy?"
Odpowiedź wzorcowa
┌────────────────────────────────────────────────────────────────┐
│ REKOMENDACJE WYBORU SILNIKA │
├────────────────────────────────────────────────────────────────┤
│ │
│ WYBIERZ UNITY gdy: │
│ ✓ Tworzysz grę 2D lub mobilną │
│ ✓ Jesteś początkującym deweloperem │
│ ✓ Masz ograniczony budżet/zespół (indie) │
│ ✓ Znasz C# lub języki podobne │
│ ✓ Priorytetem jest szybkość prototypowania │
│ │
│ WYBIERZ UNREAL gdy: │
│ ✓ Tworzysz grę AAA lub fotorealistyczną │
│ ✓ Potrzebujesz maksymalnej wydajności │
│ ✓ Robisz grę FPS/akcji z widokiem pierwszej osoby │
│ ✓ Masz doświadczenie w C++ │
│ ✓ Potrzebujesz zaawansowanych narzędzi cinematycznych │
│ │
│ UWAGI OGÓLNE: │
│ • Oba silniki są profesjonalne i dojrzałe │
│ • Wybór zależy od kontekstu projektu, nie "lepszości" │
│ • Warto znać oba dla elastyczności kariery │
└────────────────────────────────────────────────────────────────┘
🎯 Pytanie 10: Wkład naukowy pracy
Pytanie
"Jaki jest wkład naukowy Pana pracy? Co wnosi do dziedziny?"
Odpowiedź wzorcowa
Wkład naukowy:
-
Metodologia porównawcza:
- Zaproponowano systematyczne podejście do porównywania silników gier
- Połączenie metod ilościowych (benchmarki) i jakościowych (wywiady)
-
Obiektywne dane:
- Dostarczono konkretnych wyników wydajnościowych zamiast subiektywnych opinii
- Dane z kontrolowanych warunków testowych
-
Perspektywa praktyka:
- Wywiady z deweloperami dostarczają realnego kontekstu użytkowania
- Uzupełnienie luki między marketingiem a rzeczywistością
-
Dokumentacja różnic:
- Szczegółowe opisanie różnic architektonicznych
- Praktyczne implikacje dla procesu deweloperskiego
Znaczenie dla branży:
- Pomoc w świadomych decyzjach technologicznych
- Redukcja ryzyka błędnego wyboru narzędzi
- Materiał edukacyjny dla początkujących deweloperów
🎯 Pytanie 11: Object pooling
Pytanie
"Czym jest object pooling i dlaczego był kluczowy w pracy?"
Odpowiedź wzorcowa
Object pooling to technika optymalizacyjna polegająca na ponownym wykorzystywaniu obiektów zamiast ciągłego tworzenia i niszczenia.
┌────────────────────────────────────────────────────────────────┐
│ OBJECT POOLING │
├────────────────────────────────────────────────────────────────┤
│ │
│ BEZ POOLINGU: Z POOLINGIEM: │
│ ┌─────┐ ┌─────┐ │
│ │spawn│→ new Bullet() │spawn│→ pool.Get() │
│ └─────┘ └─────┘ │
│ ↓ ↓ │
│ [gameplay] [gameplay] │
│ ↓ ↓ │
│ ┌─────┐ ┌─────┐ │
│ │die │→ destroy + GC │die │→ pool.Return() │
│ └─────┘ └─────┘ │
│ │
│ Problemy: Korzyści: │
│ • Alokacje każdą klatkę • Zero alokacji runtime │
│ • GC spikes (Unity) • Brak GC spikes │
│ • Fragmentacja pamięci • Stały koszt pamięci │
└────────────────────────────────────────────────────────────────┘
Znaczenie dla pracy:
- Bullet hell generuje setki pocisków/sekundę
- Bez poolingu → ciągłe alokacje → GC spikes w Unity
- Pooling pozwala na uczciwe porównanie silników (eliminuje narzut GC)
- Technika stosowana w obu implementacjach
🎯 Pytanie 12: Różnice w zarządzaniu pamięcią
Pytanie
"Jak różni się zarządzanie pamięcią w Unity i Unreal Engine? Jakie to ma konsekwencje?"
Odpowiedź wzorcowa
┌────────────────────────────────────────────────────────────────┐
│ ZARZĄDZANIE PAMIĘCIĄ: UNITY vs UNREAL │
├────────────────────────────────────────────────────────────────┤
│ │
│ UNITY (C# / .NET): │
│ ├─ Garbage Collector (GC) - automatyczne zwalnianie │
│ ├─ Zalety: │
│ │ • Brak memory leaks z definicji │
│ │ • Prostsze programowanie │
│ │ • Bezpieczeństwo typów │
│ ├─ Wady: │
│ │ • GC spikes (nieprzewidywalne pauzy) │
│ │ • Mniejsza kontrola nad alokacją │
│ │ • Boxing/unboxing overhead │
│ └─ Mitygacja: object pooling, struct zamiast class │
│ │
│ UNREAL (C++): │
│ ├─ Ręczne zarządzanie + smart pointers │
│ ├─ Zalety: │
│ │ • Pełna kontrola nad pamięcią │
│ │ • Przewidywalna wydajność │
│ │ • Brak GC spikes │
│ ├─ Wady: │
│ │ • Ryzyko memory leaks │
│ │ • Dangling pointers │
│ │ • Większa złożoność kodu │
│ └─ Mechanizmy UE: TSharedPtr, TWeakPtr, garbage collection │
│ dla UObject │
└────────────────────────────────────────────────────────────────┘
Konsekwencje praktyczne:
- Unity: łatwiejsze dla początkujących, ale wymaga uwagi przy wydajności
- Unreal: wymaga doświadczenia, ale daje przewidywalność
🎯 Pytanie 13: Kryteria porównania
Pytanie
"Według jakich kryteriów porównywano silniki?"
Odpowiedź wzorcowa
Trzy główne kategorie kryteriów:
1. Wydajność
- Szybkość renderowania (FPS)
- Zużycie pamięci RAM
- Obciążenie procesora
- Zużycie pamięci karty graficznej
- Czas ładowania scen
2. Funkcjonalność
- Wsparcie dla różnych typów renderingu
- Systemy fizyki
- Systemy audio
- Wsparcie dla VR/AR
- Możliwości skryptowania
3. Użyteczność
- Intuicyjność interfejsu
- Jakość dokumentacji
- Dostępność tutoriali
- Wsparcie społeczności
- Czas potrzebny na naukę (krzywa uczenia)
Dlaczego te kryteria:
- Pokrywają wszystkie aspekty istotne dla deweloperów
- Możliwe do zmierzenia (ilościowe) lub oceny (jakościowe)
- Odpowiadają realnym potrzebom przy wyborze silnika
🎯 Pytanie 14: Przyszłość badań
Pytanie
"Jakie kierunki dalszych badań Pan proponuje?"
Odpowiedź wzorcowa
Propozycje dalszych badań:
-
Rozszerzenie zakresu testów:
- Testy na grach 3D (różne gatunki)
- Porównanie wydajności VR/AR
- Testy na platformach mobilnych i konsolach
-
Uwzględnienie innych silników:
- Godot (open source, rosnąca popularność)
- CryEngine, Amazon Lumberyard
- Własne silniki studiów AAA
-
Badania longitudinalne:
- Śledzenie rozwoju silników w czasie
- Porównanie wersji (Unity 2020 vs 2025)
-
Pogłębienie badań jakościowych:
- Większa próba deweloperów
- Badania w różnych krajach/regionach
- Studium przypadków konkretnych produkcji
-
Aspekty ekonomiczne:
- Koszty licencji i royalties
- ROI przy wyborze silnika
- Czas rozwoju projektu
🎯 Pytanie 15: Blueprints vs C++ w Unreal
Pytanie
"Jakie są różnice między programowaniem w Blueprints a C++ w Unreal Engine?"
Odpowiedź wzorcowa
┌────────────────────────────────────────────────────────────────┐
│ BLUEPRINTS vs C++ w UNREAL ENGINE │
├────────────────────────────────────────────────────────────────┤
│ │
│ BLUEPRINTS: C++: │
│ ├─ Wizualne programowanie ├─ Tradycyjny kod │
│ ├─ Drag & drop węzłów ├─ Tekstowe pisanie │
│ ├─ Szybkie prototypowanie ├─ Maksymalna wydajność │
│ ├─ Dla designerów/artystów ├─ Dla programistów │
│ ├─ Wolniejsze wykonanie ├─ Kompilacja do natywnego │
│ └─ Trudniejsze przy złożoności └─ Pełna kontrola │
│ │
│ TYPOWE ZASTOSOWANIE: │
│ Blueprints: UI, proste mechaniki, prototypy │
│ C++: core gameplay, AI, systemy krytyczne wydajnościowo │
│ │
│ BEST PRACTICE: Hybrydowe podejście │
│ └─ Implementacja w C++, ekspozycja do Blueprints │
└────────────────────────────────────────────────────────────────┘
Wnioski z wywiadów:
- Poradniki często skupiają się na Blueprints
- Profesjonalne produkcje głównie C++
- Blueprints dobre do nauki konceptów silnika
📋 Lista wszystkich pytań (podsumowanie)
- Cel i motywacja pracy
- Metodologia badawcza
- Wybór gry testowej (bullet hell)
- Różnice architektoniczne silników
- Hipotezy badawcze
- Wyniki wywiadów z deweloperami
- Narzędzia profilowania
- Ograniczenia badań
- Praktyczne rekomendacje
- Wkład naukowy pracy
- Object pooling
- Różnice w zarządzaniu pamięcią
- Kryteria porównania
- Przyszłość badań
- Blueprints vs C++ w Unreal
🧠 Mnemoniki dla obrony
"MWUK" - Metodologia:
Mieszana, Wywiady, Unity vs Unreal, Kryterium porównania
"BH = Benchmark Heaven":
Bullet Hell = idealny test (dużo obiektów, kolizji, alokacji)
"Unity = Easy, Unreal = Elite":
Unity: łatwiejsze, Unreal: dla zaawansowanych
"C# GC, C++ MC":
C# = Garbage Collection, C++ = Manual Control