Nastoletni
Programiści

Logo Nastoletnich Programistów

Wykorzystanie własnych możliwości do tworzenia gier

Witajcie! Pewnie nieraz macie pomysł na ciekawą grę, jednak ograniczają was pewne kwestie – mianowicie jak zrobić grafiki i dźwięk do swojej gry? Jak to wszystko rozplanować? Programiści często nie są artystami (przynajmniej plastycznie i muzycznie) i zdają sobie z tego sprawę. Co więc zrobić?

Najlepszym rozwiązaniem jest oczywiście poprosić kogoś, aby wam zrobił wizualną część gry, lecz nie zawsze jest taka możliwość. Zwłaszcza gdy nie wiemy czy gra w ogóle coś zarobi. Ale szukajcie. Mi się udało znaleźć tylko gościa od muzyki w tle. Ale jeśli jednak nie ma to co? Może jakieś stronki z darmowymi grafikami/dźwiękami? Nie najgorsze rozwiązanie, ale często są to takie bardzo oklepane, typowe materiały wykorzystywane w wielu grach. Zresztą każdy woli być oryginalny i nie kopiować. W takim razie czemu by nie spróbować swoich sił w stworzeniu zarówno efektów dźwiękowych jak i grafik? Opowiem to na przykładzie mojej gry o nazwie kodowej Cyber Attack.

A więc polecam zaczynać od mądrego konceptu. Rozplanujcie sobie wszystko! Od mechaniki, fizyki aż do grafikę i dźwięki. Policz ile plansz chcesz stworzyć, czy aby na pewno tworzenie ich nie zajmie dużo czasu (zwłaszcza gdy są to gry logiczne, gdy często generator plansz nie wystarcza, potrzebne są mądrze skonstruowane przez człowieka plansze). Jako jeden programista musisz to wszystko ogarnąć, więc postaraj się żeby nie było tego za dużo. Ile to się spotyka ciekawych projektów, które giną przez to że po prostu nudzimy się tworzeniem ich, mamy już tego projektu dosyć! To zły nawyk!

Ja chciałem stworzyć grę o tematyce survivalu. Czy to oryginalne? Wiadomo, temat survivalu jest bardzo oklepany, jednak bardzo wciągający i jest dużo możliwości, żeby był w miarę możliwości oryginalny. Nie chcę tutaj rozdrabniać na szczegóły, jak moja gra będzie wyglądać potem, bo to byłoby nie na temat. Moim (nie)skromnym zdaniem nie będzie to kolejna nudna gra survivalowa z craftingiem i po prostu przechodzeniem plansz z domieszką zombie.

Plan rozpisany, więc zaczynamy! Zacząłem od stworzenia algorytmu wyznaczania trasy. Zaimplementowałem algorytm A*, który wydaje się być łatwym i wydajnym dla mojej gry. Stworzyłem także prostą fizykę, która odpycha zombie jeśli są obok siebie, oraz wylicza kolizję obiektów ze ścianami.

Działa. Następnym elementem jaki zrobiłem to specjalną fizykę przeznaczoną dla pocisków, ponieważ są szybkie i w czasie jednej klatki mogą przeniknąć przez całą ścianę:

Działa! Wydaje się że wygląda to koszmarnie, ale szkielet przecież mamy zrobiony! Teraz najgorsza część dla programisty czyli upakowanie grafiki i dźwięków na tym szkielecie.

Grafika. Coś czego nienawidzę i nie mogę tego ogarnąć. Pamiętajcie – nie dawajcie sobie zbyt dużych celów. Gry z gorszą ale zrobioną z serca grafiką także zdobywają szacunek wśród graczy. Polecam pixelart lub coś w stylu flat design! Proste ale jak chociaż trochę popracujecie to wyniki będą zadowalające. Do tworzenia grafiki polecam Inkscape, lub jeśli macie pieniądze (lub klient Torrent) Adobe Illustrator. Inkscape zdecydowanie wystarczy, poszukajcie paru poradników, w których nauczycie się wielu operacji na ścieżkach, co znacznie przyspieszy pracę.

Plansza. Jako pierwsze chciałem zrobić planszę. Postanowiłem, że będzie ona… sześciokątem. Od tak – pierwsza plansza, więc powinna być prosta i dla gracza i dla mnie, aby ją dobrze zaprojektować. Oto etapy tworzenia planszy:

Jak widzicie zaczęło się od malutkiego sześciokąta, potem dodałem ich więcej aby dodać głębi planszy, a na sam koniec dodałem trójkąty, wpasowujące się w stylistykę gry oraz stanowiące miejsca „rodzenia się” przeciwników.

Główny bohater. Niełatwo czasem wymyślić fajnego bohatera. Czasem warto zapytać znajomych. Zwłaszcza tych co zazwyczaj mają „głupie” pomysły. Ja zapytałem i zaproponował mi zrobić klauna na wózku inwalidzkim który będzie uciekał przed policją. Na początku pomyślałem „Boże, co za debil”, ale to nie jest przecież zły pomysł. Zawsze lepiej być oryginalnym niż tworzyć kolejną zwykłą, typową, oklepaną setki razy postać.

Gorzej z rysowaniem owej postaci. Nie jestem w tym dobry. Na szczęście kamera w grze ma być dość oddalona, także gracz nie będzie się wpatrywać w tą beznadzieję, którą zrobiłem. Przynajmniej wózek w miarę ładnie wyszedł.

Bronie. Chyba jeden z prostszych elementów. Polecam znaleźć obrazek w Google i po prostu go przerobić. Efekt jest dobry:

Przeciwnicy. Planuję na każdą mapę dać innych przeciwników. To dużo roboty, jednak gracze doceniają takie rzeczy. Przeciwników oczywiście też zrobiłem w flat design, aby wszystko komponowało się w jedną całość. Pierwsza plansza ma przedstawiać współczesne + trochę fikcyjne elementy, do których flat design bardzo pasuje:

