Skip navigation

Monthly Archives: Grudzień 2009

Na appstore pojawila sie wlasnie gra Paperboy. Dla tych, ktorzy pamietaja oryginal na pewno bedzie to zajawka na iphone. Dla osob, ktore nie wiedza co to Paperboy na pewno gameplay bedzie przyjemny 😉 Gra udostepnia nam 2 tryby: 2d i 3d, warto zobaczyc.

W nowym roku pojawi sie na appstore kolejna wieksza produkcja: The Dog, na pewno napisze troche o produkcji tej gry, no ale teraz wole zyczyc wszystkim wesolych swiat!

Reklamy

Każdy wydawca jest inny, każdy człowiek jest inny, ale są pewne zasady, które wg nas każdy z nas mógłby wprowadzić w życie, gdy współpracuje się z wydawcą z którym ma się kontakt telefoniczny i mailowy. Załóżmy, że projekt już wystartował, jest rozplanowany, sporo rzeczy może się wydarzyć ‚nie z naszej winy’ więc parę uwag:

*staraj się planować również czas na dostarczenie feedbacku przez wydawcę
*wrzucaj w plan konkretne milestone’y związane z feedbackiem wydawcy
*w kontrakcie czas na feedback – co w praktyce nie zawsze działa…
*staraj się rozplanować implementacje ficzerów tak, by team zajął się czymś nie związanym z główną częścią gameplayu w trakcie gdy wydawca ewaluuje builda
*dobrze ustal jak projekt ma wyglądać zanim zacznie się development (nie zawsze działa, niektórzy wydawcy nie czytają dobrze zbudowanego GDD)
*zawsze gdy Twój ‚wydawca’ pojawi się na skype czy innym komunikatorze – zagaduj, męcz.
*raportuj o każdej wg wydawcy bzdurze
*pisz tygodniowe raporty z postępu prac
*prioryteryzuj pracę razem z wydawcą, tak by nie tylko Twój szef był zadowolony, ale wydawca również
*prioryteryzuj bugi QA razem z wydawcą tak byś wiedział co masz do zrobienia by zaakceptowali ważne milestone’y
*jak najszybciej implementuj first playable
*mów wydawcy co może a czego nie może, i z czym się wiążą jego zmiany, które może robić nieświadomie
*zawsze miej na uwadze to, że Twój wydawca nie widzi tego co się dzieje w firmie, z czym są problemy – uświadamiaj mu to
*gdy wydawca stwierdzi, że jest zajebiscie i zaczniesz odczuwać, że już nie zwraca na Ciebie uwagi bo Ci ufa – rozjeb mu takie myślenie
*jeśli masz problemy z providerem technologi (nie działa coś przez kogoś innego) – raportuj o tym wydawce asap, dobrze wytłumacz z czym to się je i jakich błędów należy się spodziewać – ustal również termin naprawy. Terminy są ważne, bez nich będziesz się dziennie pytał „when we can expect new update?”
*zanim puścisz lokalizacje do obiegu – niech teksty będą zaakceptowane przez wydawce i niech bedzie tego swiadom (niby takie proste ale praktyka zawsze robi swoje)
*aktualizuj plan, jeśli coś nie idzie tak jak zaplanowałeś – informuj o tym wydawce
*ty możesz o wszystkim wiedzieć, co nie oznacza ze Twój wydawca o tym wie…
*zdobądź telefon od swojego wydawcy, męcz go telefonami jak potrzebujesz coś wiedzieć a nie ma czasu odpisać przez parę dni, bo normalnie zapomniał (niekiedy wydawca oczekuje hardcore’u i nie wiadomo czego w krótkim czasie by tego dotrzymać musisz mieć feedback i też oczekuj hardcore’u z drugiej strony – na drugi raz wydawca w taki projekt nie będzie się wpieprzał i będzie chciał luźniejsze terminy)
*gdy rozmawiasz ze swoim wydawca zawsze mów mu z czym się wiaże dana implementacja i jakie problemy mogą wystąpić
*wytlumacz wydawcy konkretnie plan developingu
*wytlumacz wydawcy konkretnie risk plan – nie rób go po to by go zrobić tylko od razu działajcie w tym zakresie
*dobieraj odpowiednich ludzi na odpowiednie stanowiska

Czasami można się super dogadywać z wydawca, a czasami pracuje się z wydawca, który ma na głowie 10000 projektów i jego producenci nie ogarniają. Jedna ogólna rada; nie stresuj się jak coś nie wychodzi, leć do przodu – staraj się pomoc swojej ekipie, zdobadź zaufanie swojego wydawcy – dzięki czemu więcej issues będzie wstanie waivnac pózniej.

to co może się zdarzyć ‚nie z naszej’ winy:
*wydawca nie daje feedbacku, nie gra w buildy
*wydawca nie czyta GDD
*zajebałeś termin albowiem dostawca SDK dał dupy
*zajebałeś termin albowiem źle rozplanowałeś QA
*zajebałeś termin albowiem źle poustawiałeś priorytety
*zajebałeś termin albowiem dałeś dupy z lokalizacją
*zajebałeś termin albowiem za szybko zacząłeś ‚modyfikacje’ tej samej gry na inna platformę.
*ogólnie – zajebałeś termin

Dla kogoś ten wpis może być w stylu ‚przecież to jest wiadome’, ale jestem przekonany, że nie zawsze i nie każdy nad tym wszystkim trzyma pieczęć i to ze względu na czas i to ze względu na brak chęci.

