Jak zlecić stworzenie gry: poradnik dla firm

Kiedy warto zlecić stworzenie gry na zewnątrz?

Zlecenie gry zewnętrznemu studiu sprawdza się, gdy wiesz, po co Ci gra, ale nie masz zespołu, który wydawał już gry na docelowe platformy. Budowanie takiego zespołu pod jeden projekt trwa długo i jest ryzykowne. Studio od pierwszego dnia wnosi narzędzia, sprawdzone procesy i znajomość platform.

• Marki i agencje. Gry kampanijne, advergames, gry konkursowe i eventowe, w których termin jest sztywny, a gra musi działać na każdym telefonie.
• Startupy i zespoły produktowe. Prototyp albo pierwsza wersja, żeby sprawdzić pomysł na graczach, zanim zainwestujesz w cały zespół.
• Firmy z aplikacją lub platformą. Minigra albo element grywalizacji w istniejącym produkcie, połączony z kontami użytkowników, analityką czy nagrodami.
• Studia i wydawcy. Co-development, dodatkowi programiści znający konkretny silnik, portowanie na nowe platformy albo optymalizacja przed premierą.

Mniej opłaca się to wtedy, gdy gra jest głównym, długofalowym produktem firmy i potrzebujesz stałego zespołu, który ją rozwija. Nawet wtedy studio może przygotować pierwsze wydanie i przekazać je z dokumentacją, a Ty w tym czasie zbudujesz własny zespół.

Jak wybrać silnik i platformy?

Zacznij od platform i ograniczeń, a nie od nazwy silnika. Ustal, gdzie gracze uruchomią grę: na stronie kampanii, na portalu z grami przeglądarkowymi, w Twojej aplikacji, w App Store i Google Play, na Steamie czy w reklamie typu playable ad. Potem określ, jak szybko gra ma się ładować i na jakich urządzeniach musi dobrze działać.

Przy grach przeglądarkowych i mobilnych, playable ads i innych lekkich produkcjach dobrym wyborem jest Defold. To darmowy silnik z małym runtime’em, w którym z jednego projektu zbudujesz wersje na HTML5, iOS, Androida, Windowsa, macOS, Linuksa, a po rejestracji jako deweloper konsolowy także na konsole. Mały rozmiar gry i szybkie ładowanie są ważne w przeglądarkach, sieciach reklamowych i kampaniach, gdzie wielu graczy rezygnuje, zanim gra się uruchomi.

Defold nie jest jednak najlepszy do każdego projektu i dobry partner powinien to powiedzieć wprost:

• Zaawansowane 3D. Gry oparte na bardzo rozbudowanej grafice 3D i dużych pipeline’ach treści zwykle lepiej pasują do silników projektowanych pod tę skalę.
• Dotychczasowe inwestycje. Jeśli Twój zespół albo gra opiera się już na narzędziach, pluginach czy bibliotekach assetów innego silnika, zmiana może kosztować więcej, niż da.
• Wymagane SDK. Jeśli kluczowe SDK lub middleware istnieje tylko dla innego silnika, sprawdź możliwości integracji przed decyzją.
• Późniejsza rekrutacja. Jeśli planujesz przejąć grę do własnego zespołu, sprawdź, jak łatwo znajdziesz programistów tego silnika na swoim rynku.

Główną specjalizacją Codeward jest Defold, a przy pasującym zakresie wspieramy też wybrane projekty w Unity. Więcej przeczytasz w artykule o Defoldzie na web, mobile, desktop i konsole.

Co powinien zawierać brief gry?

Brief gry nie musi być długi. Jedna lub dwie strony z odpowiedziami na poniższe pytania wystarczą, żeby studio przygotowało realną wycenę i zadało trafniejsze pytania. Jeśli czegoś jeszcze nie wiesz, wpisz „do ustalenia”. To też jest przydatna informacja.

Jak studia wyceniają stworzenie gry?

Wycena gry odzwierciedla zakres i niepewność, która się z nim wiąże. Żadne studio nie wyceni dokładnie ogólnego pomysłu, więc na początku spodziewaj się widełek, a dokładniejszej wyceny po etapie analizy lub prototypie. Najbardziej wpływają na nią:

• Zakres. Liczba mechanik, poziomów, trybów i elementów treści oraz stopień ich dopracowania.
• Platformy. Każda platforma to osobne buildy, testy, wymagania sklepu i wersje SDK.
• Grafika i dźwięk. 2D czy 3D, ilość animacji i efektów oraz to, czy assety są gotowe, czy powstają od zera.
• Backend i integracje. Konta graczy, rankingi, płatności, reklamy, analityka i połączenie z Twoimi systemami lub regulaminem konkursu.
• LiveOps. Wydarzenia, aktualizacje treści, zdalna konfiguracja i narzędzia, których Twój zespół potrzebuje, żeby tym zarządzać.
• Testy. Liczba docelowych urządzeń i przeglądarek oraz poziom testów, jakiego wymaga Twoja grupa odbiorców.
• Utrzymanie. Aktualizacje systemów, SDK i zasad sklepów, które trwają także po premierze.

Porównując oferty, porównuj założenia, a nie tylko kwoty. Zapytaj, co jest w wycenie, czego w niej nie ma i co zmieniłoby cenę.

Fixed price, time and materials czy dedykowany zespół?

Model współpracy decyduje o tym, kto ponosi ryzyko zmian. Każdy pasuje do innej sytuacji:

