Porady

Ten dokument zawiera tylko pewne sugestie i porady. Ma charakter nieoficjalny. Napisałem go jako wielokrotny uczestnik i zwycięzca, a nie jako organizator konkursu Compo. Nie są to żadne oficjalne wymagania czy choćby zalecenia.

Konkurs ma długą tradycję, a jego uczestnicy mogą wymienić wiele zalet brania udziału, jak np.:

• można uzyskać motywację do intensywnego programowania
• można zmobilizować się do intensywnej nauki czegoś nowego
• można napisać i ukończyć (!) jakiś mały projekt
• można rozpocząć jakiś większy projekt, który potem będzie się rozwijało
• można miło spędzić czas na programowaniu :)
• można poczuć namiastkę programowania pod presją czasu

Jak ktoś napisał już dawno temu, to ma być friendship, a nie war. Dlatego to nie zdobyte punkty i miejsce w wynikach powinno być najważniejsze i często faktycznie nie jest. Jednak być może warto postarać się, by praca była jak najlepsza - nie tylko dla zajęcia dobrego miejsca. Właśnie tego dotyczą opisane tu porady. Prace konkursowe mają swoją charakterystykę i warto zdawać sobie z tego sprawę.

Wiadomo, że jeden miłośnik programowania nie jest w stanie stworzyć gry dorównującej komercyjnym produkcjom. Tym bardziej w ciągu kilku dni, kiedy trwa konkurs. Dlatego by praca była ciekawa, trzeba położyć nacisk na pewne elementy.

Bardzo duże znaczenie ma pomysł - to od niego wszystko się zaczyna. Ciekawe pomysły i oryginalne podejście do tematu sprawia, że praca wyróżnia się na tle innych.

Drugim pozytywnym elementem jest humor. Jeśli występuje w fabule, grafice, dialogach czy innych tekstach, ogólnie w gameplay albo wręcz cały pomysł na pracę jest zabawny, to z pewnością praca zwróci uwagę oceniających i będzie się kojarzyła pozytywnie.

Co by nie mówić, grafika również ma znaczenie. Doświadczenie pokazuje jednak, że nie musi to być profesjonalny, piękny pixel art, rendery czy modele. Zdarzało się, że Compo wygrała praca z kreskówkową grafiką zrobioną... w Paincie. Ważne, by gra miała pewien wyraźny i spójny styl, a grafika pasowała do niego.

Prace oceniają osoby, które również zajmują się programowaniem i z pewnością patrzą one również na aspekty techniczne gry, a nie tylko na efekt końcowy. Dlatego wiele efektów graficznych, fizycznych czy innych oceniane jest pod kątem zaawansowania technicznego i trudności w ich napisaniu. Efekty takie (lub przynajmniej wyglądające na zaawansowane technicznie) polepszają więc wizerunek pracy.

Najważniejsza jest oczywiście grywalność. Praca konkursowa nie musi jednak - z punktu widzenia tematu tego artykułu - dostarczać wielu godzin ciekawej rozgrywki. Podobno zawsze najważniejsze jest pierwsze wrażenie. W tym przypadku pierwsze często oznacza jednocześnie ostatnie. Dlatego gra powinna robić wrażenie i wciągnąć gracza przede wszystkim na kilka pierwszych minut gry. Jej obsługa musi też być prosta do opanowania, a gra nie może być zbyt trudna.

Ze spraw organizacyjnych po pierwsze nie radzę zaczynać pisania od razu. Najpierw należy wymyślić jakiś pomysł i możliwie dokładnie go przemyśleć, opracować. To oczywiście nie musi być kompletny projekt programu w UML-u, ale warto przynajmniej w myślach określić jasno, z jakich elementów gra powinna się składać i co będzie w niej potrzebne.

Warto, by taki projekt był elastyczny. Pisanie należy zacząć od rzeczy najważniejszych, a efekty dodatkowe zostawić na koniec. Wówczas w wypadku, jeśli zabraknie czasu, praca mimo tego będzie dobra.

Pisanie pracy na Compo wiele razy zmobilizowało uczestników do nauki jakiś nowych technologii. To z pewnością dobry efekt. Jednak z punktu widzenia tego artykułu lepiej jest chyba, kiedy do napisania pracy wykorzystuje się jedynie te technologie, które się już dobrze zna. Wówczas można napisać dużo więcej, bo nie trzeba poświęcać czasu na naukę.

Warto też korzystać ze swojego gotowego kodu - na przykład szkieletu aplikacji czy loaderów. Każdy bardziej zaawansowany programista ma swoje biblioteki, z którymi się nie rozstaje i dlatego zasady konkursu dopuszczają ich używanie. Im więcej masz już napisane, tym bardziej możesz podczas konkursu skupić się na wprowadzaniu w życie swojego pomysłu na grę.

