Jak zostać twórcą własnej rzeczywistości: AR, VR i AI jako nowe narzędzia mocy

Krótki wstęp i założenia: czym jest bycie twórcą własnej rzeczywistości

Bycie twórcą własnej rzeczywistości oznacza przejście od biernego konsumowania treści do projektowania światów i narzędzi, które inni mogą odczuwać całym ciałem. AR, VR i AI to zestaw mocy: rozszerzają zmysły, pozwalają modelować przestrzeń i tworzyć interakcje sterowane językiem, gestem, spojrzeniem. Poniżej zestaw kryteriów, punktów kontrolnych i praktycznych kroków, które prowadzą od pomysłu do działającego doświadczenia.

Brief pytań użytkownika, na które odpowiada przewodnik

• Jak wybrać między AR, VR a miksowaną rzeczywistością do mojego przypadku użycia?
• Jaki sprzęt i ekosystem da mi najszybszą drogę do prototypu, a jaki do skalowania?
• Jakie narzędzia i silniki są realnie potrzebne na start – bez kupowania pół internetu?
• W jaki sposób wpleść AI, by faktycznie zwiększała możliwości, a nie komplikowała projektu?
• Jak uniknąć choroby symulatorowej, słabej wydajności i błędów UX specyficznych dla XR?
• Jak zabezpieczyć dane przestrzenne i prywatność użytkownika?
• Jak testować, mierzyć i iterować, żeby dowozić wartość, a nie tylko „wow”?

1. Zdefiniuj cel: decyzja AR vs VR vs MR

Kryteria wyboru medium

Wybór między AR (Augmented Reality), VR (Virtual Reality) i MR (Mixed Reality) zacznij od zadania czterech pytań: gdzie użytkownik ma być (w swoim otoczeniu czy w pełni wirtualnym), jaki poziom zanurzenia jest potrzebny, jaką kontrolę nad zmysłami musisz mieć oraz jakie są ograniczenia sprzętowe odbiorców. AR łączy świat fizyczny z cyfrowymi nakładkami – idealna do gier miejskich, edukacji w terenie, instrukcji krok po kroku, showroomów. VR izoluje i daje pełną kontrolę nad bodźcami – sprawdza się w symulatorach, szkoleniach wysokiego ryzyka, medytacji, narracji 360. MR (przez pass-through lub see-through) umożliwia precyzyjne osadzenie obiektów 3D w realnej przestrzeni, z zachowaniem świadomości otoczenia – dobre dla projektowania wnętrz, współpracy na modelach, produkcji i serwisu.

Punkt kontrolny: jeśli kluczowe są interakcje z konkretnymi przedmiotami w otoczeniu – MR/AR. Jeśli ważna jest pełna kontrola tempa i bodźców – VR. Jeśli odbiorcą jest szeroka publiczność z telefonami – mobilne AR.

Sygnał ostrzegawczy: „chcę wszystkiego naraz”. Łączenie wszystkich mediów naraz komplikuje produkcję. Zacznij od jednego, dodaj kolejne formy po walidacji.

Definiowanie użytkownika i scenariusza

Opisz jedną personę i krytyczny moment użycia. Np. „technik serwisowy w hałaśliwej hali, obie ręce zajęte, 10 minut na diagnozę – potrzebuje wskazówek AR z rozpoznawaniem części”. Takie doprecyzowanie determinuje decyzje o interfejsie (gesty, wzrok, głos), kontraście, audio, rozmiarze elementów, a nawet porze dnia.

Punkt kontrolny: spisz 3 ograniczenia środowiskowe (światło, hałas, przestrzeń) i 3 ograniczenia ludzkie (doświadczenie, kondycja, wiek). To filtr dla całego projektu.

Minimalne wskaźniki sukcesu (MVP, nie maraton)

Zanim otworzysz edytor, ustal 2–3 metryki: np. „czas znajdowania elementu spada o 30%”, „użytkownik kończy onboarding w 2 min”, „90% uczestników nie zgłasza dyskomfortu”. Bez liczb nie ma decyzji o iteracji.

