Zvládnutie perzistencie vo WebXR: Kompletný sprievodca správou kontrolných bodov stavu relácie

Vitajte na hranici imerzívneho webu. Ako vývojári tvoríme dychberúce zážitky vo virtuálnej a rozšírenej realite, ktoré uchvacujú používateľov a redefinujú digitálnu interakciu. Avšak v tomto dynamickom prostredí môže jediná, často prehliadaná výzva zničiť aj tú najstarostlivejšie vytvorenú ilúziu: prechodná povaha WebXR relácie. Čo sa stane, keď si používateľ na chvíľu zloží headset, prichádzajúci hovor preruší jeho sústredenie alebo sa prehliadač rozhodne uvoľniť zdroje? Vo väčšine prípadov sa celý zážitok resetuje, postup sa stratí a frustrácia používateľa prudko stúpa. Práve tu sa koncept kontrolného bodu stavu relácie stáva nielen funkciou, ale nevyhnutnosťou.

Tento komplexný sprievodca je určený pre globálne publikum webových vývojárov, nadšencov XR a technických vedúcich. Pustíme sa do hĺbkového prieskumu umenia a vedy ukladania a obnovovania stavu VR/AR vo WebXR. Preskúmame, prečo je to kľúčové, aké údaje zachytiť, aké nástroje použiť a ako implementovať robustný systém od základov. Na konci budete vybavení na tvorbu odolných, používateľsky prívetivých WebXR aplikácií, ktoré rešpektujú čas používateľa a udržiavajú imerziu bez ohľadu na prerušenie.

Pochopenie problému: Pominuteľná povaha WebXR relácií

Predtým, ako vytvoríme riešenie, musíme plne pochopiť problém. WebXR relácia, reprezentovaná objektom XRSession v API, je živé spojenie medzi vašou webovou stránkou a XR hardvérom používateľa. Je to brána k vykresľovaniu snímok, sledovaniu pohybu a spracovaniu vstupov. Toto spojenie je však v zásade krehké.

Životný cyklus WebXR relácie

Typická relácia nasleduje jasný životný cyklus:

1. Požiadavka: Vaša aplikácia požiada o imerzívnu reláciu pomocou navigator.xr.requestSession(), špecifikujúc režim ako 'immersive-vr' alebo 'immersive-ar'.
2. Štart: Ak používateľ udelí povolenie, relácia sa spustí a vy dostanete objekt XRSession.
3. Vykresľovacia slučka: Použijete session.requestAnimationFrame() na vytvorenie nepretržitej slučky, ktorá aktualizuje scénu a vykresľuje nové snímky pre každé oko na základe polohy používateľa.
4. Koniec: Relácia sa skončí, buď keď používateľ explicitne odíde, alebo keď váš kód zavolá session.end().

Kľúčový problém spočíva v tom, čo sa deje medzi fázami 'Štart' a 'Koniec'. Relácia môže byť neočakávane ukončená alebo pozastavená a špecifikácia WebXR v súčasnosti neponúka žiadny vstavaný mechanizmus na automatické ukladanie a obnovu stavu vašej aplikácie.

Bežné príčiny prerušenia relácie

Z pohľadu používateľa sa XR zážitok javí ako nepretržitý. Z technického hľadiska je však zraniteľný voči mnohým prerušeniam:

• Prerušenia iniciované používateľom:
  • Sňatie headsetu: Väčšina VR headsetov má senzory priblíženia. Po sňatí môže systém pozastaviť zážitok alebo zmeniť jeho stav viditeľnosti.
  • Prepínanie aplikácií: Používateľ môže otvoriť systémové menu (napr. menu Meta Quest alebo prekrytie desktopového OS) na kontrolu notifikácie alebo spustenie inej aplikácie.
  • Odchod zo stránky: Používateľ môže zavrieť kartu prehliadača, prejsť na inú URL adresu alebo obnoviť stránku.
• Prerušenia iniciované systémom:
  • Systémové notifikácie: Prichádzajúci telefónny hovor, pripomienka z kalendára alebo varovanie o nízkej batérii môžu prevziať kontrolu nad displejom a pozastaviť vašu reláciu.
  • Správa zdrojov: Moderné prehliadače a operačné systémy agresívne spravujú zdroje. Ak vaša karta nie je v popredí, môže byť spomalená alebo dokonca zrušená, aby sa ušetrila pamäť a batéria.
  • Hardvérové problémy: Ovládač môže stratiť sledovanie alebo sa vypnúť, alebo headset môže naraziť na systémovú chybu.

