Streaming v Client side rendering
Members - Reputation: 100
Posted 24 April 2012 - 08:36 AM
I've been planning a game for months now, and as I've been starting to put some shit down onto paper I have come across a major hole that I really want to avoid.
This means, if I were to use WebGL and all that good stuff to render the graphics client side. It would probably have its first bot written within weeks if not days if not hours if some wanker wants too prove themselves to be an Über nerd. Something which I really want to avoid as it ruins the experience for people who really enjoy playing games.
So the easiest solution I have come up with is to stream the mofo graphics to the client in a 2D array of some sort. But then there is the problem with download speeds, bandwidth and it would up the server load majorly per user as all the 3D rendering will have to be done server side.
I was wondering if anyone else has ever considered a fix for the same problem. I also know that OnLive stream the video, but I'm guessing by the quality that it does so through UDP where I am restricted to TCP.
Any thoughts would be most appreciated!
Thanks in advance,
Crossbones+ - Reputation: 2993
Posted 24 April 2012 - 08:46 AM
Members - Reputation: 2387
Posted 24 April 2012 - 08:49 AM
That or you can do as you said and recreate onlive if you have all the money for servers equipped with graphics cards and a ISP sized pipe to the Internet.
Crossbones+ - Reputation: 8947
Posted 24 April 2012 - 06:52 PM
In most other situations you are leaking craploads of extra information besides what you show on the actual screen, which gives the wannabe hacker plenty of stuff to work with. This is unavoidable with current technology. It has been discussed in this thread and the general consensus was that:
1. if your game is not popular then probably nobody is going to bother hacking it if you implement basic security measures
2. the best defense against hackers is a responsible community i.e. an easily accessible voteban mechanism
The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.
- Pessimal Algorithms and Simplexity Analysis
Members - Reputation: 206
Posted 24 April 2012 - 07:18 PM
-Performance depends on the players machine, of which they can change by upgrading.
-The majority of information and processing is open to the player, who if educated in modifying the functionality of already compiles executables, may do whatever the heck they wish.
-Unpackaged assets may be modified or replaced in such a way that a player may gain an unfair advantage.
-The server for the streaming would cost a fortune.
-The players require sufficient access to the server, including fast enough internet, with a low enough latency and a high enough bandwidth. (this can be fixed by the players paying the service provider an arm and a leg and potentially moving homes to reduce the latency)
-Once a month the almighty god Ra will ride dinosaurs in the streets and fred flintstone would own a master chief figure
hmmm... quite evenly matched...
in case the tone wasn't clear enough,
Streaming will not be a viable alternative to client side for a very very long time, data transfer would need to become physically faster... a lot. to the point ping no longer exists. its one thing to be killed a moment after you use a shield, its another to raise the shield a moment after you press the button (tried on live with a similar problem... its bad)... as mentioned there are more problems in that to have the processing power to play a game for the thousands of people or even hundreds of people who wish to play you would need a fortune a true fortunes worth of server power.
Members - Reputation: 100
Posted 25 April 2012 - 04:50 AM
I definitely think streaming remains a good solution. As you guys have pointed out it's really expensive to implement and the networking speeds of today can't cut a real-time physics based game-play with the video stream on-top, there is too much chance of lag. I do however believe streaming the visual and sound to the client is the height of cloud computing, it also means the client hardware only has to have minimal requirements to run the game. I don't really see lack of good server hardware as a viable problem as deploying in the cloud is a really good solution when you don't look at the costs.
I wrote a quick streaming library for Node.js, HTML5 canvas and WebSockets last night to see how it works out. It definitely works, but the performance is far from optimal. If the server also has to do some projection rendering on-top of the visual/audio streaming, user control handling and physics calculations, those all important milliseconds would simply be non existent. Especially when broadcasting among multiple users becomes part of the game.
One handy thing about canvas is you can get a context of every pixel in the canvas and send it to the server as an image. This will have to do as the main anti-cheat mechanism for now.