Skip navigation

Monthly Archives: Maj 2010

Negocjacje projektu to twardy orzech do zgryzienia, niby można napić się piwka z producentem od wydawcy, niby można sobie pożartować, ale tak czy siak każdy zbiera sobie asy do rękawa, by je w odpowiednim momencie pokazać. Moim zdaniem odpowiednie podejście do tego tematu ma wiążący wpływ na jakość i zakończenie danego projektu. Co zrobisz gdy wydawca cały czas prosi się o jakieś ficzery? Co zrobisz gdy wydawca będzie chciał inną postać główną 2 dni przed Goldem? Co zrobisz gdy wydawca 2 tygodnie po Becie nie dostarcza feedbacku, a za 2 tygodnie masz oddać RC? Co zrobisz gdy wydawca dostarcza Ci feedback którego nie da się zrozumieć, ani nie można podjąć działań by coś naprawić? (np. „nie podoba mi się ten level 13”) Co zrobisz gdy licensor spóźnia się z feedbackiem a za 2 dni musisz oddać RC?

To jest tylko 1% pytań jakie można zadać. Wpływ wydawcy na tworzenie gry jest ogromny, osoby, które nie mają jeszcze doświadczenia, myślą sobie coś w stylu „Mam tak zajebisty team, zrobimy zajebistą grę” – gówno prawda 🙂 Postaram się opisać z leksza jak ja przygotowuje się do negocjacji i w jaki sposób do tego podchodzę, ponoć mi to wychodzi więc podzielę się troszkę.

Jak przygotować się do negocjacji z wydawcą w trakcie wykonywania projektu:
– Jeśli nie brałeś udziału w negocjacjach kontraktu projektu, dowiedz się od swojego szefa jakie daty zostały wprowadzone, tak byś wiedział ile czasu wydawca ma na dostarczenie feedbacku, do kogo uderzać gdy ma się jakieś pytanie
– Poznaj cały główny team po drugiej stronie, wydawca może Ci dać Producenta z którym będziesz się kontaktował, ale warto mieć bezpośredni kontakt do designera i programisty ze strony wydawcy.
– Dowiedz się jakie ficzery zostały zaakceptowane, stwórz listę ficzerów, które będą zakresem projektu (jeśli taka lista nie została wykonana)
– Przed startem projektu zrewiduj checkliste milestone’ów, możliwe, że czai się tam mina.
– Dokładnie dowiedz się jak ma przechodzić process developingu gry dla tego wydawcy. (jakie milestone’y, co musi być w technologii)
– Też napisze: dokładnie zanalizuj plan, tak byś wiedział ile czasu jest na ‚zachcianki wydawcy’.