Keď nastane ktorákoľvek z týchto udalostí, JavaScript kontext, ktorý drží celý stav vašej aplikácie – pozície objektov, herné skóre, používateľské prispôsobenia, stavy používateľského rozhrania – môže byť vymazaný. Pre používateľa to znamená návrat k zážitku, ktorý bol úplne resetovaný do počiatočného stavu. Nie je to len nepríjemnosť; je to kritické zlyhanie používateľského zážitku (UX), ktoré môže spôsobiť, že aplikácia pôsobí neprofesionálne a je nepoužiteľná na čokoľvek viac ako krátke demo.

Riešenie: Architektúra systému kontrolných bodov stavu relácie

Kontrolný bod stavu relácie je snímka základných dát vašej aplikácie, uložená v konkrétnom momente. Cieľom je použiť túto snímku na obnovenie aplikácie do stavu pred prerušením, čím sa vytvorí plynulý a odolný používateľský zážitok. Predstavte si to ako funkcionalitu 'uloženia hry', bežnú vo videohrách, ale prispôsobenú pre dynamické a často nepredvídateľné prostredie webu.

Keďže WebXR neposkytuje natívne API na tento účel, musíme si tento systém vybudovať sami pomocou štandardných webových technológií. Robustný systém kontrolných bodov pozostáva z troch základných komponentov:

1. Identifikácia stavu: Rozhodnutie, ktoré presne údaje je potrebné uložiť.
2. Serializácia dát: Prevod týchto údajov do uložiteľného formátu.
3. Perzistencia dát: Výber správneho mechanizmu úložiska v prehliadači na ukladanie a načítanie údajov.

Návrh robustného systému správy stavu pre WebXR

Rozoberme si každý komponent nášho systému kontrolných bodov s praktickými úvahami pre vývojárov po celom svete.

Aký stav by ste mali ukladať?

Prvým krokom je vykonať audit vašej aplikácie a identifikovať údaje, ktoré definujú jej stav. Ukladanie príliš veľkého množstva údajov môže spomaliť proces a spotrebovať nadmerné úložisko, zatiaľ čo ukladanie príliš malého množstva bude mať za následok neúplnú obnovu. Je to o hľadaní rovnováhy.

Kategorizujte svoj stav, aby ste pokryli všetky oblasti:

• Stav sveta: Zahŕňa dynamické prvky vášho virtuálneho prostredia.
  • Pozície, rotácie a škály všetkých nestatických objektov.
  • Stav interaktívnych prvkov (napr. dvere sú otvorené, páka je potiahnutá).
  • Informácie založené na fyzike, ak od nej vaša scéna závisí (napr. rýchlosti pohybujúcich sa objektov).
• Stav používateľa: To je všetko, čo je špecifické pre postup a identitu používateľa v rámci zážitku.
  • Pozícia a orientácia hráča/avatara.
  • Inventár, zozbierané predmety alebo štatistiky postavy.
  • Značky postupu, ako sú dokončené úrovne, úlohy alebo kontrolné body.
  • Skóre, úspechy alebo iné metriky.
• Stav UI: Stav vášho používateľského rozhrania je kľúčový pre plynulý prechod.
  • Ktoré ponuky alebo panely sú aktuálne otvorené.
  • Hodnoty posuvníkov, prepínačov a iných ovládacích prvkov.
  • Obsah textových vstupných polí.
  • Pozície posúvania v zoznamoch alebo dokumentoch.
• Konfigurácia relácie: Používateľské predvoľby, ktoré ovplyvňujú zážitok.
  • Nastavenia komfortu (napr. teleport vs. plynulý pohyb, stupne otáčania).
  • Nastavenia prístupnosti (napr. veľkosť textu, farebný kontrast).
  • Vybraný avatar, téma alebo prostredie.

Profesionálny tip: Neukladajte odvodené údaje. Napríklad, namiesto ukladania kompletných dát 3D modelu pre každý objekt, uložte len jeho jedinečné ID, pozíciu a rotáciu. Vaša aplikácia by už mala vedieť, ako načítať model z jeho ID pri obnove stavu.