Jeśli projekt jest rozrywkowy – mierz retencję i NPS po 24 h. Jeśli szkoleniowy – mierz skrócenie czasu i zmniejszenie błędów. Jeśli sprzedażowy – mierz konwersję i średni czas zaangażowania.

2. Wybierz sprzęt i ekosystem: szybkość kontra zasięg

Mapowanie sprzętu do celu

Decyzja o urządzeniu to nie tylko komfort – to cały łańcuch dystrybucji, narzędzi i kosztów. Dla VR: gogle standalone z pass-through ułatwiają MR-light i testy w terenie; zestawy PC VR dają maksymalną moc do fotorealizmu i precyzji śledzenia. Dla AR: smartfony zapewniają największy zasięg i niski próg wejścia; urządzenia see-through oferują wygodę rąk wolnych i ciągłe mapowanie przestrzeni kosztem ceny.

Punkt kontrolny: czy odbiorca ma już wymagany sprzęt? Jeśli nie, licz budżet na hardware i wsparcie (konfiguracja, aktualizacje, serwis).

Porównanie kanałów atrybucji i dystrybucji

Platformy dystrybucji decydują o recenzjach, politykach prywatności i monetyzacji. Sklepy z aplikacjami XR oferują natywne funkcje, ale wymagają zgodności z wytycznymi. WebXR/AR w przeglądarce upraszcza dostęp (link/QR), lecz ogranicza dostęp do niektórych sensorów i mocy GPU.

Budżet i utrzymanie

Oprócz ceny zakupu dolicz akcesoria (paski, etui, higiena), licencje deweloperskie, konta wydawnicze, ubezpieczenia i czas aktualizacji. W środowiskach przemysłowych istotna jest także dezynfekcja i trwałość. W VR uwzględnij koszty kontrolerów zapasowych, w AR mobilnym – testy na wielu modelach.

Jeśli budżet jest minimalny, targetuj WebXR/AR i jeden popularny headset standalone. Jeśli liczy się jakość i precyzja – PC VR i MR see-through, ale tylko z wyraźnym ROI.

3. Zestaw narzędzi: tylko to, co skraca drogę do wartości

Silnik i platforma wykonawcza

Wybór silnika decyduje o szybkości prototypowania i optymalizacji. Unity – duży ekosystem XR, bogate wtyczki, szybkie budowanie MVP. Unreal – fotorealizm, narzędzia filmowe, ale wyższy próg optymalizacji na mobile. Godot XR – otwartoźródłowy, lekki, dobry do edukacji i prostych doświadczeń. WebXR + Three.js/React Three Fiber – dystrybucja w przeglądarce, integracja z webem i analityką, kompromisy wydajnościowe.

Punkt kontrolny: wybierz jeden silnik na 90 dni i trzymaj się go. Rotacja narzędzi przed MVP zabija momentum.

Tworzenie i pozyskiwanie assetów 3D

Minimalny zestaw: edytor 3D (np. Blender), biblioteka gotowych modeli, generator tekstur/materialów, narzędzie do optymalizacji siatki (redukcja poligonów, LOD). Uzupełnij o fotogrametrię lub skanowanie LiDAR dla obiektów z rzeczywistości. Formaty docelowe: glTF/GLB dla WebXR, FBX/OBJ dla silników; trzymaj porządek w jednostkach i pivotach.

4. Wpleć AI tam, gdzie realnie skraca drogę do efektu

Warstwy użycia AI

• Interfejs rozmowy i kontekstu: agent głosowy lub tekstowy, który rozumie scenę (co widzi kamera/passthrough), stan aplikacji i cele użytkownika. Przykład: w MR serwisant mówi „pokaż kolejny krok kalibracji”, a agent podświetla właściwe śruby i skraca instrukcję do 3 punktów.
• Generowanie treści pomocniczych: szybkie warianty tekstur, promptowane animacje gestów, opisy scen dla dostępności. Przykład: AI tworzy 5 spójnych materiałów do testów LOD zamiast angażować grafika na dzień.
• Automatyzacja QA: bot „przechodzi” scenariusze w headless mode, zbiera czasy przejścia, śledzi spadki FPS po każdej kompilacji.

