Beste antwoord
Nou, ik kan de vraag voor Unity beantwoorden .
Daar was een bloeiend ecosysteem voor in-browser Unity-games, vooral op Facebook. De Unity-webplayer was goed genoeg om mooie graphics en een soepele framerate te krijgen (op voorwaarde dat je veel hebt gebakken en geoptimaliseerd). Ik heb ooit aan een serious game / simulatie gewerkt die op de webplayer werd geïmplementeerd en een beetje de grenzen verlegde, dus ik wist waartoe het in staat was.
Dat veranderde allemaal toen Chrome besloot te stoppen de NPAPI-ondersteuning, waarop de webplayer is gebaseerd. Wat is NPAPI? De volledige details zijn hier – NPAPI – Wikipedia – maar om het kort te houden, het is een methode voor het ontwikkelen van plug-ins voor de verschillende reguliere browsers. NPAPI was echter oud, vatbaar voor beveiligingsproblemen en er was een oproep om HTML5 / WebGL enz. Te gebruiken, dus Chrome besloot het geleidelijk stop te zetten.
Het grootste verschil tussen NPAPI en het gebruik van WebGL is dat het eerste gaf bijna onbeperkte toegang tot de bronnen van de lokale machine (zie NPAPI-plug-ins – Google Chrome voor details). Voor Unity3D WebGL zijn er twee grote problemen:
De eerste is dat er geen native compilatie van code is voor HTML5 / WebGL. Unity loste dit op door een project samen te stellen tot een vorm van geoptimaliseerd JavaScript. Dat is groot , in termen van bestandsgrootte, aangezien de meeste Unity-engine-code erin moet zitten om het project te laten draaien, en Unity zeker niet lichtgewicht. In het geval van een webplayer staat de meeste motorcode al in de DLL of in de plug-in, dus je zou gewoon de scènegegevens zelf kunnen laden en uitvoeren. Voor WebGL-webplayer moet de engine-code echter consequent opnieuw worden gedownload, en ik weet niet zeker of daar al een oplossing voor is.
Om de grootte te verkleinen, heeft de WebGL-code worden gecomprimeerd. Dit betekent echter dat de code moet worden uitgepakt op de computer van de client, na het downloaden , wat de ervaring traag en onhandig maakt.
Het moordende probleem is dat van geheugen. In tegenstelling tot NPAPI, kunt u bij het uitvoeren van de WebGL-webplayer alleen het geheugen gebruiken dat de browser heeft, en dat is eerlijk gezegd buiten uw controle. De speler heeft mogelijk meer dan 100 tabbladen geopend, waardoor er niet genoeg geheugen overblijft om uw game uit te voeren. Of je game kan te groot zijn voor de geheugenlimieten van de browser, waardoor hij tijdens het laden onbewust crasht, zonder een foutmelding (dat was 2 jaar geleden het geval toen ik het probeerde).
Je hebt in wezen genoegen nemen met minder gedetailleerde modellen, game-items van mindere kwaliteit (geluid, texturen enz.) om iets op te zetten met WebGL / HTML5. Franky, ik betwijfel of WebGL / HTML5 ooit het niveau van kwaliteit en framesnelheid zou bieden dat de oude NPAPI-plug-ins zouden kunnen bieden, dus ik denk dat het hele ecosysteem van webgebaseerde Unity-games is weggevaagd.
Houd er rekening mee dat dit voornamelijk voor Unity3D WebGL-spelers is – er zijn andere game-engines die games op WebGL kunnen uitvoeren, hoewel die meestal op JavaScript zijn gebaseerd en geoptimaliseerd voor het web. Unity3D is een enorme engine, en internet is geen eersteklas burger meer als implementatieplatform.
Hoe dan ook, ik ben niet in de Unity-scene van de afgelopen twee jaar, dus hopelijk zou iemand me tegenspreken.
Antwoord
Er zit hier een inhoudsprobleem en een social engineering-probleem, maar ik ben gaan praten over technische problemen. Over de eerste twee zou je een paar boeken kunnen schrijven.
De TL; DR hier is dat je niet echt dezelfde AAA-prestaties kunt halen uit de webplatform dat u van native programmas mag verwachten. Er zijn enkele tijdelijke oplossingen, maar deze zijn duurder voor de ontwikkelaars om te implementeren.
1.) Runtime-compilatie en assetverwerking
In tegenstelling tot de standaardmethode voor spelproductie, moet een webgame momenteel zijn code compileren en in realtime toegang krijgen tot zijn gerelateerde activa. Historisch gezien zou een game vooraf gecompileerde items en code hebben die op aanvraag zouden worden geladen en uitgevoerd. Door je game vooraf te compileren, kun je je game optimaliseren om beter te draaien in verschillende situaties. Een deel van deze aanpassingen gebeurt tijdens de installatie (IE, pc / MAC / consoleverschillen) en een deel hiervan gebeurt wanneer je game-opties instelt.
Aangezien deze optimalisatie plaatsvindt vóór runtime, kun je in het spel laden sneller (je weet al wat je moet doen). Runtime-compilatie betekent echter dat u dit allemaal tijdens runtime moet uitzoeken in plaats van vooraf. Dit verlengt onder andere meestal de laadtijden. In theorie is het mogelijk om gedownloade gegevens in het cachegeheugen op te slaan, maar de browser (of een ongelukkige gebruiker) kan heel gemakkelijk overschrijven wat u doet. Zie punt 3.
2.) Serveronderhoud
Via een webbrowser kunt u bestanden en middelen op afstand opslaan, maar dit vormt een onderhoudsprobleem voor gamebedrijven – het vereist tijd en geld om de serverservices te laten onderhouden. Dit probleem kan drastisch worden verminderd door de game eenmaal op een lokale computer te installeren en periodiek patches te leveren in plaats van constante streaming-updates. Bandwidth = $$$, om nog maar te zwijgen van de IT-professionals die nodig zijn om de servers met maximale uptime te laten werken.
3.) Browser-overhead / beperkingen
Alles draaien in een webbrowser betekent dat u niet alleen moet werken met het besturingssysteem als systeemvereiste, maar ook met het extra geheugen en de verwerkingstijd die de browser nodig heeft. Chrome gebruikt momenteel bijvoorbeeld ~ 148 MB om mij deze vraag te laten beantwoorden! Dit is waarschijnlijk niet slecht voor pcs of Macs, maar het is dodelijk voor tablets.
Bovendien hebben de meeste browsers beveiligingsfuncties die beperken hoe de browser kan communiceren met uw besturingssysteem en hardware. Dit betekent dat bepaalde soorten prestatiebewerkingen die u normaal zou kunnen uitvoeren met een vooraf gecompileerde game eenvoudigweg niet mogelijk zijn binnen een browser (vaak directe geheugentoegang).