Łukasz Boruń: realia powstawania zespołu w CODE FORGE

Autorem tekstu jest Łukasz Boruń.  Ostatnio Tom Bladko z Bladko Funmobile zapytał mnie o realia powstawania zespołu w CODE FORGE. Świetny pomysł na posta, pomyślałem. W swoim skromnym dorobku oficjalnie wypuściłem kilka gier, jednakże podchodów ku różnym produkcjom było bardzo wiele, a często owe produkcje zostały zabite zanim jeszcze się zaczęły.

Niektóre niemal na początku swoich „prototypów”. W takim razie, co zostało naprawione, jakie błędy wyciągnąłem przy porażkach, że w końcu udało się ukończyć grę?

Wiedza, doświadczenie, „chemia” i pieniądze to główne cechy, którymi należy się kierować tworząc zespół. O ile element – pieniądze – możemy ominąć (jeżeli masz szczęście) tak pozostałych cech nie możemy bagatelizować. Moim zdaniem nie dotyczy to tylko gamedev’u. Wymienione cechy równie dobrze sprawdzały się w innych projektach IT, w których uczestniczyłem. O co więc chodzi w tym wszystkim? Przecież zapaleńców takich ja jest dużo na tym świecie. Graficy, programiści są na wyciągnięciu ręki. No właśnie, czy aby na pewno grafik i programista wystarczą do stworzenia gry, na której chcesz zarobić? A chcesz, prawda?

Wiedza

Grafik i programista – może to tylko moje przeszłe niedouczenie, ale wypowiedziane dwie role wtedy wydawały mi się wystarczające, aby doprowadzić projekt growy od punktu A do punktu B. Głupi byłem. Oczywiście, na świecie istnieją ludzie, którzy potrafili zarobić na grze krocie, tworząc ją zupełnie samemu. Jednakże, ja do takich nigdy nie należałem, a na pewno nie wtedy, nie na początku, gdy stawiałem swoje pierwsze kroki w tworzeniu gier. Dobra! Masz grafika, masz programistę. Siadacie przy stole, jest pizza, jest browar są miliony pomysłów. Twoja wizja gry pod przypływem propozycji od strony zespołu nagle ulega mutacji. Tak! W tedy to było genialne, a teraz? Teraz to będzie zajebiste!

Na pewno!? Nie ma nic złego nad dyskusją na temat projektu. Ba! Jest to nawet wskazane. Jednakże pamiętaj o jednym, skoro to Ty stworzyłeś ten zespół, musisz decydować, a decyzji nigdy nie należy podejmować w pośpiechu (zapewne cały mój zespół teraz ze mnie przysłowiowo „leje”). Przypuśćmy, że to Twoja pierwsza gra. Zapewne zakładasz, że wystarczająco dużo przeczytałeś na temat tworzenia gier, aby poprowadzić taki projekt. No to zonk. Ja też tak myślałem. Przez takie myślenie rozwaliłem kilka projektów. Tworzenie gier to sztuka i rzemiosło, które trzeba doskonalić. Dzisiaj może to wydawać Ci się niezrozumiałe, ale kiedyś to dobrze zrozumiesz. Miedza pomiędzy wiedzą, a doświadczeniem jest bardzo mała. Skoro nigdy nie uczestniczyłeś w produkcji gry to w krótkim czasie ciężko będzie Ci ją zrobić. Twój zespół musi posiadać kogoś, kto wie jak tego „diabola” okiełznać. Nie możesz tworzyć babrząc się w błocie i chodzić w kółko. Prędzej czy później ekipa zauważy, że brakuje im postępu i zacznie się zniechęcać. A jeżeli jeszcze im na dodatek nie płacisz.. no cóż, pewnie szybko paczka się rozpadnie 🙁

Doświadczenie

