W przypadku dużych projektów nad kodem programu pracuje nie tylko wielu programistów ale wiele zespołów. To co jest w przypadku takiego projektu bardzo istotne, to możliwość równoległego prowadzenia prac. Nasz program nie jest aż tak złożony, jednak warto zastanowić się nad tym co możemy obecnie zrobić i przygotować sobie plan prac. Jeśli mamy możliwość zorganizowania grupy, możemy się nawet pobawić w specjalizację i popracować razem.

To co mamy pozwala na granie. Co prawda musimy przygotować sobie scenariusz gry, i wstawić go do kodu programu, ale sam scenariusz jest obecnie niezależny. Mamy bardzo prosty interfejs użytkownika który pozwala na wydawanie poleceń, przez co można przećwiczyć zaprojektowaną grę. Mamy także podstawowy silnik gry pracujący na danych przechowywanych w pamięci. Niby coś mamy, ale wciąż nie jest to gra jaką można zaprezentować szerszemu odbiorcy. Czego potrzebujemy?

Na pewno potrzebujemy jakiegoś bardziej złożonego scenariusza. Warto nad nim popracować i przygotować grę w której gracz będzie miał wiele możliwości wykonywania różnych czynności prowadzących do wygranej lub porażki, lub jeszcze lepiej – do nich przybliżające. Jeśli nie mamy wystarczająco dużo wyobraźni możemy przygotować jakiś znany scenariusz dodając do niego boczne ścieżki. Może to być jedna z popularnych bajek lub książek, a może to być przygoda jaką przeżywał jakiś wynalazca lub naukowiec – bo nasza gra może także uczyć służąc do przygotowania ciekawych lekcji. Czeka nas więc rozpisanie wybranej przygody na lokację przedmioty i akcje tak by gracz mógł osiągnąć cel gry nie będąc prowadzonym za rękę.

Interfejs użytkownika jest dość ubogi i warto byłoby zadbać o jakąkolwiek grafikę. Nie musi to być animacja (choć byłoby miło), ale statyczna grafika pokazująca lokację i znajdujące się w niej przedmioty – to absolutna konieczność. Wymaga to rozbudowy opisu danych o nazwy ilustracji lub elementów składowych oraz ich położeń. A także ilustracji które są grupami takich elementów.

Przy większym scenariuszu nie powinniśmy trzymać go w pamięci. Na razie gramy sami mając do dyspozycji całą moc serwera WWW, ale gdy graczy będzie więcej – zajęcie pamięci może być zbyt duże. Dlatego warto umieścić całość gry w bazie danych a do pamięci ładować tylko to co jest w danej chwili niezbędne. Dodatkowo pozwoli to na dzielenie obszaru gry pomiędzy graczy wprowadzając dodatkowy element konkurencji (na przykład o przedmioty).

Jeśli myślimy o wielu graczach którzy mogą zabierać przedmioty z lokacji – to warto zadbać o ich pojawianie się. Potrzebne będą nam przedmioty które co prawda znajdują się w jakiejś lokalizacji, ale ich ilość zależy od tego kiedy ostatnio taki przedmiot zabraliśmy.

Jak widać mamy tu cztery obszary które mogą być niezależnie rozbudowywane. Na każdym froncie robót możemy korzystać z dotychczasowego kodu, i dopiero gdy pewien etap będzie gotowy – integrujemy go z całością programu, tak by i inne zespoły mogły z niego korzystać a raczej go dokładnie przetestować w czasie prób uruchamiania własnej funkcjonalności. Jeśli nad programem pracujemy samodzielnie, lub gdy mamy do dyspozycji mniej zespołów niż kierunków rozwoju – warto przygotować sobie plan pracy obejmujący to co i w jakiej kolejności będziemy przygotowywać. Nasz plan mógłby wyglądać następująco:

