Jak się robi gry? [tom 2]
Po dłuższej przerwie wracam do naszego radosnego cyklu o poezji XXI wieku, czyli o wzniosłej sztuce tworzenia gier! Dla porządku przypominam, iż ideą artykułów nie jest stworzenie żadnej formy podręcznika/poradnika, a jedynie podzielenie się luźnymi spostrzeżeniami i wnioskami nabytymi w trakcie mojej – na razie krótkiej – kariery twórcy gier. Nie mniej gdzieś w głębi kołacze nadzieja, że właśnie taka niezobowiązująca forma tekstu dotrze do kogoś, kto naszkicowane przeze mnie tematy zechce zgłębić i zrobić z nich użytek.
->TOM 1<-
Rozdział II: Technologia
Rozdział poświęcony będzie naszym młotkom, gwoździom, łopatom, zaprawie i gładzi szpachlowej. Czy też odpowiednikom powyższych w procesie tworzenia gry. Tu od razu należy rozwiać wszelkie wątpliwości – magia nie istnieje. Porzuć marzenia o programie, który niczym różdżka Harrego Pottera pozwoli ci w kilka chwil wyklikać najlepszą grę na świecie. Czy w ogóle jakąkolwiek sensowną grę. Owszem, istnieje kilka mniej lub bardziej zabawkowych edytorów, które z różną skutecznością pomijają niektóre aspekty pracy nad prawdziwą grą (programowanie…), ale te najlepsze i tak wymagają długich godzin nauki ich obsługi i jeszcze więcej poświęconych samemu tworzeniu, a rezultaty na ogół nie zaklasyfikują się jako wspomniana wyżej “sensowna gra”. Ostatecznie tego rodzaju przybory polecam głównie jako poligon doświadczalny dla tych absolutnie początkujących. Tych ambitniejszych odsyłam natomiast do rozdziału I niniejszego artykułu i zachęcam do zgłębiania co najmniej podstaw programowania, grafiki i ogólnych zasad projektowania oraz budowania elementów rozgrywki. Z takim przygotowaniem można już coś zwojować na poważnie.
Przy czym uspokajam, iż nawet w sferze określonej powyżej jako “poważnie” funkcjonuje cała masa opcji odpowiadających różnym poziomom doświadczenia, preferencjom czy rodzajom i złożoności tworzonych gier. Nie musimy wymyślać na nowo koła. Nawet nie powinniśmy – na wyciągnięcie ręki mamy wybór silników gier, bibliotek, komponentów i dodatkowych narzędzi, które ułatwiają i uprzyjemniają proces twórczy. Dobór takowych odpowiednio do zadania to nieraz sztuka sama w sobie. Poniżej BARDZO ogólnie zarysowałem kilka poziomów trybu pracy w zależności od tego, ile ktoś miły robi za nas. Najniższy poziom to opcje najprostsze, ale dające najmniejsze możliwości, najwyższy – odwrotnie, a jakże.
0. Zabawkowe edytory “wyklikaj grę” – temu tematowi poświęciłem pierwszy akapit
1. Silniki gier w postaci edytorów – pozornie podobne do powyższych, ale znacznie bardziej złożone. Z reguły wymagają elementów programowania.
2. Silniki gier w postaci bibliotek – (niemal) gotowe rozwiązania programistyczne ułatwiające stworzenie gry w wybranym środowisku i języku programowania.
3. Silnik graficzny + inne gotowe komponenty (do dźwięku, zasobów, interfejsu, itd.) + własny kod logiki gry
4. Wszystko samemu w wersji rozsądnej – z użyciem np. C++ i DirectX/OpenGL
5. Wszystko samemu w wersji hardcore – assembler, sterowniki urządzeń i jazda. Odradzam.
[Chcę w prawdzie uniknąć elementów "kursu tworzenia gier", ale pewną kwestię muszę na tym etapie wyjaśnić. Chodzi mianowicie o pojęcia silnika graficznego i silnika gier, nagminnie ze sobą mylone. Pierwsze z nich dotyczy elementów programistycznych związanych (w głównej mierze) z wyświetlaniem obrazu - tj. są to najczęściej biblioteki ułatwiające pracę z grafiką 2D/3D. Nie muszą wcale służyć do gier! Drugie z pojęć oznacza coś więcej - kompleksowe rozwiązanie służące stworzeniu gry. Silnik gry zawiera silnik graficzny, ale też elementy odpowiedzialne za dźwięk, fizykę, sztuczną inteligencję, sterowania, animacje, itd. Po szczegóły odsyłam np. do wikipedii.]
Podkreślam jednak, iż nie jest to w żadnym razie ścisły podział. Właściwie wymyśliłem go przed chwilą, dla własnej wygody. W praktyce wracamy do powiedzenia o wymyślaniu koła - choćbyś nie wiem jak ambitnie podszedł do swojej pracy, unikanie używania gotowców będzie zwyczajnie głupie. Owe gotowce są często bardzo dopracowane, proste w użyciu i – uwaga – darmowe. Że posłużę się czytelnym przykładem – CD Projekt RED, tworząc silnik Wiedźmina 2, zbudował własny silnik graficzny i prawdopodobnie szereg innych modułów, ale w całość wkomponował także wiele z wspominanych gotowych rozwiązań – dla fizyki, interfejsu, dźwięku, a nawet specjalne narzędzie do tworzenia drzew (takich leśnych, nie matematycznych). Też tak możesz!