Punkt kontrolny: latencja interakcji z agentem < 300 ms dla komend sterujących (poza dialogiem kreatywnym), jasne granice kontekstu (jakie dane widzi AI), fallback offline dla krytycznych akcji.

Sygnał ostrzegawczy: halucynacje w instrukcjach, wysyłanie surowego wideo/passthrough do chmury bez zgody, koszt inferencji rosnący liniowo z liczbą sesji.

Jeśli asystent ma prowadzić po krokach – priorytetem jest niski lag i deterministyczne odpowiedzi (mały, wyszkolony lokalnie model + reguły). Jeśli ma inspirować i generować warianty – akceptowalne są wyższe opóźnienia i praca w chmurze.

5. Interakcje i komfort: projekt pod ludzką fizjologię

Ruch i choroba symulatorowa

• Locomotion: domyślnie teleport lub „dash” z winietą; „smooth move” tylko jako opcja z regulacją prędkości i martwą strefą.
• Stabilne punkty odniesienia: utrzymuj horyzont/siatkę podłogi; elementy UI niech „płyną” z głową, nie ze światem, w czasie nauki.
• Budżet FPS: 72/90/120 Hz zależnie od sprzętu; priorytet – stabilność, nie maksy.

Punkt kontrolny: brak przyspieszeń kamery bez sygnału z ciała (brak „samoczynnego” płynięcia), configurable vignette, test komfortu na 10 osobach o różnej wrażliwości.

Sygnał ostrzegawczy: head-bob, gwałtowne rotacje kamery, efekt „windy” przy zmianie wysokości.

Czytelność i odległości

• UI w przestrzeni: dystans 1,5–3 m dla treści głównych, kątowa wielkość tekstu min. ~1,2–1,5° dla akapitów, 2–3° dla nagłówków.
• Kontrast i kolor: tryb wysoki kontrast, test w jasnym i ciemnym otoczeniu; unikaj czerwieni na tle ciemnym dla osób z deuteranopią.
• Audio: przestrzenne wskazówki kierunkowe, krótkie „earconsy” potwierdzające akcje bez zasłaniania mowy.

Jeśli celem jest nauka procedury – uprość ruch (teleport), zwiększ kontrast i stosuj krótkie potwierdzenia audio. Jeśli celem jest imersyjna opowieść – dopuszczalne są ciemniejsze palety i płynny ruch, ale z opcjami komfortu.

6. Architektura doświadczenia: modułowość i odporność

Warstwy i kontrakty

• Oddziel input od logiki: gesty/kontrolery/wzrok mapuj do zdarzeń, a nie bezpośrednio do akcji sceny.
• Zasoby jako pakiety: asset bundles/adr (adresowalne) z wersjonowaniem i możliwością hot-swapu.
• Remote config i feature flags: bez nowego builda włączysz tryb demo, obniżysz jakość, zmienisz częstotliwość hintów.

Punkt kontrolny: wznowienie sesji w < 3 s (cache sceny + lazy init), odporność na brak sieci (kolejka zdarzeń i synchronizacja po reconnect).

Jeśli target to event/stoisko – kluczowe są auto-restart i tryb kiosku. Jeśli praca w terenie – offline-first i bezpieczne kolejki synchronizacji.

7. Wydajność i grafika: budżety zanim otworzysz profiler

Budżety na start

• Draw calle i materiały: konsoliduj siatki, używaj atlasy tekstur, unikaj wielu shaderów w jednej scenie.
• LOD, culling, occlusion: automatyczne LOD-y + ręczne dla kluczowych obiektów; wyłącz to, czego nie widać.
• Światło: na mobile bake + light probes; cienie dynamiczne tylko tam, gdzie mają wartość informacyjną.
• Foveated/dynamic resolution: włącz, o ile headset wspiera; lepiej stabilne 72–90 Hz niż „ładniej, ale nierówno”.

Punkt kontrolny: stabilne czasy klatek CPU/GPU poniżej budżetu urządzenia, TTI (time-to-interact) < 3 s w AR mobilnym i < 10 s w VR.

Sygnał ostrzegawczy: rosnąca temperatura i throttling po kilku minutach – potrzebne obniżenie jakości lub skrócenie dystansów rysowania.