1. Przeniesienie gry do bazy danych – na razie pracujemy testowo z jednym graczem, więc nie piszemy „odradzania” się przedmiotów
2. Dodanie stromy która pozwoli na dodawanie elementów gry do istniejącej bazy. Na razie cały scenariusz był pakowany do jednego skryptu, ale scenariusze mogą się przenikać a przedmioty mogą być używane w różnych sytuacjach i scenariuszach.
3. Dodanie prostej grafiki – zbiór predefiniowanych elementów (gotowe rysunki) oraz zmiana interfejsu tak, by można było tą grafikę wyświetlać.
4. Respawn przedmiotów – modyfikacja silnika gry tak by przedmioty mogły się odradzać.

Każdy z tych punktów odpowiada pewnej funkcjonalności, ale niewiele mówi o tym jak tą funkcjonalność zrealizować. Zanim zabierzemy się do kodowania, powinniśmy rozpisać każdy z realizowanych punktów na zadania które są na tyle proste, że ich implementacja nie będzie niosła specjalnych wyzwań. W przypadku pierwszego punktu dotyczącego bazy danych zadania mogą wyglądać tak:

• Połączenie się z serwerem bazy danych
• Przygotowanie tabel w bazie
• Przygotowanie zapytania które zwróci
• przedmiot o zadanej nazwie
• lokację o zadanej nazwie
• akcję
• Przygotowanie modyfikacji bazy
• dodawanie lokacji
• dodawanie przedmiotów
• dodawanie akcji do przedmiotów i lokacji
• Zmiana metod konstruujących przedmioty tak by pobierać je z bazy
• Modyfikacja klasy realm tak by pobierać lokację z bazy.
• Zapamiętanie stanu gracza w bazie danych.

Przygotowując listę zadań zastanawiamy się od razu nad tym co i jak będziemy pisać. Mimo, że nie piszemy ani linijki kodu – to właśnie tu jesteśmy najbardziej produktywni. To teraz jest miejsce na zastanowienie się nad potrzebnymi elementami programu i sposobem pisania który wymaga jak najmniejszych zmian kodu który już istnieje. Zauważmy, że jeśli dobrze przemyślimy plan pracy – to potem jest łatwiej.

Plan pracy nie jest stały. Modyfikujemy go jeśli tylko przyjdzie to nam do głowy. Możemy dodać punkty o których zapomnieliśmy. Na przykład takie:

• Modyfikacja buildera gry tak by wynik analizy scenariusza zapisywał w bazie danych.
• Restart gry – jeśli dane gracza są w bazie, to po ponownym wejściu do gry trafia tam gdzie był. Musi istnieć możliwość, choćby w celach testowych by wrócić na początek.

Przygotowanie takiej listy zadań bardzo pomaga w pisaniu kodu. Z jednej strony niczego nie zapomnimy, z drugiej, wiemy co zostało zrobione i jak działa, jeśli tylko będziemy ją na bieżąco aktualizować zaznaczając które zadania są już zrealizowane. Jest to szczególnie przydatne gdy pracujemy nad różnymi funkcjonalnościami w tym samym czasie. Warto też na bieżąco notować na tej liście pomysły jeśli tylko jakieś się pojawią, nawet jeśli ich realizacja jest wątpliwa lub nie jest przewidziana w bieżącej wersji.

Czytelnik z pewnością zauważył, że to co będziemy robić – to modyfikacje działającego programu. W większości kursów programowania ten etap się pomija mimo, że w praktyce programistycznej właśnie modyfikacja zajmuje ogromną większość czasu. A to co w modyfikacji jest najważniejsze – to by czegoś po drodze nie zepsuć. Jeśli nie będziemy mieć pewności że wszystko co działało nadal działa – możemy się obawiać przeróbek. Dlatego jesteśmy już na etapie na którym należy do naszego projektu włączyć bardzo ważny element: testy.

Trudno będzie nam przygotować testy w których będziemy coś wyklikiwać korzystając z interfejsu użytkownika, ale przecież nasz program posiada silnik który przyjmuje polecenia, a te możemy już bez problemu wydawać z programu. Dlatego w następnej części kursy oprócz realizacji połączenia z bazą danych przygotujemy sobie proste środowisko testowe pozwalające na upewnienie się, że to z czym pracujemy – nadal działa