Kod gry, przekuwanie wizji artystycznej w aplikację - temat często pomijany w mediach (chyba jako zbyt nerdowski), a przecież bardzo ciekawy. Łukasz Migas, lead programmer w People Can Fly opowiedział nam, jak te sprawy wyglądały w przypadku gry Bulletstorm
Spokojnie, nie zamierzamy zanudzać Was techno-żargonem, ani dywagacjami na temat zawiłości języków programowania. Nasz rozmówca, Łukasz Migas, sam siebie określa jako połowicznego programistę, bo jest jednocześnie managerem i na zarządzaniu oraz spotkaniach na szczycie upływa mu sporo czasu. Ma to swoja zaletę: nie przebywając jedynie wśród programistów, musząc rozmawiać z "niewtajemniczonymi", potrafi o pracy swego zespołu opowiadać tak, by laicy wszystko zrozumieli...
- Nasza praca nad Bulletstormem zaczęła się pod koniec stycznia 2007 roku, ale ze względu na różne zawirowania związane z poprzednimi projektami, okazało się, ze na początku stycznia mamy tylko... trzech programistów. Tak więc oprócz tego, ze zaczynaliśmy pracować nad grą, to musieliśmy jeszcze rozwijać zespół - wspomina Łukasz Migas. - Dużo nam tutaj pomógł Unreal Engine, przez to, że jest w dużej części kompletnym narzędziem. Siadasz, zaczynasz składać wszytko do kupy - wizje designerów, grafikę, levele, muzykę, postaci - i to zaczyna działać. Tak więc pierwsze prace trwały, a zespół budowaliśmy tak, aby móc tę grę skończyć. Rozwinęliśmy go do aż 14 programistów.
Może to kwestia wygodnego narzędzia, czyli Unreal Engine (nie trzeba poszukiwać weteranów kodu), grunt, że People Can Fly zatrudniło sporo ludzi ze skromnym doświadczeniem, ale mających talent. Programistów zaraz po studiach, otwartych i pełnych energii, którzy fachu uczyli się de facto w PCF. Ceną za to była konieczność poświecenia części czasu starszych stażem pracowników na naukę nowych rekrutów. Bonusem z tej sytuacji jest zaś pełne zgranie ze sobą zespołu, bo nikt nie wniósł z zewnątrz jakichś zupełnie odmiennych nawyków czy metodologii pracy.
- Mimo, iż Epic posiada większość w naszym studiu, to oni nam nic nie narzucają - wygląda na to, że team Łukasza Migasa ominęły próby nacisku, o których opowiadał Andrzej Poznański. - Mamy dostęp do silnika, ale sposób w jaki go używamy zależy od nas. Oczywiście jako programista nie mogę sobie pozwolić na zmienianie silnika w dowolnym kierunku, choćby ze względu na regularne jego uaktualnienia. Cały czas wykrywane są jakieś bugi, więc jeśli nie zmodyfikuję za bardzo silnika, to dostaję całkowicie za darmo wersję, z której juz zostały one usunięte.
Wspomniane regularne uaktualnienia Unreal Engine to przede wszystkim ukazujący się co miesiąc Quality Approved Build (numerowany w oparciu o miesiąc i rok). Jeśli gdzieś w mediach mówi sie sporo u dużym update tego silnika, to tak naprawdę jest to związane z jakimś wydarzeniem, typu nowa gra czy premiera UDK (Unreal Development Kit). Tak naprawdę zaś zmiany zachodzą regularnie, bez medialnego szumu, miesiąc po miesiącu. Wymiana uaktualnień pomiędzy PCF a Epic Games mogłaby teoretycznie odbywać sie dzień po dniu, ale byłoby to zupełnie nieefektywne, bo codziennie trzeba by testować większość gry w oparciu o zmiany właśnie wdrożone.
- Byliśmy zawsze na bieżąco, poza tym moja współpraca z Danielem Vogelem, który jest głównym programistą silnika, układa się świetnie - opowiada dalej Łukasz Migas. - My się po prostu osobiście znamy, spędziłem w Epicu dużo czasu, pracują nad Gears of War, koordynując współpracę pomiędzy naszym zespołem a ich zespołem. Potem było kilka wizyt odnośnie ułożenia współpracy przy Bulletstormie. Częste informowanie się na zasadzie "co nowego u ciebie", czyli co nowego oni zrobili, co my. Wymienialiśmy się po prostu technologią, oni brali od nas, my braliśmy od nich... co tydzień mieliśmy taką rozmowę.
- Większa część finalnych poprawek, które były robione by w ogóle Bulletstorm mógł chodzić na konsolach w odpowiedniej ilości klatek na sekundę, prawdopodobnie teraz będzie integrowania z główna wersją silnika - Łukasz Migas zaznacza polski wkład w rozwój Unreal Engine. - Prawdopodobnie wszyscy licencjobiorcy to dostaną.
Przy każdym projekcie pojawiają się wyzwania, którym naprawdę trudno sprostać. W wypadku gry Bulletstorm czymś takim był bullet-time. O ile w wypadku trybu singleplayer jest to rzecz prosta i oczywista, o tyle próba przeniesienia takiego rozwiązania do rozgrywki wieloosobowej rodzi trudności. Spowolnienie czasu dla każdego gracza? Cóż, w praktyce oznaczałoby to notoryczne spowalnianie zabawy dla wszystkich. Dlatego zdecydowano się bullet-time w skali lokalnej. Mówiąc najprościej, spowolnienie czasu musiało obejmować jedynie gracza, który je wywołał, jego przeciwnika i - ewentualnie - elementy w najbliższym otoczeniu.
- To wymagało od nas użycie innego liczenia czasu dla całej gry i innego dla tych obiektów, które są w efekcie bullet-time. Było to zdecydowanie największym wyzwaniem, spędziliśmy nad tym dużo czasu, choćby dlatego, ze trzeba było do tego zmusić PhysX, by działał tak jak my to widzimy. Potem była juz implementacja gotowego rozwiązania do silnika, tak by można to było wystawić dla programistów gameplayu i ewentualnie dla level designerów, żeby byli to w stanie uruchomić, jeśli potrzebują tego na danym poziomie. 
Oprócz tego typu wyzwań "okazjonalnych" istniało też wyzwanie nieustające - uzyskiwanie kompromisów pomiędzy wizjami grafików a wydajnością konsol. Różne platformy, różna ich architektura, a efekt ma być zbliżony wszędzie. Oczywiście Unreal Engine jest silnikiem multiplatformowym, ale implementacja poszczególnych elementów na daną platformę pozostaje zadaniem programistów. Nie ma cudów, narzędzie nie zrobi za nich wszystkiego...
- Graficy lubią, jak ich poziomy wyglądają pięknie i wrzucają nam tony grafiki i potem... o kurde, na PS3 to w ogóle się nie mieści w pamięci, na Xboksie też się nie mieści... No dobrze, zmieściliśmy to na Xboksie i co teraz... hmm... 20 FPS, to ile to będzie na PlayStation? Hmm... 15 FPS, to co z tym robimy? - Łukasz Migas bardzo barwnie, wręcz z zacięciem kabaretowym opisuje te zmagania. -To znaczy, ze trzeba to zoptymalizować. No i w tym momencie zaczyna się historia. Pewnych rzeczy programista nie może zoptymalizować, jeśli grafik nie potrafił dobrze przygotować levelu, w taki sposób, żeby go konsola polubiła. Musieliśmy nauczyć grafików, jak mają nam ułatwiać pracę...
Od lipca zeszłego roku do listopada toczyła się walka o optymalizację. Problem polega na tym, że bez odpowiedniej ilości klatek na sekundę w każdym momencie gry nie dostanie się certyfikacji od Sony czy Microsoftu. Jako że gra ma wyjść na ich konsole, nie pozostaje nic innego, jak tylko optymalizować, odchudzać, szukać cudownych rozwiązań. Jeśli nigdzie nie da się znaleźć odrobiny wolnej pamięci, woła się grafików i komunikuje smutną nowinę: z czegoś trzeba zrezygnować, a w najlepszym wypadku uprościć.
- Mieliśmy na niektórych postaciach łańcuchy, które im się majtały tu i ówdzie. Tak naprawdę nie było dobrze widać, że są to łańcuchy zrobione na fizyce - Łukasz Migas podaje jeden z takich przykładów. - Jak to podmieniliśmy na animację, to nikt tego nie zauważył, a było to dużo lżejsze. Konsolom było łatwiej poradzić sobie z animacją, niż z pełną symulacją, kolizjami. A człowiek musiał widzieć wersję poprzednią, by to zauważyć.
Tego typu szlifowanie drobnych elementów trwa miesiącami. Oczywiście nie pracuje się nad każdym z osobna, bo implementacja zmian pochłaniałaby za wiele czasu. Zbiera się ileś takich detali, robione są testy wydajności i projekty są ewentualnie odsyłane do ich twórców, do poprawek.
Unreal Engine pozwala na pewien komfort przy tworzeniu gier na kilka platform. Jest na tyle uniwersalny, że wersja specyficzna dla danej platformy nie składa się z dużej ilości odrębnego kodu. Programiści nie zajmujący się bezpośrednio silnikiem nie muszą się nawet zastanawiać, czy to, co akurat tworzą będzie się wykonywało na takim czy innym procesorze. Implementują pewne elementy, resztą zajmuje sie silnik. Ewentualnymi problemami zajmują się programiści techniczni, zespół specjalistów od Unreal Engine. Na skutek długotrwałych optymalizacji i tak większość programistów nauczyła się wiele o specyfice silnika, ale ogólnie nie ma konieczności, by wszyscy w studiu byli specami od UE. 
- Chodzi taka pogłoska, ze na PlayStation się bardzo źle pisze gry - Na koniec Łukasz Migas postanawia rozprawić sie z pewnym obiegowym mitem. - PlayStation jest po prostu inne. Xbox przypomina bardzo peceta. Aby na niej przygotować specyficzny kod, trzeba po prostu więcej wiedzieć, więcej sie namęczyć. Nie znaczy to, że ta platforma działa wolniej, po prostu działa inaczej. Narzędzia dla programistów są częściowo inne, momentami nawet lepsze niż w wypadku Microsoftu. Nawet jeśli są podobne, to potrzebne jest inne podejście. Nie są zintegrowane z Microsoft Visual Studio, którego się używa do pisania kodu. Są to oddzielne narzędzia, ale można z nich wyciągnąć taką samą ilość informacji, a czasami nawet więcej. Ja tam w każdym razie pracę na PlayStation sobie chwalę i gdyby kiedyś powstała koncepcja zrobienia gry exclusive dla PlayStation 3, to czemu nie...
Artykuł powstał jako część akcji promocyjnej, realizowanej wspólnie przez gram.pl i EA Polska.
