docSzymon NALIKOWSKI, Walery SUSŁOW
download 
Reklamacja Transkrypt
Szymon NALIKOWSKI, Walery SUSŁOW
SZYMON NALIKOWSKI [email protected] WALERY SUSŁOW [email protected] Wydział Elektroniki i Informatyki Politechnika Koszalińska PODEJŚCIE KONCEPTUALNE PODSTAWĄ SKUTECZNOŚCI PROGRAMISTY W PROJEKTACH GIER KOMPUTEROWYCH Streszczenie: Autorzy referatu postawili hipotezę, że skuteczność działania programisty w ramach projektu gry komputerowej może być istotnie zwiększona poprzez stosowanie podejścia pojęciowego (konceptualnego) tak przy budowie oprogramowania, jak i przy komunikacji z innymi członkami zespołu projektowego. Przeprowadzone przez autorów studium przypadku na przykładzie projektu gry turniejowej w tetrisa dostarczyło ciekawych przykładów potwierdzających sformułowaną hipotezę. Słowa kluczowe: projektowanie oprogramowania, gry komputerowe, modelowanie konceptualne 1. Wstęp Proces produkcji nowoczesnych, konkurencyjnych na rynku gier komputerowych jest bardzo złożony [1], wymaga udziału oprócz programistów przede wszystkim scenarzystów, grafików, artystów i muzyków, a często również matematyków i fizyków. Programista pracujący w takim zespole projektowym powinien umieć stosować zaawansowane metody programistyczne w rozwiązywaniu problemów typowych dla gier komputerowych, w tym dotyczących zagadnień grafiki komputerowej czasu rzeczywistego, sztucznej inteligencji, logiki, algorytmiki oraz fizyki. Sama umiejętność doskonałej prezentacji wirtualnych obiektów w złożonych scenach gry nie jest jednak wystarczająca, bo 76 Szymon Nalikowski, Walery Susłow końcowy produkt będzie oceniany przez graczy całościowo, nie tylko na podstawie wrażeń od unikatowych efektów wizualnych stworzonych przez programistę. Autorzy niniejszego artykułu postawili hipotezę, że skuteczność działania programisty w ramach projektu gry komputerowej może być istotnie zwiększona poprzez stosowanie podejścia pojęciowego tak przy budowie oprogramowania, jak i przy komunikacji z innymi członkami zespołu projektowego. Przeprowadzone przez autorów studium przypadku na przykładzie projektu gry turniejowej w tetrisa dostarczyło ciekawych przykładów potwierdzających sformułowaną hipotezę. 2. Teoretyczne uzasadnienie hipotezy pracy Zespół produkujący grę jest w praktyce grupą niezależnych osób, które pracują wspólnie nad projektem oprogramowania generalnie w trybie asynchronicznym oraz bardzo często bez wspólnej przestrzeni fizycznej i organizacyjnej. Spójność takiego zespołu osiągana jest tylko dzięki stosowaniu technologii komunikacyjnych. Wykazano [2], że świadome stosowanie podejścia pojęciowego do usprawnienia komunikacji, szczególnie w ramach wykonania zadań analityczno-projektowych, jest kierunkiem globalnego usprawnienia jakości produktów informatycznych tworzonych w takich zespołach. Tylko przy konsekwentnym stosowaniu konceptualizacji (ścisłego definiowania pojęć, konceptów, terminów) jako etapu prac nad zadaniem projektowym, można spodziewać się głębszego rozumienia istoty i detali projektu przez wszystkich jego uczestników. Należy podkreślić, że w pracy zespołów złożonych z różnych specjalistów bardzo istotną rolę odgrywa język naturalny, który stanowi medium do porozumiewania się merytorycznego. Poza tym, myślenie mowne lub werbalnologiczne, opierające się na językowym obrazie świata, jest istotą pracy projektantów oprogramowania (programistów). Myślenie mowne leży u podstaw przyswojenia i wykorzystania wiedzy, służy jako główny środek złożonej działalności poznawczej. Myśląc w oparciu o kody języka, projektanci są w stanie wychodzić poza granicę bezpośredniego zmysłowego odbioru świata zewnętrznego, postrzegać złożone związki i relacje, formować pojęcia, wyciągać wnioski i rozwiązywać złożone zadania techniczne [3]. Dodatkowe komplikacje z komunikacją w przypadku projektu gier komputerowych wynikają z konieczności rozmowy o świecie wirtualnym, który de facto jest tworzony przez projektantów. Podstawową jednostką języka jest słowo. W odróżnieniu od zwierząt, u których „słowo” wyraża raczej stan afektywny, większość słów języka ludzkiego Podejście konceptualne podstawą skuteczności programisty… 77 posiada odniesienie przedmiotowe (pojęciowe). Nie jest ono prostą asocjacją specyficznego dźwięku z pewnym konkretnym przedstawieniem. Poprzez odniesienie przedmiotowe, rzeczywiście pełni ono funkcję oznaczającą, ale jest także środkiem abstrakcji i uogólnienia, dającym możliwość analizować przedmioty – pełnić funkcję znaczeniową. Opanowując słowo, człowiek automatycznie przyswaja złożony system związków i relacji, w których odpowiadający słowu przedmiot się znajduje [3]. Problem polega na tym, że słowo nie jest prostym odniesieniem do poglądowego przedstawienia, bo może posiadać ono wiele znaczeń. Realne używanie słowa (np. w dialogu) zawsze jest procesem wyboru potrzebnego znaczenia z kilku alternatyw. Znaczenia słowa ulegają zmianom rozwojowym (historycznym), przy czym przedmiotowe odniesienie słowa generalnie pozostaje niezmienne. Przy wyborze potrzebnego znaczenia odbywa się aktywacja odpowiednich podsieci związków mentalnych oraz hamowanie innych, nieodpowiadających zadaniu lub kontekstowi. Mianowicie to jedno znaczenie, wyodrębnione z kilku znaczeń i odpowiadające sytuacji, jest sensem słowa. Proces realnego używania słowa jest to wybór potrzebnego sensu ze wszystkich możliwych alternatyw. Przy tym, sens wypowiadanego słowa zależy od intencji osoby i od konkretnej sytuacji, w której to słowo zostało użyte. Doprecyzowanie sensu możliwe jest poprzez morfologiczne zmiany słowa oraz w warunkach komunikacji bezpośredniej poprzez intonację, z którą słowo zostało wypowiedziane (zespoły rozproszone są pozbawione tej możliwości). Za każdym słowem rozwiniętego języka kryje się cały system związków i relacji, w które zaangażowany jest przedmiot oznaczany tym słowem. Przy tym, każde słowo uogólnia i jest środkiem (narzędziem) kształtowania pojęć [2]. Istotne jest, że nazywając konkretne słowo człowiek nie tylko odtwarza konkretny obraz poglądowy (ang. image), ale praktycznie powołuje do życia cały system związków, wychodzących daleko za przedziały bezpośrednio postrzeganej sytuacji i będących złożoną macierzą wiedzy uporządkowanej logicznie. System pojęć odpowiadających słowom nie jest taki sam u różnych osób. Struktura pojęć różni się nawet u tej samej osoby na różnych etapach rozwoju, za tym stoją zmiany zachodzące w procesach psychicznych. Komunikacja sprzyja skoordynowaniu pojęć. Każde słowo-pojęcie posiada związki poglądowe oraz logiczne. U ludzi znajdujących się na różnych etapach rozwoju umysłowego proporcje emocjonalno-obrazowych i logicznych związków różnią się. Czyli, przechodząc etapy rozwoju człowiek zmienia sposób świadomego postrzegania świata [3]. Pojęcie jest podstawowym składnikiem myśli, abstrakcyjnym, myślowym i całościowym odzwierciedleniem istotnych cech przedmiotów i zjawisk, my- 78 Szymon Nalikowski, Walery Susłow ślowym odpowiednikiem nazw. Z każdym pojęciem związane są jego ekstensja (klasa przedmiotów, obiektów opisywanych przez pojęcie) oraz jego intencja (klasa cech, własności, atrybutów wspólnych dla wszystkich przedmiotów z ekstensji). Psychologia rozróżnia dwa rodzaje pojęć: życiowe i naukowe. Pojęcia życiowe dobrze znamy, ale nie zawsze potrafimy sformułować (zdefiniować), przeważają w nich konkretne elementy sytuacyjne, a kształtowane one są podczas działalności praktycznej oraz w wyniku praktyk poglądowoobrazowych. Pojęcia naukowe nabywane są w trakcie nauki (edukacji), przeważają w nich związki odwleczone, a kształtowane one są z udziałem operacji werbalno-logicznych. Pojedyncze słowo może oznaczać przedmiot, uformować pojęcie, ale generalnie nie może jednoznacznie wyrazić zdarzenia lub stosunku, czyli nie może sformułować sądu, myśli. Owszem, podstawową jednostką języka jest słowo, ale za podstawową jednostkę mowy musimy uważać syntagmę – połączenie słów, tworzących frazę, zdanie lub wypowiedź. Grupa słów jest przekształcana w sensowne zdanie za pomocą syntaktycznych środków wypowiedzi – właściwego umiejscowienia słów, fleksji oraz dodawania słów służbowych. Ignorowanie opisanej złożoności języka jako środka komunikacji w zespołach projektujących gry komputerowe może być przyczyną wielu nieporozumień, co w skutku może doprowadzać do obniżenia jakości użytkowej tworzonego oprogramowania. 3. Studium przypadku Autorzy poddali badaniu warstwę pojęciową wykonanego w roku 2013 na Wydziale Elektroniki i Informatyki Politechniki Koszalińskiej projektu oprogramowania do wspomagania turnieju gry w tetrisa . Zostały zestawione i przeanalizowane pod kontem spójności ontologicznej wszystkie dokumenty projektowe, w tym listingi oprogramowania, modele UML, scenariusze, zaprojektowane widoki i dialogi, specyfikacje i podręcznik użytkownika. Poniżej przedstawiono krótki opis projektu oraz wybranych spostrzeżeń z tej analizy. 3.1. Opis gry Klasyczny Tetris [4-6] (rysunek 1) jest to gra polegająca na układaniu „spadających” tetrimino (figur z czterech klocków-kwadratów) w początkowo pustej prostokątnej planszy-studni o szerokości 10 i wysokości 20 umownych jednostek. Każde tetrimino składa się dokładnie z czterech identycznych klocków- Podejście konceptualne podstawą skuteczności programisty… 79 kwadratów. W grze istnieje siedem unikatowych kształtów tetrimino, nazywanych S, Z, I, L, J, O, T na zasadzie podobieństwa ich kształtów do kształtów wymienionych liter. Rys. 1. Przykładowy widok planszy Tetrisa w trakcie gry indywidualnej W trakcie gry nowe tetrimino po kolei pojawiają się na górze planszy w środkowej pozycji i natychmiast zaczynają spadać. Spadające tetrimino zatrzymuje się, gdy opadnie na dno pojemnika lub na którykolwiek klocek, który zatrzymał się na planszy wcześniej. Całkiem wypełnione rzędy planszy są automatycznie czyszczone przez silnik gry, co jest premiowane punktami. W sposób naturalny podczas tej akcji odbywa się demontowanie tetrimino na pojedyncze klocki. Jednorazowo za pomocą pojedynczego spadającego tetrimino gracz może wypełnić (domknąć) do czterech rzędów, co jest odpowiednio więcej premiowane punktami. W związku z koniecznością porządkowania planszy w momencie czyszczenia wypełnionych rzędów stosuje się trzy podstawowe sposoby realizacji tak zwanej mechaniki gry: pozostające klocki opadają rzędami, zachowując oryginalne ułożenie, pozostające klocki opadają kolumnami, nie zostawiając pod sobą wolnej przestrzeni, co może doprowadzać do kaskadowego czyszczenia kolejnych linii podczas opadania pozostających klocków odbywa się dodatkowa reorganizacja rzędów. W czasie opadania gracz może przesuwać tetrimino w poziomie oraz może obracać go ze skokiem 90°. Obracanie (rotacja) aktywnych tetrimino i poziome przesuwanie w trakcie ich spadania jest podstawową aktywnością, dzięki której gracz może sterować przebiegiem gry. Podczas obracania, w zależności od rodzaju tetrimino można wybrać jedną spośród czterech pozycji dla kształtów T, 80 Szymon Nalikowski, Walery Susłow L, J oraz jedną spośród dwóch pozycji dla kształtów S i Z. Wyjątek stanowi tetrimino O, który się nie obraca, różnice w liczbie dostępnych pozycji wynikają z liczby osi symetrii danego kształtu. Rys. 2. Schemat tetrimino L do sterowania rotacją i wykrycia kolizji Na rysunku 2 został przedstawiony użyty w projekcie schemat tetrimino L we wszystkich możliwych pozycjach, aby zilustrować terminologię niezbędną do programowania akcji obracania oraz do rozstrzygnięcia kolizji związanych z ruchem obrotowym i liniowym tego kształtu. Na schemacie został zaznaczony kwadrat, który nie zmienia pozycji podczas obrotu tetrimino – wokół niego następuje rotacja. Racjonalnym wyborem przy przeliczaniu pozycji kształtu podczas rotacji jest umieszczenie centrum współrzędnych właśnie na środku danego kwadratu (x, y). Wtedy pozycje pozostałych kwadratów będą opisane za pomocą odpowiednich par współrzędnych, np. w pierwszej pozycji pozostałym kwadratom, tworzącym tetrimino L, odpowiadają następujące współrzędne: (x-1, y), (x+1, y) i (x-1, y+1). Na schemacie oznaczone są również pozycje kolizyjne. Pozycje te oddalone są o jeden kwadrat w każdym kierunku od najbardziej wysuniętych kwadratów Podejście konceptualne podstawą skuteczności programisty… 81 tworzących aktywne tetrimino. Przyjęte na schemacie skrótowe oznaczenia możliwych kolizji są naniesione na odpowiednie kwadraty i oznaczają: ky – kolizja występująca wzdłuż osi y, kxl – kolizja występująca wzdłuż osi x po lewej stronie tetrimino, kxp – kolizja występująca wzdłuż osi x po prawej stronie tetrimino, kobr – kolizja występująca przy obrocie tetrimino. Obsługa wymienionych kolizji polega na tym, że po wykryciu którejkolwiek z nich tetrimino zostaje na swojej dotychczasowej pozycji i przy swojej dotychczasowej orientacji wbrew rozkazom gracza, czyli akcja przesunięcia w poziomie czy rotacji nie zostaje wykonana. 3.2. Analiza konceptualna gry Tetris Główne terminy opisujące statyczną konstrukcję gry Tetris zostały zaprezentowane w postaci mapy pojęć na rysunku 3. Mapa koncentruje się wokół trzech oryginalnych terminów: tetris – nazwa całej gry oraz jednocześnie nazwa zdarzenia odpowiadającego jednorazowemu ułożeniu przez gracza czterech pełnych rzędów (najwyższa punktacja), tetrion – plansza-studnia i tetrimino – kształty do gry, odpowiedniki pionów z tradycyjnych gier planszowych. Rys. 3. Mapa głównych pojęć dot. konstrukcji wizualnej gry Tetris 82 Szymon Nalikowski, Walery Susłow Warto zwrócić uwagę na to, że związki pojęć tetriminopiony oraz tetrionstudnia są niezbędne, aby usprawiedliwić metaforycznie złożone zachowanie tych obiektów, niezgodne całkiem z zachowaniem (odpowiednio) planszy i kształtu geometrycznego. Do opisu dynamiki gry Tetris zdefiniowano szereg dodatkowych pojęć, takich jak: miękki lub twardy upadek – odpowiadają akcji przyśpieszonego lub natychmiastowego zrzucenia tetrimino na dół planszy, opóźnione automatyczne przesunięcie – opisuje opcję automatycznego horyzontalnego przesuwania się tetrimino do momentu wykrycia kolizji, opóźnienie blokady – opisuje opcję opóźnienia unieruchomienia tetrimino po opadnięciu, daje to szansę graczowi na przesunięcie tetrimino horyzontalnie, gdy kształt już leży na dole planszy, opóźnienie generacji tetrimino – opisuje opcję opóźnienia pojawiania się nowego tetrimino na planszy w stosunku do momentu blokady spadającego tetrimino. Słownictwo niezbędne do określenia funkcjonalności gry w tetrisa można zaprezentować poprzez diagram przypadków użycia przedstawiony na rysunku 4. Łatwo zauważyć, że w tej perspektywie występuje zupełny brak specyficznych pojęć w odróżnieniu od perspektyw konstruktywnych. Rys. 4. Diagram przypadków użycia oprogramowania do wspomagania turnieju gry w tetrisa Podejście konceptualne podstawą skuteczności programisty… 83 3.3. Terminologia implementacyjna Zgodnie z hipotezą, autorzy przeprowadzili analizę porównawczą pojęć użytych do określenia elementów gry w tetrisa na różnych etapach pracy nad projektem. Najbardziej istotne składowe tej analizy zostały zestawione w tabeli 1. Istotnym szczegółem technicznym jest to, że projekt został zaimplementowany w ramach paradygmatu obiektowego na platformie Java [7-9]. Tab. 1. Zestawienie nazw użytych w różnych perspektywach projektu gry Koncept (perspektywa modelu konceptualnego) Nazwa użytkowa (perspektywa analizy domeny problemowej) Tetrimino klocek, tetrimino: S, Z, I, L, J, O, T, kształt klocka, kształty geometryczne, Kwadrat Blok, pomniejszy kwadrat Tetrion Prostokątny pojemnik, pojemnik, plansza, studnia, tetrion, matrkis, macierz Rząd pozioma linia Wypełniony rząd nieprzerwana pozioma linia, poziome linie bez pustych miejsc, linia bloków boolean zapelnieniePoziome; Czyszczenie rzędu skasowaniu linii, usunięcie/usuwanie linii public void czyscLinie(int tablica[ ][ ], int rzad) Spadanie spadanie, opad klocka public void opadaj (int tablica[ ][ ], int predkosc) Prędkość spadania grawitacja, siła grawitacji, prędkość opadania, prędkość opadu klocka Miękki upadek (Soft drop) wzrost siły grawitacji, chwilowe przyspieszenie spadania klocka Identyfikator w kodzie (perspektywa implementacyjna) Klocek (klasa), KlocekA…KlocekG (klasy), private Klocek aktywnyKlocek; private Klocek nastepnyKlocek; wartość 0 lub 1 w tablicy int[ ][ ], przy rysowaniu: rozmiarBlokuPustego, rozmiarBlokuPelnego, kolorBlokuPustego, kolorBlokuPelnego Plansza (klasa) Plansza plansza Plansza planszaA, Plansza planszaB private int iloscUsunietychLinii=0; /*wartość pomocnicza przy obliczaniu punktów kasowana przy każdym sprawdzaniu*/ private int iloscPustychLinii=0; private int sumaUsunietychLiniiPlanszy=0; /*przy podliczaniu*/ private int predkoscOpaduKlocka; private JSlider sliderPredkoscOpaduKlockow; /*w opcjach*/ protected long opoznieniePrzyspieszonegoOpadu; protected long ostatniCzasPrzyspieszonegoOpadniecia = System.currentTimeMillis(); 84 Szymon Nalikowski, Walery Susłow 4. Dyskusja Analizując dane przedstawione w tabeli 1 łatwo zauważyć, że na różnych etapach pracy nad projektem oprogramowania niejednokrotnie użyto nazw opisujących ten sam konstrukcyjny element, ale różniących się między sobą tak w perspektywie analizy domeny problemowej jak i w perspektywie implementacyjnej. Weźmy na przykład element konstrukcji gry, jakim jest tetrion. Takie określenie winno się znaleźć we wszystkich perspektywach. W perspektywie analizy domeny problemowej naprzemienne używane są nazwy prostokątnego pojemnika, pojemnika, planszy, studni, tetrionu, matriksu oraz macierzy. Natomiast w perspektywie developera tetrion określany jest mianem planszy. Nazwy elementów kodu planszaA czy planszaB mogą być logiczne dla programisty, natomiast dla wielu interesariuszy mogą stanowić problem w zrozumieniu, do czego dokładnie służy ten element. Bardziej na miejscu było by użycie opisu takiego jak np. tetrionGraczaA, tetrionGraczaB. Ciekawe spostrzeżenia wynikają mianowicie z analizy na wskroś unikatowych dla danej gry pojęć – tetrion i tetrimino. Brak odniesień danych pojęć do rzeczywistości był uzupełniany na różnych etapach pracy nad oprogramowaniem za pomocą określeń metaforycznych. Tak tetrion oprócz planszy był przedstawiany jako studnia, gdy trzeba było analizować pionowy ruch tetrimino. Ale głębsza analiza pozwala wykryć ograniczone użycie metafory studni, bo przy programowaniu zdarzenia miękki upadek koder użył uproszczonego wzoru na ruch jednostajny zamiast wzoru na ruch jednostajnie przyśpieszony, co byłoby zgodne z mechaniką rzeczywistą. To samo niepełne użycie metafory pionu-klockakształtu można zauważyć na przykładzie tetrimino, tak przy kodowaniu akcji obrotu tetrimino został potraktowany jako giętki obiekt, stąd usterki w zaznaczeniu pól kolizyjnych na rysunku 2, na przykład w rzędzie X+2 nie są zaznaczone pola od X-1 do X+1 istotne przy obrocie od pozycji 0 do pozycji 1. Naszym zdaniem jest to skutek uboczny braku stabilnych, powszechnych i jednoznacznych pojęć na określenie bytów wirtualnych, jakimi są tetrion i tetrimino. A z drugiej strony podobne sytuacje są nieuniknione przy projektowaniu gier komputerowych, bo sama ich istota polega na tworzeniu światów wirtualnych, bajkowych, pozostaje istotne pytanie: na ile te światy mogą naruszać zasady fizyki i logiki, aby gra pozostawała atrakcyjna oraz bezpieczna dla odbiorcy? Jasno sprecyzowana i dobrze dobrana przez uczestników projektu nazwa każdego z elementów jeszcze na etapie analizy domeny problemowej oraz specyfikacji wymagań skutkowałaby na etapie kodowania skróceniem czasu potrzebnego do precyzyjnego opisania wirtualnego świata bez niedomówień. Oszczędziłoby to zespołowi zbędnych tłumaczeń wyjaśniających: „co autor miał na Podejście konceptualne podstawą skuteczności programisty… 85 myśli”, które mogą prowadzić do niepotrzebnych napięć między jego członkami. Podczas pisania kodu nie ma wtedy potrzeby analizować każdy kolejny nowy element, jaką pełni funkcję, jakie ma specyficzne właściwości, a bardziej można ufać intuicji prowadzącej programistę zgodnie z semantyką użytej nazwy. Użycie w pracy wielu nazw na określenie tego samego elementu gry ma negatywny wpływ na jakość oprogramowania [10]. Niejednoznaczne, niejasne lub występujące pod wieloma nazwami elementy mogą prowadzić do niestabilności programu, przy większej ilości kodu i gdy pracuje nad nim więcej niż jedna osoba. A nawet i w zespole jednoosobowym wadliwa terminologia może skutkować wadliwym kodem. Za przykład możemy wziąć zjawisko wykrywania kolizji w tetrisie, do zaprogramowania którego trzeba posiadać właściwą metaforę ruchu obrotowego i liniowego na planszy. Ważne jest również, by od początku prac projektowych użyć unikalnej, szczegółowej i logicznej nazwy opisującej każdy z elementów, ponieważ w późniejszych etapach pisania kodu może pojawić się problem powielania elementów, na przykład tworzenia rodziny obiektów powiązanych relacją dziedziczenia, a nowe obiekty mogą pełnić bardzo podobną role, co ich rodzicewzorce. Przy bardziej ogólnym określeniu pierwotnego elementu zachodzi potrzeba refaktoryzacji kodu, co ponownie prowadzi do wydłużenia czasu powstania finalnego produktu i może generować niepotrzebne koszty. 5. Podsumowanie Reasumując, przy tworzeniu oprogramowania niezwykle ważne jest stosowanie podejścia pojęciowego tak przy budowie oprogramowania, jak i przy komunikacji z innymi członkami zespołu projektowego. Taki zabieg prowadzi do bardziej efektywnego wykorzystania zasobów ludzkich zespołu. Jasno sprecyzowane cele oraz określenia nazw (pojęć, terminów) do wszystkich elementów przed przystąpieniem do pisania kodu i dokumentacji zaoszczędzają wiele nieporozumień prowadzących do napięć w zespole jak i skracają czas wykonania zadań. Autorowi analizowanej gry udało się ukończyć projekt w terminie, ponieważ kod był pisany w pojedynkę. Jednakże gdyby zespół był większy, wiele czasu zajęłaby komunikacja niezbędna do zrozumienia logiki zastosowanych określeń poszczególnych metod oraz pozostałych elementów w szczególności w związku z tym, że różnią się one między sobą zarówno w analizie domeny problemowej jak i w kodzie. 86 Szymon Nalikowski, Walery Susłow Literatura 1. 2. Adams E., Projektowanie gier. Podstawy. Wyd. Helion, Gliwice 2011. Susłow W., Analiza i modelowanie konceptualne w inżynierii systemów oprogramowania – ujęcie humanistyczne, Monografia nr 234, Wydział Elektroniki i Informatyki, Wydawnictwo Uczelniane Politechniki Koszalińskiej, Koszalin 2013. 3. Susłow W., Podejście pojęciowe do usprawnienia komunikacji w rozproszonych zespołach IT. W: Informatyczne systemy zarządzania (wybrane zastosowania), t. 3., red. Krzysztof Bzdyra, Wydawnictwo Uczelniane Politechniki Koszalińskiej, Koszalin 2012, s.103-118. 4. Gerasimov V., Tetris Story, http://vadim.oversigma.com/Tetris.htm 5. The Tetris saga the history of the game, from its original conceiving to the climax of the Nintendo/Tengen battle, http://www.atarihq.com/tsr/special/tetrishist.html 6. Kluska B., Dawno temu w grach. Czas pionierów. Szkice z historii gier komputerowych. Inicjatywa Wydawnicza ORKA, Łódź 2008. 7. [Java] tetris początek na Polish Elite board, http://peb.pl/programowanie/691043-java-tetris-pocz-tek.html 8. Horstmann C., Cornell G., Java 2. Podstawy. Wyd. Helion 2003. 9. Szuba G., Tetris 2D. Projekt apletu graficznego do gry w Tetrisa dwuwymiarowego. http://grzegorzszuba.republika.pl/ 10. Martin R., Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall PTR. 2008.
