Tworzenie gier, od czego zacząć?


#1

Prowadząc swój najnowszy projekt, stosuję pewne poznane techniki podczas produkcji poprzednich gier. Przy każdym podejściu do tematu uczyłem się nowych rzeczy – wbrew pozorom amatorskie, duże produkcje, pomimo ogromnej szansy na niepowodzenie, naprawdę wiele uczą. Pamiętam czasy, kiedy mając jakieś 14 lat, myślałem, że zaprojektowanie gry to odpowiednio dobry pomysł i … Tyle. Rozpisanie w kilku zdaniach fabuły na zasadzie ,Był sobie X, zabito mu rodzinę, teraz się mści” i na bieżąco wymyślanie zadań, tworząc przy tym już jakieś proste modele, na pewno nie przyniesie żadnego efektu. To, co każdy amator powinien wiedzieć i doskonale znać, to podział etapów tworzenia gier komputerowych. Skąd mamy je znać, skoro nigdy nic nie stworzyliśmy? Na pewno dobrym początkiem będzie przeczytanie jakiegoś artykułu na temat tworzenia gier, zanim takową tworzyć się zacznie. Umówmy się – designer sam gry nie zrobi. Przynajmniej nie ten młody. Owszem, istnieją narzędzia dające ogromne pole do popisu choćby systemami skryptów wizualnych i budową obiektów na bazie BSP, ale mało-zaawansowany, początkujący twórca sam nic nie wskóra.

Załóżmy, że przeczytaliśmy już jakąś książkę – dajmy na to The Art of Game Design. Zaryzykuję stwierdzeniem, że po takiej lekturze, będziemy wiedzieć, jak powinienem stworzyć dokumenty projektowe mojej wymarzonej gry. Podstawowym zagadnieniem jest dokument. Dokument projektowy. Zaraz, po co robić dokument projektowy, jeśli chcę zrobić grę?
Cały sęk polega na tym, że amatorzy prawie ZAWSZE opuszczają/pomijają ten ważny dla projektu moment. Tak naprawdę, wszystko, co znajdziemy w grze, powinno być wcześniej dobrze przeanalizowane i zaprojektowane. Duże gry mają to do siebie, że jest bardzo wiele czynników zależnych od siebie, wpływających pośrednio na jeszcze inne. Co poleciłbym zrobić najpierw?

Przede wszystkim, dokument wizji projektu. Szybki, dwustronnicowy dokument opisujący pomysł gry. Najlepiej zawrzeć tam takie informacje, jak docelowy target projektu (do kogo gra ma trafić), technologię projektu (2d/3d, jeśli mamy na oku jakiś silnik to jaki) oraz skrótowy opis mechaniki gry (co ma dawać frajdę graczowi), świata gry (jak wygląda, jak duży, czy fikcyjny…) i fabuły (co się stało, jakie były tego konsekwencje, w jakim momencie rozpoczynamy rozgrywkę, co musimy zrobić, do czego dążymy).
Dzięki takiemu dokumentowi, jesteśmy w stanie ocenić grę wstępnie. Fajnie by było, gdyby po napisaniu takiego dokumentu, przespać się z tym, przeczytać go rano, wprowadzić lekkie zmiany. Poczekać. Po prostu poczekać dzień/kilka dni, żeby się upewnić, że to co jest, jest interesujące, ma szansę się ,sprzedać” w oczach graczy.

