The good news is that generation can be offloaded to the cloud. Check out the following video. This is me at my home running several of these simple clients. The content they display is generated by servers running in Amazon's cloud:
Friday, October 3, 2014
Desktops, Tablets and Phones
One of my goals starting this project was to have relatively simple client applications exposing rich and complex worlds. While we later worked on generating as much as possible in the client-side, there will always be a case where you want access from power-challenged devices. Phones, tablets and even desktop web browsers do not necessarily have the power to generate everything you would like to have in your virtual world, but are still ideal mediums for people to experience it.
The good news is that generation can be offloaded to the cloud. Check out the following video. This is me at my home running several of these simple clients. The content they display is generated by servers running in Amazon's cloud:
The good news is that generation can be offloaded to the cloud. Check out the following video. This is me at my home running several of these simple clients. The content they display is generated by servers running in Amazon's cloud:
Subscribe to:
Post Comments (Atom)
Wow, yet again I am blown away. Does this mean VF could support a 1st/3rd person "mmo"? Since most of the computing is done in the cloud, I imagine it would only be slightly more complicated to get multiple clients to access the same data at the same time. I guess latency is probably a problem? This opens so many doors... Also, I am digging the toon shaders on the mobile platform. Does VF support Cel-shading (as in, is it very difficult to pull off) or would a 3rd party engine be better for that?
ReplyDeleteI forgot to add "mobile". I'm asking how viable a mobile MMO would be using this system.
DeleteLatency is not really a problem. The client always has a scene buffered to allow the player twitch interactions with the world. This is not like game streaming services like OnLive, where each frame is sent over the network. In our approach we buffer content, but player interactions do not require a server roundtrip to manifest. So you can move instantly and change the world instantly (well as fast as you client's processing speed allows).
DeleteThis system would allow you to create a pretty cool mobile MMO. Lots of exploration and also player created content. You would still need to watch for bandwidth.
I was talking more of latency between clients, like the time it takes to see the change in other payers locations as well as what changes they make to the scene. I guess that is majorly dependent on bandwidth, like you said.
DeleteYes, latency is a factor in how soon you see changes from other players. In this aspect it is the same as any traditional MMO.
DeleteBandwidth is the bottleneck, you hit it when you outrun your capacity to buffer. So here techniques like pre-caching, pre-buffering and prediction in general come to play and could make a big difference.
I thought it was quite time consuming making the polygon mesh and LOD? Are you using multi-threading on those devices?
ReplyDeleteThis approach sends voxels for the first LOD (where the viewer can interact) and triangle meshes for any higher LOD. Only the first LOD has to be converted from voxels to triangles, anything beyond is just ready for use. Also the most time consuming task is running the procedural generation and applying the user-made changes, and this happens 100% serverside.
DeleteAnd yes, this is using multithreading on the devices.