Serializácia dát: Príprava vášho stavu na uloženie

Keď ste zhromaždili svoje stavové dáta, ktoré pravdepodobne existujú ako komplexné JavaScript objekty, triedy a dátové štruktúry (napr. THREE.Vector3), musíte ich previesť do formátu, ktorý sa dá zapísať do úložiska. Tento proces sa nazýva serializácia.

JSON (JavaScript Object Notation)

JSON je najbežnejšia a najpriamejšia voľba pre webových vývojárov.

• Výhody: Je čitateľný pre človeka, čo uľahčuje ladenie. Je natívne podporovaný v JavaScripte (JSON.stringify() na serializáciu, JSON.parse() na deserializáciu), nevyžaduje žiadne externé knižnice.
• Nevýhody: Môže byť rozsiahly, čo vedie k väčším súborom. Parsovanie veľkých JSON súborov môže blokovať hlavné vlákno, čo môže spôsobiť zasekávanie vo vašom XR zážitku, ak sa to nerieši opatrne.

Príklad jednoduchého objektu stavu serializovaného do JSON:

            
{
  "version": 1.1,
  "user": {
    "position": {"x": 10.5, "y": 1.6, "z": -4.2},
    "inventory": ["key_blue", "health_potion"]
  },
  "world": {
    "objects": [
      {"id": "door_main", "state": "open"},
      {"id": "torch_1", "state": "lit"}
    ]
  }
}

            

              
                Copy
              
            
          

Binárne formáty

Pre aplikácie kritické na výkon s obrovským množstvom stavových dát ponúkajú binárne formáty efektívnejšiu alternatívu.

• Výhody: Sú výrazne kompaktnejšie a rýchlejšie na parsovanie ako textové formáty ako JSON. To znižuje nároky na úložisko a čas deserializácie.
• Nevýhody: Nie sú čitateľné pre človeka a často vyžadujú zložitejšiu implementáciu alebo knižnice tretích strán (napr. Protocol Buffers, FlatBuffers).

Odporúčanie: Začnite s JSON. Jeho jednoduchosť a ľahké ladenie sú počas vývoja neoceniteľné. Zvážte optimalizáciu na binárny formát iba vtedy, ak zmeriate a potvrdíte, že serializácia/deserializácia stavu je vo vašej aplikácii výkonnostným bottleneckom.

Výber mechanizmu úložiska

Prehliadač poskytuje niekoľko API pre ukladanie na strane klienta. Výber toho správneho je kľúčový pre spoľahlivý systém.

`localStorage`

• Ako to funguje: Jednoduché úložisko kľúč-hodnota, ktoré uchováva dáta medzi reláciami prehliadača.
• Výhody: Extrémne jednoduché na použitie. localStorage.setItem('myState', serializedData); a máte hotovo.
• Nevýhody:
  • Synchrónne: Volania setItem a getItem blokujú hlavné vlákno. Ukladanie veľkého stavového objektu počas vykresľovacej slučky spôsobí zamrznutie vášho XR zážitku. Toto je hlavná nevýhoda pre XR.
  • Obmedzená veľkosť: Zvyčajne obmedzené na 5-10 MB na doménu, čo nemusí stačiť pre komplexné scény.
  • Iba reťazce: Musíte manuálne serializovať a deserializovať vaše dáta do reťazcov (napr. pomocou JSON).
• Verdikt: Vhodné iba pre veľmi malé množstvo nekritických stavových dát, ako je preferovaná úroveň hlasitosti používateľa. Všeobecne sa neodporúča pre kontrolné body WebXR relácií.

`sessionStorage`

• Ako to funguje: Identické API ako localStorage, ale dáta sa vymažú po skončení relácie stránky (t.j. po zatvorení karty).
• Verdikt: Nepoužiteľné pre náš hlavný cieľ obnovenia relácie po reštarte prehliadača alebo zatvorení karty.

`IndexedDB`

