Robimy Grę: Część 1 - dla bardzo początkujących. (Novashell)

Robimy Grę: Część 1 - dla bardzo początkujących. (Novashell) Jest wiele osób, które chciało by zacząć tworzyć gry, ale nie wiedzą w jaki sposób w ogóle wystartować. Postanowiłem napisać szereg artykułów opisujących tworzenie gier, pierwszym z nich jest ten, który masz przed oczami. O mnie. Nazywam się Andrzej Koloska, parę długich lat temu zacząłem projekt Afterfall, który przerodził się w komercyjną produkcje, w między czasie pracowałem nad Wiedźminem, Necrovision, grami na komórki i grami Włatcy Much. Pomagałem przy wielu amatorskich i komercyjnych produkcjach. Czego nauczysz się po przeczytaniu tego arta Ta cześć artykułu kierowana jest dla osób bardzo początkujących, takich które nie potrafią nawet programować. Nauczysz się podstawowych i krytycznych procesów występujących przy produkcji gier. Czego nie nauczysz się w tym artykule, ale nauczysz się czytając następne. - procesów zmniejszających ryzyko wyprodukowania gry - etapu negocjacji i współpracy z wydawca nad produkcja gry - metod zarządzania zasobami ludzkimi - komercyjnego podejścia do produkowanej gry WAŻNE: Projekt którego produkcje będę opisywał w tym arcie ma nastawienie hobbistyczne i ma na celu tylko i wyłącznie pokazać krytyczne procesy w produkcji gier. Projekt nie jest nastawiony na sprzedaż, choć wg mnie każdy zaczęty projekt powinien być analizowany pod względem sprzedaży (znacznie więcej wtedy można się nauczyć). Nie będziemy tworzyć tu żadnego IP, nie będziemy również projektować gry z myślą o późniejszym rozwoju (edytory, porty na inne platformy, dodatki, kolejne części). PRZYGOTOWANIE DO PROJEKTU ETAP 1 - POMYSŁ. No właśnie, pierw trzeba mieć pomysł. Etap ten nie jest taki prosty jak by się mogło wydawać, w końcu każdy może wyssać z palca parę pomysłów na grę nie :> Ale pytanie tu brzmi: czy chcesz tworzyć wymarzony projekt, którego nigdy nie skończysz, czy może chciałbyś zacząć małą grę która ma znacznie większe szanse na ukończenie? Ja w tym arcie wybieram tą druga opcje. Jeśli wybierasz opcje pierwszą - ten art Ci nie pomoże, albowiem nie ma tu opisanej drogi od samego pomysłu -> prototypy (czyli tak jak działa większość firm w branży = mamy pomysł, który staramy się zdevelopować) Projekt powinien być adekwatny do umiejętności osób które mają przy nim pracować. W tym przypadku jestem tylko ja, moje umiejętności: - podstawy programowania (załóżmy, że w każdym języku) - grafika 2d/3d - odpada - dźwięki/muzyka - odpada - animacje - odpada Wywnioskować z tego można tyle, że trzeba będzie: - użyć gotowego i bardzo prostego silnika, którego taka tępa osoba jak ja będzie mogła się szybko nauczyć - wszystkie assety (= dźwięki, grafika, etc) muszę znaleźć w internecie i stworzyć sobie bazę danych na której podstawie będę myślał o grze ktorą chciałbym zrobić