Dopiero po napisaniu takiego dokumentu, możemy pójść o krok dalej. W moich oczach, tak jak ja to robię, kolejnym krokiem powinien być coraz to bardziej szczegółowy dokument opisujący mechanikę gry. Rozłożenie całej mechaniki na systemy pierwsze, co dlaczego po czym i tak dalej. Ja osobiście, rozpoczynając projekt takiego dokumentu, spisuję na kartkę punktami featursy mechaniki. Robię z tego diagram, co następuje po czym, jak to ma działać, co na co wpływa. Dopiero po ułożeniu takiego diagramu, siadam do szczegółowego opisywania każdego z elementów mechaniki w formie tekstu. Pomocne w takich dokumentach są wstawki takich diagramów, czy to zrobione ręcznie, na tablecie graficznym/zeskanowane czy zrobione za pomocą jakiegoś prostego UMLa. Ważne, żeby rozpisać w tym dokumencie, wszystkie możliwe do użycia w grze przedmioty, opisać interakcję z postaciami, stworzyć jak najbardziej technicznie szablony obiektów/postaci. Może to ogromnie pomóc przy składaniu całej gry w edytorze/pisaniu jej ręcznie. Dzięki takiemu zabiegowi, jak tylko zabierzesz się do pisania gry/Twój programista się zabierze do pisania gry, po przeczytaniu takiego dokumentu, wystarczy przerobić to co czyta na odpowiedni algorytm, bez rozmyślania, jak to wszystko upchnąć w klasę, node itp. Staramy się operować wartościami liczbowymi, takimi jak miałoby to finalnie wyglądać – np damage danej broni. Wiadomo, to jest element, który będzie mocno polishowany (dopracowywany) podczas prototypów. Może się okazać, że to co zaprojektowałeś, ma słabe odniesienie w gameplayu – postać za szybko umiera, wtedy trzeba będzie te wartości troszkę przerobić. Z dokumentem mechaniki postępujemy tak samo, jak z dokumentem wizji. Musimy się z nim przespać. Jeśli chcemy zrobić go dobrze, nie zrobimy go w jedną ,sesję pisenniczą”. Projektując taki dokument, staram się robić przerwy co kilka ,modułów” mechanicznych. Tak, żeby mózg trochę odpoczął, złapał świeży oddech. Samo staranne projektowanie takiej mechaniki zajmuje kilka dni, później dzień/dwa odpoczynku, przeczytanie wszystkiego od nowa, wprowadzenie poprawek. Co dalej? Mając taki dokument, możemy być już pewni… Że jeszcze nieraz go zmodyfikujemy, zanim zaczniemy właściwą produkcję gry. Póki co, pracujesz sam, nikt Cię nie pogadania, więc nie ma żadnego stresu, możesz to robić swoim tempem – z czasem nabierzesz wprawy i każdy kolejny proces, będzie trwał coraz szybciej. To, co zajmuje Ci teraz tydzień, za jakiś czas zajmie Ci 3 lub 4 dni, czasem nawet nie.

Ok, mamy dokument mechaniki. Co teraz? Czy to znaczy, że mogę działać? Teoretycznie tak. Ja jednak nalegałbym, abyście zajęli się kolejnym aspektem gry, czyli jej światem, lokacjami i postaciami/npcami. Zaprojektowanie jak najwięcej ze świata gry, ułatwi prace w kolejnym etapie. Warto poświęcić na to ogrom czasu, który później nie będzie za nami chodził przy implementowaniu systemów i tworzeniu assetów. Mając dokumenty opisów świata, lokacji (w takim dokumencie lokacji, możemy – a raczej powinniśmy – opisać jakie postacie znajdziemy w tym levelu, jaki jest cel naszej wizyty w tym levelu, jakie potwory tu znajdziemy i tak dalej – w tym nawet spis obiektów, które dla danego levelu będzie trzeba wymodelować) możemy przystąpić do stworzenia scenariusza gry/storyboardów, które opiszą przebieg leveli. Nie warto robić od razu scenariusz na całą grę – musimy wiedzieć, jak gra ma się zakończyć, ale w szczegóły w tym etapie wchodzić nie musimy. Zaprojektujmy szczegółowo, ze storyboardami, scenariuszem jeden, może być to pierwszy, level. Wuala.