Uwagi dla osób negocjujących z wydawcą projekt w trakcie realizacji:
– Nigdy, ale to nigdy nie bądź wulgarny. Mówiąc coś takiego: „Nie zrobimy tego, nie ma opcji” robisz wokół siebie złą aurę. Bądź miły, zawsze, nawet jak dostajesz zjebe.
– Konkretnie tłumacz problem i sposób realizacji
– Zawsze powiadamiaj wydawcę o napotkanych problemach w projekcie i sposobie na ich naprawę. Uwzględnij w raporcie czas trwania naprawy.
– Nie gódź się szybko na jakieś feature needs od wydawcy. 3 razy się zgodzisz i wydawca będzie wiedział, że nie masz jaj i będziesz robił wszystko o co prosi, wykorzysta to by mieć w projekcie jak najwięcej ficzerów, a Ty już będziesz się martwił jak je mu dostarczyć.
– Każde słowo jest wiążące, nie obiecuj czegoś, czego nie jesteś w stanie zrobić.
– Każdą małą pierdółkę (ficzer) o którą prosi wydawca i która robisz zapisuj sobie./
– Pamiętaj o zasadzie coś za coś, to naprawdę działa. Zamiast mówić wydawcy „nie mamy czasu na to”, lepiej powiedzieć, że nie mamy czasu by to zrealizować, ale zamiast tego możemy zrobić to, co też będzie fajne. (A to jest już w feature requestach i jest znacznie mniej skomplikowane)
– Konkretnie pisz raporty tak by wydawca wiedział z kim ma do czynienia.
– Na samym początku zdobądź zaufanie wydawcy, poprzez profesjonalne podejście i zrobienie wszystkiego na czas, z konkretną jakością, dzięki temu później będzie Ci łatwiej go przekonać by porzucił parę pomysłów.
– Zawsze konsultuj features needs z teamem.
– Gdy wydawca prosi Cię o spory ficzer, nie dawaj mu odpowiedzi od razu, skonsultuj to z teamem, poproś programistów o napisanie ile czasu zajmie dodanie takiego ficzera i jakie dodatkowe problemy mogą wyniknąć z takiej funkcjonalności. Tak samo pytaj się grafików/muzyków/etc ile czasu zajmie im przygotowanie czegoś. Skonsultuj to z wydawcą, rozsądny wydawca będzie wiedział kiedy powiedzieć ‚nie’, bez zaglądania w ficzer listę z kontraktu.
– Dobrze tłumacz wydawcy co jest w danym buildzie, co ma raportować, a czego nie.
– Od pierwszego builda proś wydawcę o feedback. Tak byś już na początku dostosowywał projekt pod jego ‚wizję’. Unikniesz wtedy miliona poprawek na końcu.
– Gdy się z czymś nie wyrobisz poinformuj o tym wydawcę dużo wcześniej, tak by można było negocjować uaktualniony plan.
– Często aktualizuj plan, tak by wydawca wiedział gdzie jesteśmy.
– Daj dostęp wydawcy do bugtrackera
– Daj dostęp wydawcy do programu zarządzającego produkcją.
– Informuj wydawcę o QA projektu.
– Gdy Wydawca robi koło, czyli chce byśmy coś zmienili -> zmieniamy -> później znów chce by było tak jak dawniej nie bój się go zjebać, powiedz mu ile czasu straciliśmy i ile czasu mieli byśmy więcej na polishing projektu.
– Gdy wydawca dostarcza Ci feedback w którym 90% to rzeczy typu „Level 13 mi się nie podoba”, nie wkurwiaj się, tylko wrzuć całość do jakiegoś XLSa i zadaj pytania tak by wydawca mógł się bardziej określić.
– Gdy wydawca dostarcza Ci feedback w którym 90% to rzeczy, których się zrobić nie da, znaczy to, że nie ma pojęcia co jest w kontrakcie, na jakim etapie jest projekt, albo nie dawał Ci feedbacku wcześniej. Uświadomić go wtedy trzeba na co jest już za późno i dlaczego.
– Wysyłaj ‚tygodniówki’ wydawcy, tak by wiedział ile czasu kto poświęca na co w tygodniu, będzie wiedział czy jest czas na dodanie czegoś nowego.
– Staraj się budować referencje do których możesz szybko dotrzeć. Np. Wydawca prosi Cię o dodanie jednej postaci. Widząc log próśb wydawcy wiesz, że prosił o to miesiąc temu i zaakceptowaliśmy, że tej postaci nie robimy – temat się kończy. Widząc ilość pracy grafików wiesz już, że nie jesteś w stanie tego zrobić. Widząc ilość pracy animatorów i ich poprawek wiesz, czy można taką postać wykonać. Ważne byś był w stanie szybko wydawcy powiedzieć z czym się dana mniejsza prośba wiąże.
– Pamiętaj na co się godziłeś z wydawcą a na co nie. Bardzo często mam tak, że wydawca co jakiś czas prosi o tą samą rzecz, która na początku wykluczyliśmy. Czasami potrzeba też wydawcy pokazać miejsce w którym razem wykluczyliśmy ten ficzer. Mając takiego asa wydawca już gówno Ci zrobi.
– Ja w każdej rozmowie mam nastawienie „zanalizuje i zobaczę”, chociaż wiem, że czegoś nie da rady zrobić.
– Gdy wydawcy zależy na jakimś ficzerze, a nie możemy go zrobić, dogłębnie tłumaczę mu dlaczego tego nie możemy zrobić. Przykładowo jak nie ma czasu na zrobienie tego, motywuje się tym, że projekt będzie dopieszczony, tym, że nie będziemy wprowadzać takich zmian, które zmniejszą czas polishingu, etc etc. Wydawca często po analizie tego co mówie dochodzi do wniosku, że mam rację i że gra już teraz wygląda zajebiście, a będzie wyglądała jeszcze lepiej, więc po co to psuć…
– Jak chcesz feedback od wydawcy dobrze napisz do czego feedback oczekujesz i jak powinien być dostarczony
– Zbieraj  feedback od wydawcy do wszystkiego (HUD, Menu, AI, animacje, grafika, dany ficzer, dana minigra) nawet gdy te rzeczy są WIP. Czasami jednak warto pokazać dopiero gotową część gry, zależy od wydawcy, można to wywnioskować ze sposobu dostarczenia feedbacku. Gdy wydawca mówi Ci, że coś nie wygląda dobrze, ale jest to alpha, jest rozsądny i wie, że zostanie to naprawione, a jak Ci mówi „to wygląda do dupy, zredesignujcie to” – znaczy tyle, że więcej WIPa masz nie pokazywać 😉
– Konsultuj każdego milestone’a dogłębnie z wydawcą, tak byś sam wiedział dokładnie czego od Ciebie oczekują. Czasami checklista jest pobieżnie rozpisana i warto się dopytać.
– Codziennie rozmawiaj z wydawcą, nawet o pogodzie.
– Chwal wydawcę jak znajdzie fajny ficzer, albo znajdzie jakiś błąd. Chyba każdy lubi jak się go chwali nie? Wydawca też człowiek.
– Ja conf calle prowadzę przez skype’a (chat) by mieć archiwum, często jak się rozmawia przez telefon coś może wylecieć, no i nie będziesz miał zabezpieczenia jak się na coś nie zgodziłeś a wydawca to zaakceptował. Proponuje na początku dogadać możliwość tworzenia conf – chatów, zamiast rozmowy telefonicznej.
– Informuj wydawcę o ważnych nadchodzących wydarzeniach: np. testing gry przez osoby z poza firmy
– Gdy masz dobrego designera/lead programmera daj im bezpośredni kontakt do designera/programmera ze strony wydawcy, ominiesz wielu problemów komunikacyjnych, a w związku z tym projekt może będzie lepszy.
– Informuj wydawcę o problemach technicznych silnika którego używacie. Poinformuj go ile czasu trzeba na naprawienie tego i do kogo się odezwać by przyśpieszyć naprawienie.
– Informuj wydawcę o wszystkich problemach w teamie: np. choroba, urlop (to też problem 😛 ) tak by wydawca o takich rzeczach wiedział i zdawał sobie sprawę z tego, że developer to też człowiek tak samo jak wydawca.

