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

Każda książka dotycząca programowania mająca w tytule słowo „wzorce” w jasny sposób nawiązuje w jakiś sposób do klasycznej pozycji Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, autorstwa Ericha Gammy, Richarda Helma, Ralpha Johnsona i Johna Vlissidesa (złowieszczo nazywanych „Bandą czterech”).

Sama książka Wzorce projektowe była z kolei zainspirowana inną książką. Pomysł wykonania języka wzorców w celu opisania otwartych rozwiązań problemów pochodzi z książki A Pattern language Chrisophera Alexandra (oraz Sarah Ishikawy i Murraya Silversteina).

Nazywając tę książkę Programowanie gier. Wzorce, nie próbuję sugerować, że książki napisanej przez Bandę czterech nie można zastosować do gier. Przeciwnie: część „Wzorce projektowe raz jeszcze” niniejszej książki obejmuje wiele wzorców z Wzorców projektowych, kładąc jednak nacisk na to, w jaki sposób można je zastosować do programowania gier.

Ich książka była poświęcona architekturze (takiej prawdziwej architekturze, z budynkami, ścianami i tak dalej), mieli oni jednak nadzieję, że inni wykorzystają tę samą strukturę do opisania rozwiązań w innych obszarach. Wzorce projektowe to próba podjęta przez Bandę czterech, której celem było zrobienie tego w odniesieniu do oprogramowania.

Myślę, że jest odwrotnie i ta książka znajdzie zastosowanie również w przypadku oprogramowania innego niż gry. Również dobrze mógłbym ją zatytułować Jeszcze więcej wzorców projektowych, myślę jednak, że gry dostarczają bardziej interesujących przykładów. Czy naprawdę chcielibyśmy przeczytać jeszcze jedną książkę o ewidencji pracowników i kontach bankowych? Choć przedstawione tu wzorce są użyteczne w przypadku innych rodzajów oprogramowania, myślę jednak, że szczególnie dobrze pasują do wyzwań inżynieryjnych pojawiających się często w przypadku gier:

 Czas i sekwencjonowanie stanowią często kluczowy składnik architektury gry. Rzeczy muszą się dziać w odpowiedniej kolejności i w odpowiednim czasie.

 Cykle deweloperskie są bardzo napięte, a niektórzy programiści muszą być w stanie szybko zbudować i iterować na dużym zbiorze różnych zachowań, bez nadeptywania sobie wzajemnie na palce czy zostawiania śladów w całej bazie kodu.

 Gdy całe zachowanie jest już zdefiniowane, zaczyna wchodzić w interakcje. Potwory kąsają bohatera gry, eliksiry mieszają się ze sobą, a bomby niszczą tak wrogów, jak i przyjaciół. Te interakcje muszą zachodzić, nie powodując, że baza kodu stanie się splątanym kłębkiem wełny.

 I wreszcie: w przypadku gier wydajność jest krytyczna. Programiści gier uczestniczą w bezustannym wyścigu o to, kto wyciśnie najwięcej ze swojej platformy. Triki służące zaoszczędzeniu kilku cykli mogą stanowić o różnicy między chwaloną przez wszystkich grą i milionami sprzedanych egzemplarzy a utraconymi klatkami i rozzłoszczonymi recenzentami.