Faza kilkutygodniowego projektowania, poprawiania swoich błędów, wykreślania bezsensownych featursów dobiegła końca. Możemy zacząć jechać z prototypami elementów mechaniki. Najlepiej tworzyć małe, konkretne prototypy konkretnych zastosować mechaniki – prototyp sterowania, prototyp systemu strzelania, prototyp questów, prototyp dialogów itp dzięki temu będziemy mogli ocenić przydatność i ,fajność” każdego z elementów. Mając takie prototypy, wiemy co trzeba zmienić w mechanice – co przeprojektować, co wywalić, a co koniecznie dodać. Ważne, aby w tym momencie nie dodawać nie wiadomo ilu featursów, skupmy się na tych najważniejszych. Pamiętaj, aby w momencie projektowania mechaniki, świata gry, fabuły starać się nie zmieniać ogólnych założeń z dokumentu wizji gry. Jak już zaakceptowaliśmy wizję gry, musimy się jej trzymać do końca, inaczej – kiszka. Po re-designie dokumentów dzięki prototypom, możemy przejść do następnej fazy. Właściwie milestone’a. Tutaj, mając już całą gotową mechanikę, wiedząc jak gra będzie wyglądać faktycznie, projektujemy całą grę – kolejne levele, przebieg akcji na levelu, questy, dialogi. Dopiero mając całą grę na papierze, przechodzimy do produkcji – klepanie kodu pod gameplay, składanie mechaniki w całość, eliminowanie błędów, tworzenie modeli i tekstur, składanie wszystkiego w edytorze… To tutaj widać najwięcej efektów naszej pracy. Jeśli dobrze przeprowadzisz fazę konceptu, projektowania i będziesz w tym miejscu, szczere gratulacje. Od tej pory do końca projektu, dzieli Cię… Kupa, masa, ogrom pracy. Ale nie załamuj się – coraz więcej będziesz widział efektów, coraz ładniej będzie wszystko wyglądało. Musisz być zdeterminowany i nie odpuszczać. BROŃ BOŻE nie zmieniaj żadnej wizji, nie ingeruj już w dokumenty mechaniki, chyba, że to naprawdę konieczne, żeby ukończyć projekt – pamiętaj, żeby mierzyć siły na zamiary. Przy prototypowaniu wychodzi, czy jesteś w stanie zaprogramować/oskryptować dany element, jeśli nie – odpuść go, lub przeprojektuj tak, abyś był w stanie to zrobić. Nie ma co się porywać z motyką na słońce.

Kolejną fazą po zaimplementowaniu wszystkiego jest testowanie, poprawianie błędów i tak w kółko. Jeśli dojdziesz już tutaj, prawie pewne, że Twoja gra zostanie ukończona. Nawet jeśli podwinie Ci się noga, nie będzie wstydu opublikować tego, co już masz. Będąc w tej fazie, Twoją grę da się już na pewno przejść, z błędami, z brakami, ale się da. Co jest w tym wszystkim najważniejsze? Nie tracić wiary. Jak brakuje Ci zapału, nie masz pomysłu, czujesz, że się lekko wypalasz – odstaw projekt na kilka dni, odpocznij, najlepiej od komputera, wyjdź z domu. Po kilku dniach wrócisz, będziesz silniejszy, bardziej zdeterminowany. Nie wolno się przepracowywać – to jest tylko hobby, póki nie pracujesz w branży, rób tyle na ile masz siłę. Nikt Cie nie goni, rób sobie powoli to co chcesz, zbieraj doświadczenie. Gwarantuję Ci, że nawet jeśli podejmiesz się próby wyprodukowania 10 tytułów i każdy z nich upadnie, z każdego wyciągniesz lekcje. Nauczysz się wielu rzeczy. Jeśli jednak trafi Ci się aż tyle porażek – zastanów się mocno, co robisz nie tak, zweryfikuj to i zmniejsz założenia. Doprowadź chociaż jeden, mały projekt do końca, poczuj jakie to uczucie coś ukończyć – a przekonasz się, że ostatnia faza, wcale nie jest fazą najprostszą i najprzyjemniejszą :slight_smile: .

Pamiętajcie, starajcie się – zanim zaczniecie wszystko implementować, tworzyć grafikę, muzykę itp – mieć wszystko, całą grę, zaprojektowaną, spisaną na papierze/w dokumencie wordu. Dziel sobie wszystko na dokumenty – osobne, nie rób tzw. Biblii, Game design doca. To już jest tak naprawdę przeszłość, mega nie praktyczny dokument. Łatwiej wszystkim zarządzać, wprowadzać zmiany, czytać dokumenty, które są podzielone na pewne kategorie, np. tak, jak opisałem w tym artykule.