• Fixed price (stała cena). Sprawdza się przy dobrze opisanym zakresie, na przykład przy grze kampanijnej z ustaloną datą. Zmiany wycenia się osobno, a cena zwykle zawiera zapas na ryzyko.
• Time and materials (rozliczenie za czas). Płacisz za faktycznie przepracowany czas. To dobry model, gdy zakres będzie się zmieniał, pod warunkiem że dostajesz przejrzyste raporty a priorytety ustalasz Ty.
• Dedykowany programista lub co-development. Programiści dołączają do Twojego zespołu na dłużej i pracują w Twoim procesie, a projektem kieruje Twój producent.
• Portowanie. Istniejąca gra trafia na nowe platformy. Rzetelna wycena wymaga wcześniej przejrzenia kodu i aktualnego builda.

Modele można łączyć. Często zaczyna się od etapu analizy lub prototypu o stałym zakresie, a produkcję prowadzi w modelu dopasowanym do kolejnego etapu.

Jak wyglądają etapy tworzenia gry na zlecenie?

1. Analiza. Cele, gracze, platformy, ryzyka i zakres dopasowany do budżetu i terminu.
2. Prototyp. Grywalny test głównej mechaniki i najbardziej ryzykownej części technicznej, na przykład czasu ładowania albo integracji SDK.
3. Produkcja. Funkcje, treści i integracje budowane w kamieniach milowych, z grywalnym buildem po każdym z nich.
4. Testy. Testy na docelowych urządzeniach i przeglądarkach, poprawki błędów i sprawdzenie wydajności.
5. Wydanie. Karty w sklepach, weryfikacja przez platformy, start na portalu lub w kampanii i finalny build.
6. Po premierze. Monitoring, poprawki, aktualizacje, LiveOps albo przekazanie gry Twojemu zespołowi.

W Codeward wygląda to w czterech krokach: poznajemy Twoje potrzeby, planujemy odpowiedni zakres, budujemy i iterujemy, a na końcu wydajemy grę i ją wspieramy. Tam, gdzie to pomaga, korzystamy z narzędzi AI. Gdzie dokładnie, opisujemy w poradniku o tworzeniu gier z AI w outsourcingu.

Kto ma prawa do kodu, gry i kont w sklepach?

Kwestie praw ustal w umowie przed startem produkcji. Po premierze naprawia się je znacznie trudniej.

• Kod i assety. Umowa powinna określać, kto ma prawa do kodu źródłowego, grafiki, dźwięku i tekstów oraz kiedy przechodzą one na Ciebie, zwykle po zapłacie.
• Narzędzia studia. Studia często korzystają z własnych bibliotek i narzędzi. Ustal licencję, która pozwoli Ci utrzymywać i aktualizować grę bez ich udziału.
• Przekazanie projektu. Dostęp do repozytorium, instrukcja budowania, dokumentacja oraz lista zewnętrznych assetów, fontów i ich licencji.
• Konta w sklepach. Wydawaj grę na własnych kontach w Apple Developer Program i Google Play Console, a studiu nadaj dostęp jako członkom zespołu. Przeniesienie aplikacji między kontami wymaga później dodatkowych kroków.

Umowę warto dać do sprawdzenia prawnikowi. Ten poradnik opisuje stronę produkcyjną, a nie kwestie prawne.

Jak powinna wyglądać komunikacja w projekcie?

• Jedna osoba kontaktowa po każdej stronie. Decyzje i uwagi przechodzą przez osoby, które mogą je podejmować.
• Grywalne buildy. Aktualną wersję gry możesz regularnie sprawdzać, a nie dopiero na końcu projektu.
• Wspólna lista zadań. Tablica albo backlog, na którym widać priorytety, postępy i otwarte pytania.
• Decyzje na piśmie. Zmiany zakresu i akceptacje potwierdzone na piśmie, żeby nikt nie musiał polegać na pamięci.

Sygnały ostrzegawcze przy wyborze firmy tworzącej gry

• Dokładna cena bez pytań o cele, platformy czy ilość treści.
• Brak grywalnych buildów aż do końca projektu.
• Niejasne odpowiedzi w sprawie praw do kodu i assetów.
• Naciski, żeby wydać Twoją grę na koncie sklepowym studia.
• Obietnice gwarantowanych pobrań, viralowego zasięgu albo miejsc w rankingach.
• Brak doświadczenia z Twoją platformą lub typem gry i brak możliwości pokazania podobnych realizacji, nawet w zanonimizowanej formie.
• Brak planu testów na urządzeniach, z których korzystają Twoi gracze.

O co zapytać studio przed podpisaniem umowy?

1. Jakie podobne projekty wydaliście i na jakie platformy?
2. Kto będzie pracował nad projektem i kto będzie moją osobą kontaktową?
3. Jak często dostanę grywalny build?
4. Czego nie obejmuje wycena?
5. Jak obsługujecie zmiany zakresu?
6. Co dostanę przy przekazaniu projektu i kiedy prawa do kodu przejdą na mnie?
7. Jak testujecie grę na docelowych urządzeniach?
8. Co dzieje się po premierze: poprawki, utrzymanie, aktualizacje?
9. Czy korzystacie z narzędzi AI i na jakich zasadach?

Odpowiedzi powiedzą Ci więcej niż samo portfolio. Jeśli planujesz grę marketingową, sprawdź, kiedy gry marketingowe się opłacają. Jeśli promujesz grę mobilną, przeczytaj poradnik o playable ads dla gier mobilnych.

O autorze

Paweł Jarosz jest programistą gier z Krakowa z ponad 13-letnim doświadczeniem, założycielem studia Codeward oraz Community & Content Managerem w Fundacji Defold. Tworzy gry i dzieli się praktyczną wiedzą na kanale Unfolding Gamedev na YouTube.