GoniecRM

Warsztat pracy

Obserwując drużynowe zapędy niektórych twórców, nie trudno dojść do wniosku, że na ogół gry tworzone grupowo nie dochodzą do skutku. Poza scenowymi sukcesami takimi jak Exogenesis, za przykład nieudanego przedsięwzięcia można uznać m.in. Najemnika czy zapowiadanego przeszło 4 lata temu Life of Gangster. Podobne aspiracje wykazywali swego czasu użytkownicy UF, jednak nie przetrzymały one próby czasu i wielu ujawniających się w trakcie tworzenia problemów. Każdy grupowy projekt powinien bowiem charakteryzować się starannym podziałem obowiązków, a przede wszystkim posiadać zorganizowanego koordynatora działań. Dlatego właśnie każdemu z projektów TagTeam patronuje inna osoba, która tworzy całą otoczkę, rozdziela pracę, sugeruje mechanikę (albo przyjmuje pomysł innego członka grupy) i jakkolwiek sposób ten wygląda na wyidealizowany, w praktyce okazuje się zbawienny. Ze względu na mój zespołowy charakter prac, chciałabym pokrótce przedstawiać, w jaki sposób rozkłada się podział obowiązków przy tworzeniu gier przez grupę TagTeam oraz podzielić się kilkoma uwagami na temat zadań, za których realizację zazwyczaj odpowiadam osobiście.

Współpraca
Praca TagTeam rozpoczyna się od tzw. „rzucenia hasłem” przez Lartarin, gdyż to właśnie ona wymyśla podłoże gier, czyli jest iskrą działań. Opisuje m.in. jaką grę można by zrobić (jej główny wątek) i – co najważniejsze – w jakich klimatach będzie. Często dochodzi do sytuacji, że sama zaczyna tworzyć, stopniowo zapoznając, coraz to nowe osoby, ze specyfiką projektu. Gdy pomysł zostanie przyjęty przez grupę, dochodzi do ustalenia wspomnianego wcześniej koordynatora działań oraz do podziału obowiązków. Zazwyczaj schemat jest ten sam:
- za fabułę, mapy (poza tworzonym Systemem II) i dobór muzyki odpowiada Lartarin, niekiedy wspomagana przez innego członka TagTeam lub osobę spoza grupy,
- za mechanikę walki, bazę danych (bestie) i trudność gry odpowiada Seivoth,
- za skrypty, system menu i inne sprawy graficzne odpowiadam ja,
- współpracujące również z TagTeam – SaE i Ozzma odpowiadały za część dialogów i efekty dźwiękowe.
Oczywiście fakt, że znamy się i spotykamy prywatnie jest kluczowym, jeśli chodzi o współpracę. Tworzymy jednak we własnych domach, starając się nie wkraczać na pole działań drugiej osoby. Niestety są to ograniczenia, których nie da się uniknąć zważywszy na fakt, że uniemożliwiłoby to poprawne połączenie projektów. Łączeniem bazy danych i materiałów zajmuje się koordynator tak często, jak to tylko możliwe. Pomocne na tym etapie jest częste wykonywanie kopii zapasowych oraz umieszczenie w nazwie folderu z grą daty jej ostatniej aktualizacji. Dzięki temu też widać, jak systematycznie idą prace nad projektem.

Realia i wątek fabularny
Ustalanie realiów gry nie sprawia nam większego problemu, gdyż wszystkie nasze projekty nawiązują do gry fabularnej czerpiącej z takich tytułów jak Warhammer czy Kryształy Czasu. Stworzony – przez lata wcielania się w różne postaci – świat jest na tyle zarysowany i rozległy, że można w nim dowolnie umieścić każdy wątek fabularny, od walki z potężną kreaturą z 11 roku, po luźny turniej w barze Stukoczące Kopytka. Użyczone na potrzeby gry postaci, to najczęściej bohaterowie graczy lub bohaterowie niezależni, a ich zachowanie jest po prostu odzwierciedleniem indywidualnych cech charakteru.
Pomysł na fabułę przychodzi wraz z ustaleniem jakiego rodzaju ma być projekt. W przypadku Pustkowi Chaosu, nastawionych przede wszystkim na walkę, fabuła z założenia miała być prosta, przedstawiać chaotyczność osób, opisywać niecodzienne historie napotkanych przeciwników, ogółem opowiadać historię świata z „Roku Mistyka”. Shikima mająca treści niecenzuralne z pogranicza filmów dla dorosłych (tak, to eufemizm) z kolei została ulokowana w świecie rządzonym przez kobiety, które funkcję mężczyzn zepchnęły do roli zapładniaczy. Była dużo bardziej nastawiona na akcję i kreację świata za pomocą zachowania bohaterów. W obu tych przypadkach fabuła powstała w przeciągu kilku minut, nie była nigdzie spisywana, a kolejne wątki dodawane były na bieżąco. Nieco inny schemat pozwoliliśmy sobie zastosować w Systemie 2, przy tworzeniu którego spisaliśmy wszystkie najważniejsze wydarzenia i podzieliliśmy je kolejno na etapy. Zobaczymy, co z tego wyjdzie…

Mapy
Dobór tilesetów, do chwili przejęcia kierownictwa nad Systemem 2, nie był w mojej gestii. Jak w pierwszej części gry wygląd map był sprawą dwudziestorzędną, tak w kolejnych projektach coraz więcej uwagi przykładaliśmy do ich „ładności”. Znaczący wpływ na zmianę naszego podejścia miała krytyka pierwszej części, choć nadal pod adresem TagTeam kierowane są zarzuty co do wyglądu lokacji. Wychodzimy z założenia, że najważniejsza jest grywalność, a styl ułożenia kwiatków na polance to jedynie względnie przyjemny dodatek. Za sukces uznajemy mapy, które nie wyglądają, jak poniższa ;)


