- wczytywanie animacji z formatu Havoka oraz zarządzanie nimi poprzez prostą maszynę stanów, umożliwiającą płynne przejścia między kolejnymi animacjami
- integracja z silnikiem graficznym Ogre3D; wszystkie kalkulacje animacji odbywają się w Havoku, na końcu następuje przemapowanie tych danych na szkielet modelu w Ogre
- animacje fizyczne – blendowanie animacji szkieletowych z uwzględnieniem np impulsów oddziałujących na ragdolla, będącego synchronizowanego z animacją ale też mającego na nią wpływ (np efekt postrzału w kończynę postaci, odgrywającą animację chodu)
- pełne wsparcie dla Havokowych ragdolli, upadanie w pełnej bezwładności bądź blendowane z animacją
- płynny powrót z ragdolla poprzez kilka animacji wstawania do neutralnej pozycji modelowej; w zależności od tego w jakiej pozie postać jest ułożona, używana jest animacja wstawania z leżenia na plecach bądź brzuchu
- dismemberment, czyli powszechnie lubiane „rozczłonkowywanie” postaci; w procesie tym nie zachodzi żaden podział siatki modelu wspieranego przez Ogre3d ani dublowanie elementów ragdolla, model musi być uprzednio podzielony tak, aby pasował do elementów z których składa się ragdoll
Jeśli chodzi o sam dismemberment, w planie mam połączenie tego feature’a z animacjami fizycznymi, tak aby zaprezentować uderzenie w daną cześć ciała, której rezultatem jest oderwanie kończyny. Wymaga to jednak pewnego doszlifowania.
Chciałbym również w późniejszym czasie zająć się możliwościami IK i tu głównie zależy mi na:
- kierowaniu głowy i rąk trzymających broń, tak aby pokrywało się to z obranym celem, na początek nic wielkiego, coś co można by wykorzystać przy ustawieniu kamery TPP ala Gears of War
- dopasowywaniu stóp do podłoża, a właściwie i nóg przy większych przeszkodach, jak np pokonywanie schodów
producent: Drago Entertainment
Stanowisko: Game Logic Programmer
Zadania szczególne:
-Implementacja, wdrażanie i rozwój części klienckiej systemu animacji, ścisła współpraca z team’ami odpowiedzialnymi za animacje (animatorzy, engine)
-Implementacja, wdrażanie i rozwój części klienckiej systemu zarządzania particlami
-Zachowanie pojazdów i efekty wizualne\dźwiękowe z nimi związane
Pozostałe obowiązki:
-Rozwijanie klienta gry MMORPG
-Implementacja logiki typu klient-serwer oraz rozwiązań dotyczących tylko aplikacji klienckiej, w tym przygotowywanie GUI
Przykłady opracowanych przeze mnie funkcjonalności:
-Looking for Group (Client\Serwer, GUI, Game logic)
Zautomatyzowany system umożliwiający graczom wyszukiwanie i tworzenie grup z wykorzystaniem określonych kryteriów
-Direction Visibility System (Client, Game logic)
System określający poziom widoczności gracza przez najbliższych przeciwników, znajduje ‘n’ zadanych najbliższych przeciwników, którzy widzą gracza oraz określa stopień z jakim gracz jest dla nich widoczny, przedstawiając te informacje na HUD’zie
-Player Cover System (Client, Game logic)
System wykrywający obecność gracza w obszarze pełnej bądź częściowej osłony przed przeciwnikami, przejmujący częściowa kontrolę nad animacjami czy postawą postaci, realizujący logikę jak np automatyczne wstawanie zza zasłony, za którą gracz kuca, w chwili rozpoczęcia celowania, a następnie powrót do kucania
-Vehicles dynamic special effects(Client, Game logic)
System, a właściwie zbiór mniejszych systemów, odpowiedzialny za efekty (głównie particle i decale) związane z pojazdami, a ściślej zależne od ich określonego zachowania, prędkości poruszania, stopnia uszkodzenia, czy zdarzeń chwilowych, jak upadek z wysokości czy moment dodania gazu. System ten zapewnia osobie pracującej nad particlami dostęp do chwilowych parametrów pojazdu jak np kierunek ruchu czy prędkość
-Animations of all ingame characters and objects(Client/Animation tree, Game logic)
W skrócie, system odpowiedzialny za kontrole nad animacjami w grze, począwszy od prostych funkcjonalności jak uruchamianie animacji przeładowania broni zarówno na postaci jak i na samym modelu broni, poprzez dynamiczne modyfikowanie parametrów animacji w zależności od sytuacji (np skalowanie animacji poruszania, aby dopasować je do faktycznej prędkości ruchu postaci) na logice kryjącej się pod procesem zmiany z jednej broni na drugą (animacja chowania, zamiana modelu broni, animacja wyjęcia broni, wszystko synchronizowane przez eventy wysyłane w czasie rzeczywistym przez graf animacji)
Fragmenty kodu źródłowego:
]]>Jest to prototyp wykonany na potrzeby rekrutacji w warszawskim studio 11bits studios, nie miałem go jednak okazji nigdy przedstawić, gdyż w między czasie dostałem propozycję pracy w innej firmie. Sam projekt i pomysł rozwiązania oparty jest o kod napisany w 2011 w chwili rekrutacji, w roku 2013 dodałem drobne usprawnienia, poprawiłem wizualizację i oddzieliłem kod odpowiedzialny za logikę dema, tak aby był on czytelniejszy.
Podczas nagrywania filmiku, fraps wprowadził dziwne „szarpanie” jednostek podczas ruchu, które nie występowało podczas normalnej symulacji nawet przy niskich fpsach. Jednak jak na prototyp przystało, mogły prześlizgnąć się tu jakieś drobne błędy 
Dodatkowo:
]]>
Najciekawsze cechy projektu:
-w pełni dynamiczne oświetlenie sceny bazujące na modelu Phong’a (światło odbijane zwierciadlanie + natężenie światła rozproszonego + natężenie światła otoczenia obliczane w 100% per-pixel)
-oświetlenie uwzględniające powstawanie cieni (metoda Parallel-Split Shadow Mapping) z wykorzystaniem źródła światła typu directional
-HDR rendering + Bloom
-cykl dnia i nocy – dynamiczne niebo, widoczne wędrujące po sklepieniu za dnia słońce, będące jednocześnie źródłem światła zmieniającym swoją intensywność zależnie od pory dnia
-renderowanie roślinności
-zastosowanie techniki Texture splatting w celu nadania terenowi bardziej naturalnego wyglądu
-renderowanie wody z uwzględnieniem zjawisk refleksji i refrakcji oraz jej animacja za pomocą Flow Maps
-możliwość znacznego przyspieszenia wczytywania lokacji na komputerach wyposażonych w procesory wielordzeniowe dzięki wykorzystaniu wielowątkowości
Dodatkowo:
-implementacja oparta o opensourcowy silnik Ogre3D
Fragmenty kodu źródłowego:
]]>
Najciekawsze cechy projektu:
-rendering z wykorzystaniem metody Deffered Shading
-w pełni dynamiczne oświetlenie sceny bazujące na modelu Phong’a (światło odbijane zwierciadlanie + natężenie światła rozproszonego + natężenie światła otoczenia obliczane w 100% per-pixel)
-oświetlenie uwzględniające powstawanie cieni (metoda variance shadow mapping) z wykorzystaniem źródeł światła typu pointlight oraz spotlight
-oświetlenie wolumetryczne dla źródeł światła typu spotlight
-High Dynamic Range Rendering wykorzystujące efekt Bloom wraz z symulacją stopniowego przystosowywania się oka obserwatora do nagłych zmian natężenia światła
-Normal Mapping
-Per-Pixel Motion Blur
Dodatkowo:
-optymalizacja renderowania sceny poprzez podział na strefy połączone portalami oraz techniki early z-pass
-wykorzystanie biblioteki Havok do kontroli otoczenia, poruszania postaci gracza, trigger’ów itp
-implementacja silnika graficznego oparta o opensourcowy silnik Ogre3D
Fragmenty kodu źródłowego:
]]>
Najciekawsze cechy projektu:
-statyczne oświetlenie sceny źródłami światła typu pointlight, bazujące na modelu Phong’a
-renderowanie cieni z wykorzystaniem pre-kalkulowanych lightmap dla statycznych elementów sceny
-Normal Mapping
-Motion Blur
-implementacja Projective Decals umożliwia uzyskanie efektu rozprysku krwi pozostającej na elementach sceny
-wklęsłe ślady po kulach powstające na powierzchniach dzięki zastosowaniu metody Parallax Mapping
-elastyczny, nie wymagający rekompilacji projektu, system dodawania do świata gry nowych elementów n.p. ekwipunku czy przeciwników porzez tworzenie plików z definicjami, które wczytywane są podczas uruchomienia
-wykorzystanie języka skryptowego Squirrel – definicje zachowań i reakcji przeciwników, np. po oddaniu strzału do przeciwnika, gromadzone są informacje m.in. o trafionej części ciała i przekazywane one są do odpowiedniego skryptu, gdzie informacje te są przetwarzane i podejmowane jest na ich podstawie określone działanie
Dodatkowo:
-wykorzystanie biblioteki PhysX do kontroli postaci gracza jak i przeciwników (w tym Ragdolls) oraz innych dynamicznych elementów sceny m.in. łuski wyrzucane z broni
-podstawowa sztuczna inteligencja przeciwników pozwalająca im dostrzec gracza, podążać za nim, omijać napotkane przeszkody na drodze do celu oraz atakować
-implementacja oparta o opensourcowy silnik Ogre3D
]]>
Najciekawsze cechy projektu:
-swobodna możliwość poruszania się po losowo generowanych lokacjach
-lokacje tworzone są z dostępnej puli dużych segmentów, jak n.p. małe pokoje, korytarze, schody, ale też fragmenty ścian czy podłóg
-poruszanie postaci w kierunku punktu kliknięcia myszą (brak algorytmów wytyczania trasy) z możliwością omijania drobnych napotkanych na drodze przeszkód
-lokacje nie są ograniczone do jednej płaszczyzny, możliwość wstawiania elementów budulcowych jak m.in. schody czy zapadnie oraz umieszczania wielu pomieszczeń nad sobą
-podążająca za postacią gracza kamera, posiadająca możliwości zbliżenia oraz orbitowania
Dodatkowo:
-wykorzystanie opensourcowej biblioteki Newton Game Dynamics do kontroli postaci i jej interakcji ze środowiskiem
-implementacja z wykorzystaniem opensourcowego silnika Ogre3D
]]>
Najciekawsze cechy projektu:
-możliwość poruszania się po losowo generowanych lokacjach
-lokacje składają się z niewielkich elementów budulcowych o stałych rozmiarach – elementu podłogi i ścian
-lokacje mogą znajdować się tylko na jednej płaszczyźnie
-postać może poruszać się pomiędzy połączonymi ze sobą elementami podłogi, zatrzymując się pośrodku docelowego elementu
-do przemieszczania postaci wykorzystano algorytm wyszukiwania najkrótszej trasy A*
-podążająca za postacią gracza kamera, posiadająca możliwości zbliżenia oraz orbitowania
-implementacja ekwipunku samodzielnie układającego znajdujące się w nim przedmioty tak, aby uzyskać jak najwięcej miejsca
-elastyczny, nie wymagający rekompilacji projektu, system dodawania do świata gry nowych elementów n.p. ekwipunku poprzez tworzenie plików z definicjami, które wczytywane są podczas uruchomienia
-wykorzystanie języka skryptowego Game Monkey w celu sprawdzenia wymagań, jakie postać musi spełnić, aby móc użyć przedmiotu z ekwipunku oraz umożliwienia wykonania pewnych działań po jego użyciu; przykładowo, używamy pochodni, sprawdzana jest siła postaci, która umożliwi jej utrzymanie przedmiotu, następnie tworzymy encje tj źródło światła oraz system cząsteczek symulujący płomień
Dodatkowo:
-implementacja z wykorzystaniem opensourcowego silnika Irrlicht
]]>