Przykład:
Wydawca: Cześć, tak ostatnio sobie pomyślałem, że fajnie byłoby mieć jakiś fany postprocess w naszej grze, co o tym myślisz, wysłałem Ci listę postprocessów jakie chciałbym zobaczyć?
Producer: Cześć, świetny pomysł!
Wydawca: to kiedy mógłbym taki zobaczyć w grze?
Producer: porozmawiam z ludźmi, zorientuję się ile trzeba wykonać pracy i za chwilkę się do Ciebie odezwę.

Szybkie rozwiązywanie takich kwestii też jest ważne, wydawca czekając tydzień na Twoją odpowiedź, może pomyśleć, że temat jest już wdrożony w życie. Nie mówiąc o tym, że po prostu wydawcy się nie olewa.

Producer: Cześć, rozmawiałem z ludźmi, implementacja wszystkich postprocessów zajmie 2 tygodnie, zaznaczyłem Ci na liście, które z tych efektów będą kłopotliwe i które mogą sprawić sporo problemów z optymalizacją. Zaznaczyłem Ci też, które postprocesy możemy zrobić i na kiedy. Zanalizuj dokument i daj mi znać co o tym myślisz 🙂
Wydawca: Czemu nie możecie ich wszystkich wykonać?
Producent:  Głównie ze względu na czas, jak widzisz zostało nam 4 tygodnie do końca projektu, zaczęliśmy wprowadzać tą zmianę o która prosił Wasz designer, potrzebujemy jeszcze tydzień czasu by ją skończyć. Będziemy mieli trudne 3 tygodnie poprawiania błędów i testowania, tak jak pisałem w mailu jesteśmy w stanie zrobić te postprocessy, które zaznaczyłem, tak czy siak nie powinniśmy ich robić, ze względu na brak czasu, ale razem stwierdziliśmy, że te efekty będą miały wpływ na odbiór, więc parę z nich zrobimy i naprawimy wszystkie problemy z optymalizacją.
Wydawca: OK, co nie zmienia faktu, że było by fajnie je wszystkie wprowadzić.
Producent: no co racja to racja, zrobimy tak: wprowadzimy te postprocesy, które zaznaczyłem, wprowadzimy poprawkę od Waszego designera, stestujemy grę i ponaprawiamy błędy, a jak starczy nam czasu doimplementujemy resztę postprocesów, co Ty na to?

