easy to move the render part from to client to server for Torque 3D?
by lys · in Torque 3D Professional · 02/28/2013 (6:26 pm) · 6 replies
here i am not talking about the efficiency. I just want to know whether it is possible to move the rendering part from client side to server without modifying the source code of engine. I already read the source code and know how a game runs. It looks a little difficult to do this only using script without modifying any source code of the engine or a game. anyone have some advice? thanks very much~
#2
03/01/2013 (10:18 pm)
thanks David, yeah, that's what i am talking about, the thin-client and cloud gaming. How do you think Onlive is implemented? since it can support over 300 games, it seems that the platform is independent of the game engine. I guess just as you said, they run both the server and client at the data center and player just connect to one of the client via a remote desktop like software? 
#3
To copy how Onlive works you would just have both the server and client exist on your service, with the client's output being sent over the 'net to some thin client. You also need to pump the remote input into the client running on your service.
Perhaps this could be done with a bunch of virtual machines you start on demand as users connect. It sounds like most of the work here is on the server architecture and thin client, rather than T3D itself.
I would recommend searching for how Onlive and Gaikai are put together. I seem to recall some technical articles being written when these services were announced. I also seem to recall at least one of those services used special Nvidia cards for their servers.
- Dave
03/06/2013 (12:11 pm)
@lys:To copy how Onlive works you would just have both the server and client exist on your service, with the client's output being sent over the 'net to some thin client. You also need to pump the remote input into the client running on your service.
Perhaps this could be done with a bunch of virtual machines you start on demand as users connect. It sounds like most of the work here is on the server architecture and thin client, rather than T3D itself.
I would recommend searching for how Onlive and Gaikai are put together. I seem to recall some technical articles being written when these services were announced. I also seem to recall at least one of those services used special Nvidia cards for their servers.
- Dave
#4
03/06/2013 (1:57 pm)
To add to what Dave said, Onlive and Gaikai both required you to integrate their API into your game. This would allow their servers to manage your game correctly as well as provide latency solutions between the user at home and all of the client/server processing happening in their cloud array. Much like Steam, Onlive works with the developers who are putting their games on their service directly to ensure that it is a solid experience.
#5
03/06/2013 (6:00 pm)
thanks two Davids:) i think you are right, the existing cloud gaming platforms should use the virtual machines to support multiple players. i try to find the articles you mentioned to get some details regarding the architecture they used.
#6
Not a Cloud in Sight
03/13/2013 (8:45 am)
Thought you might find this article interesting, even if it is from a business PoV rather than a development PoV.Not a Cloud in Sight
Associate David Montgomery-Blake
David MontgomeryBlake
What is the specific use case for this? Are you thinking of performing all rendering on the server and delivering a thin-client interface (aka Gakai or Onlive experiences) to the user? In that case, the server running your application also acts as the client, and distribution and event polling (and latency management) are the keys. That and how to scale a massive GPU architecture for future growth and maintain a reasonable price-point for your service.