W pracy wszystko się rolluje, więc jeśli chcielibyście bym o czymś napisał – piszcie mi komentarz, albo maila: andrzejkoloska@gmail.com tematy jakie by Was interesowały. Tematy jakie miałem w TODO już się skończyły, więc będę wdzięczny za małą pomoc 🙂
Chcesz być producentem? Daj sobie spokój. Jeśli chcesz:
– nie mieć czasu na nic, może czasami w weekendy
– dostawać po dupie za każdy błąd, którego Ty nie zrobiłeś
– urlopu większego niż tydzień nie dostaniesz, bo wiesz, że coś się po drodze spierdoli
– kłucić się większość Twojego czasu z różnymi ludźmi, czasami dałnami, z którymi się nie da rozmawiać
– widzieć jak team się męczy wprowadzając kolejne bez sensowne poprawki wymagane przez wydawcę
– widzieć jakie hardcorowe terminy Ciebie czekają
– robić wszystko tak idealnie by nie było żadnego błędu podczas produkcji – inaczej nie zdążysz na czas i w odpowiedniej jakości
– tłumaczyć wszystkim co mają robić po kilka razy
– mieć już tyle na głowie, że nie wiesz jaki jest aktualnie dzień
– mieć problemy ze spaniem, bo ciągle myślisz czy aby na pewno idziesz dobrą drogą i czy coś się po drodze nie spierdoli
– ciągle podwyższać swoje kwalifikacje, bo ciągle wymaga się więcej
– mimo całego wkurwienia i stresu musisz na spokojnie wszystkim wszystko tłumaczyć
– przepracowywać się
– poprzez Twój błąd, ktoś musi robić nadgodziny
– jesteś odpowiedzialny za projekty niezależnie co się z nimi dzieje
To praca producenta jest dla Ciebie. Powiem Wam, że jak ja nie miał bym tak konkretnego teamu i supportu ze strony szefostwa w Vivid Games – dawno wylądował bym w psychiatryku 😛 Ktoś kiedyś mówił, że najlepsi są w pracy Ci, którzy co jakiś czas mają tej pracy dość, a tak czy siak w głębi duszy ją kochają. Ten ktoś chyba miał rację.
Wszyscy wannabe producer powinni się 2, góra 8 razy zastanowić. Trzeba jeszcze dodać, że dla producenta projekt nie kończy się po akceptacji finalnej wersji, taki projekt jeszcze przez miesiąc, dwa dla producenta się ciągnie i oznacza dalszą część obowiązków i stresu 🙂
Niedawno skończyłem kolejny projekt – tym razem na Mobile (Android, j2me) Projekt wykonany bardzo szybko, było parę problemów w produkcji, ale ogólnie efekt jest taki jaki chcieliśmy no i na czas (a termin był hardcorowy). Bardzo podoba mi się design gry – czuć klimat Amigi. Tak aby było konstruktywnie:
– Gdy robicie grę pod mobile – zainwestujcie czas w implementacje autoplaya, który może przyśpieszyć portowanie przynajmniej o połowę. Do każdego projektu dorzucaj taki feature.
– Naucz swoją technologie automatycznie skalować grafikę do potrzebnych rozdzielczości, tak by programiści mogli pracować na wszystkich rozdzielczościach od samego początku produkcji.
– Stwórz sobie klasy rozdzielczości, tak by zaczynać od tej najwyższej, a resztę po prostu skalować
– Zaopatrz się w super plugin do photoshopa: Blow Up 2. Dzięki, któremu grafiki w potrzebie można nawet skalować w górę, prawie bez utraty jakości.
– Jak najszybciej prototypujcie grę na najlepszym i na najsłabszym device.
– Od samego początku starajcie się umieszczać jak najwięcej feature flags – tak by szybciej poszło portowanie
– Pisząc kod nie wstawiajcie nic na sztywno i hardcodowo – wszystko musi się ładnie skalować zależnie od rozdzielczości ekranu
– Design gry (ekranów) projektujcie na wszystkich problematycznych rozdzielczościach ekranu
– Już od samego początku zwracajcie uwagę na touchscreena, po co zostawiać to sobie na później? 🙂
To wszystko pewnie dla tych, którzy tworzą gry mobilne jest na porządku dziennym, ale tak czy siak chciałem to napisać dla tych, którzy chcą zacząć tworzyć gry na urządzenia mobilne.
W demko można pograć gdzieś tutaj. Na słabszych telefonach chcieliśmy by gra chodziła jak najszybciej (mniejsza jakość, ale jest płynność). Bardzo fajna gra do autobusu, pod koniec turnieju jest już naprawdę trudno wygrać 😉 Oceny ludzi mówia chyba za siebie (9,7/10)
Typowe pytanie jak się używa czyjegoś SDK. Czasami można ochujać po prostu. Przykład:
Wydawca dostarcza Ci SDK które jest swoją drogą bardzo dobre – konkretny engine, ale dopiero co zaczął wspierać 3d. Okazuje się, że przez tydzień 50% czasu grafika i programisty idzie na to by ‚problemy z 3d zostały rozwiązane’. Wydawca sugeruje przejście na 2d, odmawiam. Po drugim tygodniu okazuje się, że prawie wszyscy programiści SDK ze strony wydawcy są na urlopie – developerzy dalej 50% swojego czasu męczą się z tym by 3d działało. Jedno rozwiązanie: przerzucamy się na 2d, wydawca się zgadza, ale po godzinie dochodzi do niego, że nie chce tego robić – wymusza 3d.
Przez grube 3 godziny spalam pół paczki fajek i negocjuje z wydawcą. Próbuje wszystkiego, od każdej strony:
– nie będziemy robić nadgodzin by naprawiać SDK
– programista nie będzie w stanie się skupić na samej grze tylko będzie musiał się babrać z tym by 3d w ogóle się odpaliło
– z doświadczenia wiem, że jak jakaś biblioteka nie działa tak jak ma działać trzeba ją porzucić jak najprędzej, albowiem problemy będą się mnożyć.
– jak mamy używać tego 3d API naprawcie wszystkie problemy w ciągu tygodnia – inaczej nie zdążymy z milestonem
– nasz plan ma wdrożyć wykonanie gry, a nie poprawienie 3d API, które jest WIP i to wydawca jest za niego odpowiedzialny
– gra będzie wyglądała znacznie lepiej w 2d na ekranie iphone/iPada
– zrobimy mockupy by Was przekonać
– zrobimy w parę dni prototyp by Was przekonać
– chcę jednego programistę od Was, który będzie odpowiedzialny za działanie 3d, jesteś w stanie to nam zapewnić?
Chuja, koleś ani drgnie, dalej jest przy 3d, aż do momentu jak mu powiedziałem coś w stylu:
– Sam chciałeś 2d 2 tygodnie temu, czemu teraz nagle zmieniasz zdanie, czego tak nagle się wystraszyłeś z tym 2d?
Nie potrafił mi odpowiedzieć. Zaakceptował zmianę 3d->2d i sam stwierdził, że mam racje, nie ma co tracić czasu na poprawianie czegoś co nie działa, lepiej skupić się na grze i samych terminach, a 2d tak czy siak będzie ładniejsze 🙂
Masakra jakaś. Jak byśmy używali 3d na pewno do końca projektu wszyscy w tym projekcie robili by nadgodziny by gra działała tak jak należy.
Do wszystkich używających SDK/Silnika od kogoś:
– Sprawdź zanim zaczniesz produkcje czy aby na pewno ma wszystkie featury takie jak są Ci potrzebne
– Sprawdź czy jest odpowiednia dokumentacja z samplami – jeśli jej nie ma, postaraj się taką wynegocjować, jeśli Ci jej ktoś nie jest w stanie dostarczyć – olej takie SDK/Silnik bo będziesz się męczył
– Wynegocjuj sobie programistę do pomocy ze strony SDK – tak by zawsze był dostępny dla Twoich programistów. Nawet konkretny i finalny engine ma problemy, które rozwiązać może tylko developer SDK/Silnika. Miej to na uwadze, jak taki jeden mały błąd ma rozstrzygnąć czy gra zostanie wykonana na czas fajnie jak by był ktoś kto może taki błąd naprawić efektywnie.
– Nie lekceważ małych problemów z Silnikiem/SDK, nie zostawiaj ich sobie na później. Najczęściej jest tak, że mały problem podczas produkcji przekształca się w problem typu: „robimy tą część od nowa”, a to jest zabójstwo projektu.
– Spisuj wszystkie problemy z SDKiem i staraj się załączyć je do kontraktu – tak by wydawca też miał milestone’y do wykonania jeśli pracujesz na jego technologi
– Naucz swoich programistów angielskiego – jeśli sam nie jesteś w stanie wytłumaczyć problemu, który występuje w SDK
– Męcz wydawce o szybkie poprawki – z rana, po obiedzie, wieczorem – niech czuje ,że projekt nie leci do przodu przez niego.
– Pamiętaj, że zawsze nad programistą, który pracuje przy SDK jest ktoś (Producent, Szef, Lead) – jak ktoś się obija, uderzaj do kogoś wyżej i zrób mu z dupy jesień średniowiecza. Bardzo szybko skutkuje, błędy naprawiają się bez narzekania i naprawiane są efektywnie.
– Jak czujesz, że programista Cię olewa (np. przy każdej próbie kontaktu mówi „mam meeting, muszę uciekać” nie lekceważ tego, to jest tylko początek olewki programisty (który może np. nie mieć czasu dla Ciebie) od razu kontaktuj się z wyższym kierownictwem byś zapewnił sobie kogoś do pomocy.
Reasumując zastanów się dwa razy czy chcesz używać jakiegoś SDK/biblioteki/Silnika – a jak jest jakiś problem nie zastanawiaj się tylko decyduj inaczej Twoje pytanie „what about engine issues?” będzie się pojawiało codziennie, a terminy będą coraz bliżej, okażę się, że nie masz akceptacji milestone’a bo coś w SDK nie działa, a to nie jest Twoja wina. Mi to się nigdy nie przytrafiło, ale ryzyko jest.
Najlepiej pracuje się na własnej technologii 🙂
Dzisiaj zaczął się III Ogólno Polski Zjazd Twórców Gier (ale długa nazwa :D) Jest to chyba największy taki event w Polsce do tej pory (ponad 200 uczestników). W sobotę będę miał jedną szybką prelekcje na temat portowania gry Artist Colony z PC na iPhone. Już teraz chciałbym dać Wam do rąk plik z prezentacją, zapraszam w Sobotę o 18stej na godzinkę rozmowy 😉
Plik: ZTG2010 – Vivid Games – port Artist colony na iPhone_AK
Z jednej strony fajnie się robi gry na popularnym IP, ale z drugiej strony często (chyba nawet zawsze) Licensor Holder ma nie fajne podejście…dla tych, którzy nie wiedzą jeśli ktoś udostępnia nam IP ma on wpływ na developing, finalny wygląd gry – może zmieniać co mu się podoba. Nawet jak ktoś ma jaja licensor ma je większe (sprawy związane z prawem)
Wydawcy zabezpieczają się przed typowymi akcjami takimi jak:
– Długi okres oczekiwania na feedback od licensora
– Brak feedbacku od licensora na początku
– Gdy zbliża się koniec produkcji (RC) licensor się budzi i chce zmienić 50% gry
Nawet jeśli pokazujemy licensorowi wersję Beta to koniec końców i tak odzywa się po RC z konkretami.
W moim przypadku było tak, że licensor po Becie zmienił 70% tekstów w grze, dał parę uwag, zmieniliśmy wiele grafik etc – typowe poprawki nie mające raczej większego wpływu na timeline. Po RC wydawcy chyba się gra spodobała albowiem dostaliśmy gruby feedback. (z prośbą nawet o zmianę Menu, dostaliśmy oryginalne kawałki o które prosiliśmy na samym początku produkcji i inne bardzo przydatne assety).
Licensor się budzi. Wszystkie poprawki zrobione w terminie, teraz ‚tylko’ czekac na finalna akceptacje…czekac…czekac…przed ostatni milestone poszedl (akceptacji licensora nie ma)…czekanie…czekanie…ostatni milestone juz przed nami…
Jak ja bym miał bezpośredni kontakt z licensorem bym go budził codziennie o 4tej, a nie tak jak teraz dziennie pisał po parę razy „Any news from licensor?” do wydawcy…
Są też dobre strony: gra jest lepsza, ale tak czy siak moim obowiązkiem jest zrobienie gry na czas a licensor to czasami psuje, na co wplywu nie mam ani ja, ani wydawca, tym bardziej jak się robi grę na IP znanego serialu, gdzie feedback dają aktorzy, reżyser, sprzątaczki 😛
Dupa blada po prostu.
Za niecały miesiąc na app store będzie można znaleźć rozdziewiczoną grę na iPada. Bardzo fajnie się pod niego robi (możliwość portów na inne platformy – rozdzielczość). Trzeba uważać na performance, niby sprzęt lepszy, ale tak naprawdę ma problemy z renderowaniem tak dużego ekranu.
Dam znać jak gra będzie na app store.
Z Nintendo to jakaś masakra jest, nawet jeśli trzymasz się wytycznych w 100%, robisz wszystko zgodnie z dokumentacją tak czy siak Twoja aplikacja wraca do Ciebie w związku z ‚widzi-mi-się’ nintendo.
Nawet mając tłumaczy, którzy specjalizują się w lotchecku Nintendo zarówno gestapo z Niemiec (EU) i amerykanie są w stanie wyłapać rzeczy, które im ‚nie pasują’. W moim przypadku gestapo dowalił się nawet do małego pixelka, który nie był o jeden pixel wycentrowany.
Frustracja. DS/DSi to jest coś w czym można nabyć konkretną specjalizację, którą pewnie można nabyć jak wyda się sporo gier i będzie się znało na pamięć ‚widzi-mi-się’ Nintendo.
Nie ważne czy robisz wszystko zgodnie z dokumentacją, konkretnie testujesz, zabezpieczasz lokalizację – Nintendo coś znajdzie 🙂
Jak komuś z Was udało się przejść lotcheck za pierwszym razem – będę wdzięczny za kontakt!
Skonczylem swoj pierwszy projekt na platforme Samsunga – BADA, uwielbiam to uczucie gdy sie wrzuca juz skonczonego builda do akceptacji, caly swiat wtedy widzi sie przez pryzmat szczescia 😉
Andrzej Koloska's Blog 