Jeśli jesteś początkujący, zacznij od naprawdę małych projektów – typu pingpong, snake. Nawet taki projekt, wymaga (powiedzmy) fazy konceptu, projektowania. Dzięki temu, nabierzesz wprawy. Podziel sobie wszystko na elementy, zaprojektuj świat/levele w jakich gra ma się znaleźć, opisz szczegółowo mechanikę, technicznie, tak żebyś później konwertował treść dokumentu na algorytmy, bez zbędnego do-wymyślania w trakcie programowania. Daję Ci słowo, że takie podejście do sprawy, zaowocuje – jeśli jesteś programistą, będziesz dobrze projektował swoje programy, swój kod. Jeśli jesteś designerem – nauczy Cię to pewnych zasad panujących w game devie. Ściągnij Unity, UDK naucz się je obsługiwać – projektuj i prototypuj. Nie trzeba grafików, nie trzeba programistów. Twórz gray boxy/mapy bsp według opisów lokacji, na nich opieraj swój gameplay. Do Unity jest masa addonsów, w tym darmowe języki skrpytowe-wizualne, dzięki czemu nawet bez umiejętności programowania jesteś w stanie zrobić swoją wymarzoną grę – jej prototypy.

Niech etap projektowania, pisania dokumentów Cię nie nudzi, nie możesz go omijać. Nie ważne, czy jesteś designerem czy programistą – nawet programista projektuje swój kod zanim go napisze. Musisz przez to przejść, im wcześniej i dokładniej, tym lepiej.

Mam nadzieję, że komuś mogę pomóc - jeśli masz pytania, chciałbyś się o coś spytać, pisz śmiało: konicki.jakub@gmail.com


[Android] EASY Game 2 - nowa darmowa gra
Mega klimatyczny FPS w starym stylu szukam pomocy-ekipy-porady
#2

@konicki_jakub przeniosłem Twój artykuł z Gamedev.pl


#3

bardzo fajny artykuł :slight_smile: przyda się nowym bo to jest bardzo ważny etap w tworzeniu Projektu


#4

A post was split to a new topic: Unity 5 MySQL Rejestracja i Logowanie cz. 2


#5

Witam grając w gry wkurzali mnie nie uczciwi ludzie tacy jak w taernie .Myśleli jak stworzyli toł grę to wszystko im wolno przeklinać killac idt,…Dlatego chciał bym załorzyć nowoł grę albo dołonczyć się do czyjejś czy ktoś może zainteresowany ?


#7

Ciekawy artykuł - sporo uświadamia. Rzeczywiście jest różnica między teoretyzowaniem na temat tworzenia gier - a praktyką.

Trochę brakuje mi informacji o tworzeniu samej mechaniki - jakie opcje są dostępne, jak mechanikę wizualizować, opisywać. Ale nie czepiam się - bo widać, że artykuł napisał praktyk :slight_smile:

Mogę jednocześnie polecić swojego bloga i artykuł na nim - 9 skilli, jakie powinien mieć dobry projektant gier - może się przydać w omawianym temacie:


#9

Artykuł interesujący, ale tytuł ("… od czego zacząć") nie do końca oddaje to co w nim jest. Ktoś kto nigdy nie tworzył gier (a trafi tutaj, po wpisaniu tego hasła w google), nie szuka raczej wiedzy o tym, że zacząć należy od spędzenia miesiąca na opisaniu całej gry w dokumentach. Ten artykuł da mu interesujący pogląd na to, jak wygląda profesjonalne tworzenie gier i prawdopodobnie zniechęci go, gdyż przedstawione jest to tutaj jako ciężka i mozolna praca, a nie jako coś przyjemnego.

“Od czego zacząć?”, na pewno nie od myślenia o tym, jakie to wszystko jest trudne i na pewno nie od nauki pisania dokumentów projektowych. Oczywiście to tylko moja opinia. Jeśli chcecie nauczyć się jak robić gry w prosty i przyjemny sposób, bawiąc się przy tym, to przeczytajcie kurs tworzenie gier od zera.


#10

Od siebie podrzucę wywiad ze scenarzystą Wiedźmina, o tym jak stworzyć wciągającą grę:
https://geek.justjoin.it/scenarzysta-wiedzmina-o-tym-stworzyc-wciagajaca-gre/ :slight_smile: