- nie napisałeś nic o marketingu. Chociaż pozornie wydaje się że darmowy projekt go nie potrzebuje, to mi się to wydaje sporym błędem. Dobrym przykładem jest Afterfall, który przez 2-3 wpadki i lekką niefrasobliwość stał się obiektem kpin, przez co nikt tej gry nie traktuje już poważnie. Musieliście pewnie zdawać sobie sprawę że jako kolejny projekt polskiej gry postapo, będziecie do niej porównywani, a gracze (nawet ci którzy bardzo by chcieli by się wam udało) będą mówić że się nie uda. Wpisałem sobie w przeglądarkę Slincer, i w zasadzie oprócz newsów na schronie wyskoczyła nowina na Polygami i ze dwie na GameCorner. Wydaje mi się że trochę ten obszar zaniedbaliście, zresztą pewnie nie mieliście osoby odpowiedzialnej wyłącznie za ten aspekt projektu?
Zgadza się, marketing u nas leżał. Nie wspomniałem o nim, dlatego że go u nas nie było. Newsy na Polygami i GameCorner ,,napisały się same", lecz na gram.pl daliśmy cynk. Mieliśmy pewien plan, nawet na schronie miał pojawić się dłuższy wywiad (z trzema osobami od nas), nawet nie wiem dlaczego się nie pojawił - albo go nie wysłaliśmy ostatecznie, albo o to poprosiłem. Wszystko co było publikowane nie było przemyślane za bardzo, ale drugi raz się to już nie powtórzy.
Projekt który tworzymy obecnie będzie zaprezentowany w inny sposób i tutaj na pewno o marketingu nie zapomnimy.
- Rola szefa projektu - opisałeś sporo zagadnień z tym związanych oraz problemów jakie napotkałeś. Wydaje mi się że jednak źle poszedłeś do tej roli. Sam prowadziłem kilka małych projektów (oczywiście kompletnie nieporównywalnych do tworzenia gry) i zawsze traktowałem to zajęcie, jako kontrolowanie innych - patrzenie im na ręce, sprawdzanie co robią i ewentualne poprawianie tego. Po przeczytania twojego wpisu, mam wrażenie że głównie skupiłeś się na wykonywaniu elementów projektu, siedzeniu w kodzie. Nie uważasz że to błąd, że rolą szefa przede wszystkim powinno być kontrolowanie innych, a nie wykonywanie roboty którą oni mogli by zrobić?
Uważam, że był to błąd. W tej chwili jest inaczej - na prawdę chcemy się uczyć i cieszę się, że dostrzegamy nasze błędy, szkoda tylko, że tak późno. Fajnie, że Wy też zwracacie uwagę. Powiem krótko - uważam, iż lights out padł przeze mnie. Do dema byliśmy w stanie go doprowadzić, gdybym to inaczej poprowadził - ale do ukończenia gry na pewno nie, tutaj tak czy tak byśmy musieli zawiesić prace lub przenieść je do studia.
W LO nie było Wiki, raportów z prac, konferencji, dotprojectu. Przykładem jednego z faili jest praktycznie zerowa komunikacja między osobami w zespole. Na 20 osób, tylko ja miałem kontakt z większością, chociaż i tak nie ze wszystkimi. Dla przykładu koncept artysta nigdy nie rozmawiał z programistą. Ot taki przykład. Teraz staram się zrobić to inaczej, na razie udaje się w 100%. Jeszcze bardzo dużo przede mną jeśli chodzi o szlifowanie ,,szefostwa", ale na pewno jest dużo lepiej niż było.
Na pewno upadek też był przyczyną rzucenia się na wszystko. Tzn. lokacje były projektowane od razu wszystkie, modelować też chcieliśmy od razu wszystko. Teraz widzimy to inaczej. Najpierw kończymy design jednej lokacji, konceptujemy, tworzymy modele, składamy lokacje -> projektujemy drugą i tak dalej. Dzięki temu daje to wszystkim kopa na dalszą pracę. Fajny przykład się z tego robi.
Jeśli zaprojektujemy wszystkie lokacje jedna po drugiej, ale nie zaczniemy jeszcze konceptować ani modelować - mamy 10% progressu w lokacjach.
Jeśli zaprojektujemy jedną lokację, skonceptujemy i wymodelujemy - mamy 10% progressu w lokacjach.
Wystarczy tylko spojrzeć i samemu sobie odpowiedzieć, który wariant bardziej motywuje do dalszej pracy.
Dużo jest takich rzeczy. Nic tak nie daje do myślenia, jak praktyka - my jeszcze nie mięliśmy praktyki kończenia projektu, więc teraz mamy taki zamiar hehe
Wystarczy przeczytać Post Mortem, żeby wiedzieć, iż nauczyłem się patrzeć trzeźwym okiem na pracę, ocenić czy jesteśmy w stanie to zrobić czy nie.