W związku z tym powinienem napisać sobie główne założenia pomysłu na grę, która chcę tworzyć: - gra tylko i wyłącznie 2D Programowanie gier 2d jest znacznie prostsze od 3d, skoro ja nie potrafię programować to po co mam się rzucać na głęboką wodę. - gotowy silnik/framework do tworzenia gier 2d Moje umiejętności programistyczne nie wystarczają do tego by napisać własny engine 2d, więc będę musiał poszukać sobie jakiegoś gotowego - silnik napisany w C++ najlepiej z parserem języku skryptowego LUA dawno temu dużo programowałem w C++ więc łatwiej będzie mi sobie przypomnieć ten język. W paru produkcjach programowałem w LUA, więc byłoby fajnie gdyby silnik korzystał z tego języka skryptowego - silnik działający pod linuxem to zwiększy moje morale :) - gra powinna być 'bez wyrazistej' grafiki mój pomysł na grę powinien jakoś wymigać się z kwestii tworzenia do niej assetów. Za grafikę odpowiedzialne będą placeholdery, które znajdę w internecie (więc będę musiał swój pomysł oprzeć o znalezione biblioteki gotowych grafik) - pomysł na grę nie ma być rozwojowy. Moim celem jest jak najszybsze stworzenie gry, nie chce skupiać się na edytorach i rozwoju samej gry. Chce taka grę stworzyć i o niej zapomnieć. W następnym Epizodzie artykułu zajmę się rozwojem (portem gier na inne platformy, rozwijaniem samej technologii). - pomysł musi być prosty do implementacji Nie programowałem z 5 lat, nigdy nie skupiałem się na programowaniu, więc nie mogę wymyślić czegoś, czego nie będę potrafił zaimplementować. Niby nie są to żadne założenia, a jednak jak się sami przekonacie są one bardzo konkretne i mają ogromny związek na dalszą produkcje. DOTPROJECT Mamy już główne założenia, z których można wywnioskować pierwsze zadania. Każdy projekt = szereg zadań, które trzeba wykonać. Im większe projekty tym, wiadomo - ilość zadań się zwiększa. Ludziki są takie inteligentne, że stworzyły różne programy pomagające w zarządzaniu (MS Project, Excel, Bugzilla, Mantis, FlySpray etc). Ja tu proponuje program DotProject, który działa przez przeglądarkę. Okazuję się, że tego programu używają nawet zagraniczne firmy developerskie przy swoich produkcjach. Sam program jest bardzo prosty i bardzo łatwo jest go zainstalować na swojej maszynie. Więc zaczynamy projekt: PRZYGOTOWANIA, do którego wrzucimy sobie zadania przygotowawcze do naszego projektu. Nazwa Zadania Wybór Silnika Opis Zadania Musimy przeszukać internet w poszukiwaniu silnika, który będzie spełniał wszystkie nasze wstępne założenia projektu Osoba/ Departament odpowiedzialny Planowany czas wykonania - 24 h Wynik zadania Dokument opisujacy wybor silnika. Ja tylko napisze, że wybrałem silnik Novashell. Wykonano w 6h

Analiza Tutoriali/ Exampli Silnika Musze zanalizować wszystkie tutoriale udostępnione przez autorów silnika, tak bym mógł wogóle obczaić jak engine działa i jakiego typu gry można na nim robić. 12h Dokument sugerujacy jakiego typu gre mozna szybko i prosto stworzyc za pomoca tego silnika 10h Analiza Jezyka Skrytpowego musze nauczyc sie podstaw jezyka skryptowego silnika, by wiedziec co mozna zaimplementowac w samych skryptach (nie chce grzebac w zrodlach silnika) 18h Dokument opisujacy mozliwosci jezyka skryptowego, sugerujacego jakiego typu gre mozna stworzyc 12h Analiza Forum Silnika Musze przeczytac cale forum by znalezc problemy na ktore natkneli inni, sugestie, pomoc etc 4 Dokument opisujacy sugestie osob kozystajacych z silnika, linki do examplow, bledy silnika 2h Tworzenie bazy assetow Musze sciagnac z internetu tyle ile sie da assetow (sprajty 2d, dzwieki, muzyka etc) 8h Folder z assetami ktore pojda do analizy 4h Po co wogóle pisać sobie zadania? - by nie zapomnieć jaki ma być wynik zadania (musisz zmusić się do pisania dokumentacji, możesz mi zaufać, że to jest bardzo ważna część gamedeveloperki) - by móc analizować swoją efektywność - byś miał wgląd w projekt ETAP 2 - POMYSŁ CD No to teraz dzięki naszym przygotowania mamy parę konkretów: - Gra używa silnika Novashell - Gra 2d w świecie 'fantazy', polegająca na znalezieniu jak najwięcej skarbów w labiryncie zanim zostaniemy zabici przez żyjące tam żyjątka fantastyczne ;)

