Producent a udźwiękowienie i strona wizualna projektu.

Będę szczery. Producent ma na te tematy wyjebane. Jest osoba, która trzyma jakość contentu w dobrej formie, jeśli Producent jest osobą kompetentną może się tym zająć, choć raczej lepiej będzie jak skupi się na produkcji a nie jakości assetów.

To co producent robi to:
– Review projektu. Wiąże się z review grafiki, dźwięków etc. Może dawać komentarze tym, którzy odpowiedzialni są za ten aspekt (Art Director). Jeśli review jest co tydzień, Producent tak czy siak bierze udział w kreacji assetów.
– Często zdaża się, że ktoś prosi Producenta bądź Producent sam ogląda assety i daje do nich uwagi/komentarze. Generalnie tak czy siak to powinno przechodzić przez Art Directora i powinno być ustalane razem, tak by nie było sytuacji gdzie ktoś dostał zadanie od Art Directora a Producent zmienia je bez wiedzy Art Directora. Robi się wtedy po prostu burdel i zamieszanie
– To co Producera powinno interesować to Pipeline. Czyli jakie processy muszą zaistnieć by dany asset znalazł się w grze i czy pipeline jest optymalny.
– Producent musi sprawdzać czy pipeline jest optymalny (np. czy łatwo będzie można wprowadzić zmianę do danego assetu bez konieczności rekompilowania czegoś, czy techniczne aspekty są łatwe do zrozumienia i czy osoby tworzące assety bez problemu sobie z nimi radzą, czy pliki są odpowiednio podzielone, czy potrzeba większego podziału (może na layery, prefaby). Jeśli producent tego nie będzie ogarniał i nie sprawdzi pipeline’u ujebie projekt, bądź samemu da nagrodę innym – crunch-time.

Producento-Designer bądź Producento-Grafik to jest jeden wielki crap. Wpierdala się w design, wpierdala się w grafikę a nie zajmuje się tym czym powinien się zajmować. Moim zdaniem jak masz w firmie producenta który zajmuje się jakością assetów bądź designem – masz przejebane. Producent wtedy będzie się skupiał na tych rzeczach, a nie na produkcji.

Oczywiście to jest tylko i wyłącznie moje zdanie na podstawie własnego doświadczenia (pracowałem z producentami-grafikami, producentami-designerami, każdy dawał dupy po całej linii, podstawy kuleją). Ktoś mądry może powiedzieć, że taki producent jest lepszy, bo wie więcej i ogarnia więcej spraw, ale w praktyce wychodzi to tak, że ogarnia wszystko to czego ogarniać nie powinien. Producent ma wgląd na wszystko, wszystko może komentować, dawać feedback, rozmawiać z wydawcą co myśli o grafice etc etc. Producent ma cały ten zajebiście duży motor rozpędzić i trzymać na najwyższych obrotach przez cały czas trwania projektu, a nie siedzieć z grafikiem mu przestawiać pixele.

Generalnie tematy mi się skończyły, więc jeśli chcielibyście bym o czymś napisał, macie jakieś pytanie – piszcie, postaram się szybko na blogu odpisać.

Wydawca tez robi gre

Czasem zastanawiam się czy to tak wypada cisnąć wydawcę/klienta o różne rzeczy, skoro to on płaci za produkcje gry…czasem czuje się tak jak by to wydawca robił grę a ja bym mu mówił co ma robić i na kiedy…czy ktoś z Was też ma taką sytuację? Bardzo mnie to zastanawia, współpracując z wydawcami oni robią dla developerów zawsze masę rzeczy, też ich cisniecie konkretnie po dupach czy zlewacie temat (w końcu to oni zlecają) ? Tak tak, jest kontrakt w którym są requesty dla Wydawcy, ale często one są po prostu zaniedbywane z powodu braku czasu. Czy ktoś z Was też konkretnie wymusza w wydawcy działanie? Czy to ze mną jest coś źle i powinienem przytulnie czekać na wydawcę i się nie odzywać?

Znając życie i tak nikt mi nie odpowie, bo w Polsce oczywiście jest tendencja do; „Sorry nie chcę dzielić się wiedzą jaką zdobyłem”, dajcie spokój. Wszyscy jesteśmy na tym samym polu bitwy.

Wena kiedyś a dzisiaj…

Wczoraj miałem ciekawą rozmowę na temat weny ze znajomymi…pewnie nie jeden z Was pamięta czasy gdy starało się uczyć robienia gier gdy nie było dostępu do internetu, była Amiga, było Commodore…to były czasy. Pamiętam jak nie raz pędziłem do znajomka ściągnąć sobie jakiś tutorial o programowaniu, a w domu przez 2 tygodnie go rozgryzałem, nic mnie nie rozpraszało, nie było facebooka, nie było gg, nie było skype’a, nie miałem internetu. Mogłem w pełni skupić się na zajawce. Pamiętacie te zajebiste czasy? Gdzie każda mała rzecz nas cieszyła (malutki tutorial) i z czegoś takiego się uczyliśmy…jak dużo byliśmy w stanie się nauczyć i jak bardzo się skupić…ciężko to ogarnąć na trzeźwo. Pamiętam jak uczyłem się 3dsMaxa z Helpa, nic mnie nie rozpraszało, rozkminiałem cały system, sam, z kawką, bez stresu i pytania „Co dalej?”, „Czy robię dobrze?, „Czy idę dobrą drogą?”, „Czy na pewno tak to ma być?” Miałem tyle czasu i zaangażowania, że w dupie miałem takie pytania – po prostu robiłem, działałem, miałem wkręte konkretną.

A jak jest teraz?
Dostęp informacji jest ogromny. Przykład: zacząłem się uczyć UDK tak weekendami, albo jak mam czas po robocie. Patrzę, parę książek o UDK, 30GB video tutoriali, miliard tutoriali na necie…jedno pytanie w głowie „Kurwa, jak mam się do tego zabrać?”. Jak bym nie miał netu i żył parę lat temu, poszedł bym do znajomego, sciągnął bym sobie jeden tutorial i rozgryzał bym go parę dni. Teraz oglądając video tutoriale w drugiej części ekranu czytam książke, a w głowie tylko myślę „Co mam dalej robić, którą książke przeczytać, jakiego tutoriala się nauczyć” KURWA! Jak już zacznę coś pisać ktoś się odzywa na skype/gg/icq – obojętnie. Przez to, że jest taka zajebista łatwość w znalezieniu informacji ludziom robi się burdel z głowy. Ile razy czytam przecież tematy w stylu „Czy warto uczyć się C++?”, „W jakiej kolejności mam się uczyć jakiegoś silnika?”, ta łatwość informacji otempia ludzi, chcą wszystko jak najszybciej zrobić, jak najszybciej kazdą część wiedzy w internecie po prostu kurwa zjeść. Niestety przez coś takiego uczymy się tak naprawdę może 30%, reszta idzie w las, bo się po prostu nie skupiamy. Ucząc się czegoś w pewnym momencie mówimy sobie „Już to umiem, idę dalej”, przez to nic się  kurwa nie uczymy. Przez właśnie coś takiego amatorskie projekty gier nie potrafią dojść (bez skojarzeń) do końca, bo team zdaje sobie sprawę w pewnym momencie, ze Pac Man, którego robią jest już na takim etapie designu, że mogą zacząć robić coś bardziej skomplikowanego – np. cRPG.

DOŚĆ KURWA! Zróbmy coś z naszymi głowami, postarajmy się znów uczyć się tak jak kiedyś…spokojnie, bez ciśnienia na wiedzę…spokojnie, bez pośpiechu, nauczmy się czegoś konkretnie zamiast po omacku. Chłońmy maksimum wiedzy z minimalnego tutoriala 🙂 Było by fajnie. Najlepiej było by zamknąć się bunkrze bez wifi 😛

UDK

Ci którzy chcą sobie szybko zrobić prototyp bądź nauczyć się czegoś w związku z tworzeniem gier:

1. Ściągaj UDK

2. Ściągaj wszystkie video tutoriale

Z UE3 ostatnią styczność miałem 2,5 roku temu i przyznam, że teraz wygląda to całkiem całkiem. Licencja dla UDK jest z dupy, ale engine do prototypowania czy POFów jest zajebisty.

Krytyczne zarządzanie projektem

Krytyczne zarządzanie projektem jest moim słówkiem i nie ma raczej takiego stwierdzenia w branży, ale jakoś musiałem sobie to nazwać. Generalnie pewnie nie raz pod koniec projektu bądź przed milestonem mieliście tak że macie 500 błędów do naprawienia a czasu tyle by zrobić 50. Co w takich wypadkach robić?

Generalnie najważniejszy jest team. To co ludzi wkurwia/stresuje to termin i ilość pracy do wykonania, musisz to zminimalizować, zminimalizować stres – team musi się czuć bezpiecznie pod Twoim szyldem. To, że jest crunch time znaczy tylko tyle, że wyższe zarządzanie dało dupy przy produkcji i organizacji pracy. To jest tylko i wyłącznie Twoja wina i jak masz jaja musisz coś z tym zrobić.

Tak naprawdę krytyczne zarządzanie projektem zaczyna się już na samym początku, musisz się zabezpieczyć:

– Ile razy klient/wydawca prosił Cię o dodanie jakiegoś ficzera, którego nie ma w kontrakcie/GDD? To normalka, spisuj sobie takie rzeczy, każdy dodatkowy ficzer jaki zaimplementowałeś by być miłym dla swojego pracodawcy miej na kartce i aktualizuj taką listę. W trakcie crunch-time’u możesz dzięki takiej liście negocjować konkretne warunki z klientem. Przykład: Wydawca prosi Cię podczas crunch-time’u o zaimplementowanie 2 nowych ficzerów, Ty w takim wypadku możesz mu powiedzieć sorry stary ale zaimplementowaliśmy podczas całego trwania produkcji 100 dodatkowych ficzerów i niestety nie jesteśmy w stanie tego zaimplementować, za to skupimy się na dopracowywaniu i debuggowaniu gry, a ficzer o który prosisz zostanie dodany do listy ficzerów na następna wersję/dodatek/update/patch. Taka lista to złoto dla Producenta, czasami potrafi zdziałać cuda. Mała rzecz, nie bagatelizuj jej.

– Ile razy klient/wydawca chciał coś poprawić, zmienić,. przesunąć o 2 pixele w prawą stronę? Prawdopodobieństwo jest ogromne. Za każdym razem gdy zaczyna się tego typu dyskusja zadaj mu pytanie „Czy to Twoim zdaniem ma ogromny wpływ na gameplay/fun?” Jeśli nie to wypierdalaj takie rzeczy z głowy osobom po stronie wydawcy. Po czasie się nauczą i będą do Ciebie uderzać z rzeczami związanymi z gameplayem bardziej. Rzeczami bardziej major.

– Wydawca/klient musi mieć poczucie, że tworzy projekt z developerami – skup się na tym. Dzięki czemu szybciej wydawca/klient się podjara i łatwiej będzie go zmotywować do wyrzucenia paru ficzerów.

OK, pomijam tutaj rzeczy podstawowe jak prowadzenie projektów, spotkania, odpowiedni pipeline etc etc etc. Załóżmy, że sam developing jest zorganizowany idealnie, ale komunikacja z wydawca/klientem leży i kwiczy.

To co to jest w końcu to krytyczne zarządzanie projektem? Każdy producent musi ciągle analizować progress projektu, im szybciej zauważysz, że nie team nie wyrobi się na czas ze wszystkim tym lepiej. Jak będziesz na bieżąco z projektem taki moment wychaczysz w mgnieniu oka. Co zrobić mając 300 issues, a wiesz, że w takim terminie jesteś w stanie zrobić 50? Generalnie jest wiele osób, które nie robi nic z tym tylko każe teamowi siedzieć po godzinach/ w weekendy co jeszcze bardziej zmniejsza efektywność pracy. Moim zdaniem Producent to osoba która unika crunch-time’u, która wspiera team i napierdala wydawcę po dupie. Weź się w garść, spotkaj się ze swoim wydawcą i przewertujcie każdy issue zadając sobie pytania w stylu:
– czy to ma duży wpływ na fun/gameplay?
– czy na pewno to jest tak bardzo ważne?
– czy to nie wiąże się z innym nowym ficzerem?
– czy nie lepiej będzie to zrobić tak: ‚podaj prostrze rozwiązanie’?
– czy jesteśmy w stanie ten minor issue wrzucić do update’a/patcha – możemy skupić się tylko na poważnych rzeczach?
Im dłużej będziesz rozmawiał z wydawcą tym więcej issues Ci zniknie. Czasem nawet do 40%.

Spotkaj się znów z wydawcą. Niektórzy ludzie nie zdają sobie sprawy jak ważny jest etap polishingu/debuggowania i wrzucają ficzery 2 dni przed Goldem. Wytłumacz mu na czym to polega i co gra straci jeśli będziemy coś dodawać/zmieniać a co może zyskać jak skupimy się na polishingu.

Porozmawiaj ze swoim teamem. Przewertujcie każdy issue jeden po jednym, zastanówcie się jaki priorytet ma każdy jeden issue. Zacznijcie naprawiać te z największym priorytetem. Wytłumacz teamowi do czego dążycie, dlaczego chcecie to zrobić i co najważniejsze uspokój ich. Najgorsze jest gdy ktoś przez stres Ci po prostu wymięknie. Wtedy dopiero będziesz w ciemnej dupie. Weź podejście w stylu „Zróbmy tyle ile się da by gra była dopracowana, bez poważnych błędów – niech będzie jeszcze bardziej zajebista!”

Po filtracji zostanie Ci jakieś 150 issues, w tym pewnie jakieś 30 issues z wysokim priorytetem. Teraz musisz lizać dupę wydawcy. Pokazuj mu progress z dnia na dzień. Ważniejsze issues = wiążą się z gameplayem, więc każdy jeden = widoczny progress. Pokazuj go, chwal się, chwal tak by wydawca myślał, że to dzięki jego wiedzy i feedbacku. Odpowiednio wcześniej przed milestonem musisz wyczaić moment gdy wydawca jest tak podjarany, że będzie w stanie Ci odpowiedzieć na pytanie:
– Dobra to powiedz mi co musimy zrobić by mieć zaakceptowany milestone? Skupiając się jak dotychczas na najważniejszym co Twoim zdaniem musimy jeszcze zrobić?

I w taki sposób dostaniesz listę 20 issues jeśli dobrze Ci poszło z resztą, które pewnie zrobisz z lekką obsówą, ale bez crunch-time’u, team będzie miał siły na kolejny milesteone, wydawca będzie bardziej poinformowany, Ty będziesz miał czas na polishing gry. Wszyscy będą happy. Oczywiście liczby które podawałem są czysto teoretyczne bardziej chodzi mi o etapy krytycznego zarządzania. Gdy zanalizujesz sobie tego posta bardziej dokładnie będziesz w stanie dostrzec te etapy i momenty krytycznego zarządzania.

Miło by było gdyby wszystkie firmy miały to na uwadze, mieli byśmy lepsze gry i bardziej zadowolonych pracowników.

Jak dobrze zacząć amatorski projekt?

Postaram się opisać jak moim zdaniem dobrze jest zacząć tworzenie amatorskiego projektu gry.  Pierw może powiem na czym będę się skupiał, jeśli jakaś z poniższych wypowiedzi nie będzie pasować do Twojego myślenia odnośnie przyszłości takiego amatorskiego projektu możesz już teraz zamknąć tą stronę i poszukać innego arta na ten temat. Założenia:

– Chce stworzyć zajebiście grywalną grę,
– Chcę by assety również były zajebiste (grafika, teksty, muzyka)
– Nie chcę kończyć na jednym projekcie,
– Chciałbym taką grę wydać,
– Chciałbym stworzyć studio/grupę ludzi tworzących gry.

Ktoś może mieć po prostu założenie „Chcę stworzyć nowe zajebiste MMORGP” – podobnych założeń niestety opisywać nie będę. No to do dzieła. Od czego tak naprawdę wystartować jak jesteśmy sami? Potrzebujesz koordynatora/producenta/project managera – jak zwał tak zwał, ale generalnie osobę, która będzie organizowała pracę i posuwała ją do przodu. Założymy, że taką osobą będziesz Ty, więc musisz pierw się nieco poduczyć i zdobyć tą podstawową wiedzę:  to, to, to, to, to, to, to, to, to, to, to.

Generalnie chodzi o to byś parę tygodni/miesięcy poświęcił na zbieranie informacji z każdego zakresu. Zarządzanie, design, programowanie. Znajdź jak najwięcej książek i je po prostu czytaj, twórz notatki. Wszystkie te książki możesz znaleźć na rapidshare jak nie lubisz amazoona. Chcesz konkretnie zacząć musisz zdobyć jak najwięcej wiedzy.

Kolejnym krokiem jest programowanie. Naucz się podstaw C++ (Symfonia C++, bądź po prostu tutoriale z neta), stwórz prostego tetrisa czy coś w ten deseń. Chodzi o to byś miał podstawy programowania i wiedział mniej więcej jak może wyglądać szkielet gry. Gdy już będziesz pewny, że wiesz jakie etapy występują w produkcji gier, jak wygląda tworzenie ich od wewnątrz znajdz sobie silniczek, na którym zrobisz samemu swoją pierwszą grę. Proponuję do tego silnik Novashell. Gdy się zmusisz i zrobisz na nim prostą grę – będziesz gotowy do zaczęcia swojego amatorskiego projektu. To co powyżej napisałem może Ci zająć pół roku. Pamiętaj – wiedza nie idzie w błoto. Oczywiście większość wiedzy przyjdzie z doświadczeniem, ale te podstawy powinieneś mieć. Wiele osób, które chce zacząć swój projekt omija ten krok – nie zrób tego błędu. Im więcej będziesz wiedział bym bardziej profesjonalnie będziesz się zachowywał przez co inni będą inaczej Cię odbierać. Jak zaczynałem Burżuazję nikt z osób z którymi pracowałem nie miał pojęcia o tworzeniu gier – ja miałem minimalne informacje, które spożytkowałem. W dzisiejszych czasach ludzie raczej już mają te minimalne informacje, które ja kiedyś miałem – więc teraz Ty musisz mieć znacznie więcej w głowie. No ale dosyć biadolenia. Załóżmy, że przeczytałeś 15GB książek, nauczyłeś się podstaw c++ i napisałeś w nim tetrisa, nauczyłeś się jakiegoś prostego silniczka i zrobiłeś na nim prostą gierkę. Co dalej?

ZACZYNASZ OD POMYSŁU!
Wciąż w Twojej własnej norce pracujesz sam. Myślisz jaki projekt mógłbyś zacząć robić, z mojego doświadczenia mogę Ci powiedzieć, że:
– Pomysł na grę musi być na tyle wykurwisty by większe grono osób po samym przeczytaniu pomysłu mogła by powiedzieć „To będzie zajebiste!”. To wiąże się po prostu z zainteresowaniem. Musisz mieć zainteresowanie jak chcesz zebrać odpowiedni team.
– Niestety musisz znaleźć optymalną granicę pomiędzy ‚zajebisty super innowacyjny projekt’ a ‚do zrealizowania’.  To wiąże się z możliwością skończenia projektu.

Pamiętaj – proste pomysły często są najlepsze. Flow jaki Ci proponuje w wymyśleniu gry to:
– Dowiedz się jaki typ gry najbardziej by Ci pasował (strategia, point & click, etc etc)  i wybierz,
– Pograj w gry z kategorii jaką wybrałeś,
– Poczytaj komentarze/recenzje gier z kategorii jaką wybrałeś,
– Przez cały ten czas Twórz sobie notatki w stylu („Chcę by rozwijanie postaci było bardzo rozbudowane”, „Chcę by gra była nieliniowa”, „Chcę by można było tworzyć w niej przedmioty” )
– Jak już będziesz miał 1-2 strony A4 takich uwag (fontem nie mniejszym niz 12 :P) zacznij zagłębiać się w każdy z tych tematów. Rozwiń te tematy o kolejne myślniki.

Gdy już dojdziesz do etapu gdzie więcej nie wymyślisz, znajdź odpowiedzi na te pytania:
– Kto jest bohaterem gry (tzn kim będzie się grało)?
– Gdzie rozgrywa się gra (świat, lokacje)?
– Dlaczego bohater znalazł się w świecie gry (historia)?
– Co bohater musi zrobić by przejść grę? (jaki jest główny cel gry)
– Co bohater będzie musiał zrobić by progressować game-flow? (jakie są mniejsze cele – przykładowo: „Zabicie 100 przeciwników” , „Przejście wszystkich poziomów”, „Zdobycie wszystkich archiwementów” )
– W jaki sposób gracz będzie widział grę? (czyli jakiej kamery chcesz użyć)
– W jaki sposób gracz będzie sterował swoją postacią? (controlsy)
– Jak wygląda główny element gameplayu? (czyli co gracz głównie będzie robił w grze – jeśli walczył to przydało by się wiedzieć jak taka walka ma wyglądać)

Mając odpowiedzi na podstawowe pytania wiesz już mniej-więcej co chcesz zrobić. Zastanów się teraz czy aby za bardzo ambitnie nie podchodzisz do sprawy, weź pod uwagę, że nie masz 300 ludzi i profesjonalnego studia – jeśli masz jakieś wątpliwości zacznij kroić pomysły albo po prostu wymyśl coś innego. Generalnie jeśli Tobie trudno jest wymyślać takie rzeczy pewnie masz znajomych graczy, którzy mogą Ci w tym pomóc. Mi przy Burżuazji cały design robiło parę osób. Już na tym etapie konsultowałem się z innymi bo samemu po prostu nie potrafiłem nic fajnego wykminić 🙂

OK, załóżmy, że Twój pomysł jest:
– zajebisty, na pewno ludzie będą zainteresowani taką grą,
– prosty i będzie dało radę się go zrobić bez większych problemów

Co dalej?

WSTĘPNA DOKUMENTACJA
Ładnie spisz wszystkie najważniejsze informacje w jakimś dokumencie. Dodatkowe informacje również zawrzyj, ale na końcu dokumentu. Dokument twórz od ogółu do szczegółu. To nie ma być Game Design Document (GDD), tylko w 2-3 stronach opis gry, która chcesz stworzyć. Dokument podziel sobie na rozdziały (gracz, controlsy, kamera, gameplay, historia, swiat etc etc) zreszta czytając książki będziesz już wiedzieć jak najlepiej jest napisać taki dokument.

Na jakich platformach będzie można pograć w Twoją grę? Tak naprawdę to pytanie powinieneś sobie zadawać ciągle, ale chciałbym byś na początku o tym nie myślał, tylko później wrócił jeszcze raz do projektowania. Twój pomysł powinien być łatwo przeniesiony na inne platformy. Gdy zaczniesz jeszcze raz myśleć o projekcie (kreowanie pomysłu) zastanów się jak gra mogła by się zmieścić na mniejszym ekranie i czy można by było nią sterować w inny sposób niż wymyśliłeś.

Gdy już będziesz pewny, że Twoja gra będzie grywalna na różnych platformach zabierz się za zaktualizowanie dokumentacji. Tam gdzie masz opis sterowania i kamery opisz jak wyglądać to będzie na innych platformach. Możesz stworzyć parę mockupów, dzięki czemu też przemyślisz dogłębnie sprawę HUDa/MENU, będziesz mógł zaktualizować dokumentacje o kolejne rozdziały.

Generalnie w firmach te wszystkie etapy są pomijane, robi się po prostu spotkania, myśli się nad nowymi pomysłami etc etc – ale mówimy o amatorskim podejściu, w domu, po godzinach, bez wiedzy. Dobrze, mamy wstępną dokumentacje, co dalej?

CZY JESTEM W STANIE ZROBIĆ PROTOTYP?
Pewnie nie, ale jak jesteś ambitny i zdeterminowany – dasz radę. Musisz dowiedzieć się czym jest gamedev – jest to bardzo trudna praca, choć bardzo kreatywna (nie zawsze, ale ogólnie tak) musisz zebrać swoje siły jak chcesz doprowadzić taki projekt do końca. Jesteś w stanie zrobić prototyp. Wybierz sobie wg Ciebie najprostszą platforme, znajdz silnik, który będzie prosty i w którym będziesz mógł zrobić taki prototyp (jeśli Novashell Ci nie wystarczy) . Nie skupiaj się na menu 🙂 Skup się na części grywalnej. Jeśli Twoja gra jest o kulce która ruszamy myszką by łamać jakieś logiczne łamigłówki – taki prototyp musisz zrobić z jednym poziomem. Prototyp ma przedstawić core Twojego pomysłu. Placeholderowe assety znajdziesz w necie bez problemu. To może być kolejne pół roku ciężkiej pracy dla Ciebie, a może się okazać, że taki prototyp zrobisz w 2 tygodnie. Nawet jak nie masz na tyle doświadczenia programistycznego – naucz się języka jaki potrzebny Ci jest do stworzenia takiego prototypu. Wiele się nauczysz, a nawet jak nie uda Ci się zrobić prototypu Twoja wiedza nie zniknie. Jeśli Twoja gra jest za skomplikowana na to byś mógł zrobić prototyp – wróć się i wymyśl coś innego. Wiem, chujowo, ale taki jest lajf.

Załóżmy, że zrobiłeś prototyp. Pokaż go swoim znajomym, zbierz uwagi – popraw go na tyle ile możesz. Nie pokazuj go publicznie.

PROTOTYP Z ASSETAMI
Kolejnym krokiem jest podmiana placeholderowych assetów na coś fajnego i zrobionego przez innych, chyba, że sam potrafisz Tworzyć muzykę, modele, teksury 😉 Generalnie nie wychylał bym się jeszcze na tym etapie nigdzie tylko poszukał bym ludzi na różnych forach (gamedev.pl, max3d.pl, digart.pl) i wysyłał bym spam na PMa z prośbą o stworzenie grafiki/muzyki. Stwórz sobie listę assetów do wykonania. Prędzej czy później znajdziesz ludzi, którzy Ci taką grafikę zrobią. By monitorować progress stwórz listę tych assetów w Google Docs (XLS), niech ludziki Ci zaznaczają co zrobili, a czego nie. Narazie cały Twój projekt jest u Ciebie na komplie więc wszyscy muszą Ci wysyłać wszystko na maila. Możesz na tym etapie szukać już repozytorium jakiegoś, gdzie wrzucisz projekt i każdy z grafików będzie mógł pograć i aktualizować resource. W czasie gdy inni tworzyć będą assety Ty możesz skupic się na dwóch rzeczach:
– dopracowywanie prototypu, rozwijanie go
– dopracowywanie dokumentacji, możesz zacząć tworzyć powoli GDD

Załóżmy, że masz już prototyp z super grafiką, jest super grywalny i wszystkim którym go pokazywałeś się podoba. Co dalej?

SZUKAJ LUDZI
Nie szukaj wszystkich. Znajdź pierw designera, który skończy GDD i jednego programistę, który rozwinie Twój prototyp i będzie brał udział w designie gry tak by Twój designer nie popłynał i nie zrobił Ci z tetrisa MMORPG. Jak szukać ludzi? Na forach, różnych. Pokazać możesz prototyp, wstępną dokumentacje. Ważne byś zrobił jakiś formularz zgłoszeń, może się okazać, że na jedno stanowisko zgłosi się parę osób. Możesz zrobić zadania testowe dla wszystkich i wybrać najlepszych (np. zadanie dla designerów – rozwinąć jeden rozdzial z GDD, dla grafików zrobienie jednej grafiki, a do programistów to już niestety musisz mieć smykałke – nie zmuszaj ich do spędzenia 3 tygodni by Ci coś zaimplementowali. Tak czy siak programiste potrzebujesz jednego, nie więcej.

Załóżmy, że masz już:
– Designera
– Programistę
– Grafika

REPOZYTORIUM / FORUM / DOTPROJECT
Wykombinować musisz repozytorium, forum na którym będziecie rozmawiać o projekcie/designie no i dotproject do organizacji zadań. Po przeczytanych książkach będziesz wiedział, że trzeba zrobić odpowiednią strukturę katalogów na repozytorium, programisty będziesz mógł wypytać się jakie informacje są mu potzebne do zaimplementowania danego modułu, a grafik będzie mógł zająć się opracowywaniem mockupów/konceptów tak by nie zaczynać tworzyć finalnej grafiki zanim wszyscy nie będą zgodzeni z klimatem gry.

PREPRODUKCJA
Wchodzisz w etap konkretnej preprodukcji. Jest to etap w którym kreuj się pomysł gry. Nie wychodź z tego procesu zanim:
– nie będziesz wiedział jaki klimat graficzny ma mieć gra (grafik) i zanim wszyscy w 3 będziecie się z tym zgadzać,
– nie będziesz miał skończonego GDD
– wszystko to co opisane jest w GDD zaakceptowane jest przez programistę
– masz listę modułów i zadań programistycznych na podstawie GDD dzięki których można będzie zaimplementować grę
– masz listę wszystkich grafik do wykonania w raz z uwagami technicznymi
– wiesz jaki jest pipeline assetów i jest on przetestowany i zaakceptowany przez wszystkich
– wiesz w jaki sposób będzie można sportować grę na inne platformy
– Twój prototyp rozwinięty jest na tyle by pokazywał główne części gameplayu (a nie tylko główną cześć) w raz z finalną grafiką
– Masz Sprint Plan projektu
– Masz rozpisane milestone’y projektu
– Wszystkie zadania do pierwszego milestone’u masz na dotproject
– Wiesz ile ludzi potrzebujesz dodatkowo i już ich znalazłeś
– Masz rozpisany TDD (techniczny design dokument opisujący metody implementacyjne, strukturę kodu, styl kodu ktorego trzeba sie trzymac, etc etc)

PRODUKCJA
Po Twojej i innych ciężkiej pracy przychodzi czas na jeszcze cięższą pracę 🙂 Tak jest w tej branży – im dalej, tym trudniej. Po przeczytanych książkach będziesz wiedział:
– by aktualizować zadania/plan jak się ktoś spóźnia,
– robić review gry co tydzień i spisywać błędy/uwagi w jakimś bugtrackerze (flyspray na przykład)
– trzymać źródła wszystkiego, tak by jak ktoś się wykruszy ktoś inny mógł go zastąpić,
– Aktualizuj listę assetów do wykonania byś wiedział na jakim etapie praca stoi
– Aktualizuj listę zadań implementacyjnych,
– Motywuj swoich ludzi, postaraj się z nimi spotkać na żywo przy wódce 😉
– Znajdź dobrego testera, który będzie testował każdy nowo zaimplementowany moduł,
– Szybko reaguj na występujące problemy, niczego nie bagatelizuj,
– Gdy dojdzie do jakiegoś milestone’a sprawdź czy aby na pewno wszystko z checklisty zostało zrobione, jeśli nie – zrób to zanim przejdziesz do kolejnego etapu, nie przepuszczaj milestone’a nawet gdy brakuje jednego SFXa,
– Nie wychodź z produkcji zanim gra nie będzie grywalna od początku do końca,
– Nie wychodź z produkcji zanim wszystkie placeholdery zostaną zastąpione finalnymi assetami,
– Nie wychodź z produkcji zanim wszystkie major bugi nie zostały naprawione,
– Nie wychodź z produkcji zanim wszystkie ficzery nie zostały zaimplementowane,
– Nie wychodź z produkcji zanim GDD nie zostanie zaktualizowane,

Parę dodatkowych informacji:
– Możesz na tym etapie zrobić stronę internetową gry = zwiększy motywacje
– Możesz już na tym etapie rozmawiać z wydawcami o wydawaniu Twojej gry
– Możesz myśleć o czymś w rodzaju in-app purchase w trakcie produkcji

QA
Zacznijcie grać i spisywać błędy do bugrackera. Co dziennie sprawdzaj bugtrackera i wyszukuj dziwne błędy/prośby tak by z Twojej gry nie wyszedł MMORPG. Filtruj bugtrackera codziennie i wyrzucaj zbędne rzeczy. Liczy się POLISH na tym etapie, a nie rozbudowywanie gry. Jak odpowiednio rozkminiłeś milestone’y – nie będziesz miał z tym problemów. Tak naprawdę jeden tester cały czas testował grę więc jako-takie QA już było w trakcie. Pełnego QA nie zaczynaj za wcześnie. Lepiej jest zagadać ze znajomym by pograł i dał Ci uwagi na etapie produkcji niż zaczynać QA wcześniej.

Na tym etapie powinieneś już mieć jakiś deal z jakimś wydawcą. Pamiętaj by się zabezpieczyć:
– jak największe revenue  (% z zysków)
– pierwszeństwo w tworzeniu kontynuacji
– prawa autorskie zostają w teamie
– możliwość wydania gry na jedną platformę
– kasa za podbicie dealu = motywacja dla zespołu
Generalnie to jest dużo, ale jest to do negocjacji wszystko jeśli Twoja gra jest naprawdę świetna i daje wiele funu. Nie możesz zamykać sobie po prostu drogi 🙂

To by było w sumie na tyle. Moim zdaniem taki flow jest dobry. Oczywiście jest wiele rzeczy które można by tu zoptymalizować, zacząć robić wcześniej etc etc, ale po co skoro pracujemy amatorsko? Liczy się kreatywna praca. Zazdroszczę wszystkim którzy tworzą amatorskie produkcje gdzie nie ma kasy. Kreatywna praca to powinno napędzać taki zespół. Cel. Mam nadzieję, że komuś się to przyda. Chciałbym bardzo by coraz mniej było osób które chcą stworzyć MMORGP a więcej ludzi, którzy naprawdę chcą robić gry i będą zdawać sobie sprawe jak przejebana jest to robota. W dzisiejszych czasach szczegółowe informacje o każdym z etapów jakie podałem masz na wyciągnięcie ręki. Ja sam kiedyś musiałem dochodzić do tego jak się Tworzy gry, miałem C64 i po prostu pisałem…teraz masz google, książki, tutoriale, silniki – kurwa potrzeba tylko kogoś z dobrym podejściem 🙂

Powodzenia życzę wszystkim tym, którzy tworzą amatorskie projekty – pamiętajcie o tym by zawsze myśleć do przodu, na dłuższą metę jeśli chcecie pracować w tej branży! <piwo>

Speedball 2 od Vivid Games

Dla tych którzy lubią Amigowe klimaty: http://polygamia.pl/Polygamia/1,107162,8500984,Speedball_powraca__tym_razem_dzieki_Polakom.html

Gra jest po prostu zajebista! Jak się pojawi na appstore dam znać 🙂

Jak ubić deal z wydawcą / inwestorem

Wczoraj znajomy zapytał mnie co ma zrobić by dogadać się z inwestorem/wydawcą. Postaram się opisać co ja bym w takim przypadku zrobił. To co napiszę może się różnić od naszych Polskich odpowiedników i może nie być najlepszą drogą, która można pójść.

Po pierwsze zastanowił bym się 15 razy dokładnie czy chcę współpracować z inwestorem, dlaczego?
– Proces tworzenia gier komputerowych jest bardzo skomplikowany. Przeciętny inwestor nie ma pojęcia o co w tym chodzi,
– Inwestorzy zawsze podjarani są na początku, gdy widzą jak długo trwa produkcja istnieje ryzyko, że zwiną interes,
– Inwestorzy nie będą w stanie pomóc Ci w tworzeniu gry, tak jak to robią wydawcy z doświadczeniem w produkcji gier, więc istnieje duże ryzyko, że Twoją grę będziesz robił latami, bo inwestor sam nie będzie wiedział czego oczekiwać,
– Inwestor nie będzie w stanie zbadać rynku i ryzyka projektu więc nie pomoże Ci w sprzedaży.

Generalnie takich rzeczy można wypisywać multum. Głównie chodzi o to, że nie powinieneś współpracować z kimś kto nie zna się na produkcji gier bo prędzej czy później się po prostu spalisz i z interesu nic nie wyjdzie. Takie podejście w Polsce ma wiele doświadczonych developerów i każdy z nich powie Ci to samo. Inwestora nie nauczysz produkcji gier, to też miej na uwadze. Naprawdę zastanów się 15 razy nawet jak inwestor chce dać Ci 3 mln$ na produkcje.

Podobnie jest z wydawcami, którzy nie znają się na produkcji gier bądź nie mają czasu na to by Cie supportować. Dowiedz się w pierwszej kolejności czy wydawca może zapewnić Ci:
– Profesjonalny review milestone’ów na czas. Profesjonalny = konkretny, bez mówienia, że to i to się nie podoba. Wydawca powinien Ci mówić czego oczekuje,
– Czy jest w stanie pomóc Ci w przygotowaniu checklisty milestone’ów, tak by wszyscy byli świadomi tego co na kiedy trzeba zrobić i kiedy mają być płatności,
– Czy wydawca tworzył już tego typu gry na platformy które chcesz wspierać i czy jest w stanie supportować produkcje = czy są w stanie przydzielić Ci Producera, Designera i Programistę do pomocy,
– Jak duży zakres terytorialny jest w stanie wydawca ogarnąć w swojej sprzedaży,
– Jak wygląda marketing od strony wydawcy,
– Czy płacą na czas i czy dają revenue,
– Czy mają swoją technologie na której masz się opierać,

Wszystkiego tego możesz dowiedzieć się podczas negocjacji, no ale dość pierdolenia, przejdę do konkretów.

1. Pomysł na grę.
Pierwszą rzeczą jaką musisz zrobić to wykombinować zajebisty pomysł na grę. Jest to najtrudniejszy moment, resztę, która opisze można się nauczyć. Nie dawaj sobie terminu, jak już jakiś pomysł Ci się wyklaruje 15 razy zadaj sobie pytanie „Czy można wykombinować coś lepszego?” Zanim zaakceptujesz pomysł bądź pewny, że jest to coś co na pewno się sprzeda i na pewno da maksimum frajdy z gry. To co interesuje wydawców jeśli chodzi o pomysł to:
– Jakie platformy będzie wspierał? W dzisiejszych czasach trzeba wspierać wiele platform, miej to na uwadze przy projektowaniu. Przykład: chcesz stworzyć grę na iPhone’a – będzie można ją zaadoptować na PSP/DS/Mobile?  Oczywiście każdą grę można przeportować, ale tu chodzi o łatwiejsze przeniesienie. Główne części gameplayu tak jak ekran in-game i controsly powinny być rozkminiane pod kątem różnych platform. Gdy będziesz pracował nad pomysłem – zadawaj sobie pytania w stylu: „OK, mogę poruszać postacią myszką, będę w stanie nią poruszać klawiszami w telefonie bądź padem, lub też dotykaniem ekranu?” Im więcej platform Twój pomysł będzie wspierał tym większy plus będziesz miał u wydawcy.
– Czy z pomysłu można zrobić brand? Wydawca myśli długo planowo, go nie interesuje jedna gra – ale cały brand. Oczywiście w Polsce tego nie widać, ale na zachodzie można to zauważyć. Myśl jak wydawca – myśl długoplanowo. Zadaj sobie pytanie: „czy będzie można łatwo zrobić dodatek do gry, płatne małe elementy, drugą część?”
– Jakiego typu będzie to pomysł. Generalnie najlepszą drogą jest zbadanie rynku na który chcesz uderzać. Zobacz jakie gry są popularne – zrób dokładnie coś takiego tylko znacznie lepszego. Wydawca musi mieć jakiś background. Drugą drogą jest oryginalny pomysł, którego można porównać do innych super sprzedających się gier.
– IP. Zrób sobie analize starych gierek, może znajdziesz coś co było popularne i może uda Ci się dogadać z autorami byś mógł wykorzystać ich pomysł. Zawsze możesz zrobić coś podobnego a wydawcy przedstawić to jako remake.
– Im więcej pomysłów tym lepiej. Nie wysyłaj 100 stronicowego dokumentu, tylko dokument 1-3 stronicowy z opisanym pomysłem. Fajnie gdy uda Ci się takich pomysłów rozkminić parę, tak by wydawca miał w czym wybierać.

Jak opisać pomysł? Opisać trzeba najważniejsze elementy, czyli:
– Nazwa gry
– Wspierane platformy
– Główny bohater
– Świat w którym rozgrywa się gra
– Controlsy
– Mockupy ekranu in-game z opisem gameplayu
– Mockupy menu
– Title screen
– Przyszłość: czyli jak pomysł może ewaluować.

Mając takie dane na 1-3 stronach podaj taki dokument komuś kto nie ma pojęcia o Twoim pomyśle i spytaj się go jak zrozumiał dokument, tak byś mógł wprowadzić odpowiednie zmiany. Najważniejsze jest to by przekazać informacje w taki sposób by nikt się nie zastanawiał tylko wiedział dokładnie to samo co Twórca dokumentu. Mając już spisany pomysł musisz zabrać się do roboty. Jedziesz dalej.

2. Prototyp/Vertical Slice/Demo
W dzisiejszych czasach nie sprzedasz swojego pomysłu samym tekstem 😉 Będziesz musiał zainwestować jeśli chcesz dobić targu. Pamiętaj o tym, że dla wydawcy developer musi mieć trackline na daną platformę. Ty będziesz na straconej pozycji więc musisz czymś nadrobić, czym? Najlepiej grywalnym demem, które pokaże:
– Główną część gameplayu – musi być mega fun. Gdy będziesz już miał ją zaimplementowaną daj pograć znajomym, ważne jest to by główna część gameplayu powalała na nogi wszystkich. Gdy ktoś nie powie Ci po zagraniu „Kurwa, ale fajne!” wróć do punktu nr 1 czyli wymyśl inny pomysł. Nie ma co inwestować w coś co nie jest grywalne i nie daje przyjemności z gry.
– Finalna grafika do głównej części gameplayu – nie używaj placeholderów. Demo/Prototyp/VS ma wyglądać ładnie. Ma pokazywać jak grafika będzie wyglądać finalnie.
– ANGIELSKI. Wszystkie teksty jakie masz – pisz po angielsku. Jak nie potrafisz – zainwestuj w tłumacza.
– Tutorial bądź how-to. W Demie/Prototypie/VS musi być informacja o tym jak wogólę grać. Tworzenie tutoriala to ciekawa sprawa, poświęć na niego dużo czasu. Będzie dobrze jak ktoś kto nie zna projektu po zobaczeniu tutoriala będzie potrafił grać w grę bez pytania Ciebie o to jak grać.
– Jeśli chcesz wspierać inne platformy – możesz stworzyć bardzo prosty protyp na innej platformie. Już możesz tam używać placeholderów.
– Muzyka i dźwięki – zainwestuj w nie. niech z dema wali klimatem.
– BugFree – wykołuj miliard testerów by Ci demo sprawdzili pod każdym kontem. Jak pokażesz coś z błędem jesteś udupiony.

Zamiast prototypu/dema/VS możesz zrobić po prostu .avi w maxie, ale to nie będzie to samo. Na takie .avi możesz sobie pozwolić jak będziesz miał już jakiś trackline. Jak już jesteś zadowolony ze swojego dema możesz przejść do kolejnego punktu.

3. Opis teamu/firmy
Stwórz dokument opisujący ludzi, którzy będą pracować nad projektem. Ich doświadczenie pokaż w białym świetle – „jesteście zajebiści” coś takiego po przeczytaniu dokumentu każdy powinien powiedzieć. Pokażcie swoje portoflio w takim dokumencie, chwalcie się

4. Budżet/plan
Kolejnym krokiem jest stworzenie planu produkcji gry na jedną platforme w raz z kosztem. To co wydawcę interesuje to:
– jak najkrótszy czas trwania projektu
– jak najmniejsze koszty
– jak najlepsza jakość produktu

Jak nie potrafisz zrobić planu – poproś kogoś kto potrafi i Ci go zrobi. Bez doświadcznie dobrego planu nie zrobisz. To co Ci może pomóc to słowa sprint plan w google i Twoje własne doświadczenie. W planie powinny znaleźć się milestone’y, zaproponuj im:
– First Playable  (główna część gameplayu ready z placeholderami)
– Alpha (prawie cała gra gotowa, mogą występować placeholdery i błedy)
– Beta (cała gra gotowa, w raz z tekstami, muzyką etc – brak placeholderów)
– DF (cała gra gotowa od tego momenu nowych ficzerów nie wymyślamy)
– IF (cała gra gotowa od tego momentu nie implementujemy nowych ficzerów, tylko zajmujemy się bugfixem)
– RC (gra jest już na tyle skończona by można było ją wydawać )
– Release (można wydawcać)

Ważne jest też by mieć checklistę milestone’ów czyli konkretnie rozpisany każdy milestone punkt po punkcie. Co dokładnie potrzebne jest by mieć zaakceptowaną Alphe. Generalnie ja zawsze zaczynam od rozpisywania milestone’ów, dopiero później podchodzę do planu. W dokumencie sprint planu powinna znaleźć się też zakładka budżetu jaki potrzebny jest na wykonanie projektu w raz z płatnościami. Wydawcę interesuje to kiedy ma wysyłać kasę. Generalnie najczęściej jest tak, ze dostaje się pięniążki na start, betę bądź RC i ostatnią ratę za release. Nie dyskutuj z wydawcą o tym by płacił Ci miesięcznie bo Cie wyśmieje.

Do dokumentacji możesz dodać risk dokument, czyli dokument opisujący ryzyka jakie mogą wystąpić w projekcie i jak można się przed nimi uchronić, bądź co zrobić gdy jakieś ryzyko wystąpi.

5. Podsumowanie. OK mając już:
– dokument pomysłu na grę
– grywalne i zakurwiste demo
– budżet
– sprint plan
– checklistę milestoneow
– dokument ryzyka
– dokument opisujący team

Możesz zacząć wysyłać spam do wydawców 🙂 Pomiń w wysyłaniu maili/poczy Polskę.  Jak bym miał coś jeszcze dodać do tego posta dajcie znać. (generalnie nie pokaże Wam żadnego takiego gotowego dokumentu ze względu na NDA, którego się trzymam)

Afterfall i ostatnie video

Pewnie dostanę konkretne zjeby za tego posta, może też ktoś zacznie na mnie polować, ale ze względu na to,  że sam zacząłem ten projekt i gdyby nie moja jazda nikt z pracujących w Nicolas Intoxicate nie miał by pracy pozwolę sobie na konkretną garść krytyki jeśli chodzi o Afterfalla.

Jakiś czas temu zobaczyłem sobie ten filmik: http://www.youtube.com/watch?v=lu2z0JMxEII starałem się zrobić profesjonalny review tego co zauważyłem, ale niestety chyba pracownicy Nicolas Intoxicate związali się emocjonalnie ze swoją pracą, co wiąże się z nieprofesjonalnym wykonywaniem swoich zadań. Ale pokolei, to co mnie wkurwia to mówienie o tym, że projekt wywodzi się z Burżuazji/Burżuazji: Perła Pustkowi – zwykłe pierdolenie, z tego co kiedyś było planowane w tej grze która widzę na tym filmiku nie ma kompletnie nic, więc proszę nie obrażajcie mojej ciężkiej pracy publicznie.

Zajebiście się cieszę, że Afterfall ma wydawcę, finansowanie i  w ogóle, ale chyba trzeba pójść teraz poziom wyżej jeśli macie się tam rozwijać. Czy ktoś tam w ogóle testuje tą grę? Jeśli tak to nie ma chyba zielonego pojęcia o tworzeniu napięcia. Jedyną rzeczą jaka jest fajna na tym filmiku to grafika – jest na dobrym poziomie, choć jest parę miejsc, które różnią się klimatem tak jak by wszystko tworzone było przez 100 grafików z chin bez konkretnych wytycznych, tak czy siak grafika trzyma poziom. Nie dziwi mnie to – Nicolas Intoxicate ma bardzo dobrych grafików.

Czy nikt z Was nie zauważył konkretnie hardcodowo zaimplementowanych cutscenek/akcji. Zdaję sobie sprawę, że od czegoś trzeba zacząć, ale chcecie wydawać Afterfalla na początku następnego roku! Nie wyobrażam sobie teraz w jaki sposób ktoś ogarnie wszystkie cutscenki. Widać oskryptowanie gołym okiem. Nie powinno być tego widać jak chcecie tworzyć napięcie/klimat gry. Gracz zawsze będzie wiedział, że jak wejdzie tu, bądź tu wyskoczy mu jakaś akcja. To jest to co jest właśnie trudne do osiągnięcia i mam nadzieję,  że popracujecie nad tym aspektem gry, który konkretnie kuleje. Jeśli sami tego nie widzicie – zatrudnijcie kogoś kto Wam stestuje całą grę i powie o co mi chodzi, myślę, że warto.

Dlaczego komentarze głównego bohatera są po polsku a wszystkie napisy na GUI po angielsku?! Tomek ma fajny głos, nawet tam pasuje jak by go jeszcze trochę przefiltrować, ale bądźcie konkretni w tym co robicie – nie mieszajcie języków, chyba, że chcecie nauczyć całego świata języka Polskiego. Pograjcie sobie w Alan Wake’a np, zobaczcie jak tam to wygląda. Bierzcie przykład z dobrych gier.

Kamera – fajnie, że nie chcie robić HUDa na ekranie by nie zasłaniać ekranu, ale kurwa – postać zasłania 1/3 ekranu. Mogliście już dać HUDa na ekran a kamerę spolishować. Niekonsekwencja moim zdaniem. Jeśli komuś ta kamera się podoba to bardzo mnie to zdziwi, zasłania…koleś który grał – sam nie potrafił umiejętnie wycelować tam gdzie chciał, ze względu właśnie na kamerę, a grał w to pewnie więcej razy niż ktokolwiek inny.

Oświetlenie – mishmash totalny, ciągłe zmiany kolorów, boli oczy. Popatrzcie globalnie na swoje lokacje – sprawdźcie sobie sami jakie są różnice w kolorach. Wiem wiem, musi być ‚realnie’, ale w grach nic nie jest realne, ważne jest to by odbiór gry był jak najlepszy.

Walka. Moim zdaniem ten element gry jest jeszcze zaniedbany. Nie czuje walki z tego video, czuje tylko wycelowanie w jakąś postać i strzał – co jest i tak trudne z tego co widać. Gdzie tu jakaś taktyka? Widać znów mega oskryptowane elementy. Postacie lecą w naszą stronę i musimy sobie poradzić, one nie myślą. W grach chyba fajne jest to, że czuje się, że walczy się z postacią, a nie kawałkiem skryptu.

Cutscenka lecących nietoperków. Fajny motyw, ale nie wyszedł. Gra stopuje przy wejściu w trigger, nie wiadomo co się dzieje. Nagle wylatują nietopery, kamera łapie focusta sztywnie i koniec cutscenki. Ten element pewnie miał w jakiś sposób wprowadzić gracza w klimat, a mnie wprowadził bardziej w WTF/Żal. Wiem wiem, nie macie czasu. Dopracujcie takie elementy inaczej gra zginie w negatywnych komentarzach a tym samym ja – dalej jest jeszcze masa osób, która myśli, że ja tworze tą grę, dostaje maile co za kiłe zrobiłem. Zróbcie to dobrze, zacznijcie polishować – wywalcie designerów, którzy chcą wrzucać nowe ficzery, zacznijcie polishing, bo tego brakuje.

Udźwiękowienie. Baaaardzo dużo macie sfxów i komentarzy głównego gracza, jeśli cała gra taka będzie to nie wiem czy się pomieścicie objętościowo. Nie wiem jak UE3 zarządza pamięcią, ale jak nie streamuje tych sfxów jesteście spaleni już na starcie – obadał bym to mini ryzyko. Dodatkowo co z lokalizacją, chcecie robić voiceovery w EFIGS? Nie zazdroszczę.

Muzyka – zajebista. Nie wiem czy Kwazi tworzył całość, jeśli tak – konkretnie dał sobie z tym radę!

Animacje postaci – postać chodzi jak robot.

Łamigłówki – dobry klimat, robił bym ich jak najwięcej skoro inne elementy kuleją.

Ktoś tam mówił o budowaniu napięcia przez muzykę, spoko muzyka muzyką, ale by ona tworzyła klimat reszta też musi go tworzyć. Samą muzyką klimatu nie stworzycie. Słuchajcie ludzi, popatrzcie sobie na komentarze pod filmem jaki został wrzucony na youtube. Weźcie to do siebie, nie olewajcie tego. Ludzie chcieli by zobaczyć dobrą grę, ja również – to nie jest atak na Was i jeśli tak zostaje przez Was odebrany to za bardzo emocjonalnie się przywiązaliście do projektu.

Generalne odczucie jest sztywne, za dużo skryptów, sztywnych akcji – brak dynamizmu. Nie czuje funu z tego co widzę, może dlatego, że osoba która gra nie potrafi przedstawić tego co dobre. Nie pisał bym tego gdybyście nie porównywali się z AAA produkcjami. Jeśli jesteście AAA działajcie jak AAA, każdy element gry musi być dopracowany. Macie mało czasu, ale wiem, że jesteście zmobilizowani. Zastanówcie się co jeszcze trzeba dopracować komentarze innych Wam w tym pomogą, sami pewnie już jesteście ‚przejedzeni’ grą i nie jesteście w stanie zauważyć wielu rzeczy – to normalne.

Fajnie, że coś widać – pewnie wiele osób Wam to piszę, ale chuj z tym, że fajnie, że coś widać – ma być widać grę, która wciągnie. Jeśli wciągnie nikt Wam nie powie ‚fajnie, że coś widać’. Po prostu zróbcie coś z tym, a nie obrażajcie się na mnie. Jak ktoś będzie miał problem z tym postem – może mieć żal tylko do siebie, komentuje to co widzę. Chcecie pozytywnych komentarzy – ogarnijcie się. Dobrze wiecie, ze mimo wszystko wspieram Was, to, że dajecie radę i pracujecie nad tym projektem mimo problemów jakie kiedyś były. Jak to kiedyś się mówiło – Na Burżuja Nie Ma Chuja.

Go!Go! Rescue Squad w sklepach

Zgodnie z zapowiedzią Nintendo.

Moja pierwsza gra na DSi będzie już niedługo w sklepach. Generalnie parę informacji dla osób robiących gry dla Nintendo DS/DSi:

– to, że Twoja gra wspiera w 100% dokumentacje nintendo i checklistę lotchecku nie oznacza, że przejdzie Lotcheck,
– podczas lotchecku wychodzą rzeczy, które nie są opisane w żadnym dokumencie,
– zależnie od tego kto sprawdza Ci lotchecka może przyczepić się do każdego pixela,
– USA i Europa nie kontaktuje się w sprawach lotchecku – więc jeśli jakiś błąd wykazali w USA mogą go nie wykazać w Europie,
– Sprawdzaj aktualizacje dokumentacji Nintendo codziennie,
– Gdy chcesz zlokalizować swoją grę (a w sumie to musisz) zdecyduj się na tłumaczy, którzy znają specyfikę Nintendo. Jest opis jakich wyrazów/słów używać, ale gdy dasz do tłumaczenia jakiemuś native speakerowi bez wiedzy o Lotchecku Nintendo na pewno zrobi Ci masę błędów i oblejesz lotcheck.  Zamów lokalizacje w profesjonalnej firmie zajmującej się również tłumaczeniami pod lotchecka Nintendo,
– Nie śpiesz się z wysłaniem builda do Nintendo,
– Zagospodaruj sobie dobre QA, gdzie testować będzie parę osób (wiąże się z zakupem device’ów do testowania),

Generalnie oryginalnym developerem tej gry było Connect2Media, gra została sportowana z iPhone’a. Mnie osobiście ta gra bardzo wkręciła, jak ktoś lubi łamigłówki na pewno mu się spodoba. Nie obeszło się bez problemów przy portowaniu – kod był słabo zakomentowany, feedbacku od developerów nie było prawie wcale, ale doświadczenie i wiedza Programisty, który pracował nad portem dała się we znaki 🙂 Port przeszedł gładziudko, nawet nie było ‚problemów nie do rozwiązania’ z tak podstawowymi rzeczami jak dopasowanie grafik, udało się parę nowych ficzerów doimplementować. Ze wszystkim poradziliśmy sobie wyśmienicie 😉

Teraz nic tylko czekać na Nintendo3D ;]