Czym jest Build in Public?

Jak sama nazwa wskazuje – polega na publicznym budowaniu 😛

Nieważne, co budujesz – czy jest to gra, firma czy strona internetowa – możesz publicznie opisać proces tworzenia. Build in Public dotyczy jednak częściej większych projektów – takich, których tworzenie trwa wiele miesięcy czy nawet lat.

Ponieważ gry są dużymi projektami – często tworzone są publicznie. Ten rodzaj zapisywania swoich osiągnięć otrzymał nawet swoją nazwę – devlogs.

Ze swojej strony mogę polecić devlogi robione na YouTube przez Randy'ego. Prócz samego tworzenia gry dodaje on do swoich logów wiele humorystycznych elementów. Tworzył też swoją stronę internetową publicznie, w trakcie live streamów. Czy muszą to jednak być filmy? Niekoniecznie! Do logowania swojej pracy oprócz vlogów świetnie się nadają też blogi 😉 Ale czy to znaczy, że Randy udostępnił kod strony? Czy trzeba to robić?

To nie open source!

Wydawać by się mogło, że skoro udostępniamy wszystko, to musi być to rozwiązanie open source – o otwartym, ogólnodostępnym kodzie a najlepiej to jeszcze na bardzo liberalnej licencji.

Niekoniecznie! Build in Public polega na opisywaniu swoich dokonań i publikowaniu osiągnięć krok po kroku. Nie oznacza to, że każdy może budować i „publika” buduje projekt.

Oznacza to, że zamiast zaprezentować swój projekt w jego końcowej fazie, możesz pokazywać osobom, które cię śledzą, jak wygląda proces tworzenia.

Są więc to w pewnym stopniu działania marketingowe.

Marketing w pierwszych fazach produkcji

Publiczne pisanie o produkcie to działania marketingowe, które możesz podjąć na najwcześniejszym etapie produkcji. Wystarczy, że istnieje tylko nazwa projektu – nawet tymczasowa – i już możesz opisywać, jakie wykonujesz działania.

– Pierwsze spotkanie designerów w jakim klimacie chcemy grę? Dyskusja jaki będzie gatunek?

Napisz posta, jak wygląda takie spotkanie! Co omówiliście na tym spotkaniu i wzięliście pod uwagę przy waszym wyborze? Przyszli gracze mogą ekscytować się klimatem i wspominać na forach, że nadchodzi interesujący projekt – nawet jeżeli za dwa lata.

Nawet większe studia korzystają z tej techniki. Riot Games zapowiedziało swoje MMO na... Twitterze!

Co prawda nie tworzą całej gry publicznie, ale jest to pokazanie jak nawet we wczesnej fazie produkcji można tworzyć akcje marketingowe – w zasadzie znając tylko i wyłącznie gatunek gry!

Myślisz sobie – tak, to Riot Games, więc mają duży ruch – ale twoja mniejsza gra też może zdobyć zasięgi!

Napisz na forach związanych z twoim gatunkiem czy klimatem o tworzeniu gry – może zdobędziesz pierwszych fanów!
Warto do takich rzeczy stworzyć np. Serwer na Discordzie czy grupę na Facebooku – ale o tym już w innym poście dotyczącym marketingu 😛

Szybki feedback i recenzja

Jedną z dużych zalet Build in Public jest szybki feedback. Niezależnie, czy przeczytają to 4 osoby, czy 400, każda z nich będzie miała swoją opinię. i powinno się zachęcać do zostawienie gdzieś feedbacku!

Co, jeśli właśnie wzięliście się za grę RTS, a społeczność powie wam, że nie tego oczekiwali?

Na YouTube publikowane są nawet całe filmy dotyczące stanu danego gatunku. Zamiast ignorować tę wiedzę, może warto wejść w odpowiednie miejsca i zapytać – co sądzą o waszym tytule?
A co jest lepszym tematem do rozmowy, niż robimy grę i chcemy, żeby wam się spodobała? Gracze z chęcią opowiedzą, o czym marzą i czego pragną.

W późniejszych etapach rozwoju możecie też pytać o dokładne feature’y, które rozpisane dokładniej w devlogu mogą okazać się sukcesem lub klapą. Beta testy, zanim zrobicie beta testy 😉

Jak zacząć? Jak prowadzić?

Od social media! Nie potrzebujecie dedykowanej strony czy bloga. Możecie postować na Twitterze, Facebooku czy Discordzie. Tam, gdzie dotrzecie do swojej grupy docelowej.

Niezależnie, czy zdecydujesz się na o wiele trudniejsze wideo, czy łatwiejsze tekstowe blogi, warto pamiętać o cykliczności – cotygodniowe logi mogą zachęcić stałych czytelników do powrotu, a nowych utwierdzić, że projekt jest żywy i dużo się w nim dzieje!

Czego jednak warto unikać?

Numeracji i podziału na części! Często czytelnicy są przerażeni, widząc cyfry, że muszą zrozumieć większą całość – starajcie się, aby każdy devlog był oddzielną całością opisującą jakiś element procesu. Warto też linkować inne wcześniejsze logi, aby potencjalny czytelnik wiedział, gdzie udać się dalej.

Dzięki, Zosia, za korektę!