A tak z innej beczki, na początku przyszłego roku kolejne dwa projekty zostaną wrzucone w obieg więc na pewno się pochwalę, niestety screenów pokazać jeszcze nie mogę 😉

Kolejne gry wylądowały właśnie na app store’a. Electo Hunter i Samurai Puzzle Battle. Polecam sprawdzić gameplay 😉

Właśnie przez przypadek natknąłem się na opublikowane portoflio Hatreda. Masakra, pamiętam jeszcze jak zaczynałeś…Twoje prace na pewno kogoś zaciekawią.

Ten post jest kopią pewnej dyskusji na forum Warsztatu, ale może komuś się przyda.

Flyspray i mantis jest idealnym rozwiązaniem dla QA. (testtrack pro oczywiście jest lepszy, ale wszystko zależy od projektów jakie się prowadzi) dotproject jest idealnym rozwiązaniem do rozpisywania timeline’ow projektow gier komputerowych.

Wszystko zależy od osoby która odpowiedzialna jest za organizację pracy i zadań. Może nawet używać excela przecież, ważne by wszyscy rozkładali efektywnie swoje 8 godzin w pracy, szefowie i wydawca wiedział co się dzieje, a milestone’y były robione na czas – to jest ważne, nie system, którym się posługuje.

Dotproject ma dodatkowo super wsparcie do planowania spotkań, burzy mózgów, informacji nt pracowników etc etc

Oczywiście, każda firma używa oprogramowania, które im się podoba, ale zdziwił byś się ile firm pracujących nad AAA i AA (nie tylko polskich) korzysta z dota i flyspraya. Więc stwierdzenie, że używanie tego oprogramowania jest błędem nie jest uzasadnione. W końcu firma która ma ogromny budżet i profesjonalistów w produkcji gier nie używała by babola..

Cytat: Technicznie da się jak najbardziej, ale traci się na przejrzystości i specyficznych funkcjach softu PM, jak np. autorysowanie Gantta, kalendarz, listy kontaktów.

Typowe dla project managerów – tylko nasz szef chce by wszystkie projekty były robione tak by wywiązać się z kontraktu, autorysowanie gantta w tym akurat nie pomoże. Oczywiście, tak jak mówiłem wcześniej – to zależy od umiejętności osoby zarządzającej projektem. Niby im więcej pomocy informacyjnej, tym lepiej – ale najwięcej informacji uzyska się z własnego doświadczenia. Jeśli pojawia się problem wystawienie klientowi bądź licensorowi (który może akurat nie zna się na grach) wykresu gantta nic nie da, trzeba przejrzyście tworzyć odpowiednią dokumentacje i znać się na swojej pracy, by nie dać się zrobić w jajo i samemu przez swój błąd, bądź nie czytelną dokumentację zabić projekt przez oczekiwania klienta. Co do samej przejrzystości QA – zainstaluj sobie na lokalu flyspray i sam zobacz jaki jest przejrzysty, czego o mantisie akurat powiedzieć nie można, ale gdy ktoś się przyzwyczai to i mantis będzie dla niego przejrzysty. (gdy stopniowo rozplanuje się QA i nie znajdzie się tam 2k issues)

To jest tak samo jak wojna co jest lepsze OGL czy DX – zależy od punktu widzenia, od prowadzonych projektów, od planowania, od infrastruktury informacyjnej w firmie etc. Nie ma co się kłucić na ten temat Wink

Ja np prawdopodobnie w przeciwieństwie do Ciebie uważam, iż MsProject nie jest efektywny w prowadzeniu projektów gier komputerowych, albowiem więcej czasu spędza się nad tabelkami, wykresami, analizą, niż samą produkcją gry. To samo tyczy się Jira do obsługi issues.

*produkcja gry pod kątem producenta, PM etc
– efektywne rozłożenie pracy pracowników
– pilnowanie pracy pracowników
– ewaluacja buildów
– feedback nt poprawności działania buildów (czy jest tak jak w kontrakcie)
– kontakt z wydawcą, klientem, licensorem etc
– raportowanie
– meetingi
– sporządzanie proponowanych pipeline’ów
– rozmowy z teamem developerskim
– motywacja teamu developerskiego
– zdobycie zaufania klienta, wydawcy, licensora
– wywiązywanie się z terminów
– wstępne planowanie QA
– prioryteryzacja preprodukcji, produkcji, QA
– tworzenie risk planów i odpowiednia motywacja ich osobą ‚ponad nami’
– więcej już mi się pisać nie chce, tak samo jak w przypadku pisania tego Arta – Art jest po to by ktoś mógł zacząć robić gry, albowiem nie ma na świecie żadnego arta, który powie Ci jak gry robić – taką wiedzę zdobywa się przez doświadczenie, każdy projekt jest inny, każdy rynek jest inny (mobile, ds, psp, xbox, PC, app store) i do każdego inaczej podchodzi się do projektów, używa się innych devkitów, zarządzanie projektem wygląda inaczej, tak samo jak praca nad takimi projektami.

I gdzie tu teraz czas na tworzenie tabelek, przestawianie zadań w MsProject? Ja osobiście wolę skupić się na tym co ważne, a dotproject w raz z mantisem, bądź flyspray sprawdza się znakomicie w rozpisywaniu zadań/problemów QA