A legjobb válasz
Nos, válaszolni tudok a Unity kérdésére .
A régen virágzó ökoszisztéma volt a böngészőben található Unity játékokhoz, különösen a Facebookon. A Unity webplayer elég tisztességes volt ahhoz, hogy szép grafikát és sima framerátát kapjon (feltéve, hogy sok sütést és optimalizálást végzett). Egyszer egy komoly játékon / szimuláción dolgozom, amelyet a web-lejátszón telepítettek, és valamennyire túlléptem a határait, így tudtam, mire képes.
Ez mind megváltozott, amikor a Chrome úgy döntött, hogy megöli. az NPAPI támogatás, amelyen a weblejátszó alapul. Mi az NPAPI? A részletek itt találhatók – NPAPI – Wikipédia – azonban röviden összefoglalva, ez egy plugin fejlesztési módszer a különféle mainstream böngészők számára. Az NPAPI azonban régi volt, hajlamos volt a biztonsági problémákra, és felhívás volt a HTML5 / WebGL stb. Használatára, ezért a Chrome úgy döntött, hogy fokozatosan megszünteti.
A legnagyobb különbség az NPAPI és a WebGL használata között az, hogy az előbbi szinte korlátlan hozzáférést adott a helyi gép erőforrásaihoz (a részletekért lásd: NPAPI bővítmények – Google Chrome ). A Unity3D WebGL esetében két nagy probléma van:
Az első az, hogy a HTML5 / WebGL számára nincs natív kódfordítás. A Unity ezt úgy oldotta meg, hogy egy projektet optimalizált JavaScript formára állított össze. Ez a fájlméret szempontjából nagy , mivel a projekt futtatásához a Unity motor kódjának nagy részének ott kell lennie, és a Unity semmiképpen sem könnyű. Web-lejátszó esetén a motor kódjának nagy része már megtalálható a DLL-ben vagy a beépülő modulban, így csak magát a jelenet adatait töltheti be és futtathatja. A WebGL webplayer esetében azonban a motorkódot következetesen újra le kell tölteni, és nem vagyok biztos benne, hogy erre volt-e még megoldás.
A méret csökkentése érdekében a WebGL kód tömöríteni. Ez azonban azt jelenti, hogy a kódot le kell tölteni az ügyfél számítógépén, a letöltés után , ami lassúvá és zavarossá teszi az élményt.
A gyilkos problémája a memória kérdése. Az NPAPI-val ellentétben a WebGL weblejátszó futtatásakor csak a böngésző memóriáját használhatja, vagyis őszintén szólva az ön ellenőrzése alatt. Előfordulhat, hogy a játékosnak több mint 100 lapja van megnyitva, így nincs elég memória a játék futtatásához. Vagy a játék túl nagy lehet a böngésző memóriakorlátjaihoz, ami kegyetlenül összeomlik, miközben betöltődik, hibaüzenet nélkül (ez történt 2 évvel ezelőtt, amikor megpróbáltam).
Lényegében rendelkezik kielégíteni a kevésbé részletes modelleket, a rosszabb minőségű játékeszközöket (hang, textúrák stb.), amire valamit fel lehet tenni a WebGL / HTML5 használatával. Franky, kétlem, hogy a WebGL / HTML5 valaha is biztosítaná azt a minőségi és képkockasebességi szintet, amelyet a régi NPAPI beépülő modulok képesek lennének biztosítani, ezért úgy gondolom, hogy a webalapú Unity játékok teljes ökoszisztémáját kiirtották. > Ne feledje, hogy ez főleg a Unity3D WebGL-lejátszókra vonatkozik – vannak más játékmotorok is, amelyek képesek játékokat futtatni a WebGL-en, bár ezek általában JavaScript-alapúak és webre optimalizáltak. Az Unity3D egy hatalmas motor, és a web már nem első osztályú állampolgár telepítési platformként.
Egyébként nem voltam az Unity jelenetben az elmúlt két évben, úgyhogy remélhetőleg valaki ellentmond nekem.
Válasz
Itt rejtőzik egy tartalmi probléma, valamint egy társadalmi mérnöki probléma, de én technikai kérdésekről fog beszélni. Írhat pár könyvet az első kettőre.
A TL; DR itt az, hogy nem igazán kaphatja meg ugyanazt az AAA teljesítményt webes platform, amelyet elvárhat a natív programoktól. Van néhány megoldás, de ezeket a fejlesztők számára drágábban kell megvalósítani.
1.) Futtatási idő összeállítása és eszközfeldolgozás
A játékkészítés szokásos módszerével ellentétben egy webes játéknak jelenleg össze kell állítania a kódját, és valós időben hozzá kell férnie a kapcsolódó eszközökhöz. Történelmileg egy játéknak előre összeállított eszközei és kódjai lennének, amelyeket igény szerint betöltenének és futtatnának. A játék előzetes fordítása lehetővé teszi a játék optimalizálását, hogy jobban működjön a különböző helyzetekben. Ennek a testreszabásnak egy része telepítéskor történik (IE, PC / MAC / konzol különbségek), és ezek egy része a játékopciók beállításakor.
Mivel ez az optimalizálás a futási idő előtt történik, betöltheti a játékba gyorsabban (már tudja, mit kell tennie). A futási idő összeállítása azonban azt jelenti, hogy mindezt futásidőben kell kitalálni előzetes helyett. Ez általában megnöveli többek között a betöltési időt. Elméletileg lehetséges a letöltött adatok gyorsítótárba helyezése, de a böngésző (vagy egy szerencsétlen felhasználó) nagyon könnyen felülírhatja, amit csinál. Lásd: 3. sz.
2.) Szerver karbantartás
Egy webböngészőben fájlokat és eszközöket távolról is tárolhat, de ez a játékcégek számára fenntartási problémát jelent – ehhez szükség van idő és pénz a szerverszolgáltatások karbantartásához. Ezt a problémát drasztikusan csökkenthetjük, ha a játékot egyszer telepítjük egy helyi gépre, és rendszeresen továbbítunk javításokat az állandó adatfolyam-frissítések helyett. Sávszélesség = $$$, nem is beszélve azokról az informatikai szakemberekről, akiknek a szerverek maximális üzemidőben történő üzemeltetéséhez szükségesek.
3.) Böngésző általános költségei / korlátozások
Bármi futtatása egy webböngészőben azt jelenti, hogy nemcsak az operációs rendszerrel kell rendszerkövetelményként dolgoznia, hanem azzal a további memóriával és feldolgozási idővel is, amelyet a böngésző felhasználni fog. Például a Chrome jelenleg ~ 148 MB-ot használ, csak hogy megválaszoljam ezt a kérdést! Ez valószínűleg nem rossz PC-k vagy Mac-ek számára, de gyilkos a táblagépeknél.
Ezenkívül a legtöbb böngésző rendelkezik olyan biztonsági funkciókkal, amelyek korlátozzák a böngésző interakcióját az operációs rendszerrel és a hardverrel. Ez azt jelenti, hogy bizonyos típusú teljesítményműveletek, amelyeket általában egy előre lefordított játékkal végezhetnének el, egyszerűen nem lehetségesek a böngészőben (gyakran közvetlen memóriakapcsolat).