Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Streaming v Client side rendering

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Hi I'm Chris   Members   -  Reputation: 100


Posted 24 April 2012 - 08:36 AM

Hello people and search engine bots.

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.

Part of the system is going to be in JavaScript, the reason for this is that I can easily make a HTML5 document which can be used on a wide range of devices, which I'm sure you guys are most likely already aware of.

The problem with this is that it is in JavaScript. And as we all should know, JavaScript sucks balls when it comes to the simplicity it offers end users to read and alter the code.

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,



#2 Madhed   Crossbones+   -  Reputation: 3467


Posted 24 April 2012 - 08:46 AM

Every game has to deal with cheaters and hackers at some time. If you have client side code running there is no way to prevent hacking 100%. You can (and should) implement server side heuristics to detect cheaters/hackers/bots and warn/ban their accounts. That's how most games do it.

#3 Chris_F   Members   -  Reputation: 2653


Posted 24 April 2012 - 08:49 AM

The solution is to add a button that says "report user for hacking" or "vote ban".

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.

#4 Hi I'm Chris   Members   -  Reputation: 100


Posted 24 April 2012 - 08:56 AM

Aw yeah, why do I always try to make things more difficult than they should be, that would be freak'n awesome. I'mma add achievements for reporting real cheaters.

#5 Bacterius   Crossbones+   -  Reputation: 10559


Posted 24 April 2012 - 06:52 PM

Onlive naturally prevents cheating because it leaks zero undesirable information. The only information the player gets is what he sees, and while he may post-process it real time (change contrast, etc...), it does not give him any significant advantage. And the only information the player can send to the server is keyboard actions (pretty much) at a controllable rate which means he cannot gain an advantage this way either.

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

#6 bombshell93   Members   -  Reputation: 225


Posted 24 April 2012 - 07:18 PM

Client Issues:
-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.

Streaming Issues:
-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.

#7 Hi I'm Chris   Members   -  Reputation: 100


Posted 25 April 2012 - 04:50 AM

I'm going to continue the project doing the rendering client side. When and if I ever get it finished, and if it ever earns any money I might invest in a better solution than user based cheat reporting.

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.

Looks like I'm going to have to stick with some JavaScript obfuscation for now.

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.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.