• Ako to funguje: Plnohodnotná, transakčná, objektovo orientovaná databáza zabudovaná v prehliadači.
• Výhody:
  • Asynchrónne: Všetky operácie sú neblokujúce, používajú Promises alebo spätné volania. Toto je pre XR nevyhnutné, pretože to nezamrazí vašu aplikáciu.
  • Veľké úložisko: Ponúka výrazne väčšiu kapacitu úložiska (často niekoľko stoviek MB alebo dokonca gigabajty, v závislosti od prehliadača a povolení používateľa).
  • Ukladá komplexné objekty: Dokáže uložiť takmer akýkoľvek JavaScript objekt priamo bez manuálnej serializácie JSON, hoci explicitná serializácia je stále dobrou praxou pre štruktúrované dáta.
  • Transakčné: Zabezpečuje integritu dát. Operácia sa buď dokončí úplne, alebo vôbec.
• Nevýhody: API je zložitejšie a vyžaduje viac boilerplate kódu na nastavenie (otvorenie databázy, vytvorenie objektových úložísk, spracovanie transakcií).
• Verdikt: Toto je odporúčané riešenie pre akúkoľvek serióznu správu stavu WebXR relácií. Asynchrónna povaha a veľká kapacita úložiska sú dokonale prispôsobené požiadavkám imerzívnych zážitkov. Knižnice ako `idb` od Jakea Archibalda môžu zjednodušiť API a urobiť prácu s ním oveľa príjemnejšou.

Praktická implementácia: Vytvorenie systému kontrolných bodov od nuly

Prejdime od teórie k praxi. Načrtneme si štruktúru triedy `StateManager`, ktorá dokáže spracovať ukladanie a načítanie stavu pomocou IndexedDB.

Spúšťanie akcie uloženia

Vedieť, kedy ukladať, je rovnako dôležité ako vedieť ako. Najefektívnejšia je viacúrovňová stratégia.

1. Ukladanie riadené udalosťami: Uložte stav po významných akciách používateľa. Toto je najspoľahlivejší spôsob, ako zachytiť dôležitý postup.
   • Dokončenie úrovne alebo cieľa.
   • Získanie kľúčového predmetu.
   • Zmena kritického nastavenia.
2. Periodické automatické ukladanie: Ukladajte stav automaticky každých pár minút. Funguje to ako záchranná sieť na zachytenie zmien stavu medzi hlavnými udalosťami. Uistite sa, že túto akciu vykonávate asynchrónne, aby neovplyvnila výkon.
3. Pri prerušení relácie (Kritický spúšťač): Najdôležitejším spúšťačom je detekcia, kedy sa relácia chystá byť pozastavená alebo zatvorená. Môžete počúvať niekoľko kľúčových udalostí:
   • session.onvisibilitychange: Toto je najpriamejšia udalosť WebXR. Spustí sa, keď sa zmení schopnosť používateľa vidieť obsah relácie (napr. otvorí systémové menu alebo si zloží headset). Keď sa `visibilityState` stane 'hidden', je to ideálny čas na uloženie.
   • document.onvisibilitychange: Táto udalosť na úrovni prehliadača sa spustí, keď celá karta stratí fokus.
   • window.onpagehide: Táto udalosť je spoľahlivejšia ako `onbeforeunload` na ukladanie dát tesne predtým, ako používateľ prejde na inú stránku alebo zatvorí kartu.

Príklad nastavenia poslucháčov udalostí:

            
// Assuming 'xrSession' is your active XRSession object
xrSession.addEventListener('visibilitychange', (event) => {
  if (event.session.visibilityState === 'hidden') {
    console.log('XR session is now hidden. Saving state...');
    stateManager.saveState();
  }
});

// A fallback for the whole page
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    console.log('Page is now hidden. Saving state...');
    // Only save if an XR session is active to avoid unnecessary writes
    if (stateManager.isSessionActive()) {
      stateManager.saveState();
    }
  }
});

            

              
                Copy
              
            
          

Logika ukladania/načítania (s konceptmi kódu)

Tu je koncepčný náčrt triedy `StateManager`. Pre stručnosť použijeme pseudokód a zjednodušené príklady. Odporúčame použiť knižnicu ako `idb` na správu spojenia s IndexedDB.

            
import { openDB } from 'idb';

const DB_NAME = 'WebXR_Experience_DB';
const STORE_NAME = 'SessionState';
const STATE_KEY = 'last_known_state';

class StateManager {
  constructor(scene, player, ui) {
    this.scene = scene; // Reference to your 3D scene manager
    this.player = player; // Reference to your player object
    this.ui = ui;         // Reference to your UI manager

    this.dbPromise = openDB(DB_NAME, 1, {
      upgrade(db) {
        db.createObjectStore(STORE_NAME);
      },
    });
  }