Bonusy. W tym stylu bardzo łatwo narysować różnorodne bonusy:

Edytor plansz. Grę piszę w frameworku LibGDX. Nie ma w nim żadnego edytora plansz czy coś na jego wzór, dlatego musiałem sobie stworzyć swój prosty edytor plansz. Napisałem go w Javie wykorzystując standardową bibliotekę GUI Swing. Nie wygląda on jakoś świetnie, ale sprawdza się w roli pomocy do tworzenia plansz. Wygląda on mniej więcej tak:

O edytorze nie będę za dużo mówić, bo to trochę nie na temat. Powiem tylko że jest bardzo pomocny, szczególnie gdy zamierzacie robić kilka map do gry – nie wyobrażam sobie umiejscawiać każdego obiektu bezpośrednio w kodzie, zwłaszcza jak mamy dużą mapę. Edytor pełni u mnie tylko funkcję pomocy, do umiejscawiania obiektów, cała reszta (skrypty itp.) dzieje się już w kodzie. Zerknijmy jeszcze na to, z czego składa się edytor:

  • Points – punkty, używane do tworzenia ścian, węzłów nawigacji,
  • Navigation Nodes – węzły nawigacji, potrzebne do algorytmu A* (wyznaczanie trasy przez przeciwników). Składają się z kilku punktów, tworzą wielokąt (koniecznie wypukły),
  • Walls – ściany. Po prostu ściany w grze – każdy taki obiekt składa się z dwóch punktów,
  • BackgroundTex / Tex – tekstury. Tex wyświetlają się nad graczem, BackgroundTex pod graczem,
  • Spawners – oznaczają punkt w którym mogą pojawić się przeciwnicy.

Całą resztę mam zrealizowaną w kodzie. Wszystkie elementy interakcji, Easter Eggi teraz można łatwo wyłapać, po prostu pobierając punkt z pliku edytora i na przykład sprawdzając jego odległość od gracza.

Okej, mamy już planszę. Nie wygląda najgorzej, co nie?

Ale brakuje dźwięków – i to bardzo. Przecież nie będę ogarniać FL Studio – zajęłoby mi to parę tygodni, zresztą i tak nie mam słuchu muzycznego. Ale Audacity chyba każdy zna. Mikrofon też wiele osób ma. Ja użyłem bezprzewodowych mikrofonów Singstar do nagrania efektów dźwiękowych (siostra je używała do gry na PS3, teraz się kurzą, więc czemu by im nie nadać drugiego życia?).

Brzmi mało profesjonalnie, co nie? Pamiętajcie, gracze to nie audiofile, nie potrzebują wszędzie formatu *.flac ani idealnej jakości dźwięku. W takim razie możemy przystąpić do nagrań!

 

 

 

  1. Wybuch
    Oryginalne nagranie (po prostu dmuchanie w mikrofon):

    Po drobnej edycji (m. in Paulstretch, zmiana tonu):
  2. Strzał z shotguna
    Oryginał (zrobione ustami + przeładowanie):

    Po drobnej edycji:
  3. Śmierć bohatera:Oryginał/po drobnej edycji:
  4. Uderzenie w jednego z robotów (pistolet na kulki + strzelanie w garnek)

Jak widać efekty dźwiękowe można samemu zrobić w domu. Wystarczy chcieć!

Muzyka. Muzykę w tle ogarnęli moi koledzy. Pozdrawiam Marcina Marszałka i Huberta Rzeszótko ;-). Jednak jeśli nie macie kogoś, kto by wam zrobił utwór muzyczny, to możecie skorzystać z opengameart.org. Tylko szukajcie dosyć „głęboko”, aby utwór nie powtarzał się często w innych grach. Efekt końcowy wygląda tak:

Czy to już koniec? Nie.

W planach mam dużo bardziej skomplikowane plansze, których stworzenie będzie teraz już dużo szybsze dzięki edytorze oraz dobrze napisanym kodzie programu, w którym łatwo dodawać i oskryptowywać plansze. Zamierzam dodać fabułę, zmienić styl na jeszcze bardziej arcade i stworzyć masę Easter Eggów i pobocznych misji. Oczywiście multiplayer (lokalny + sieciowy) też by się przydał.

Podsumowanie

Samemu da się stworzyć przyzwoitą grę. Jeżeli nie masz ekipy to nie jesteś od razu skazany na porażkę. Wyliczcie dobrze swoje umiejętności, nie twórzcie dużych projektów, które od razu są skazane na porażkę, gdyż znudzicie się podczas ich tworzenia. Lepiej jest robić coś mniejszego, ale równie dobrego – zawsze są to też jakieś projekty które na pewno przydadzą się wam w waszym portfolio. Często spotyka się ambitnych młodych programistów, którzy nie mają tak naprawdę żadnego projektu skończonego. Czasami trzeba się wziąć w garść i dokończyć jakiś projekt mimo, iż wam się nie chce. Jak to mówił św. Benedykt z Nursji: Ora et labora (łac. módl się i pracuj). Przecież w pracy też nie będziecie mogli sobie wymyślać. Dzięki małym projektom nauczycie się wiele, dopełnicie portfolio oraz zyskacie szansę na zarobek (bo czemu niby takiej gry nie wrzucić do serwisu Google Play lub Steam?).

Jakub Dybczak

Jakiś tam Math.random() z internetu ;-)

Zobacz wszystkie posty tego autora →

Komentarze

  • Jakub Kuniszewski

    Chyba jeden z najbardziej wartościowych artykułów jaki tu przeczytałem!

    • Jakub Dybczak

      Dzięki wielkie! 🙂