Istnieje specyficzny rodzaj tarcia, który ujawnia coś na temat tego, dla kogo produkt został zaprojektowany, i zazwyczaj staje się widoczny w momencie, gdy marketing przekazuje pałeczkę dokumentacji technicznej. Pozycjonowanie Stacked skierowane do konsumentów mówi do studiów, które chcą przestać płacić platformom reklamowym i zacząć bezpośrednio nagradzać swoich graczy. Język jest przystępny, problem do rozwiązania jest jasno określony, a domniemanym klientem jest ktoś, kto ma dość istniejącego modelu i szuka mniej wydobywczego rozwiązania. Potem otwierasz listę kontrolną integracji.
#pixel Siedem technicznych punktów kontrolnych dzieli studio od uruchomienia. Wydarzenia przesyłane przez serwer muszą być zweryfikowane jako działające poprawnie. Webhooki muszą być potwierdzone jako aktywujące. Zrzuty użytkowników muszą być aktualizowane zgodnie z harmonogramem. Warunki ukończenia muszą dokładnie śledzić postępy w odpowiednich zdarzeniach gry. Każde z tych zadań to prawdziwe wyzwanie inżynieryjne. Przejście przez listę wymaga kogoś, kto rozumie architekturę opartą na zdarzeniach, potrafi debugować asynchroniczne przepływy danych i wie, jak instrumentować grę na poziomie backendu. Dla zespołu z tym doświadczeniem, lista kontrolna jest rozsądna. Dla studia, którego głębokość techniczna leży głównie w projektowaniu gier i rozwoju po stronie klienta, to inny rodzaj zapytania.
Aby zrozumieć, co każdy punkt kontrolny rzeczywiście wymaga, pomocne jest śledzenie integracji w kolejności. Wydarzenia przesyłane przez serwer to mechanizm, który pozwala serwerowi na przesyłanie aktualizacji w czasie rzeczywistym do podłączonego klienta bez powtarzającego się zapytania. Osiągnięcie ich poprawności oznacza weryfikację, że stałe połączenia są utrzymywane, że logika ponownego połączenia radzi sobie z przerwami w odpowiedni sposób, a strumień zdarzeń przychodzi w odpowiedniej kolejności. Webhooki dodają osobną warstwę: studio potrzebuje punktu odbioru zdolnego do obsługi żądań HTTP POST z serwerów Stacked, walidacji ładunku i działania na zdarzeniu wewnątrz oczekiwanego okna latencji. Zrzuty użytkowników wymagają od studia zdefiniowania, jak wygląda obecny stan gracza, poprawnego serializowania go i zapewnienia, że odświeża się, gdy zmieniają się dane gry. Warunki ukończenia wymagają, aby zdarzenia gry były instrumentowane na tyle precyzyjnie, aby platforma mogła odróżnić prawdziwe ukończenie od częściowego lub fałszywego wyzwalacza.
Brane indywidualnie, żadne z tych zadań nie jest niezwykłe w połączonym oprogramowaniu. Brane razem jako brama przed uruchomieniem, opisują studio z rzeczywistymi umiejętnościami inżynieryjnymi na backendzie. To niekoniecznie jest studio, które obrazują język skierowany do konsumentów.
Napięcie tutaj może odzwierciedlać kilka różnych rzeczy, a ja nie jestem pewien, które odczyt jest najbliższy prawdy. Jedną z możliwości jest to, że platforma została zbudowana przez i dla studiów Web3 z umiejętnościami inżynieryjnymi, a bardziej dostępne ramy marketingowe to stwierdzenie ambicji, a nie opis tego, kto obecnie znajduje się po drugiej stronie integracji. To jest rozpoznawalny wzór w produktach infrastrukturalnych, które zaczynają od technicznych wczesnych adopcji, a później próbują dotrzeć do szerszej publiczności, nie mając jeszcze uproszczonej ścieżki, aby dopasować się do tej nowej publiczności. W takim przypadku lista kontrolna jest resztą rzeczywistych początków produktu, a luka między nią a marketingiem to luka, której zespół jest świadomy i nad którą pracuje, aby ją zamknąć.
Drugą możliwością jest to, że złożoność nie jest przypadkowa, ale strukturalna. Platforma, której wartość zależy od dokładnych danych behawioralnych, odpornej na oszustwa dystrybucji nagród i śledzenia stanu gracza w czasie rzeczywistym, rzeczywiście potrzebuje, aby studia poprawnie wdrażały te punkty kontrolne. Studio, które źle skonfiguruje swój webhook lub pozwoli, aby jego zrzuty użytkowników wyszły z synchronizacji, produkuje złe dane, które przepływają przez segmentację platformy i logikę nagród w sposób, który jest trudny do wykrycia i poprawienia w dalszej kolejności. Z tego punktu widzenia, lista kontrolna odzwierciedla minimalną infrastrukturę, której produkt rzeczywiście potrzebuje do działania zgodnie z opisem, a nie niepotrzebny opór, który można usunąć bez konsekwencji.
Trudność z tym drugim odczytem polega na tym, że nie rozwiązuje kwestii marketingowej. Jeśli minimalna opłacalna infrastruktura wymaga umiejętności inżynieryjnych na backendzie, to platforma zmierza w stronę segmentu klientów, który może nie być w stanie spełnić tego wymogu bez znaczącego wsparcia. Studio, które uważa, że dostępne ramy dla konsumentów są przekonujące i osiąga siedem technicznych punktów kontrolnych w trakcie procesu onboardingu, znajduje się w innej sytuacji niż to, które już rozumiało, na co się zapisuje. To doświadczenie zazwyczaj prowadzi do konkretnego wyniku, który nie jest zazwyczaj udaną integracją.
Czego lista kontrolna nie może mi powiedzieć, a co sprawia, że jestem naprawdę niepewny, to w jakim kierunku zmierza platforma. Uproszczenie ścieżki integracji, aby służyć casualowemu studiu Web2, jak sugeruje marketing, wytworzyłoby inny produkt niż ten, który utrzymuje swoje obecne wymagania techniczne i aktualizuje swoje pozycjonowanie, aby odzwierciedlić, kto rzeczywiście go kupuje. Oba to spójne wybory z różnymi implikacjami dla dostępnego rynku, pozycji konkurencyjnej i rodzaju ekosystemu, który formuje się wokół platformy w czasie.
Co lista kontrolna ujawnia, bez większej niejednoznaczności, to klienta, którego obecnie dobrze obsługuje. Pytanie, które pozostawia otwarte, to czy studio, do którego kieruje marketing, ma kogokolwiek w zespole, kto pracował wcześniej z Wydarzeniami przesyłanymi przez serwer, i jak wygląda doświadczenie integracyjne, gdy odkryją, że muszą to zrobić.$PIXEL