Speaker: Tomasz Bilnicki Language: Polish Wystąpienie pokrótce przybliża sposób tworzenia gier komputerowych przy pomocy silnika Unreal Engine 4. Duże możliwości tworzenia mechanizmów gier przy pomocy rozwiniętego wizualnego języka skryptowego Blueprints w połączeniu z stosunkowo łatwym w obsłudze edytorem oraz wizualnym tworzeniem materiałów mogą dawać poczucie, że programista nie jest już niezbędnym ogniwem zespołu tworzącego gry. Czy takie podejście ma szansę sprawdzić się praktyce i czy będzie to rozwiązaniem lepszym? Czy jest sens, aby programista tworzył Blueprints? Kto może zastąpić programistę? Jakie problemy prawdopodobnie pojawią się podczas prac nad produktem? Wystąpienie jest przygotowane dla osób nie zaznajomionych z procesem tworzenia gier oraz nie znających silnika Unreal Engine 4. 4Developers: http://4developers.org.pl/pl/

1. Czy programiści nadal są konieczni?
Jak silnik Unreal Engine 4 zmienił podejście do tworzenia gier.

2. Kim jestem?
• Wydział Automatyki, Elektroniki i Informatyki Politechniki
Śląskiej w Gliwicach
• City-Interactive (Katowice)
• The Farm 51 (Gliwice)
• Anshar Studios (Katowice)

3. Tworzenie gier wideo - klasyczny
podział ról w zespole
• Projektanci (designerzy)
• Artyści
• Programiści

4. Wykorzystanie języków skryptowych
• Oddzielenie danych i logiki
• Przyspieszenie prototypowania
• Uproszczenie implementacji mechanik gry

5. Unreal Engine 3 - języki skryptowe
UnrealScript

6. Unreal Engine 3 - języki skryptowe
Kismet

7. Unreal Engine 4 - Blueprints (BP)

8. Możliwości BP
• Dynamiczne tworzenie i usuwanie aktorów/komponentów oraz ustawianie ich
właściwości
• Pętle
• Instrukcje warunkowe
• Definiowanie zmiennych oraz tablic zmiennych
• Tworzenie funkcji
• Definiowanie struktur danych
• Rzutowanie
• Definiowanie typów enumerowanych
• Tworzenie klas oraz interface'ów
• Dziedziczenie po zdefiniowanych klasach
• Debugowanie

9. Unreal Engine 4 - nowe podejście
tworzenia gier
• Artyści - tworzą grafiki, modele itp.
• Projektanci - wymyślają oraz implementują mechaniki gry

11. Spaghetti Style

12. Co może pójść nie tak?
• Spaghetti style
• Redundancja kodu/klas
• Brak podatności na zmiany stworzonego kodu
• Problemy wydajnościowe

13. Przypadki skrajne
BP nie dostarczają rozwiązań
• Obsługa zdarzeń typu odłączenie kontrolera itp.
• Nie wszystko jest dostępne w BP
• Prawdopodobnie certyfikacje

14. Jak używać BP?
• Prototyp
• Reprezentacja graficzna
• Definiowanie danych
• Implementacja logiki mapy
• Składanie pełnoprawnych aktorów z komponentów

15. Kto powinien tworzyć BP?
• Projektanci
– Prototypy
– Logika map
– Ewentualnie część mechanik
• Programiści
– Mechanika bazowa
– Nadzór nad kodem projektantów

16. Dlaczego programista jest
niezbędny?
• Wiedza
– Matematyka, fizyka, algorytmika
– Specyfika działania niektórych mechanizmów
– Architektura i refactoring
• Debugowanie
– "Nie działa i nie wiemy dlaczego"
• Optymalizacja
• Implementacja specyficznej funkcjonalności

17. Pod jakimi warunkami jest możliwe
stworzenie gry bez programisty?
• Mały produkt (niski stopień komplikacji)
• Nie pojawią się nieprzewidziane problemy techniczne
• Nie przejmujemy się certyfikacją
• Nie obsługujemy warunków brzegowych

18. Dziękuję za uwagę
tomasz.bilnicki@gmail.com