- Gracz steruje postacią człowieka, który który szuka skarbów w tajemniczym labiryncie, jak się okazuje nie możne wyjść z tej wyprawy żywy Mamy już pomysł na grę. Normalnie w tym momencie (bądź zależnie od skomplikowania następuje to po Etapie 3cim) następuje proces budowania POCa (Proof of concept) i rozwijania pomysłu o ulepszające gameplay możliwości gry. My skupiamy się na najważniejszych procesach występujących w produkcji gry wiec omijamy i lecimy dalej. ETAP 3 - GAME VISION DOCUMENT. Gdy już wiemy co chcemy zrobić przychodzi czas na napisanie Game Vision Document (dokument wizji gry), czyli 1-2-3 stronicowy dokument opisujący nasz pomysł na gre. Sporo ludzi pyta się mnie po co taki dokument tworzyć, wiec już tłumaczę: - taki dokument ma na celu przedstawienie wszystkim co chcemy zrobić - taki dokument ma na celu zgromadzenie jak największej ilości feedbacku od osób które go przeczytają i zanalizują - taki dokument pozwala na start preprodukcji (= mamy punkt wejściowy) - dzięki takiemu dokumentowi możemy zacząć szukać wydawcy (jeśli posiadamy kontakty z Producentami) Nie będę pisał jak powinien wyglądać Game Vision Document, albowiem każdy rodzaj gry się rożni - odpalcie google. W dokumencie powinny być zawarte najważniejsze informacje o grze + koncept widoku gry. Gdy już dokument wizji zostanie zanalizowany przez znajomych (badz team) wprowadzane sa do niego poprawki i można zacząć preprodukcje. PREPRODUKCJA ETAP 4 - PREPRODUKCJA. No to podchodzimy do następnego etapu, pamiętać musicie ze nie będziemy tu tworzyć dokumentacji technicznej, dokumentacji pipeline'ow i innych rzeczy które są BARDZO ważne przy produkcji produkcji, które chcą być 'poważne'. Chyba najlepiej będzie przedstawić ten temat w sposób 'zadaniowy'. Wczesna preprodukcja przechodzi najczęściej w taki sposob : Design -> Researching -> Redesign Co oznacza: spisujemy założenia -> tworzymy prototypy założeń, dyskutujemy nad założeniami, wyciągamy wnioski -> poprawiamy dokumentacje Nazwa Zadania Design Document v1 Opis Zadania Stworzyc trzeba dokumentacje gry, najlepiej podzielic taki dokument na dzialy by mozna bylo sprawnie przeprowadzac dynamicznie etapy Researching i Osoba/ Departament Odpowiedzialny Designerzy Planowany Czas Wykonania 48h Wynik Zadania Design Document v1 Wykonano w 12h

Redesign. Mozna uzyc WIKI przy pisaniu dokumentacji. Nad tym zadaniem musi panowac koordynator/ manager (whatever), poprostu osoba ktora przeprowadzi to zadanie odpowiednio. Researching Zalozen Z Design Dokumentu tworzymy liste procesow do Researchingu (np. Menu, Poruszanie sie Postacia, AI przeciwnikow, Bronie, Efekty Specjalne etc). Researching to nic innego jak tworzenie prototypow naszych zalozen. wszyscy 2 tygodnie Tuzin prototypow, wnioskow i rozmow 70h Redesign (Design Document v2) Podczas Researchingu na pewno zostaly wyciagniete jakies wnioski, poprawiono zalozenia, zwiekszono grywalnosc - teraz trzeba zaktualizowac dokumentacje Designerzy 48h Design Document v2 4h Pipeline'y Trzeba stworzyc podstawowe dokumenty pipelineow (Tworzenie Animatorzy, Graficy, Programisci, Muzycy, Level Designerzy 5h Dokumentacja podstawowych pipeline'ow 2h

grafiki, tworzenie leveli, tworzenie dzwiekow etc) Załóżmy ze nasza gra składać się będzie z jednego jebitnego levelu. Nie będę pisał jak wygląda Design Document, albowiem o tym jest masa książek i tak naprawdę rożnie podchodzi się do tego tematu. (wg mnie design document = dokument pozwalający na rozpoczęcie produkcji, a nie pokazania go publiczności by się podjarac) Z dokumentacji trzeba teraz rozplanowac wyprodukowanie grywalnego Dema, ktore zakonczy Preprodukcje. - my ten bardzo wazny punkcik omijamy i lecimy z produkcja. Tak samo jak omijamy tworzenie repozytorium, struktury katalogow, tworzenie technicznej dokumentacji - to nam nie potrzebne, artykul ten ma pokazac GLOWNE i KRYTYCZNE procesy wystepujace przy produkcji gier. PRODUKCJA ETAP 5 PRODUKCJA Tu zaczynają się tworzyć wszystkie assety do gry, tu zaczyna działać build system, tu zaczyna się level design i tu zaczyna się początek końca życia projektu jeśli złe przeprowadziliśmy etap Preprodukcji. Tak na logikę ten etap jest prosty, albowiem mamy: - liste grafik do wykonania - liste animacji do wykonania - liste dzwiekow/muzyki do wykonania - liste leveli do stworzenia - liste modulow do zaprogramowania - liste cutscenek - itd, itd Niby proste, mamy liste- rozdajemy zadania i czekamy az ludzik skonczy, wyexportuje i wrzuci do repozytorium. Tak naprawde najwazniejszy w tym etapie jest Pipeline produkcji poszczegolnych assetow tak by nie 'gryzl' sie z innymi. Samo skoordynowanie pracy ludzi to pestka, ale stworzenie pipeline'u pozwalajacego na unikniecie podstawowych bledow nie jest juz takie latwe. (dlatego przed koncem preprodukcji tworzy sie demo by stestowac i poprawic pipeline'y). Etapu produkcji nie da sie w latwy sposob pojechac waterfallem (czyli ze tak powiem 'pokolei'). No ale my sie tym nie stresujemy, mamy swoj jeden level wiec zaczynamy jazde (pamietac trzeba o tym ze mamy wszystkie assety ktore sobie sciagnelismy i wybralismy do naszej produkcji): Nazwa Zadania Opis Zadania Osoba Odpowiedzialna/Departament Pl Przygotowanie mapy glownej Rozstawienie PF Rozstawienie elementow mapy Rozstawienie przeciwnikow Rozstawic odpowiednio Tile (ciagle testujac grywalnosc) Rozstawic do gotowej mapy glownej pathfindera Rozstawic nasze skarby po levelu w strategicznych miejscach Rozstawic naszych przeciwnikow w strategicznych miejscach