Jeśli priorytetem jest fotorealizm – testuj wcześnie na docelowym sprzęcie i ogranicz dynamikę oświetlenia. Jeśli szkolenie/procedury – czytelność i stabilny FPS są ważniejsze niż detale materiałów.

8. Dane przestrzenne i prywatność: minimalizacja i kontrola

Klasyfikacja i przepływy

• Co zbierasz: mapy przestrzeni, kotwice, gesty, głos, wideo passthrough? Oznacz jako PII lub dane wrażliwe.
• Gdzie przetwarzasz: on-device domyślnie; chmura tylko dla danych zagregowanych lub z anonimizacją.
• Zgody i przejrzystość: ekran startowy z jasnym celem zbierania, przyciski opt-in, osobny toggle dla nagrań.

Punkt kontrolny: szyfrowanie w spoczynku i tranzycie, retencja z limitem czasowym, brak wysyłki surowego passthrough bez wyraźnej zgody.

Sygnał ostrzegawczy: łączenie map pomieszczeń z danymi osobowymi w jednym magazynie; brak możliwości usunięcia kotwic przez użytkownika.

Jeśli działasz w UE – projektuj „privacy by default” (RODO), prowadź rejestr czynności i DPIA dla funkcji nagrywania. Jeśli to wewnętrzne wdrożenie B2B – umowa powierzenia i segmentacja środowisk.

9. Testy i metryki: od prototypu do nawyku iteracji

Instrumentacja i badania

• Eventy kluczowe: czas startu scen, FPS, rodzaj locomotion, błędy interakcji, punkty rezygnacji.

Projekt eksperymentów A/B w XR

• Hipoteza i zmienna pierwotna: formułuj precyzyjnie (np. „winieta 35% obniża rezygnacje w 10. minucie”). Wybierz jedną metrykę rozstrzygającą (np. odsetek ukończonych kroków).
• Randomizacja i izolacja: losuj na poziomie użytkownika/urządzenia. Unikaj przełączania wariantów w trakcie jednej sesji – efekt przeniesienia psuje wynik.
• Okres aklimatyzacji: wyklucz pierwszą minutę (nauka sterowania) z pomiaru czasu zadania i komfortu.
• Weryfikacja instrumentacji: test A/A na małej próbie, by sprawdzić spójność eventów i brak biasu w przydziale.
• Wielkość próby i sekwencyjne testy: przy niskim ruchu stosuj testy sekwencyjne lub schematy within-subject (crossover), ale z przerwą między wariantami.
• Etyka i bezpieczeństwo: twardy próg przerwania testu, jeśli wskaźnik dyskomfortu przekroczy limit; krótkie badanie po sesji zamiast „think aloud” w trakcie.

Punkt kontrolny: wykrywanie „sample ratio mismatch” i alert, gdy któryś wariant zbiera istotnie mniej/więcej ruchu niż zakładano.

Sygnał ostrzegawczy: testy na ruchu z eventów targowych – niereprezentatywne dla warunków domowych/produkcyjnych.

Jeśli ruch jest mały – wybierz schemat within-subject z odpoczynkiem między warunkami. Jeśli produkt jest B2B – porównuj pre/post na tej samej grupie z kontrolą sezonowości.

Badania terenowe i labowe w headsetach

• Bezpieczeństwo i setup: wyznacz strefę, mata antypoślizgowa, „spotter” obok. Sprawdź guardian/boundary i higienę sprzętu.
• Rekrutacja: miks 1/3 nowicjusze, 1/3 średniozaawansowani, 1/3 doświadczeni. Oddziel sesje na stojąco od siedzących.
• Protokół: krótki briefing, kalibracja interpupillary/dioptrii, z góry określony scenariusz i kryteria ukończenia.
• Zbieranie danych: marker czasu przy każdym błędzie, nagranie obrazu z urządzenia (jeśli zgoda), notatki z obserwacji rąk i wzroku.
• Skale i ankiety: SSQ/ISC (komfort), krótkie 3 pytania po sesji: jasność celu, trudność sterowania, moment rezygnacji.
• RODO/prywatność: jawna zgoda na nagrania/wideo passthrough; anonimizacja i retencja z limitem.

