Bästa svaret
Tja, jag kan svara på frågan för Unity .
Det brukade vara ett blomstrande ekosystem för Unity-spel i webbläsaren, särskilt på Facebook. Unity-webbspelaren var tillräckligt bra för att du skulle få bra grafik och smidig framrate (förutsatt att du gjorde mycket bakning och optimering). Jag jobbade en gång med ett seriöst spel / simulering som distribuerades på webbspelaren och drog på något sätt sina gränser, så jag visste vad den kunde göra.
Allt detta förändrades när Chrome bestämde sig för att döda NPAPI-stödet, som webbspelaren bygger på. Vad är NPAPI? De fullständiga detaljerna finns här – NPAPI – Wikipedia – men för att korta det är det en metod för plugin-utveckling för de olika vanliga webbläsarna. NPAPI var emellertid gammal, benägen för säkerhetsfrågor, och det uppmanades att använda HTML5 / WebGL etc, så Chrome bestämde sig för att fasa ut det.
Den största skillnaden mellan NPAPI och att använda WebGL är att den tidigare gav nästan obegränsad tillgång till den lokala maskinens resurser (se NPAPI-plugins – Google Chrome för mer information). För Unity3D WebGL finns två stora problem:
Den första är att det inte finns någon sammanställning av kod för HTML5 / WebGL. Unity löste detta genom att sammanställa ett projekt till en form av optimerad JavaScript. Det är stort , när det gäller filstorlek, eftersom det mesta av Unity-motorkoden måste finnas där för att projektet ska kunna köras, och Unity inte alls lätt. När det gäller en webbspelare finns det mesta av motorkoden redan i DLL-filen eller i plugin-programmet, så du kan bara ladda själva scendata och köra den. För WebGL webplayer måste dock motorkoden laddas ned konsekvent, och jag är inte säker på om det ännu har funnits en lösning.
För att minska storleken har WebGL-koden som ska komprimeras. Detta betyder dock att koden måste dekomprimeras på klientens dator, efter nedladdning av den , vilket gör upplevelsen långsam och klumpig.
Killer-problemet är minnet. Till skillnad från NPAPI, när du kör WebGL-webbspelaren kan du bara använda det minne som webbläsaren har, och det är uppriktigt sagt utom din kontroll. Spelaren kan ha öppnat mer än 100 flikar, vilket inte ger tillräckligt med minne för att ditt spel ska kunna köras. Eller så kan ditt spel vara för stort för webbläsarens minnesgränser och orsaka att det kraschar otrevligt, medan det laddas, utan ett felmeddelande (det var fallet för två år sedan när jag försökte det).
Du har i princip att nöja sig med mindre detaljerade modeller, speltillgångar av sämre kvalitet (ljud, texturer etc.) för att sätta något på med WebGL / HTML5. Franky, jag tvivlar på att WebGL / HTML5 någonsin skulle ge den kvalitet och bildhastighet som de gamla NPAPI-plugin-programmen kunde, så jag tror att hela ekosystemet med webbaserade Unity-spel har utplånats.
Observera att detta huvudsakligen är för Unity3D WebGL-spelare – det finns andra spelmotorer som kan köra spel på WebGL, även om de tenderar att vara JavaScript-baserade och optimerade för webben. Unity3D är en enorm motor, och webben är inte längre en förstklassig medborgare som en distributionsplattform.
Hur som helst har jag inte varit i Unity-scenen de senaste två åren, så förhoppningsvis skulle någon motsäga mig.
Svar
Det finns en innehållsfråga som gömmer sig här liksom ett socialtekniskt problem, men jag är kommer att tala till tekniska frågor. Du kan skriva ett par böcker om de två första.
TL; DR här är att du inte kan få samma AAA-prestanda ur webbplattform som du kan förvänta dig av inbyggda program. Det finns några lösningar men de är dyrare för utvecklarna att implementera.
1.) Kör tidskompilering och bearbetning av tillgångar
Till skillnad från standardmetoden för spelproduktion måste ett webbspel för närvarande sammanställa sin kod och få tillgång till tillhörande tillgångar i realtid. Historiskt sett skulle ett spel ha förkompilerade tillgångar och kod som skulle laddas och köras på begäran. Förkompilering av ditt spel låter dig optimera ditt spel för att fungera bättre i olika situationer. En del av denna anpassning händer när du installerar (IE, PC / MAC / konsolskillnader) och en del av detta händer när du ställer in spelalternativ.
Eftersom den här optimeringen sker före körtid kan du ladda in i spelet snabbare (du vet redan vad du behöver göra). Sammanställning av körtid betyder dock att du måste räkna ut allt detta under körning istället för i förväg. Detta ökar vanligtvis bland annat belastningstiderna. I teorin är det möjligt att cacha nedladdad data men webbläsaren (eller en olycklig användare) kan åsidosätta det du gör mycket enkelt. Se # 3.
2.) Serverunderhåll
Via en webbläsare kan du lagra filer och tillgångar på distans, men detta utgör ett underhållsproblem för spelföretag – det tar tid och pengar för att behålla servertjänsterna. Detta problem kan minskas drastiskt genom att installera spelet en gång på en lokal maskin och leverera korrigeringar med jämna mellanrum istället för kontinuerliga uppdateringar. Bandbredd = $$$, för att inte tala om informationstekniker som krävs för att driva servrarna vid maximal drifttid.
3.) Webbläsares omkostnader / begränsningar
Att köra vad som helst i en webbläsare betyder att du måste arbeta med inte bara operativsystemet som ett systemkrav utan den extra minne och behandlingstid som webbläsaren använder. Till exempel använder Chrome just nu ~ 148 MB för att låta mig svara på den här frågan! Detta är förmodligen inte dåligt för datorer eller Mac-datorer, men det är mördare för surfplattor.
Dessutom har de flesta webbläsare säkerhetsfunktioner som begränsar hur webbläsaren kan interagera med ditt operativsystem och maskinvara. Detta innebär att vissa typer av prestationsåtgärder som du normalt kan göra med ett förkompilerat spel helt enkelt inte är möjliga i en webbläsare (ofta direkt minnesåtkomst).