Mapa z pierwszej części – jaskinia Bitito :P

Skrypty
Ta część przypisanych zadań sprawia mi najwięcej radości. Zdecydowanie nie reprezentuję tutaj starej szkoły tworzenia wszystkiego na zdarzeniach. Swoją pracę rozpoczynam od grupowania klas w edytorze i odpowiedniej selekcji dostępnych w sieci skryptów. Ze względu na wysokie ryzyko braku kompatybilności, użyte w projekcie skrypty łączę z domyślnymi w taki sposób, że doklejam odpowiednie linijki kodu do istniejących już klas lub definicji. Dzięki temu udaje mi się uniknąć sytuacji nadpisywania się definicji (nie każdy skrypt można aliasować, czyt. dodawać nowe fragmenty kodu nie zmieniając oryginalnej jego formy). Dopiero po przejrzeniu istniejących już zasobów, biorę się za pisanie własnych skryptów, które podobnie jak wyżej „wpinam” w istniejące już klasy. Użyta przeze mnie metoda wymaga jednak względnej orientacji w klasach RGSS(2/3). Dla osób ze słabą pamięcią, proponuję znakowanie nazw modyfikowanych klas w pasku po lewej stronie, np. kilkoma znakami „/”.

Pogrupowane skrypty w Systemie 2. Na czerwono zaznaczony sposób znakowania modyfikacji domyślnej klasy w RGSS.

Z mojego punktu widzenia, jednym z ważniejszych elementów gry jest system menusów, na którego stworzenie poświęcam mnóstwo czasu (zaprojektowanie i oskryptowanie menu w Pustkowiach zajęło prawie tydzień). W sieci dostępnych jest już tyle poradników skryptowania, że przy odrobinie chęci i pracy można wzbogacić grę o własną kompozycję menu, co niewątpliwie nada jej atrakcyjności. Warto na tym etapie sięgnąć do najprostszej techniki kartki i ołówka, by w szybki sposób zarysować wygląd menu, a następnie używając wybranych oprogramowań graficznych, wykonać najpotrzebniejsze elementy tj. tło, paski, awatary postaci. O czym nie można zapomnieć? O dostosowaniu stylu menu do rodzaju i klimatu gry. Groteskowo bowiem wyglądać mogą metalowe zakładki i koła zębate w symulacji wiejskiego życia, czy serduszkowe akcenty w grze o tematyce postapokaliptycznej.

Projekt ekranu tytułowego aktualnie tworzonej „Areny” – gry stylizowanej na arkadowe bijatyki 2D.

Mechanika
Jestem gorącą zwolenniczką wyboru przez gracza poziomu trudności, o co nierzadko dochodziło do sprzeczek w grupie. W grze fabularnej według mnie optymalnym poziomem trudności powinien być łatwy, wybrany system walki – niezbyt wymagający, rozwój bohatera – szybki, zaś częstotliwość wypadania przedmiotów za pokonane bestie – wysoka. W mojej ocenie bowiem walka jest jedynie dodatkiem do gry, który z zasady ma ją jedynie wydłużyć. Wspomniane rozwiązanie z wyborem poziomu trudności przeciwników pozwoliłoby zatrzymać przy grze również graczy ambitniejszych. Życie pokazało mi jednak, że nawet taka opcja nie daje gwarancji, że gracz trafnie oceni swoje umiejętności i sprosta nawet „kulawym” przeciwnikom.

Dodatkowe wskazówki
1. Dobrą formą autoreklamy może być umieszczenie w aktualnie tworzonym projekcie zapowiedzi przyszłych gier. Forma prezentacji nie musi być rozbudowana – kilka screenów i krótka informacja wystarczy.
     2. Nie zapominajmy o wykazie wszystkich osób współpracujących przy grze lub będących autorami użytych materiałów. Poza przyjętym obowiązkiem jest to również forma podziękowania za pomoc.
     3. Ostatnio modne stało się tworzenie „profesjonalnych” plików instalacyjnych gier, co niekoniecznie w mojej ocenie jest dobrym pomysłem. Wystarczy tutaj plik tworzony domyślenie przez RM i ewentualna zmiana ikony za pomocą programu „ResHacker”.
     4. Dołączenie wszystkich grafik RTP może nie jest wymagającą czynnością, lecz niestety nieużywane w większości materiały jedynie sztucznie zwiększają „wagę” projektu. Najefektywniejsze, choć czasochłonne, jest wyłączenie RTP w programie, sprawdzanie w teście, których zasobów brakuje i wklejanie ich do folderu z grą. Zdecydowanie odradzam twórcom wymuszanie na potencjalnych graczach własnoręcznej instalacji RTP.

Myśl końcowa
Na zakończenie swoich wywodów chciałabym podzielić się jeszcze jedną myślą… Gry jakie wyszły do tej pory spod naszej ręki, jak i te które zapewne wyjdą, tworzymy hobbistycznie, z dala od postawionych na scenie wymagań. Cieszą nas pochlebne komentarze, nie martwią nadto krytyczne. Choć nie wszystkie gry się podobają, ze wszystkich jesteśmy tak samo dumni. I tego życzę osobom, które dotarły do niniejszego zdania ;)