W branży gier jednym z kluczowych elementów, wpływających na ostateczny kształt docelowej aplikacji jest czas. Przy ograniczonym czasie, nasze możliwości również stają się ograniczone. Wszelkie “dopieszczenia”, dodatkowe elementy interaktywne podbijające uwagę użytkownika, “ulepszacze”- to wszystko przy ograniczonym czasie, zawsze w hierarchii priorytetów jest poniżej głównego celu . Przy krótkich deadlinach, musimy skupiać się przede wszystkim na realizacji podstawowych założeń, oraz jakości naszego produktu. Często drobne mechaniki poboczne schodzą wtedy na drugi plan. Mimo, że często są to małe, drobne elementy, to finalnie potrafią one zrobić sporą różnicę w odbiorze naszego produktu. Czy warto więc zainwestować więcej czasu w swoją produkcję po zrealizowaniu docelowych założeń?
Realizacja vs wizja artystyczna
Staramy się zawsze w taki sposób przygotować dokumentację, aby móc wziąć pod uwagę wszystkie dodatkowe czynniki, które nie zostały uwzględnione pierwotnie w koncepcie. Zależy nam na wyłapaniu na wczesnym etapie nieprawidłowości związanych z założoną przez nas wizją i omówieniu przypadków, dających konkretne rozwiązanie. Jednak zdajemy sobie sprawę, że wszystkiego nie da się przewidzieć. Trudno jest w pełni zwizualizować sobie koncepcje, która na razie jest tylko na papierze. Często pełny obraz wychodzi dopiero w trakcie realizacji – zwłaszcza, gdy osoba zamawiająca daną aplikację nie miała wcześniej większego doświadczenia w branży growej. Okazuję się wtedy, że “przydałoby się jeszcze coś” i “powinno być może jeszcze to”.
Z naszej perspektywy nie jest to z reguły żaden problem, ale trzeba mieć na uwadze, że każda dodana sugestia może mieć wpływ na ostateczny termin oraz wycenę. Czasem niektóre sugestie są tak banalne, że potrafimy dodać je w lada moment. Są jednak takie, które zajmują już dużo więcej czasu. Sytuacja wygląda inaczej również w przypadku, gdy dostajemy bardzo małe sugestie, ale w sporych ilościach. Ktoś może zapytać “ale co to za problem dodać to tu”? Żaden, ale jeśli dodajemy nowe elementy liczone w dziesiątkach, to zaczyna to zagrażać naszemu założonemu terminowi i należy o tym pamiętać.
Często propozycje i sugestie, które dostajemy są naprawdę bardzo dobre i rzeczywiście świetnie byłoby zobaczyć je w końcowej aplikacji, ale co jeśli nie pozwala nam na to wyznaczony czas?
Aktualizacje w oprogramowaniu
Tworzenie gry nie kończy się na dacie wydania, a wypuszczenie aplikacji nie oznacza, że nie można dodać nowych elementów w kolejnych aktualizacjach. W przypadku aplikacji, która spełnia w pełni daną wizję i cel, nie trzeba wypuszczać co chwilę nowych aktualizacji, ale można się nad nimi zastanowić. Co mogło być zrobione lepiej? W jaki sposób sprawić, aby nasz produkt zyskał na wartości? Jednak najważniejszym pytaniem jest: Czego oczekują od nas docelowi użytkownicy? Wypuszczenie na rynek produktu często powoduje utworzenie się wokół niego jakiejś społeczności. Osób, którym rzeczywiście zależy, aby nasz produkt stał się lepszy, które widzą potencjał danej produkcji. Takich osób trzeba słuchać. Trzeba sobie uświadomić, że bycie game developerem to robienie produktu dla kogoś. Tym kimś może być jeden klient lub tysiące osób wystawiających recenzje dla twojej produkcji. To dla nich tworzona jest nasza aplikacja, więc na ich zdaniu powinno nam najbardziej zależeć. Należy wsłuchiwać się w społeczność, ocenić możliwości oraz wszelkie “za i przeciw” związane z wprowadzeniem danych propozycji. Jeżeli są sensowne i mają polepszyć nasz produkt to dlaczego by ich nie wprowadzić?
Właśnie dzięki tej komunikacji pomiędzy użytkownikiem docelowym, a deweloperem jesteśmy w stanie stworzyć naprawdę trwałą społeczność, która zyska poczucie uczestnictwa w realizacji danej gry. Jest to bardzo cenne, gdyż pozwala to nam przedłużyć żywotność naszej produkcji i wiele zyskać w oczach naszych użytkowników jako studio. Temu “współtworzeniu” danych produkcji wraz z twórcami, zawdzięczamy wysoką popularność gier wypuszczanych w formie “early access”. Dzięki temu, twórcy na bieżąco w trakcie projektowania mogą wspierać się feedbackiem zaczerpniętym ze środka społeczności graczy. Mają oni dzięki temu tendencję przywiązywać się do danego studia, co zwiększa popularność również przyszłych produkcji. Wypuszczając docelową grę bez early access trzeba liczyć się z tym, że jest się na celowniku osób wypatrujących niedociągnięć – nic dziwnego, bo łatwiej jest nam zauważyć defekt, niż docenić część dobrze funkcjonującej rozgrywki. Gdy rozgrywka przechodzi płynnie jesteśmy wtedy zagłębieni w świat fabularny, a każdy brak, lub trudność jaką napotkamy prowadzi do frustracji wybijającej nas z tego stanu. Stąd łatwiej jest nam zawsze dostrzegać wady niż zalety, bo są one czynnikiem wpływającym na flow rozgrywki. Jednak early access jest procesem długotrwałym, potrafiącym ciągnąć się czasem latami. Na takie podejście trzeba wiele czasu, wiele pieniędzy i prawdziwej społeczności – bo nie ma nigdy gwarancji, że taka utworzy się wokół twojej produkcji. Jeżeli jednak uda się wokół niej zbudować fandom, to staje się ona jedną wielką piaskownicą, a gracze w trakcie zabawy dostrzegają w niej coraz to nowe możliwe udoskonalenia, dążąc do perfekcji, której w pewnym momencie nie jesteśmy w stanie osiągnąć. Dlatego uważam, że trzeba dbać o swój produkt, prowadzić go, słuchać swojej społeczności, ale trzeba również umieć go w odpowiednim stanie i czasie zakończyć, żeby móc przejść dalej.
“Gdybym miał jeszcze więcej czasu…”
Kto pracuje w branży ten nie raz to usłyszał, a ten kto tylko interesuje się grami, nie raz w dzień premiery miał okazję się przekonać, że “coś tu jednak nie zostało dociągnięte”. Czasem tak bywa, że nawet wielkie studia jak Ubisoft, CD Project, EA w dzień premiery potrafią nas bardzo negatywnie zaskoczyć. Osobiście pamiętam doświadczenia po odpaleniu pierwszy raz Assasin’s Creed Unity oraz Cyberpunk 2077 – byłem bardzo zawiedziony, ale też trochę rozbawiony. Dlaczego? Bo te firmy nie wytrzymały presji czasu, którą samemu sobie narzuciły. Nikt nie kazał im wypuszczać tych gier w takim stanie – nikt nie kazał ogłaszać im dnia premiery w ten konkretny dzień. Oni sami przeszacowali swoje możliwości, a hype już się rozniósł . Machina została rozpędzona i nie można było jej już zatrzymać – ludzie zapłacili za preordery. Premiera tej gry była przenoszona wiele razy i każda informacja o kolejnym przeniesieniu daty była dla osób oczekujących bardzo frustrująca. Pomimo tych wielokrotnych przeniesień dobrze wiemy, jaki był stan gry w dzień premiery… Czas to wszystko, czego potrzebowali. Te firmy posiadają przecież uzdolnionych ludzi na stanowiskach, wielkie siedziby, mnóstwo osób w nich pracujących czy inwestorów – ale mimo to czas ich pokonał.
Nieważne więc, czy jesteś wielką firmą z ogromnym doświadczeniem, czy może małym studiem growym – nigdy nie przeceniaj ile czasu potrzebujesz. Ja jestem pewny, że deweloperzy wypuszczający niedziałające gry dobrze wiedzą o większości występujących w nich błędów. Problem tkwi w tym, że nikt nie miał czasu ich naprawić. Niektórzy inwestorzy z pewnością nie pomagają takim firmom i chcą po prostu zrealizować jak najszybciej zysk związany ze sprzedażą. Trudno im się dziwić, chcą w końcu zobaczyć jak najszybciej owoce swoich inwestycji. Tylko trzeba pamiętać, że robienie gier to nie sprint– to maraton.
Podsumowując: o projektowaniu VR/AR/MR/XR
Tworząc oprogramowanie dla większych społeczności zawsze warto wziąć pod uwagę opinie i sugestie użytkowników docelowych. Trzeba pamiętać, że jest ono tworzone dla nich i to ich uwagi powinny znaczyć dla nas najwięcej. Należy również zadbać o zagwarantowanie wsparcia technicznego związanego z udostępnioną przez nas aplikacją, a także przygotować zespół na ewentualne quick updates po samej premierze. Co innego jest testować jednej firmie aplikację, a co innego gdy nagle do tych “testów” przystępuje tysiące użytkowników – jest zawsze szansa, że nasi testerzy nie natrafili na dany błąd wcześniej i trzeba być przygotowanym na to, by takie potencjalnie bugi móc później szybko załatać.
Każdy deweloper i inwestor powinien również uważać, aby samemu na siebie nie zawiązać pętli, niemożliwymi do zrealizowania terminami. Nic bardziej nie irytuje graczy, niż przekładanie długo oczekiwanej premiery. Lepiej jest dowieść zadowalający produkt później, niż udostępnić go w opłakanym stanie w szybszym terminie.
Wypuszczając nasz produkt na rynek, odpowiedzialnie byłoby wpisać do jego budżetu ewentualny okres wsparcia dla naszej aplikacji. Technologia się zmienia, świat idzie do przodu a wraz z nimi wymagania rynku. Warto więc rozważyć w budżecie nie tylko koszt samej produkcji, ale również perspektywę jej dalszego rozwoju.
Maciej Fiałkowski, EpicVR
