Читать книгу Programowanie gier - Robert Nystrom - Страница 8

Rozdział 1: Architektura, wydajność i gry

W piątej klasie ja i moi znajomi zyskaliśmy dostęp do małej, nieużywanej sali lekcyjnej, w której znajdowało się kilka zdezelowanych komputerów TRS-80. Mając nadzieję, że nas to zainspiruje, nauczyciel odnalazł wydruk jakichś prostych programów w BASIC-u, przy których moglibyśmy pomajstrować.

Czytniki kaset magnetofonowych w komputerach były popsute, więc za każdym razem, gdy chcieliśmy uruchomić jakiś kod, musieliśmy starannie wklepywać go od zera. Sprawiło to, że preferowaliśmy programy, które miały jedynie kilka wierszy:

Być może gdyby komputer wypisał to wystarczająco dużo razy, w magiczny sposób stałoby się to prawdą.

Mimo to proces ten był pełen niebezpieczeństw. Nie znaliśmy się na programowaniu, więc drobne błędy składni były dla nas nieprzeniknione. Jeśli program nie działał – co zdarzało się często – zaczynaliśmy od początku. Z tyłu stosu stron znajdowało się prawdziwe monstrum: program, który zabierał kilka gęsto zapisanych stron kodu. Minęło trochę czasu nim nabraliśmy odwagi, aby choćby spróbować się z nim zmierzyć. Nie mogliśmy jednak mu się oprzeć – tytuł znajdujący się powyżej kodu głosił, że mamy do czynienia z programem „Tunele i Trole”. Nie mieliśmy pojęcia, na czym polegał ten program, ale brzmiało to jak jakaś gra, a co mogłoby być lepszego niż gra komputerowa, którą zaprogramowało się samemu?

Nigdy nie udało nam się jej uruchomić, a po roku wynieśliśmy się z tej sali. (Znacznie później, gdy faktycznie znałem trochę BASIC, zdałem sobie sprawę, że był to jedynie generator znaków dla gry planszowej, a nie sama gra). Kości jednak zostały rzucone – odtąd chciałem zostać programistą gier.

Gdy miałem naście lat, do mojej rodziny trafił Macintosh wyposażony w QuickBASIC, a później THINK C. Spędzałem większą część moich letnich wakacji, klecąc gry. Samodzielne uczenie się było powolne i bolesne. Uruchomienie czegoś, co działało, było łatwe – na przykład ekranu z mapą lub niewielkiej łamigłówki – ale w miarę tego, jak program się rozrastał, stawało się coraz trudniejsze. Początkowo wyzwaniem było nawet to, aby coś zaczęło działać. Następnie stawało się nim wykombinowanie, jak napisać program większy niż coś, co mogłoby zmieścić się w mojej głowie. Zamiast po prostu poczytać o tym, „Jak programować w C++”, spróbowałem poszukać książek o tym, w jaki sposób organizować programy.

Swoje wakacje wielokrotnie spędzałem też łapiąc węże i żółwie na bagnach południowej Luizjany. Gdyby na zewnątrz nie było tak piekielnie gorąco, istnieją spore szanse, że książka ta byłaby poświęcona płazom lub gadom, a nie programowaniu.

Kilka lat później mój znajomy wręczył mi książkę Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku¹. Nareszcie! Książka, której szukałem od czasów, gdy byłem nastolatkiem. Za jednym zamachem przeczytałem ją od deski do deski. Nadal zmagałem się z moimi własnymi programami, ale dostrzeżenie, że inni ludzie również zmagają się ze swoimi i dochodzą do jakichś rozwiązań, przyniosło mi ogromną ulgę. Poczułem, jakbym wreszcie miał do dyspozycji trochę narzędzi, a nie tylko nagie ręce.

Było to nasze pierwsze spotkanie i pięć minut po tym, jak zostałem przedstawiony, usiadłem na jego kanapie i spędziłem kilka następnych godzin kompletnie go ignorując i czytając. Mam nadzieję, że od tego czasu moje umiejętności społeczne nieco się poprawiły.

W 2001 roku dostałem swoją pracę marzeń: zostałem inżynierem oprogramowania w firmie Electronic Arts. Nie mogłem się doczekać, kiedy będę mógł rzucić okiem na jakieś prawdziwe gry i popatrzeć, w jaki sposób profesjonaliści składają je w całość. Jak wyglądała architektura gry tak ogromnej, jak Madden Football? W jaki sposób różne systemy wchodziły ze sobą w interakcję? W jaki sposób udawało im się sprawić, że pojedyncza baza kodu działała na wielu platformach?

Wgryzanie się w kod źródłowy było uczącym pokory i zadziwiającym doświadczeniem. Grafika, sztuczna inteligencja, animacje i efekty graficzne zawierały genialny kod. Mieliśmy ludzi, którzy wiedzieli, jak wycisnąć ostatnie cyki z procesora i dobrze je wykorzystać. Ci ludzie jeszcze przed lunchem robili rzeczy, o których nie wiedziałem nawet, że są możliwe.

Architektura, od której zależał ten genialny kod, była jednak często wynikiem namysłu już po fakcie. Ludzie ci byli tak skupieni na funkcjonalnościach, że na sposób organizacji kodu patrzono przez palce. Sprzężenia między modułami były częste. Nowe funkcjonalności były często przyśrubowane do kodu źródłowego tam, gdzie akurat dało się je wpasować. Wyglądało na to, że wielu z tych programistów nawet nie zerknęło do Wzorców projektowych, a już na pewno nie przebrnęło przez wzorzec Singleton (rozdz. „Singleton”).

W rzeczywistości nie było rzecz jasna tak źle. Wyobrażałem sobie programistów gier siedzących w jakiejś pełnej tablic suchościeralnych wieży z kości słoniowej, tygodniami spokojnie omawiających najdrobniejsze szczegóły architektury. Rzeczywistość była taka, że kod, na który patrzyłem, był napisany przez ludzi starających się dotrzymać ostatecznych terminów. Robili wszystko, co mogli, a to, co mogli zrobić, było często bardzo dobre, z czego stopniowo zdawałem sobie sprawę. Im więcej czasu spędzałem pracując nad kodem gry, tym więcej odnajdywałem genialnych elementów kryjących się pod powierzchnią.

Niestety, „kryjących się” było często trafnym opisem. W kodzie ukryte były prawdziwe perły, ale wiele osób przechodziło tuż obok nich. Widziałem współpracowników usiłujących wymyśleć na nowo dobre rozwiązania, podczas gdy przykłady tego, czego potrzebowali, znajdowały się w tej samej bazie kodu, przy której pracowali.

Jest to problem, który usiłuje rozwiązać ta książka. Wykopałem i wypolerowałem najlepsze wzorce, jakie znalazłem w grach, i przedstawiłem je tutaj, byśmy mogli poświęcać swój czas na wymyślanie nowych rzeczy, a nie na wymyślanie ich raz jeszcze.