  async saveState() {
    console.log('Gathering application state...');
    const state_snapshot = {
      version: '1.0',
      timestamp: Date.now(),
      sceneState: this.scene.serialize(),
      playerState: this.player.serialize(),
      uiState: this.ui.serialize(),
    };

    try {
      const db = await this.dbPromise;
      await db.put(STORE_NAME, state_snapshot, STATE_KEY);
      console.log('State saved successfully to IndexedDB.');
    } catch (error) {
      console.error('Failed to save state:', error);
    }
  }

  async loadState() {
    try {
      const db = await this.dbPromise;
      const savedState = await db.get(STORE_NAME, STATE_KEY);

      if (!savedState) {
        console.log('No saved state found.');
        return null;
      }

      console.log('Saved state found. Ready to restore.');
      return savedState;
    } catch (error) {
      console.error('Failed to load state:', error);
      return null;
    }
  }

  async restoreFromState(state) {
    if (state.version !== '1.0') {
      console.warn('Saved state version mismatch. Cannot restore.');
      return;
    }

    console.log('Restoring application from state...');
    this.scene.deserialize(state.sceneState);
    this.player.deserialize(state.playerState);
    this.ui.deserialize(state.uiState);
    console.log('Restore complete.');
  }
}

// --- In your main application logic ---

async function main() {
  // ... initialization ...
  const stateManager = new StateManager(scene, player, ui);

  const savedState = await stateManager.loadState();
  if (savedState) {
    // GOOD UX: Don't just force a restore. Ask the user!
    if (confirm('An unfinished session was found. Would you like to restore it?')) {
      await stateManager.restoreFromState(savedState);
    }
  }

  // ... proceed to start the WebXR session ...
}

            

              
                Copy
              
            
          

Táto štruktúra vyžaduje, aby vaše hlavné aplikačné komponenty (`scene`, `player`, `ui`) mali svoje vlastné metódy `serialize()` a `deserialize()`. To podporuje čistú, modulárnu architektúru, ktorá sa ľahšie spravuje a ladí.

Najlepšie postupy a globálne úvahy

Implementácia základnej logiky je len polovica úspechu. Ak chcete vytvoriť skutočne profesionálny zážitok, zvážte tieto osvedčené postupy.

Optimalizácia výkonu

• Zostaňte asynchrónni: Nikdy neblokujte hlavné vlákno. Používajte `IndexedDB` na ukladanie a zvážte použitie Web Workers pre CPU-náročnú serializáciu/deserializáciu veľmi veľkých scén.
• Debounce častých uložení: Ak ukladáte na základe nepretržitých udalostí (ako je pohyb objektu), použite funkciu 'debounce', aby ste zabezpečili, že operácia uloženia sa spustí až po období nečinnosti, čím sa zabráni záplave zápisov do databázy.
• Buďte selektívni: Profilujte svoje uložené dáta. Ak je váš stavový objekt príliš veľký, zistite, čo zaberá miesto a určte, či je skutočne potrebné ho ukladať, alebo či sa dá pri načítaní procedurálne regenerovať.

Používateľský zážitok (UX) je prvoradý

• Komunikujte jasne: Používajte jemné notifikácie v UI na informovanie používateľa. Jednoduchá správa "Postup uložený" poskytuje obrovský pocit istoty. Keď sa aplikácia načíta, explicitne informujte používateľa, že jeho predchádzajúca relácia sa obnovuje.
• Dajte používateľom kontrolu: Ako je ukázané v príklade kódu, vždy sa opýtajte používateľa pred obnovením stavu. Možno budú chcieť začať odznova. Zvážte tiež pridanie manuálneho tlačidla "Uložiť" do menu vašej aplikácie.
• Zvládajte zlyhania elegantne: Čo sa stane, ak `IndexedDB` zlyhá alebo sú uložené dáta poškodené? Vaša aplikácia by nemala spadnúť. Mala by zachytiť chybu, zaznamenať ju pre vaše vlastné účely ladenia a spustiť novú reláciu, možno s upozornením pre používateľa, že predchádzajúci stav sa nepodarilo obnoviť.
• Implementujte verzovanie stavu: Keď aktualizujete svoju aplikáciu, štruktúra vášho stavového objektu sa môže zmeniť. Jednoduché pole `version` vo vašom uloženom stave je kľúčové. Pri načítaní skontrolujte túto verziu. Ak ide o starú verziu, môžete sa pokúsiť spustiť migračnú funkciu na jej aktualizáciu na nový formát, alebo ju zahodiť, aby ste predišli chybám.

