Yeah regarding the on-demand asset streaming, I've been chatting with the developer that did the Doom 3 port, and he's looking creating at a similar solution in the future. I fully agree that games should only be loading what is absolutely necessary, and in regards to the memory limit issue, I think the solution is by bringing vertical slices of games to the web, acting as a sort of "proving ground" for games. Can act as a bridge to becoming an early access title on PC (Steam) and gives the developer early feedback from their audience. In terms of the business case, I also agree that specific games are best suited for this use case, particularly smaller gamers with multiplayer aspects. We're currently using the F2P business model, with the future migration to freemium (similiar to Spotify's model). Older PC games, mobile games are the perfect use case, but the Doom 3 demo port has proved that both technically and business wise, AAA gaming on the web has a place and most certainly be a reality. But it's going to take incremental steps to get there. Are you interested in helping us further solve these issues and pioneer this new era of gaming on the web? Here's a link to our Discord: https://discord.gg/VgB4zg
On Sun, Mar 10, 2019 at 6:17 AM Floh <[email protected]> wrote: > IMHO the most important problem (before all the others) is how do you get > all that data into your game. Current PC/console games are usually > downloaded and installed upfront before you can start playing. This is a > problem for web platforms, you don't want to let the player wait for half > an hour or longer before he can start playing, and the browser doesn't > allow to store many gigabytes as persistent storage anyway. > > Unfortunately most games engines are built around the idea that asset data > is downloaded is big blobs, and stored in a persistent location (of the big > ones, Unity may be the best fit because it has a long history on the web). > > I've been implementing on-demand-streaming of asset data in the past a > couple of times. > > It works quite well *if the whole ending *and* all games built with this > engine are designed around the idea of on-demand-data-streaming. The core > problem basically moves from "how much data do we need for the next > level/region" to "how much *new* data can we stream per second" (and thus > present to the user). Download bandwidth dictates everything you can do in > the game, but if your game is built around the idea that you can only > present as much new (uncached) data to the user as bandwidth allows, the > overall asset size of the game can be basically infinite. > > Another advantage is that player don't need to download data they will > never see. Most players only ever see 10% of a game until they move on to > another game. Why download 100% of the data upfront if only 10% are needed? > > TL;DR: design your game engine's asset loading strategy the same way > Google Earth does it. > > The other problems are less of technical nature I think, but marketing and > monetization. How do you sell an AAA game on the web? How do you advertize > it? Do you need copy-protection? If yes, how would this be implemented? > > That's why I think the open web also needs a new type of game, typical > console-AAA games are not a good both for technical and non-technical > reasons. Some variant of the current F2P client/server model (give away the > client for free and control the server), basically "up-ported" mobile > games, not "down-ported AAA games". > > Cheers, > -Floh. > > On Sunday, 10 March 2019 07:51:30 UTC+1, [email protected] > wrote: >> >> Just curious if it's currently too early to deploy console-quality PC >> games to the web using wasm? Seems like multithreading and wasm-64 will >> bring about the biggest improvements in this regard. >> > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
