Beste svaret
Vel, jeg kan svare på spørsmålet til Unity .
Det pleide å være et blomstrende økosystem for Unity-spill i nettleseren, spesielt på Facebook. Unity-webspilleren var anstendig nok til at du kunne få fin grafikk og jevn framerate (forutsatt at du bakte og optimaliserte mye). Jeg jobbet en gang med et seriøst spill / en simulering som ble distribuert på nettspilleren, og liksom presset grensene, så jeg visste hva det var i stand til.
Alt endret seg da Chrome bestemte seg for å drepe NPAPI-støtten, som nettspilleren er basert på. Hva er NPAPI? De fulle detaljene er her – NPAPI – Wikipedia – men for å kutte det kort, er det en metode for plugin-utvikling for de forskjellige vanlige nettleserne. NPAPI var imidlertid gammel, utsatt for sikkerhetsproblemer, og det ble ringt om å bruke HTML5 / WebGL osv., Så Chrome bestemte seg for å fase det ut.
Den største forskjellen mellom NPAPI og bruk av WebGL er at den tidligere ga nesten ubegrenset tilgang til den lokale maskinens ressurser (se NPAPI Plugins – Google Chrome for detaljer). For Unity3D WebGL er det to store problemer:
Den første er at det ikke er noen samling av kode naturlig for HTML5 / WebGL. Unity løste dette ved å kompilere et prosjekt til en form for optimalisert JavaScript. Det er stort , når det gjelder filstørrelse, ettersom det meste av Unity-motorkoden må være der for at prosjektet skal kunne kjøres, og Unity på ingen måte er lett. Når det gjelder en web-spiller, er det meste av motorkoden allerede på DLL eller i plugin-programmet, så du kan bare laste selve scenedataene og kjøre den. For WebGL webplayer må imidlertid motorkoden lastes ned konsekvent, og jeg er ikke sikker på om det har vært en løsning på det ennå.
For å kutte ned på størrelsen, har WebGL-koden skal komprimeres. Dette betyr imidlertid at koden må dekomprimeres på klientens datamaskin, etter nedlasting , noe som gjør opplevelsen langsom og klønete.
Killer-problemet er minnet. I motsetning til NPAPI, når du kjører WebGL-spilleren, kan du bare bruke minnet som nettleseren har, og det er ærlig talt utenfor din kontroll. Spilleren kan ha åpnet mer enn 100 faner, slik at det ikke er nok minne til at spillet ditt kan kjøres. Eller spillet ditt kan være for stort for nettleserens minnegrenser, noe som kan føre til at det krasjer nådig, mens det lastes inn, uten en feilmelding (det var tilfellet for to år siden da jeg prøvde det).
Du har egentlig å nøye seg med mindre detaljerte modeller, dårligere kvalitet på eiendeler (lyd, teksturer osv.) for å bruke noe på å bruke WebGL / HTML5. Franky, jeg tviler på at WebGL / HTML5 noen gang ville gi nivået på kvalitet og bildefrekvens som de gamle NPAPI-pluginene kunne, så jeg tror hele økosystemet med nettbaserte Unity-spill er blitt utslettet.
Vær oppmerksom på at dette hovedsakelig er for Unity3D WebGL-spillere – det finnes andre spillmotorer som kan kjøre spill på WebGL, selv om de pleier å være JavaScript-baserte og optimaliserte for nettet. Unity3D er en stor motor, og nettet er ikke lenger en førsteklasses borger som en distribusjonsplattform.
Uansett har jeg ikke vært i Unity-scenen de siste to årene, så forhåpentligvis ville noen motsette meg.
Svar
Det er et innholdsproblem som skjuler seg her, i tillegg til et sosialteknisk problem, men jeg er skal snakke til tekniske problemer. Du kan skrive et par bøker om de to første.
TL; DR her er at du egentlig ikke kan få den samme AAA-forestillingen ut av webplattform som du forventer fra innfødte programmer. Det er noen løsninger, men de er dyrere for utviklerne å implementere.
1.) Kjør tidskompilering og prosessering av aktiva
I motsetning til standardmetoden for produksjon av spill, må et nettspill for øyeblikket kompilere koden og få tilgang til relaterte eiendeler i sanntid. Historisk sett ville et spill ha forhåndskompilert eiendeler og kode som ville bli lastet og kjørt på forespørsel. Ved å forhåndskompilere spillet ditt kan du optimalisere spillet for å kjøre bedre i forskjellige situasjoner. Noe av denne tilpasningen skjer når du installerer (IE, PC / MAC / konsollforskjeller), og noe av dette skjer når du konfigurerer spillalternativer.
Siden denne optimaliseringen skjer før kjøretid, kan du laste inn i spillet raskere (du vet allerede hva du trenger å gjøre). Imidlertid betyr kjøretidskompilering at du må finne ut av dette på kjøretid i stedet for på forhånd. Dette øker vanligvis blant annet belastningstider. I teorien er det mulig å cache nedlastede data, men nettleseren (eller en ulykkelig bruker) kan overstyre det du gjør veldig enkelt. Se nr. 3.
2.) Servervedlikehold
Over en nettleser kan du lagre filer og eiendeler eksternt, men dette representerer et vedlikeholdsproblem for spillselskaper – det tar tid og penger for å opprettholde servertjenester. Dette problemet kan reduseres drastisk ved å installere spillet en gang på en lokal maskin og levere oppdateringer regelmessig i stedet for kontinuerlige streamingoppdateringer. Båndbredde = $$$, for ikke å nevne profesjonelle informasjonsteknologier som kreves for å betjene serverne ved maksimal oppetid.
3.) Nettleseromkostninger / begrensninger
Å kjøre noe i en nettleser betyr at du må jobbe med ikke bare operativsystemet som et systemkrav, men den ekstra minnet og behandlingstiden som nettleseren bruker. For eksempel bruker Chrome akkurat nå ~ 148 MB bare for å la meg svare på dette spørsmålet! Dette er sannsynligvis ikke dårlig for PCer eller Mac-maskiner, men det er mordere for nettbrett.
I tillegg har de fleste nettlesere sikkerhetsfunksjoner som begrenser hvordan nettleseren kan samhandle med operativsystemet og maskinvaren. Dette betyr at visse typer ytelsesoperasjoner som du normalt kan gjøre med et forhåndskompilert spill ganske enkelt ikke er mulig i en nettleser (ofte direkte minnetilgang).