Punkt kontrolny: minimum 5–7 pełnych sesji na build, zanim wyciągniesz wnioski kierunkowe.

Sygnał ostrzegawczy: notowanie tylko „opinii” bez timestampów i kontekstu sytuacyjnego – trudne do przełożenia na backlog.

Jeśli celem jest poprawa sterowania – priorytetyzuj obserwację rąk/wzroku i nagrania z kontrolerów. Jeśli celem jest narracja – skup się na przepływie uwagi i zrozumieniu celu sceny.

Metryki sukcesu i pulpit decyzyjny

• Aktywacja: time-to-first-value (TTFV), odsetek ukończenia pierwszego zadania.
• Wydajność/komfort: FPS i frametime p95/p99, wskaźnik dyskomfortu, liczba przerw/odpoczynków na sesję.
• Skuteczność zadań: completion rate, liczba błędów na krok, powtórzenia krytycznych gestów.
• Retencja i nawyk: powroty D1/D7, średnia długość sesji, punkty rezygnacji.
• Agent AI: trafność komend (precision/recall na zestawie etykietowanym), latencja p95, koszt na sesję, odsetek „fallback do reguł”.
• Stabilność: crash-free sessions, błędy krytyczne na 1k sesji, temperatura i throttling po N minutach.

Punkt kontrolny: jeden żywy dashboard per platforma (WebXR, mobile AR, VR standalone) z alertami progów SLO.

Sygnał ostrzegawczy: średnie ukrywają problemy – monitoruj ogony rozkładu (p95/p99).

Jeśli agent steruje krokami – kluczowa jest latencja i deterministyczna trafność. Jeśli to doświadczenie kreatywne – ważniejsze będą retencja i wrażenie jakości.

10. AI w XR: od pomocy tworzenia do agenta w runtime

Wybór modelu a budżet latencji

• Mapa zadań vs. klasa modelu: rozpoznanie poleceń i krótkie riposty – małe/on-device; planowanie wieloetapowe – średnie modele w edge/chmurze; narracja/kreatywność – większe modele z buforem czasu.
• Budżety reakcji: sterowanie i podpowiedzi UI – p95 ≤ 200–300 ms; dialog głosowy współtowarzyszący – p95 ≤ 700–900 ms; generacja treści „między scenami” – do kilku sekund z wyraźnym stanem ładowania.
• Strategie obniżenia opóźnień: streaming ASR/TTS, warm start (utrzymuj kontekst i połączenie), spekulatywne odpowiedzi i szybkie fallbacki regułowe na krytyczne akcje.
• Hybryda planista–wykonawca: LLM jako planista wysokopoziomowy, niskopoziomowe decyzje (kolizje, locomotion) deterministyczne lub klasyfikatory on-device.

Punkt kontrolny: p95 latencji komendy głosowej poniżej 900 ms; brak blokowania głównej pętli renderu przez sieć/LLM (kolejki asynchroniczne, priorytety zadań).

Sygnał ostrzegawczy: agent steruje ruchem kamery/ciała w czasie rzeczywistym wyłącznie przez LLM – ryzyko opóźnień i dyskomfortu.

Jeśli celem jest „hands-free” asysta – zainwestuj w on-device ASR/TTS i szybkie reguły awaryjne. Jeśli nacisk kładziesz na kreatywną narrację – akceptowalna jest dłuższa latencja z jasnym stanem w toku.

Uziemienie w scenie i ograniczony zestaw narzędzi

• RAG na grafie sceny: przekazuj do promptu zwięzłe listy obiektów, ich kotwice i stany (pozycja, zajętość, prawa interakcji). Kontekst rotuj – tylko to, co w pobliżu wzroku/ręki.
• Function/tool calling: jawny katalog akcji (np. move(object_id, anchor_id), highlight(target_id), explain(step_id)) z walidacją schematu JSON i uprawnień.
• Rozstrzyganie niejednoznaczności: jeśli >1 dopasowanie – prośba o doprecyzowanie lub domyślna heurystyka (najbliższy obiekt widoczny użytkownikowi).
• Obsługa braków: gdy brak kotwicy/celu – agent proponuje skan/rekalibrację zamiast „halucynować” obiekty.

