„Mierz siły na zamiary”
Napisanie własnej gry (ale i nie tylko, bo to, co tu opiszę, może dotyczyć czegokolwiek) to nie taka prosta sprawa jakby się mogło wydawać.
Najważniejszym w tym wszystkim jest pomysł. Często jest tak, że ktoś sobie myśli: programować jakoś tam umiem to sobie napiszę. O.K., tylko jaką?
Najlepszym moim zdaniem pretekstem do napisania gry jest pomysł, który chodzi nam w głowie od dawna. Przez co dojrzewa i nabiera jakiegoś kształtu.
Jeśli już wiemy czego chcemy możemy przystąpić do realizacji swojego pomysłu. Jednak tu na przeszkodzie mogą stanąć różne problemy: na jaką platformę chcemy to zrobić, jakimi dysponujemy informacjami na jej temat, jakimi narzędziami się posłużymy do realizacji celu.
Nie od dziś wiadomo, że bardzo dużo narzędzi (tzw. „game makerów”) powstało po to, żeby nie odkrywać kola na nowo. Więc jeśli nie posiadamy nawet wiedzy o programowaniu możemy z nich skorzystać i przy bardzo dużej wytrwałości stworzyć coś konkretnego.
Ambitniejsi chcieliby wypróbować własnych sił w programowaniu. Tu też z pomocą mogą przyjść całe pakiety bibliotek, które bardzo mocno mogą pomoc. Nie każdy przecież zna dokładnie architekturę swojego komputera. A biblioteki te mogą pomoc w przeniesienie swoich prac na jakąś inną platformę.
Jeszcze inni tworzą swoje produkcje tylko i wyłącznie z wykorzystaniem tego, co daje już na starcie dana maszyna. W tym przypadku należy dogłębnie przestudiować dostępne dokumentacje do danego komputera. Oczywiście nie trzeba od razu sięgać do asemblera i do najniższych warstw sprzętowych. Najlepiej wykorzystać do tego celu to, co już producenci dostarczyli z daną platformą.
„Hurra! Robię grę”
Wiemy czego chcemy, wiemy co umiemy, no to zaczynamy.
Po pewnym czasie okazuje się sam kod to nie wszystko. Przecież musimy w jakiś sposób testować to, co stworzyliśmy. Tak więc kod produkcji, który jest niewidoczny dla użytkownika, nie jest dla niego ważny, ważne jest to co będzie widział.
Elementy graficzne (o ile w grze występują) muszą być przez kogoś zrobione.
Czy koder może być dobrym grafikiem? Pewnie może. Ale zazwyczaj do testów potrzebuje czegoś „na już”. Dlatego sięga po jakiś program graficzny, narysuje kilka kolorowych kwadratów i tego używa sprawdzając, czy wszystko jest tak jak należy i zazwyczaj na tym się kończy. Często jest tak, że jakbyśmy się nie starali to nigdy nie jest to takie jak nam się wydawało że będzie. Dlatego, jeśli nasza praca nabrała już jakichś kształtów, możemy się pochwalić komuś innemu. Ktoś może podłapać temat i zgłosić chęć do pomocy mówiąc: „Wow, podoba mi się to, co robisz. Mogę ci pomóc przy grafice”. W ten sposób zaczyna się tworzyć kooperacja, która powoduje , że nasza praca może stać się godna uwagi dla innych. Przez co możemy być kiedyś rozpoznawalni i proszeni do współpracy przy innego rodzaju projektach.
„Współpraca”
Po jakimś czasie może się zgłosić człowiek, który ma pomysł na grę, ale sam jej nie jest w stanie zrealizować a jest np. dobrym grafikiem. Może dogadać się z jakimś koderem, z którym będzie współpracował. W takim przypadku musi przedstawić chociaż zarys swojego pomysłu: jaka to będzie gra, jaka będzie mechanika gry itp.
Koder po przedstawieniu wszystkich aspektów może zadecydować czy podejmie współpracę, czy nie. Odmowa może nastąpić z różnych przyczyn, np. z powodu zaangażowania w inne projekty, braku czasu z powodu innych zajęć, za niskich umiejętności lub ze zwykłego lenistwa.
Gdy jednak zdecyduje się, zaczyna się omawianie spraw czysto technicznych. Pokazanie co i gdzie trzeba w grze umieścić: grafika „taka”, dźwięki będą tu „takie” a tam „inne”.
Muzyka? A, faktycznie. to może zróbmy tak… I tak się to mniej więcej kręci.
Zazwyczaj to wszystko ma już opracowane pomysłodawca i on jest głównym koordynatorem projektu i sprawdza, czy wszystko jest tak jak by chciał.
Wszystko w trakcie może się dynamicznie zmieniać. Pierwsze grafiki mogą być tylko zarysem, aby programista miał prościej. Z czasem dostarczane są coraz bardziej dopracowane.
W czasie kiedy programista klepie kod, grafik ma czas na dopieszczenie swoich pikseli.
Może się zdążyć tak, że koder po pewnym czasie zaczyna „widzieć” to nad czym pracują.
Dzieli się wtedy swoimi uwagami mówić: „słuchaj, a może tu zamienimy 'to’ na 'coś’”, albo „tu dodajmy jeszcze 'to’”.
Tak więc wspólnymi siłami może powstać coś o wiele lepszego niż było w założeniach. Dodatkowo może się okazać, że będzie potrzebne dodatkowe narzędzie, które ułatwi lub przyspieszy tworzenie danego pomysłu. Jeśli to jest gra logiczna to jakiś edytor plansz, aby nie trzeba ich było robić „na piechotę”.
Najważniejsze jest częste i dogłębne testowanie programu, aby już we wczesnej fazie wykryć wszystkie możliwe błędy. Coś co może przegapić programista może wychwycić sam pomysłodawca. Najważniejsza jest wymiana informacji.
Gdy osoby biorące udział w tworzeniu swojego dzieła uznają, że wszystko, co chcieli aby w danej produkcji było już jest i nic innego nie wymyślą, postanawiają podzielić się nią szerszemu gronu. Dobrym przykładem są tutaj różnego rodzaju konkursy typu RetroKomp, na którym prezentowane są gry na platformy, które są w posiadaniu entuzjastów starszego rodzaju sprzętu.
’Phibrizzo’ – Amiga NG (5) 4/2018
