Bedste svar
Nå, jeg kan besvare spørgsmålet til Unity .
Der
Det hele ændrede sig, da Chrome besluttede at dræbe NPAPI-understøttelsen, som webafspilleren er baseret på. Hvad er NPAPI? De fulde detaljer er her – NPAPI – Wikipedia – men for at forkorte det er det en metode til pluginudvikling for de forskellige almindelige browsere. NPAPI var dog gammel, tilbøjelig til sikkerhedsproblemer, og der blev kaldt på at bruge HTML5 / WebGL osv., Så Chrome besluttede at udfase det.
Den største forskel mellem NPAPI og brug af WebGL er, at den tidligere gav næsten ubegrænset adgang til den lokale maskins ressourcer (se NPAPI-plugins – Google Chrome for detaljer). For Unity3D WebGL er der to store problemer:
Den første er, at der ikke er nogen kompilering af kode indbygget til HTML5 / WebGL. Unity løste dette ved at kompilere et projekt til en form for optimeret JavaScript. Det er stort med hensyn til filstørrelse, da det meste af Unity-motorkoden skal være derinde for at projektet skal køre, og Unity på ingen måde er let. I tilfælde af en webafspiller er det meste af motorkoden allerede på DLL eller i pluginet, så du kan bare indlæse selve scenedataene og køre dem. For WebGL webplayer skal motorkoden dog downloades konsekvent, og jeg er ikke sikker på, om der endnu har været en løsning.
For at skære ned på størrelsen har WebGL-koden skal komprimeres. Dette betyder dog, at koden skal dekomprimeres på klientens computer, efter downloadet , hvilket gør oplevelsen langsom og klodset.
Killer-problemet er hukommelsens. I modsætning til NPAPI, når du kører WebGL-webafspiller, kan du kun bruge den hukommelse, browseren har, og det er ærligt uden for din kontrol. Spilleren kan have åbnet mere end 100 faner, så der ikke er nok hukommelse til, at dit spil kan køre. Eller dit spil kan være for stort til browserens hukommelsesgrænser, hvilket får det til at gå ned ondskabsfuldt under indlæsning uden en fejlmeddelelse (det var tilfældet for to år siden, da jeg prøvede det).
Du har i det væsentlige at nøjes med mindre detaljerede modeller, spilaktiver af dårligere kvalitet (lyd, teksturer osv.) for at sætte noget på ved hjælp af WebGL / HTML5. Franky, jeg tvivler på, at WebGL / HTML5 nogensinde ville levere det niveau af kvalitet og billedhastighed, som de gamle NPAPI-plugins kunne, så jeg tror, at hele økosystemet med webbaserede Unity-spil er blevet udslettet.
Vær opmærksom på, at dette hovedsageligt er til Unity3D WebGL-afspillere – der er andre spilmotorer, der er i stand til at køre spil på WebGL, selvom de har tendens til at være JavaScript-baserede og optimerede til internettet. Unity3D er en enorm motor, og web er ikke længere en førsteklasses borger som en implementeringsplatform.
Jeg har alligevel ikke været i Unity-scenen i de sidste to år, så forhåbentlig ville nogen modsige mig.
Svar
Der skjuler sig et indholdsproblem her såvel som et socialt ingeniørproblem, men jeg er vil tale med tekniske problemer. Du kunne skrive et par bøger om de to første.
TL; DR her er, at du ikke rigtig kan få den samme AAA-præstation ud af webplatform, som du ville forvente af oprindelige programmer. Der er nogle løsninger, men de er dyrere for udviklerne at implementere.
1.) Kør tidskompilering og behandling af aktiver
I modsætning til standardmetoden til spilproduktion skal et webspil i øjeblikket kompilere sin kode og få adgang til dets relaterede aktiver i realtid. Historisk set ville et spil have forud kompilerede aktiver og kode, der ville blive indlæst og kørt efter behov. Præ-kompilering af dit spil giver dig mulighed for at optimere dit spil til at køre bedre i forskellige situationer. Noget af denne tilpasning sker, når du installerer (IE, PC / MAC / konsolforskelle), og noget af dette sker, når du konfigurerer spilindstillinger.
Da denne optimering sker inden kørselstid, kan du indlæse i spillet hurtigere (du ved allerede, hvad du skal gøre). Imidlertid betyder løbstidskompilering, at du skal finde ud af alt dette på kørselstid i stedet for på forhånd. Dette øger normalt bl.a. belastningstiderne. I teorien er det muligt at cache downloadede data, men browseren (eller en ulykkelig bruger) kan tilsidesætte det, du laver meget let. Se nr. 3.
2.) Servervedligeholdelse
Over en webbrowser kan du gemme filer og aktiver eksternt, men dette repræsenterer et vedligeholdelsesproblem for spilvirksomheder – det tager tid og penge til at servicere servertjenester. Dette problem kan reduceres drastisk ved at installere spillet en gang på en lokal maskine og regelmæssigt levere patches i stedet for konstant opdateringer til streaming. Båndbredde = $$$, for ikke at nævne de professionelle inden for informationsteknologi, der kræves for at betjene serverne ved maksimal oppetid.
3.) Browseroverhead / begrænsninger
At køre noget i en webbrowser betyder, at du ikke kun skal arbejde med operativsystemet som et systemkrav, men den ekstra hukommelse og behandlingstid, som browseren bruger op. For eksempel bruger Chrome lige nu ~ 148 MB bare for at lade mig besvare dette spørgsmål! Dette er sandsynligvis ikke dårligt for pcer eller Macer, men det er dræbende for tablets.
Derudover har de fleste browsere sikkerhedsfunktioner, der begrænser, hvordan browseren kan interagere med dit operativsystem og hardware. Dette betyder, at visse typer ydeevnehandlinger, som du normalt kunne gøre med et forud kompileret spil, simpelthen ikke er mulige i en browser (ofte direkte hukommelsesadgang).