Punkt kontrolny: pokrycie katalogiem narzędzi ≥ 80% kroków tutoriala i zadań krytycznych; walidacja JSON przed wykonaniem akcji z czasem ≤ 50 ms.

Sygnał ostrzegawczy: odpowiedzi modelu odwołują się do obiektów, których nie ma w aktualnym grafie sceny.

Jeśli agent ma prowadzić po procedurze – postaw na mały, szczelny zestaw narzędzi z deterministyczną walidacją. Jeśli to sandbox kreatywny – rozszerz katalog, ale taguj akcje „ryzyka” i wymagaj potwierdzeń.

Guardrail’e: bezpieczeństwo, ton, granice

• Filtry wejścia/wyjścia: lista zabronionych poleceń (np. ingerencje w system/OS, treści nieodpowiednie), normalizacja języka i wykrywanie prompt injection (instrukcje o zmianie reguł).
• Rate limiting i deadman switch: twarde limity na liczbę akcji na sekundę, automatyczny stop generacji przy zbliżeniu do granic guardian/boundary.
• Transparentność: krótkie etykiety trybu („AI asystuje”, „AI proponuje, ty zatwierdzasz”), logi działań dostępne do wglądu i wyczyszczenia.

Punkt kontrolny: zestaw testów czerwonych (prompt injection, niejednoznaczności, brak kontekstu) przechodzi w ≥ 95% przypadków bez nieautoryzowanych akcji.

Sygnał ostrzegawczy: odpowiedzi „pewne” mimo braku dostępu do danych sceny; brak limitów akcji na jednostkę czasu.

Jeśli aplikacja działa w środowisku produkcyjnym – egzekwuj zatwierdzanie akcji wysokiego ryzyka. Jeśli to aplikacja domowa – utrzymaj jasne granice i szybkie „wyłącz AI” na wierzchu UI.

Ocena jakości agenta i ciągła poprawa

• Zbiór ewaluacyjny: realne transkrypty z etykietą intencji, powodzenia akcji i komfortu. Dodatkowo scenki trudne: hałas, przerwane zdania, ambiwalencje.
• Metryki: skuteczność wykonania komendy (success@1), czas do akcji (p95), odsetek fallbacków do reguł, liczba dopytań na zadanie.
• Pętla uzupełniająca: semi-automatyczna re-etykietacja błędów, fine-tuning/adaptery na domenie, smoke testy na buildzie nocnym.

Punkt kontrolny: korelacja offline→online (ρ ≥ 0,6) między metrykami z zestawu testowego a wynikami produkcyjnymi.

Sygnał ostrzegawczy: ocena „LLM-as-judge” jako jedyne kryterium – ryzyko dryfu bez związku z realnym doświadczeniem.

Jeśli priorytetem jest niezawodność – mierz success@1 i p95 latencji; jeśli ekspresja – śledź preferencje użytkowników i parowe porównania odpowiedzi.

11. Publikacja i zgodność: od builda do sklepu

Komfort, bezpieczeństwo i ratingi

• Klasy komfortu: dopasuj do sklepów (np. Comfortable/Moderate/Intense) na podstawie locomotion, szybkości ruchu kamery i ekspozycji na migotanie.
• Boundary/guardian: wymuś konfigurację przed startem, komunikaty przy zbliżeniu do granic, tryb siedzący jako alternatywa.
• Health & Safety: ekran ostrzegawczy, pauza po X minutach, łatwe „odłóż i wróć”.

Klasyfikacja treści, wiek i prywatność