Nie ma nic gorszego, niż praca niedokończona. Szczególnie, jeśli nie zawiera prawie niczego, co miała zawierać. Dlatego należy zawsze wybierać taki pomysł i tak zaprojektować swoją pracę, by nie była zbyt ambitna. Uwzględnić trzeba ilość czasu, jaka jest dostępna w danej edycji konkursu, jak również czasu wolnego, jaki będziesz miał w podczas jego trwania. Można też postarać się, by było go jak najwięcej - np. odrabiając wcześniej trudne prace domowe, wypracowania itp.

Bardzo ważne jest, by nie pisać na ostatnią chwilę. Wiąże się z tym wiele niebezpieczeństw. Praca może być niedokończona i niedopracowana. Może też zawierać jakiś błąd, który znacznie pogorszy jej wizerunek albo wręcz uniemożliwi jej uruchomienie. Gra pisana na ostatnią chwilę to gra pozbawiona dokumentacji (readme), słabo przetestowania, nieskalibrowana. Wiem, że nawet niektóre poważne firmy tak robią swoje gry, ale jednak podkreślam - naprawdę nie warto. Jeszcze jednym niebezpieczeństwem jest fakt, że praca wysłana na ostatnią chwilę może nie dojść na czas i w ogóle nie wziąć udziału w konkursie.

By praca mogła zostać oceniona, musi się ją dać uruchomić. Inaczej na pewno nie dostanie żadnych punktów. Dlatego niezwykle istotne są aspekty techniczne takie, jak użyte technologie, wymagane biblioteki czy wymagania sprzętowe. Czasami praca wymaga dodatkowych, niedostarczonych z nią plików DLL lub co gorsza, całej biblioteki wymagającej instalacji (np. .NET Framework czy wirtualna maszyna Javy) czy też nowoczesnej karty graficznej. Należy wtedy zadać sobie pytanie - jak wiele osób będzie w stanie spełnić te wymagania?

Podobnym problemem jest docelowy system operacyjny. Od pewnego czasu pojawiają się prace adresowane dla Linuksa. Mimo coraz większej jego popularności chyba nadal bardziej warto jednak tworzyć gry działające pod kontrolą Windowsa - będzie je w stanie bez problemów uruchomić więcej osób.

Znaczenie ma także rozmiar pracy. Kiedy jest za duża, zgodne z zasadami uczestnik ma obowiązek hostować ją w Internecie samemu. Wówczas nowym problemem jest miejsce na serwerze, jego prędkość, a także niekiedy godzinny limit transferu. Najgorsze jednak, że takiej dużej pracy wiele osób może po prostu nie móc bądź nie chcieć ściągnąć i nawet nie zapozna się z nią. Chyba, że została już wcześniej zareklamowana jako ciekawa i warta tego wysiłku.

Aby zadbać o rozmiar wysyłanej pracy, należy oczyścić ją z niepotrzebnych plików tymczasowych, jak kopie bezpieczeństwa źródeł, pliki NCB, PDB, OBJ, a także thumbs.db i inne. Pliki EXE należy kompilować w wersji Release.

Warto dołączyć do pracy dokumentację w postaci pliku "Readme" i napisać w nim przynajmniej podstawowe informacje o grze - o co w niej chodzi i jakimi klawiszami się steruje. Często w takich plikach zamieszczane są także informacje o autorze, użytych bibliotekach i multimediach (oraz źródła ich pochodzenia), powstawaniu pracy, jak również fabuła gry czy podziękowania i pozdrowienia.

Pewne rzeczy mogą kompletnie popsuć dobre wrażenie i całkowicie zdyskwalifikować grę w oczach oceniających. Należą do nich np. duże kłopoty z uruchomieniem, a także konieczność opanowania skomplikowanych zasad gry czy skomplikowanej klawiszologii.

Praca nie powinna w żaden sposób ingerować w system, zapisywać informacji w Rejestrze itp. Szczytem niewygody byłoby, gdyby praca wymagała instalacji (raz się taka zdarzyła).

Podsumowując - dobra praca powinna być po prostu mała, prosta, ciekawa, dać się łatwo uruchomić, przetestować i ocenić.

Na zakończenie chciałbym wspomnieć o strategiach marketingu pracy konkursowej. Zasady nie zabraniają zdradzania informacji o swojej pracy przed zakończeniem konkursu czy nawet jej całkowitego udostępnienia. Dlatego można stosować różne podejścia do tego tematu.

1. Jednym z nich jest z pewnością pisanie pracy po cichu, bez zdradzania jakichkolwiek szczegółów na jej temat czy nawet o tym, że bierze się udział w konkursie. Wtedy oceniających czeka niespodzianka :)
2. Model "katedry" (porównaj The Cathedral and the Bazaar) - można zdradzać zainteresowanym jedynie pewne szczegóły na temat powstającej pracy i pokazywać screeny podsycając ich ciekawość.
3. Model "bazaru" - można kolejne wersje swojej niedokończonej jeszcze pracy udostępniać publicznie. Dzięki temu ludzie będą już dobrze znali daną grę. Będą także mogli uczestniczyć w jej powstawaniu, zgłaszać błędy i sugestie. Praca będzie dobrze przetestowana i może być lepiej dopracowana.