Czym się różni wiedza od doświadczenia? Lubisz piwo? Tworzysz gry, musisz lubić piwo! Nie jest to Twoje pierwsze piwo, wiesz na ile możesz sobie pozwolić, prawda? To jest właśnie doświadczenie. Zapewne, kiedyś tego nie wiedziałeś i obudziłeś się z bólem głowy. Brnąc dalej, wiedza natomiast pozwoliłaby, zrozumieć ten fakt przez niektórych nazywanym stanem umysłu ;). W takim razie, wiedza  > doświadczenie? A może doświadczenie > wiedza? Rozwiązanie tego zagadnienia jest tak, popieprzone jak zdefiniowane czym w dzisiejszych czasach są gry niezależne. W ostateczności, rozmowy i tak będą musiały przenieść się do pobliskiego PUB’u.

Reasumując. Nie tworząc – nie posiadasz doświadczenia. Nie potrafisz reagować zwinnie na problemy. Masz trudności w podejmowaniu decyzji. Twój zespół poraz kolejny spogląda na Ciebie z politowaniem i ze znakiem zapytania nad głową! Uważaj, znowu przyczyniasz się do rozpadu drużyny. 

W niektórych przypadkach, nie zawsze, to założyciel/inicjator projektu musi posiadać owe doświadczenie. Możesz zawsze posiadać pieniądze, które pozwolą Ci na zwerbowanie doświadczonej osoby, która z w/w obowiązków Cię wyzwoli. Pamiętajmy jednak, że to moja historia, w której pieniędzy nie miałem na start. CODE FORGE to moja 5 inicjatywa. Niestety, powiedzenie „do trzech razy sztuka” tutaj nie zadziałało. Po pierwszej porażce, gdy zespół nie widział wyraźnie leadera projektu postanowiłem zrobić kilka gier samodzielnie. Na początku powstał tytuł, który był miłym doświadczeniem – „Fantasy War”. Gra była połączeniem gry Tower Defense z Hero Aarcade. Ciekawy był fakt, że w tamtych czasach nie grałem zupełnie w gry typu Tower Defense. Gra była wykonana przy wykorzystaniu framework’u XNA Microsoft’u. Potem powstało kilka innych projektów, które przyczyniały się do uzyskania wystarczającej ilości expa, aby podnieść poziom wiedzy i doświadczenia.

Gdy ukończyłem prace nad Roayl Sails (Pierwsza gra od CODE FORGE)  pojąłem, że w tamtym momencie zaczyna się przygoda z tworzeniem gier. Ukończenie RS dało mi niesamowicie wiele cennego doświadczenia i pozwoliło zająć się bardziej skomplikowanymi rozwiązaniami w tej dziedzinie. Napisałem, że tworzenie gier to rzemiosło, a każde rzemiosło doprowadzane do mistrzowskiego poziomu jest poprzedzane latami ciężkich prac, prób i błędów, z których należy wyciągać cenne doświadczenie.

Czas

W moim przypadku od samego początku nastawialiśmy się na gry typu casual na platformy mobilne. Chcieliśmy, w dosyć krótkim czasie, ukończyć projekt i wypuścić go na AppStore. Przy Royal Sails pracowały wówczas cztery osoby: dwóch programistów, grafik i projektant świata. Na początku wszystko szło tak jak należy, mieliśmy plan, wiedzieliśmy jak ma wyglądać tzw „early game” i zatrzymaliśmy się na tym etapie na dwa kolejne miesiące 🙂 Brak pomysłu na middle i end game sprawiał, że błąkaliśmy się w kółko, patrząc cały czas na ten sam projekt,  na te same pieprzone statki i zaczęliśmy mieć z tym problem. Czas zaczął działać na naszą niekorzyść, co przyczyniało się na wiele bezsensownych kłótni i sprzeczek. Projekt, który miał trwać cztery miesiące przeciągnął się do 10 miesięcy. Kto zawinił? Ja! Mieliśmy dobry pomysł, lecz widać było, że brakuje nam zmysłu designerskiego pod kątem gameplay’u. Brak roli Game Designera w zespole powinienem rozwiązać dużo szybciej. Jednakże gra została wydana. Wprowadziliśmy kilka „innowacji”, doklepaliśmy  kolejne misje, przeprowadziliśmy testy i wysłaliśmy grę w świat.

Jeżeli pracujecie nad grą po godzinach, nie macie na projekt pieniędzy to czas jest naturalnym wrogiem, zarówno jakości projektu i rzetelności w zespole. Zanim ruszysz z tworzeniem gry, przemyśl mocno co dokładnie chcesz oddać w ręce graczy. Spisz, opracuj, naszkicuj, prototypuj.