Gdy tu wydawca się nie godzi trzeba już zacząć inaczej mówić:
Producent: Niestety naprawdę nie mamy czasu by je wszystkie zaimplementować. Zgodziliśmy się na poprawkę Waszego designera, choć dobrze wszyscy wiemy, że taka poprawka na tym etapie nie powinna być wprowadzana. Zgodziłem się byśmy zaimplementowali parę z postprocesów o których mówiłeś, choć i tak miałeś sporo czasu by nam o tym powiedzieć wcześniej. Nie mogę spełnić Twojej prośby, albowiem wiem, że nie zdążymy ze wszystkim i przez to projekt, jego jakość może ucierpieć, a tego byśmy nie chcieli.

Gdy wydawca dalej chce je zrobić:
Producent: Nie wiem dlaczego aż tak bardzo zależy Ci na tych postprocesach, jak chcesz możemy zrezygnować z poprawki Twojego designera, ale wtedy gra straci na grywalności. Moim zdaniem lepiej jest skupić się na tej poprawce i konkretnym spolishowaniu gry. Nie możemy sobie teraz pozwolić na implementacje czegoś co zajmie 2 tygodnie czasu z istniejącym ryzykiem powstania błędów w optymalizacji. Gdy takie błędy się pojawią może być trudno oddać projekt na czas.

Gdy wydawca dalej chce je robić, powinieneś dalej wałkować ten temat aż do skutku. Powiedzenie w stylu „sorry, ale nie ma tego w kontrakcie, nie mówiłeś o tym na początku projektu” zostaw sobie na koniec. Często jest tak, że wydawcy już się źle robi od takiego pierdolenia i chce skończyć temat po 3h gadania 🙂

Na ten temat, można by pisać i pisać, mam nadzieję, że przynajmniej troszkę komuś pomogłem.

Post mortem powinien być obowiązkowy w każdym projekcie, jest to coś w rodzaju „co zrobiliśmy źle i jak możemy się przed tym zabezpieczyć w następnych projektach.

Podczas trwania jakiegokolwiek projektu na bieżąco zawsze uzupełniam listę błędów, które popełniliśmy w projekcie tak by na koniec stworzyć z tego dokument i przedstawić wszystkim co zrobiliśmy źle i jak się przed tym zabezpieczyć. Przy większych projektach tworze taki dokument co milestone, by na bieżąco mówić wszystkim co zepsuliśmy i jak to naprawiliśmy/mogliśmy naprawić. Dzięki temu:

– Team czuje bardziej, że ‚jest w projekcie’ i ma wpływ na podejmowane decyzję. W końcu rozwiązanie jakiegoś problemu = cały team
– Team widzi, że ktoś ciągle patrzy i stara się trzymać projekt by się nie rozleciał
– Team widzi, że jest w stanie poprawiać poważne problemy, których ktoś inny poprawić nie potrafił
– Producent/Szefostwo widzą, że team wie co robi i robi to profesjonalnie

Taki dokument również dostarczany jest wydawcy, z prośbą o napisanie takiego z ‚ich strony’, dzięki wymianie dokumentami, w kolejnych projektach można uniknąć wielu problemów.

Przykład problemu:
Problem:
Zbyt późny feedback wydawcy w początkowej fazie projektu. Przez co wprowadzaliśmy za dużo zmian w końcowej fazie, zmiany te mogły zostać wprowadzone na samym początku dzięki czemu zaoszczędzilibyśmy sporo czasu.  Czas ten mógłby być zaadresowany na dopracowywanie projektu.

Rozwiązanie problemu:
– Wydawca powinien dostarczać feedback również w początkowej fazie projektu, na czas, zgodnie z założonymi datami.
– Producent powinien skupić się na rozmowach z wydawcą w początkowej fazie realizowania projektu.”

Oczywiście problemy na które natrafiamy przy produkcji są różne, ale tak czy siak starał bym się je wszystkie zawsze przedyskutować z teamem, tak by każdy wiedział co się dzieje.

Swoją drogą mój ostatni PM miał w sobie w 90% issues związane z wydawcą, to daje do myślenia 😉

Tak jak kiedyś obiecałem opiszę parę ciekawych rzeczy, na pierwszy rzut leci przesłany przez kogoś temat: Sposoby szukania inwestorów i/lub wydawców (bądź po prostu
pieniędzy) dla projektu, który jest w zaawansowanym studium produkcji. Nie pamiętam niestety kto przesłał taką prośbę, ale postaram się jak najlepiej opisać ten temat.

Po pierwsze musimy przyjrzeć się w jaki sposób developerzy pracują/zarabiają. Pierwsza i chyba najczęstsza forma pracy to:

– Wykonywanie projektu na zlecenie.
Przykładowo firma A zleca tworzenie gry firmie B. Równie często tworzone są przetargi na projekty, w którym to developer musi wydawcy powiedzieć ile czasu taka produkcja potrwa i ile pieniędzy Firma A będzie musiała zapłacić za wykonanie takiego projektu. Oczywiście tekst na skype w stylu: „80k $ and 5 months” nie wchodzi w grę, ale to już inny temat, wycena projektu, planowanie i dobre ‚sprzedanie’ swojej firmy to podstawa, ale o tym będę pisał nieco później.

Kolejna forma pracy to:
– Firma A chce stworzyć swoją grę, ma na to pieniążki, tutaj raczej wiadomo o co chodzi.

Dalej:
– Firma A chce stworzyć swoją grę, ale na znanej marcę. Markę (IP) można dostać na różnoraki sposób: zapłacić, dać revenue, wygrać przetarg, ładnie poprosić 😉
Często w tej formie pracy trzeba użerać się z licensor holderem (który udostępnia nam prawa do marki), który może mieć wpływ na produkcje, tym bardziej jeśli jest ze stanów (ESRB i konkretna jazda po jakości), ale to też nie jest temat na tego posta

Dalej:
– Firma A zleca stworzenie projektu Firmie B, inwestuje w produkcje projektu Firmy B, ale w zamian chce/ma pieniążki ze sprzedaży. Tutaj raczej wszystko powinno być jasne.

Dalej:
– Osoba prywatna (inwstor) ma marzenie i chce zrobić grę, więc zleca wykonanie projektu. Praca z inwestorem różni się tym, że inwestor nie ma pojęcia o gamedevie i prędzej czy później jego wielkie marzenie dotyka firmowe finanse i gówno powstaje 🙂  (nie mówiąc o podstawowych problemach w kontroli projektu)

Może istnieją jeszcze jakieś inne formy pracy (a, za darmo!) ale o nich pisać nie chcę. Moim zdaniem za każdym razem osoba która chce znaleźć wydawcę/inwestora powinna postawić się na miejscu osoby, która miała by włożyć pieniądze w projekt. Czy włożył byś pieniądze w coś, czego stworzyć się po prostu nie da? Czy włożył byś pieniądze na coś, przy czym pracują niedoświadczeni i niezgrani ludzie? Czy włożył byś pieniądze w firmę, która nie ma żadnego portfolia podobnych projektów? Czy włożył byś pieniądze na kogoś, kogo się nie zna? 🙂 Można się posrać, nie? 🙂

Młodzi developerzy mają najgorzej, bez kontaktów muszą zaczynać od samego zera, nie mają komu wysłać portfolia, a jak wysyłają bezpośrednio do office@nazwafirmy.com zostają zlewani. Sposobów do szukania wydawców/inwestorów jest mało:

– Zainwestowanie w GDC czy inny konwent, gdzie można pokazać gierkę. W takich miejscach zbiera się najwięcej osób z branży.
– Wysłać Demo/Portfolio firmy/projektu gdzie tylko popadnie (również do Polskich firm, choćby do Codeminion jeśli będzie to jakiś casusal, konkretni ludzie)
– Znaleźć osoby prywatne (inwestorów) i wysłać im demo/portfolio/budżet/plan projektu.
– Publicznie pokazać demo/portfolio firmy/projektu tak by zebrać dane analityczne do biznes planu.

To chyba jest logiczne, jeśli nie – mogę spamować przykładami na gg/skype. To co już nie musi być logiczne, to przygotowanie się do szukania wydawcy/inwestora. Więc co powinieneś przygotować gdy szukasz wydawcy, który docelowo włożył by pieniążki w produkcję:

– Grywalne demo gry (nie kamera lecąca koło grafiki 3d), które pokazuje główne elementy gameplayu. Coś takiego ludzie nazywają Vertical Slice (vs), googlując znajdziesz pełną formułkę. Demo musi miażdżyć, nie może być w nim żadnych placeholderów.
– Portfolio firmy. Jeśli Twoja firma nie ma żadnych projektów skończonych, pochwal się tym co robiły wcześniej osoby uczestniczące w projekcie, napisz parę zdań o nich (ile mają lat expa, w czym pracowali, jaka spełniali funkcje etc).
– Resource plan – czyli rozpiska potrzebnych do wykonania resource’ów (w tym ludzi) w miesiącach
– Production Plan – miesięczna rozpiska zadań, by dojść do finału (na tym etapie nie wdrażamy się w szczegóły, wydawca musi poznać ogólnie zamysł na stworzenie takiej produkcji) Musi też wiedzieć kiedy planowo można skończyć grę pod daną platformę.
– Game Proposal document – dokument opisujący Twoją grę, to nie ma być GDD, w takim dokumencie mają być konkrety nie jakieś tabelki. (konkrety = rozpiska głównego gamplayeu, jakie platformy gra ma wspierać, jaka technologia, jaka grupa docelowa gry, ilę planowo języków, można dorzucić badania rynku, napisać o grach które są podobne i ile na tym zarobiły etc etc – dokument ma ‚sprzedać’ Twój pomysł.
– Art Bible (czy jakkolwiek sobie to nazwiesz) – dokument, po którego przeczytaniu/zobaczeniu wydawca będzie wiedział jaki jest klimat gry, będzie wstanie ocenić grupę docelową.
– Budżet – rozpisany miesięczny budżet, z propozycją płatności (za milestone, za kwartał, za ‚poważny’ milestone (taki jak RC, Release, Ref etc), płatne z góry etc. Ogólnie najczęściej jest tak, że zapłatę chce się dostać na start, w połowie i na końcu, ale to już można sobie obgadać z wydawcą, ważne byś mu zaproponował jak chciałbyś widzieć rozbudżętowanie projektu. Wydawca musi wiedzieć ile go taka impreza będzie kosztować i kiedy miałby płacić (i za co)
– Rozpiska milestone’ów z wymaganiami. Zaproponować musisz wydawcy co chcesz do danego milestone’a zrobić (np. First playable = można używać placeholderów, brak muzyki. Beta = grafika 100% gotowa, muzyka zrobiona, podpieta etc) Wydawca powinien mieć też taką checkliste, która Ci przekaże jak już będzie się pisał w projekt. Ważne jest by wydawca mógł sprawdzić sobie czy za ten milestone może Ci zapłacić (czy wszystko zostało gotowe), w checkliście mogą być nawet takie rzeczy jak: „Czy ikonka gry została wykonana dla wszystkich rozdzielczości?, Czy ikonka gry została podpięta pod wszystkie rozdzielczości”, więc można sobie wyobrazić ile tam tego jest i jak ważne jest by wszystko było na czas.
– GDD nie wysyłaj, ale miej już taki na ukończeniu, wydawca może będzie chciał go zobaczyć. To samo tyczy się TDD, jak okaże się, że wydawca będzie chciał sprawdzić podejście do technologii.
– Możesz przedstawić wydawcy proponowane podejście do kontaktu z nim. Np. cotygodniowe raporty, telefony, co tygodniowe sprawdzanie buildów i wysyłanie swoich uwag, program do zarządzania feedbackiem od wydawcy (jakiś issue tracker), program do sprawdzania postępów nad projektem (jakis project manager)
– Ja jak bym był wydawcą chciałbym również wiedzieć w jaki sposób zorientujemy się, że gra się sprzeda, że gracze ją polubią, czyli jak miałby wyglądać proces preprodukcji, gdzie tworzone byłyby prototypy (przez niektórych nazywane: proof of concept)

To wszystko oczywiście w języku angielskim, nawet jak wysyłasz do polaków, chyba większego ‚respekta’ dostaniesz.

Tak naprawdę mało kto przygotowuje tyle dokumentów, czasami wysyła się demo na skypie komuś i tyle, ale jak się nie zna ludzi to trzeba profesjonalnie do tego podejść niestety. Polecam przeczytać książkę „Game Producers Handbook 2nd”, w której można znaleźć więcej informacji na ten temat. Oczywiście, jak już ubijecie targu pamiętaj o tym by się zabezpieczyć (daty dostarczania feedbacku, daty płatności, daty akceptacji powinny być w kontrakcie 😉 ) Często bywa tak, że ktoś wyśle to wszystko o czym pisałem do kogoś, a ten ktoś będzie chciał mu zlecić wykonanie innej gry 🙂 Gdy wydawca nie będzie oczekiwał od Ciebie żadnych dokumentów, zastanów się dwa razy czy chciałbyś z takim pracować, bo możesz sobie zniszczyć parę ładnych latek życia 😉

Mam nadzieję, że coś z tego tekstu ktoś wyniesie, powodzenia dla wszystkich tych, którzy chcą znaleźć wydawce!   (jak to brzmi 😀 )

Dzisiaj mija mi 6 roczek w GD 🙂