Wpadłem w pułapkę.
Kiedy wszystko wiadomo nie opłaca się tego opisywać. Szkoda czasu, bo i po co systematyzować już usystematyzowaną wiedzę? By zapisać kolejne strony nic nie znaczących słów, zostawiając tylko czarne ślady atramentu na papierze? Zawsze, kiedy dotykam piórem papieru obawiam się, że oto ze stalówki spłynie ten dziecinny ból, małego skrzywdzonego dziecka, przemycając w każdym zdaniu ślad goryczy, każdy niestarannie postawiony czarny znak będzie pokrywał arkusz, niczym strup ukrywający pod sobą dawną ranę. Tyle, że pewnych rzeczy nie można zrobić, bez usystematyzowania już uporządkowanej wiedzy. W sytuacji, gdy cała wiedza wyryta jest w bruzdach mojego mózgu nagle okazuje się, jak bardzo płynnym zjawiskiem jest zmagazynowana w ten sposób informacja, w pewnych wypadkach ten cudowny proces transmutacji wiedzy w niewiedzę może być bardzo zajmujący. A jego obserwowanie dosyć zabawne.
Jednak nie zawsze.
Dawno temu, kiedy jeszcze męczyłem się z Final Fantasy 13, a moi przyjaciele byli w dupie ze studiami obiecałem coś kumplowi w formie zakładu. 24 godziny na napisanie prostej rzeczy. Banalne. Wyzwaniem jednak okazało się samo przystąpienie do pisana. Wiem wszystko, więc nie wiem niczego. Od czego zacząć w sytuacji, gdy stan mojej wiedzy przypomina stan przypisywany kotu Schrödingera?
Nie jestem ani pierwszą, ani ostatnią osobą, która stoi przed takim dylematem, w końcu hasła pokroju “Think first… code later” skądś musiały się wziąć. Odpowiedzią na ten dylemat jest oczywiście służący do modelowania różnego rodzaju systemów UML, oraz wszelkiego rodzaju specyfikacje. Jednak znowu problem, co powinna zawierać dobra specyfikacja? W momencie, kiedy piszemy grę nie będącą programem na zamówienie zdaje się odpadać analiza sytuacji metodą SPIN, chyba że miałaby powstać jako wyjście, na którym budowane będą kolejne niesamowite elementy systemu. Oczywiście wewnątrz znaleźć można sporo ciekawych rzeczy znajdujących własne zastosowanie. Kwestią jest jednak zawsze kolejność.
Jako osoba związana nie tyle z samym tworzeniem światów, co opisywaniem zasad rządzących nimi, zawsze główną uwagę zwracałem na diagram klas. Choćby dlatego, iż zawiera model najbliższy mojej pracy. Model wartych zaimplementowania klas, powiązań między nimi. Tutaj czeka kolejna pułapka. Jakkolwiek programowanie obiektowe mocno zmieniło sposób projektowania aplikacji, przestawiając myślenie z mocno podejrzanego strukturalnego, na bardziej “swojskie” obiektowe, nadal jest to rozważanie bardziej ukierunkowane na modelowanie jasno określonych wymagań, na coś takiego można sobie pozwolić jednak tylko wtedy, gdy piszemy niewielki pogram, na przykład na zaliczenie, gdy w temacie pracy mamy dokładnie podane wszystkie funkcjonalności. Jeśli jednak czegoś takiego nie ma, albo nie jesteśmy pewni czy wszystko zawrzemy w swoim modelu, warto posiłkować się różnymi diagramami UML, nie tylko diagramem klas.
Dlatego na początek postanowiłem sporządzić w miarę poprawną dokumentację, obiecanego dawno, dawno temu Dan’owi programu. Przyznam upubliczniam ją głównie dla niego, choć nie sądzę by kiedykolwiek jeszcze tu zajrzał. Pytanie jednak od czego zacząć? Najmędrsi zawsze powiedzą “od początku”, gdzie on się jednak znajduje? Zapewne w opisie funkcjonalności.
Dawno, dawno temu opisałem podstawy pac-mana, razem z uroczo brzmiącymi imionami duszków, czy celem gry. Tylko, czy to wystarczy?
Podstawową funkcjonalnością całej gry jest oczywiście umożliwienie przeprowadzenia rozgrywki. To jasne, jak słońce, jednakże na czym polega sama rozgrywka?
Zasada działania gry:
Cóż, gdyby to były inne czasy nie trzeba by tego chyba nawet tłumaczyć. Niestety świat poszedł do przodu.
Rozgrywka polega na prostej rywalizacji pomiędzy graczem, oraz komputerem:
Na planszy złożonej, ze skończonej liczby pól (powiedzmy width, height), znajduje się określona ilość kropek, oraz nazwijmy to pigułek, dających na pewien czas super moc. Poruszają się po niej również dwa typy istot, tytułowy Pac-man, oraz cztery duszki.
Rozgrywka toczy się do momentu, kiedy gracz zje wszystkie kulki, bądź duszki zjedzą gracza pewną, narzuconą ilość razy.
Założenia
- Kontakt gracza z duszkiem przez większość czasu powoduje śmierć gracza. Wyjątkiem jest sytuacja, w której gracz znajduje się pod wpływem pigułek.
- Kontakt ze ścianą zatrzymuje i gracza i duszki.
- Kontakt gracza z kulką powoduje zjedzenie kulki i zwiększenie liczby punktów.
- Kontakt gracza z pigułką powoduje przekręcenie licznika i pozwolenie na zjadanie duszków.
- Każda kolejna pigułka odnawia licznik.
- Gdy licznik dojdzie do zera duszki znów zjadają gracza.
- Od czasu do czasu na planszy pojawia się specjalny owoc dający bonus punktów.
- Zjedzony duszek odradza się w specjalnym miejscu na planszy.
- Każdym z duszków kieruje inny algorytm:
+ Blinky próbuje podążać za graczem,
+ Pinky próbuje zajść graczowi drogę,
+ Inky próbuje zajść graczowi drogę, jednak jego celem jest podążanie ‘za bratem’ (trzyma się z tyłu w stosunku do niego)
+ Clyde powinien poruszać się losowo.