Wizualne tworzenie skryptów nie zawsze jest prostsze niż ich programowanie. Ten skrypcik z UDK odpala kilka dźwięków.
OK kolego, nie zdziwię się, jeśli na tym etapie czujesz się zagubiony, zwłaszcza jeśli na temat tworzenia gier wiesz jeszcze niewiele. Jeśli jednak masz dość zapału, by stworzyć coś więcej, niż pierdołę, którą pochwalisz się kolegom, na bazie własnego doświadczenia polecę ci coś konkretnego. Zadbaj o niezbędne podstawy, o których wspominałem wcześniej, a potem sięgnij po rozwiązanie numer 1. Mowa o tych najbardziej kompletnych silnikach gier – względnie prostych w użyciu, ale dających nieraz ogromne możliwości. I powszechnie stosowanych w komercyjnych produkcjach!
Do powyższych należy m.in. Unreal Development Kit, czyli kompletny zestaw narzędzi od twórców Unreala – dostępny dla każdego, za darmo. To niesłychanie kobylasta, ale też niezwykle piękna maszyna. Co ciekawe, pozwala wiele zdziałać nie ruszając kodu, choć w dalszym ciągu opanowanie jej to niełatwe i bardzo czasochłonne zadanie. Za to jest gdzie szukać pomocy – UDK może się pochwalić doskonałym wsparciem, wliczając bardzo przyjemne video tutoriale.
Ja jednak szczególnie chciałbym was zainteresować innym narzędziem z tej kategorii – wyjątkowo przeze mnie lubianym. Mowa o zyskującym coraz większą popularność Unity, dostępnym również w darmowej wersji. Silnik ten zaskakuje kompletnością i łatwością obsługi, choć w “gołej” wersji będzie od ciebie wymagał umiejętności opisania elementów mechaniki gry w postaci skryptów (programowanie). Komponentowy charakter narzędzia pozwala jednak sprawnie podzielić pracę – np. w taki sposób, by całe programowanie zwalić na kolegę. A co, niech się męczy.
Co szczególnie ciekawe, Unity pozwala w łatwy sposób przygotować wersję gry na PC, Maca, iPhone’a, konsole, a nawet przeglądarkę. Te dobrodziejstwa dostępne są jednak za opłatą – w darmowej wersji jesteśmy ograniczeni do PC i przeglądarki (o ile mnie pamięć nie myli).
Tyle na dziś. Tom 3 już niedługo! Albo za dwa lata.

![Jak się robi gry? [tom 2] Jak się robi gry? [tom 2]](http://themimizu.files.wordpress.com/2011/07/making_games2.jpg?w=497)







Mam wrażenie, że proponowanie początkującemu programiście UDK nie jest dobrym pomysłem. To tak, jakby rekrutowi do wojska dać czołg i instrukcję – jak sobie poradzi będzie super, ale raczej naprzeklina, popsuje i zniechęci. Lepiej zacząć od pozornie prostszych rzeczy.
Ze swej strony polecę – z wiadomych względów – XNA od Microstu. Nie stworzy się w tym nowego UT, ale załapie o co chodzi w projektowaniu gier, zarządzaniu animacjami czy planowaniu logiki. Graficznie nie będzie to zapewne super, ale w ramach dokumentacji gotowe są solidne modele do wykorzystania, więc odpada dłubanie z różnymi edytorami 3D. A tutoriali i porad – także dla zaawansowanych technologicznie – jest bardzo dużo.
Efekty mogą być zaskakująco dobre: http://www.youtube.com/watch?v=3tTPv3fSGs8 czy http://www.youtube.com/watch?v=EAcMWJvibjo&feature=related robię niezłe wrażenie. Potem, po pokonaniu paru barier, można atakować UDK ;]
Skoro Minecrafta napisano w Javie, równie dobrze coś podobnego można zrobić w C#. Polecam
Tak, UDK jest ciężką do ogarnięcia kobyłą – wyraźnie to zaznaczyłem i dlatego z większym naciskiem podsunąłem Unity. Natomiast odnoszę wrażenie, że XNA leży jednak odrobinę niżej niż “silnik gier” i w dalszym ciągu wymaga od tego nieszczęsnego początkującego, by zrobił sam wiele rzeczy, które w technologiach typu Unity ma z miejsca zapewnione. Mowa np. o importerze zasobów w różnych formatach, narzędziach do animacji, tworzenia terenu i drzew. O fizyce, GUI, lightmapach, efektach cząsteczkowych… Wszystko wygodnie zintegrowane z głównym edytorem i w większości obsługiwane wizualnie. Które z tego rodzaju udogodnień oferuje XNA?
Inna rzecz przemawiająca na niekorzyść XNA to niewielka liczba stworzona przy jego użyciu ważnych, komercyjnych produkcji (a wszyscy chcemy takie robić, prawda?
). Natomiast Unity coraz lepiej sobie w tej sferze poczyna.
Czy tylko ja mam wrażenie, że tekst został napisany przez “twórce gier”, którego wiedza kończy się na ściągnięciu UDK z sieci?