• Wiek i rating: skonfiguruj age-gate, wskaż poziom intensywności i treści wrażliwe (przemoc, wysokości, migotanie). Zgodność z lokalnymi wymogami (np. PEGI/IARC) i sklepami.
• Przetwarzanie głosu/wideo: jawne zgody dla ASR/TTS i wideo passthrough. Ikona mikrofonu/kamery w UI, łatwy przycisk „wyłącz”.
• Minimalizacja danych: zbieraj tylko to, co potrzebne. Wyłącz domyślnie nagrywanie ekranu/oczu; włączaj per-cel (debug/UX study).
• DPIA/RODO: ocena ryzyka (DPIA), polityka retencji, prawo do usunięcia danych w aplikacji. Umowy powierzenia z dostawcami AI/chmury.
• Bez dzieci bez zgody: osobne strumienie dla nieletnich lub całkowite wyłączenie funkcji społecznościowych/UGC w tym trybie.

Punkt kontrolny: zgody kontekstowe na mikrofon/kamerę z podglądem użycia; link do polityki prywatności dostępny w ≤ 2 klikach; DPIA zidentyfikowała i ograniczyła ryzyka.

Sygnał ostrzegawczy: logi zawierają surowe klatki kamery/albo transkrypty z danymi osobowymi; brak trybu natychmiastowego wyłączenia czujników.

Jeśli celem jest szeroka dystrybucja – wdroż age-gate i jasne etykiety przetwarzania. Jeśli produkt jest B2B – wzmocnij DPA i segregację danych per klient/tenant.

Checklisty zgłoszeniowe platform i sklepów

• Artefakty: ikony w wymaganych rozdzielczościach, zrzuty z obu oczu (dla VR), trailer z ostrzeżeniami komfortu, opis z tagami funkcji (hand tracking, room-scale, seated).
• Wydajność: celowany tryb 72/90 Hz, stabilny frametime p95, brak spadków przy streamingu audio/LLM. Test w gorącej obudowie i po dłuższej sesji.
• Uprawnienia: deklaracje mikrofon/kamera/środowisko, tylko gdy są używane. Brak nieużywanych scope’ów w manifeście.
• Kompatybilność: fallback na kontrolery, gdy hand tracking zgubi dłonie; tryb siedzący i stojący; guardian/boundary wymuszony przed startem.
• Lokalizacja i dostępność: kluczowe ciągi w językach docelowych; napisy do audio; kontrasty i rozmiar fontów zgodne z wytycznymi HIG/platform.
• Proces: build podpisany, numeracja zgodna ze sklepem, crash-free session rate w testflight/beta, raporty z listy kontrolnej QA dołączone do zgłoszenia (gdy wymagane).

Punkt kontrolny: przejście wewnętrznego „pre-submission” – zero nieużywanych uprawnień, stabilny frametime na najniższym wspieranym urządzeniu, komplet assetów sklepowych.

Sygnał ostrzegawczy: dialogi z prośbą o dostęp pojawiają się przed wyjaśnieniem celu; brak trybu seated w doświadczeniu wymagającym precyzji.

Jeśli planujesz premierę równoległą na kilku sklepach – utrzymuj matrycę różnic w wymaganiach i osobne paczki zasobów. Jeśli zaczynasz od jednego ekosystemu – dopasuj produkt do jego ratingów komfortu i HIG.

12. Monetyzacja i ekonomia doświadczeń XR+AI

Model przychodu a koszt inference i chmury

• Kalkulacja jednostkowa: policz koszt sesji (ASR, TTS, LLM, transfer danych). Ustal twarde limity zapytań i czasów generacji na plan użytkownika.
• Cache i „zimne” ścieżki: keszuj odpowiedzi niepersonalne, kompresuj i deduplikuj prośby do LLM; dla krytycznych akcji stosuj modele on-device.
• Cennik: płatność jednorazowa + pakiety kredytów AI, subskrypcje z fair use, lub pay-as-you-go dla klientów pro. Przejrzyste progi i alerty zużycia in-app.
• Fail-open/close: na przekroczeniu budżetu – deterministyczne reguły lub degradacja jakości (krótsze odpowiedzi), a nie cisza systemu.

Punkt kontrolny: p95 kosztu sesji mieści się w bezpiecznej części marży; alert kosztowy przy zbliżaniu do progu dziennego; zdefiniowana polityka degradacji.

Sygnał ostrzegawczy: niekontrolowane pętle tool-calling i „toksyczne” prompty generujące lawinę tokenów; brak komunikatu o ograniczeniach planu.