Bezpečnosť, súkromie a globálna zhoda

Keďže ukladáte dáta na zariadení používateľa, máte zodpovednosť za ich správne zaobchádzanie. Toto je obzvlášť dôležité pre globálne publikum, keďže predpisy o ochrane osobných údajov sa výrazne líšia (napr. GDPR v Európe, CCPA v Kalifornii a ďalšie).

• Buďte transparentní: Majte jasné zásady ochrany osobných údajov, ktoré vysvetľujú, aké dáta sa lokálne ukladajú a prečo.
• Vyhnite sa citlivým údajom: Neukladajte osobné identifikačné údaje (PII) vo svojom stave relácie, pokiaľ to nie je absolútne nevyhnutné a nemáte výslovný súhlas používateľa. Stav aplikácie by mal byť anonymný.
• Žiadny prístup z inej domény: Pamätajte, že mechanizmy úložiska prehliadača ako IndexedDB sú v sandboxe pre každú doménu. Toto je vstavaná bezpečnostná funkcia, ktorá bráni iným webovým stránkam v prístupe k uloženému stavu vašej aplikácie.

Budúcnosť: Štandardizovaná správa WebXR relácií

Dnes je budovanie systému kontrolných bodov relácie manuálny proces, ktorý musí podstúpiť každý seriózny vývojár WebXR. Avšak Immersive Web Working Group, ktorá štandardizuje WebXR, si je týchto výziev vedomá. V budúcnosti sa môžeme dočkať nových špecifikácií, ktoré uľahčia perzistenciu.

Potenciálne budúce API by mohli zahŕňať:

• API na obnovenie relácie: Štandardizovaný spôsob, ako 'hydratovať' novú reláciu dátami z predchádzajúcej, možno spravovaný bližšie samotným prehliadačom alebo XR zariadením.
• Podrobnejšie udalosti životného cyklu relácie: Udalosti, ktoré poskytujú viac kontextu o tom, prečo sa relácia pozastavuje, čo umožňuje vývojárom reagovať inteligentnejšie.

Dovtedy je robustný, na mieru vytvorený prístup popísaný v tomto sprievodcovi globálnou osvedčenou praxou pre vytváranie perzistentných a profesionálnych WebXR aplikácií.

Záver

Imerzívny web má neobmedzený potenciál, ale jeho úspech závisí od poskytovania používateľských zážitkov, ktoré nie sú len vizuálne ohromujúce, ale aj stabilné, spoľahlivé a rešpektujúce pokrok používateľa. Pominuteľný, ľahko resetovateľný zážitok je hračka; perzistentný je nástroj, destinácia, svet, ktorému môže používateľ dôverovať a do ktorého sa môže vrátiť.

Implementáciou dobre navrhnutého systému kontrolných bodov stavu relácie pozdvihnete svoju WebXR aplikáciu z krehkého dema na profesionálny produkt. Kľúčové poznatky sú:

• Uznajte krehkosť: Pochopte, že WebXR relácie môžu a budú prerušované z mnohých dôvodov.
• Naplánujte si svoj stav: Starostlivo identifikujte základné údaje, ktoré definujú zážitok používateľa.
• Vyberte si správne nástroje: Využite asynchrónnu, neblokujúcu silu `IndexedDB` na ukladanie.
• Buďte proaktívni so spúšťačmi: Ukladajte stav v kľúčových momentoch, vrátane periodicky a, čo je najdôležitejšie, pri zmene viditeľnosti relácie.
• Uprednostnite používateľský zážitok: Komunikujte jasne, dajte používateľom kontrolu a zvládnite zlyhania s gráciou.

Vytvorenie tejto funkcionality si vyžaduje úsilie, ale odmena – v podobe udržania používateľov, ich spokojnosti a celkovej kvality vášho imerzívneho zážitku – je nesmierna. Teraz je čas prekročiť základy a budovať perzistentné, odolné virtuálne a rozšírené svety budúcnosti.