Rozstawienie dzwiekow/ustawienie muzyki Implementacja Poruszania sie postaci Implementacja Itemow Implementacja Przeciwnikow Podpiac i rozstawic dzwieki (dla itemow, postaci, elementow aktywnych, etc) Zaimplementowac poruszanie sie postaci klawiatura Zaimplementowac klase Itemow, pozwalajaca na zbieranie przez postac glowna skarbow Zaimplementowac klase przeciwnikow i AI dla nich Programisci Programisci Programisci Implementacja GUI/Menu - Programisci No to mamy naszą grę gotową. Trzeba mieć na uwadze, że każde te zadanie ciągnie za sobą drugie - testowanie i tweakowanie. KONTROLA JAKOSCI ETAP 6 - QA Jest to już prawie ostateczny etap w produkcji gier. Gdzie poprawiane są wszystkie błędy, często dodawane nowe możliwości gry (albowiem dopiero teraz okazuje się, że czegos brakuje, albo byłoby fajnie by coś jeszcze zaimplementować do gry). Etap ten najczęściej dzieli się na etapy Alpha, Beta i Master. Bardzo często na tym etapie zmienia się build system naszej produkcji tak by ułatwić testowanie i tracking wersji gry. My zrobimy tak: odpalamy flyspray (użyj google). dajemy grę paru osobą by sobie pograli, napisali błędy, uwagi, sugestie, feartures needs. Musimy tylko napisać dokument w którym opiszemy jak błędy mają być zgłaszane (tak by była jedna forma) - w google możesz znaleźć pewnie sporo informacji na ten temat. POSTPRODUCTION/SUPPORT Jest to etap w którym planuje/produkuje się Patche i w którym supportuje się grę Parę ważnych informacji na koniec ode mnie: - nie pokazuje dokumentacji jaką pisałem podczas produkcji tej gry, jeśli chcesz na poważnie robić gry - musisz sam zacząć tworzyć (dlatego proponuje tutaj gotowy engine) dokumentacje, sam zacząć programować (bądź współpracować z programistą) tak byś wiedział jakie informacje trzeba podawać w dokumentacji i na czym trzeba się skupiać. Tak naprawdę feedback osoby która się czymś zajmuje da Ci najwięcej. Załóżmy, że napisałeś w dokumentacji statystyki postaci - programista stara się zaimplementować i mówi Ci że brakuje jakiejś statystyki, albo nie ma opisanej statystyki zależnej. Chce również zmusić czytających

do obslugi google - gdzie można znaleźć naprawde wszystko. - dlaczego Planowany Czas Wykonania ma się często ni-jak do Wykonano w czasie? Dlatego by odrazu uczulić wszystkich, że nigdy nie jest tak jak planujemy. Myślałem, że coś skończe w takim czasie + dodałem do tego troche czasu dodatkowego, okazało się inaczej :) - wybrałem silnik, którego każdy może się nauczyć jak ma wolny czas. Jak zaczniesz projekt na tym silniku będziesz znał odpowiedź na wszystkie niedopowiedzenia w tym arcie. Uczy sie najlepiej na swoich błędach i wnioskach niż na moich. - głównie napisałem tą część arta by jakoś zmusić ludzi, którzy chcą zacząć 'pisać gry' do zaczynania od czegos prostego. (proste gry 2d na gotowym rozwiązaniu, które można rozwijać) I tak naprawde do szybszego uczenia się. Pewnie i tak nic z tego nie wyjdzie, bo w końcu większą motywacje ma się wtedy gdy developuje się swoją wymażoną grę.