Jeśli doświadczenie opiera się na rozmowie – preferuj subskrypcję z limitami czasowymi. Jeśli to narzędzie zadaniowe – pakiety kredytów powiąż z efektami (np. „sceny/miesiąc”).

Free-to-try, próg wartości i konwersja

• Pierwsza wartość: dostarcz „aha moment” bez rejestracji i bez AI (offline demo), a następnie włącz opcje premium z jasnym porównaniem.
• Paywall kontekstowy: po ukończeniu mikro-zadania, nie przed. Pokazuj, co się odblokuje (np. tryb kreatywny z agentem).
• Testy cen: krótkie eksperymenty A/B poziomów ceny/prób; jasna polityka zwrotów i przenoszenia licencji między urządzeniami.
• Funnel: śledź TTFV, miejsce rezygnacji, czas do decyzji. Usprawnij onboarding zanim dotkniesz ceny.

Punkt kontrolny: większość nowych użytkowników dociera do pierwszego rezultatu przed pierwszym pop-upem monetyzującym; ekran ceny zawiera demo różnic w funkcjach.

Sygnał ostrzegawczy: paywall blokuje konfigurację guardiana lub kalibrację; subskrypcja wymagana przed pierwszą interakcją.

Jeśli produkt ma krzywą uczenia – wydłuż okres próbny do momentu pierwszej samodzielnej kreacji. Jeśli to narzędzie „zrób to za mnie” – krótsza próba, ale z gwarancją efektu.

UGC, marketplace i podział przychodów

• Kuracja i moderacja: dwustopniowy flow – automaty (klasyfikacja treści) + recenzja człowieka dla twórców z większym zasięgiem.
• Licencje i IP: jasne prawa do assetów (komercyjne/niekomercyjne), zasady przekazu praw i takedown (hashing treści, szybka ścieżka zgłoszeń).
• Monetyzacja twórców: transparentny procent, harmonogram wypłat, dashboard sprzedaży. Sandbox podatkowy i KYC dla wypłat międzynarodowych.
• Jakość techniczna: walidator pakietu (rozmiary, LOD, kolizje, tekstury), test automatyczny kompatybilności z wersją runtime’u.

Punkt kontrolny: każdy asset przechodzi walidację techniczną przed publikacją; SLA reakcji na zgłoszenia naruszeń; umowa marketplace opublikowana w aplikacji.

Sygnał ostrzegawczy: brak standaryzacji licencji; assety zwiększają rozmiar aplikacji bez kontroli LOD i wpływu na FPS.

13. Operacje, utrzymanie i analityka produkcyjna

Obserwowalność i budżety błędów

Bez telemetrii nie wiesz, co realnie widzą użytkownicy. Zbierz sygnały z urządzenia, chmury i warstwy AI – i przypisz im budżety błędów.

• XR perf: FPS, p95/p99 frametime, headroom GPU/CPU, termika, dropy przy przechwycie wideo i TTS.
• AI perf: latencja p50/p95 ASR/LLM/TTS, „tokeny na sesję”, odsetek timeoutów, skuteczność tool-calli.
• Sieć: jitter, straty pakietów, przepływności per ścieżka (wideo passthrough, audio, inference).
• Stabilność: crash-free rate, out-of-memory, błędy sterowników XR/Audio, awarie providerów.
• Doświadczenie: success@1 z produkcji, dopytania na zadanie, porzucone sesje vs. czas do efektu.

Minimum: jeden dashboard korelujący FPS z latencją AI i odsetkiem sukcesów; alerty na przekroczenie budżetów (np. 1% timeoutów LLM p95 > 4 s).

Punkt kontrolny: po wydaniu hotfixu widać poprawę metryk w ciągu 24 h; regresje latencji AI nie pogarszają FPS (brak „przeciągania” wątku głównego).

Sygnał ostrzegawczy: sukces@1 spada w godzinach szczytu bez zmian w FPS – wąskie gardło po stronie inference lub sieci.

Jeśli budżet błędów jest jasny – eskalujesz problemy zanim użytkownicy je zgłoszą. Jeśli metryki są rozproszone – zbierasz symptomy, nie przyczyny.