Chemia

Zespół to ludzie, ludzie to charakter, a charakter często jest przyczyną problemów. Dobierając zespół, zastanów się z jakimi ludźmi chciałbyś pracować. Nie chodzi mi tu o ich rolę w zespole, lecz ich sposób „bycia” na tym świecie. Sukcesy i przyjemność z pracy będziesz odnosił wtedy, kiedy w zespole będzie porozumienie i dokładne zrozumienie czym jest zespół. Tak, dla niektórych w dalszym ciągu kolega/koleżanka w tej samej drużynie jest konkurencją. Zespół to szczerość, zaufanie i możliwość polegania na sobie. W jednej z firm, w której pracowałem, staraliśmy się wdrożyć Scruma do wewnętrznych projektów. Mój nowo powołany przełożony (sic!) był przeciwny. Według niego w drużynach scrumowych nie ma rywalizacji i ciężko nagradzać tych, co ciężej pracują od innych w zespole. Miał rację, dlatego nigdy nie można było powiedzieć, że istniały jakiekolwiek zespoły w tej firmie… Na pewno nie od tamtego czasu. Dobierając sobie zespół zastanów się , czy z daną osobą żyje Ci się dobrze, czy potraficie rozmawiać, a nie się sprzeczać, czy zamiast wytykania sobie błędów staracie się je wspólnie rozwiązywać. Innym słowem, czy istnieje między wami chemia.

W niektórych przypadkach warto zastanowić się nad samym sobą. Warto debilne cechy własnego charakteru wypisać na kartce papieru i zastanowić się jak je w sobie poprawić. Bądź spostrzegawczy, jeżeli zespół się dobrze bawi tworząc grę, a jedyne kłótnie wynikają przy kontakcie z Tobą to znak, że coś jest nie tak. Starajmy się być obiektywni i szczerzy wobec siebie. Jeżeli nie lubisz fali krytyki ukierunkowanej w Twoją stronę to najwyższy czas nad tym popracować. Zespół to ciągła debata. Jesteś leadem, a dobry lead pokazuje jak się zachowywać i pracować. Jesteś częścią zespołu, nie zapominaj o tym.

Pieniądze

Zarówno z budżetem, jak i bez niego, można stworzyć świetne produkcje. Jestem realistą, jeżeli co miesiąc Twój pracownik dostanie wiadro kasy to automatycznie dostaje niezłego buffa i może ignorować niedociągnięcia w projekcie wynikające z Twojego doświadczenia, wiedzy i charakteru. Ja rozpoczynałem przygodę bez budżetu. Na pewne wydatki jednak trzeba było wyłożyć pieniądze np. na licencję. Nie odkryje niczego nowego mówiąc, że z pieniędzmi jest łatwiej. Mamy na sprzęt, licencję, miesięczne wynagrodzenia itp. Rozpatrzmy jednak gorszy wariant. Jak namówić przyszłego członka zespołu aby pracował za darmo? Cóż, nie ma czegoś takiego jak praca za darmo. W moim przypadku sprawa pieniądza była jasna od początku do końca. Nie mogłem zaoferować wynagrodzenia miesięcznego, mogłem natomiast podzielić się udziałem ze sprzedaży gry. W niektórych przypadkach to rozwiązanie może się dużo bardziej opłacać. Graj uczciwe, chcesz zarobić na tej grze. Pamiętaj jednak, że sam jej nie robiłeś i nie pal po sobie mostów.

Uff.. Wyżaliłem się 🙂 Royal Sails nie był udaną produkcją, wiele elementów brakowało w tej grze. Jednakże, był zaplanowanym i ukończonym projektem potwierdzającym naszą determinację i chęć uczenia się tego rzemiosła. Dzisiaj nie patrzymy na RS z perspektywy starty wielu miesięcy, lecz zupełnie odwrotnie. Royal Sails to kamień milowy i wielki mur, który udało się przeskoczyć. Naturalnie, teraz widzimy kolejne mury, ale to tylko kwestia czasu, wiedzy i doświadczenia. Cześć!