Jump to content

  • Log In with Google      Sign In   
  • Create Account


Hard to stream the game? and what cheats it prevent?


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
5 replies to this topic

#1 glhf   Banned   -  Reputation: -585

Like
0Likes
Like

Posted 14 July 2012 - 09:48 AM

I heard that streaming your game through onlive is a good way to prevent some forms of cheating.
Do you have to have your game only on onlive then or can you still have your game on steam and when they launch the game on steam its streamed thru onlive?
Also i would assume onlive takes a nice fee? Is it hard to create your own stream for your game?
and what cheats does streaming the game prevent exactly?

Sponsor:

#2 Hodgman   Moderators   -  Reputation: 28422

Like
1Likes
Like

Posted 14 July 2012 - 10:18 AM

1) Do you have to have your game only on onlive then or can you still have your game on steam and when they launch the game on steam its streamed thru onlive? Also i would assume onlive takes a nice fee?
2) Is it hard to create your own stream for your game?
3) and what cheats does streaming the game prevent exactly?

1) They're both competing online "digital stores", so I doubt they'd want to cooperate closely like that. You might be able to strike a deal with them like that, but you'd have to contact them both, and they'd both want to take a cut of your revenue obviously. What's the point of selling on steam if you're relying on OnLive anyway?
2) You need to rent enough dedicated servers to run enough instances of your game for your customers to be able to play it. That could be something like $100/mo per concurrent customer... You also need these servers to be distributed around the world so they're geographically close to your customers... and then build the actual video encoder/decoder and input streaming service, so that you can get the image/sound from your server-farms to the client in ~80ms (or whatever it is that OnLive claims to do). I have no idea how OnLive has managed to make this into a profitable business... Maybe they haven't -- maybe they're losing money and hoping to be bought out by Microsoft before they go bankrupt?
3) Assuming people can't hack into yours/OnLive's dedicated servers, then it stops all cheats that involve modifying the code/assets/network-packets. The only thing it doesn't stop is meta-gaming (e.g. sharing info outside of the game), input scripting (e.g. on a guitar hero game, I could record the winning inputs and just play them back), and some bots (most kinds of bots would become insanely difficult, as they'd need to be able to "see" the video stream, which requires the use of slow machine-intelligence/computer-vision algorithms).

Edited by Hodgman, 14 July 2012 - 10:37 AM.


#3 glhf   Banned   -  Reputation: -585

Like
0Likes
Like

Posted 14 July 2012 - 11:10 AM

1) Do you have to have your game only on onlive then or can you still have your game on steam and when they launch the game on steam its streamed thru onlive? Also i would assume onlive takes a nice fee?
2) Is it hard to create your own stream for your game?
3) and what cheats does streaming the game prevent exactly?

1) They're both competing online "digital stores", so I doubt they'd want to cooperate closely like that. You might be able to strike a deal with them like that, but you'd have to contact them both, and they'd both want to take a cut of your revenue obviously. What's the point of selling on steam if you're relying on OnLive anyway?
2) You need to rent enough dedicated servers to run enough instances of your game for your customers to be able to play it. That could be something like $100/mo per concurrent customer... You also need these servers to be distributed around the world so they're geographically close to your customers... and then build the actual video encoder/decoder and input streaming service, so that you can get the image/sound from your server-farms to the client in ~80ms (or whatever it is that OnLive claims to do). I have no idea how OnLive has managed to make this into a profitable business... Maybe they haven't -- maybe they're losing money and hoping to be bought out by Microsoft before they go bankrupt?
3) Assuming people can't hack into yours/OnLive's dedicated servers, then it stops all cheats that involve modifying the code/assets/network-packets. The only thing it doesn't stop is meta-gaming (e.g. sharing info outside of the game), input scripting (e.g. on a guitar hero game, I could record the winning inputs and just play them back), and some bots (most kinds of bots would become insanely difficult, as they'd need to be able to "see" the video stream, which requires the use of slow machine-intelligence/computer-vision algorithms).


Wow, streaming games must be the future in that case! Completely stopping cheaters! Which means those big games made by big studios like blizzard etc can start creating games that aren't focused on completely removing incentive for cheating.. no more auto target etc.. this would be huuuuuge :D :D :D !!!

But I really would like to sell it on steam because that's like the most popular platform.. and has a lot of good marketing techniques with special offers and all that stuff.
I never really even heard about onlive and im a hardcore gamer, and now that i have heard of it i still wouldnt want to pay that monthly fee for that game.. I dont think many would tbh because there's so many players in the f2p market or games that are a cheap one time purchase and can play infinitely, or maybe even save up money to buy an expensive game that will last forever... for example: tf2, diablo, lol, cod etc.
I just think steam could make you million times more money than onlive... but woud be so great being able to make a game without worrying about cheaters with onlive.

Probably will have to continue making games where its possible to cheat but removing incentive for it until streaming games is more popular..

#4 hplus0603   Moderators   -  Reputation: 5067

Like
0Likes
Like

Posted 14 July 2012 - 01:08 PM

OnLive lets you completely manage all the computation, and the user just sees the graphics and provides inputs. This is like a dream to a content creator and competitive game operator. The best you could do as a cheater would be to emulate a very good player: do image recognition on the screen, and send inputs to aim and shoot -- basically, an aimbot that's very hard to distinguish from a really skilled player. Map hacks, wall hacks, speed hacks, radar hacks, and asset ripping would all to away as threats, at least as long as you can trust the people who run the server-side render farm.
Additional benefits touted by OnLive include being able to target just one or two hardware configurations, so driver problems are much more manageable.

There are several draw-backs to the technology, though:
- Latency between control and reaction. If you're in a big city near a OnLive data center, and have a good internet connection, this can be measured in 3-6 frames of latency. This is in addition to the latency between your decoding device and the actual screen -- you may have heard of "game lag" making certain games hard to play on certain TVs.
- Technical compatibility. OnLive is known to not work well with "marginal" network connections -- which includes WiFi, 3G/4G, Cell Phone, Satellite broadband, etc.
- Limited resolution. OnLive started out doing "SD" resolution (640x480 or 800x600 IIRC) but has now stepped up the resolution a little bit -- 1024x576 or 1280x720 if I read their documentation right.
- Compression artifacts. You simply can't send a 60 Hz video stream at high definition and 6.1 sound stream over a 2 Mbit connection without degradation in quality.
- Market acceptance. Players like having their own machine that they can control the experience through. Paying a subscription just to be able to pay for games is a hard sell.

Some of these (acceptance, resolution) can be fixed with time; others are kind-of hard-coded into the fabric of the solution (latency, artifacts.)

Regarding "getting your own stream":
The OnLive service look like a reasonably regular PC with a mid-line CPU and graphics card. If you can play your game on a PC with GamePad input, it's apparently not hard to convert it to work with the OnLive system.
If you want to sign up as an OnLive developer, they have a contact form: https://www.onlive.com/contact#developer
If you want to set up a similar system yourself, then you need to figure out how to run many instances of the same game on a server that you manage, how to compress the frame buffer and sound in real time, how to deliver that stream to users who can decode and play it, and how to send control inputs back to your server. I know of no solution that does this "out of the box" with low enough latency to be useful. All the "live video" broadcasting systems I've seen introduce unacceptable latency. Then again, many gamers clain that OnLive also introduces unacceptable latency for competitive games like Counter-Strike or Unreal Tournament.
enum Bool { True, False, FileNotFound };

#5 glhf   Banned   -  Reputation: -585

Like
0Likes
Like

Posted 14 July 2012 - 03:33 PM

OnLive lets you completely manage all the computation, and the user just sees the graphics and provides inputs. This is like a dream to a content creator and competitive game operator. The best you could do as a cheater would be to emulate a very good player: do image recognition on the screen, and send inputs to aim and shoot -- basically, an aimbot that's very hard to distinguish from a really skilled player. Map hacks, wall hacks, speed hacks, radar hacks, and asset ripping would all to away as threats, at least as long as you can trust the people who run the server-side render farm.
Additional benefits touted by OnLive include being able to target just one or two hardware configurations, so driver problems are much more manageable.

There are several draw-backs to the technology, though:
- Latency between control and reaction. If you're in a big city near a OnLive data center, and have a good internet connection, this can be measured in 3-6 frames of latency. This is in addition to the latency between your decoding device and the actual screen -- you may have heard of "game lag" making certain games hard to play on certain TVs.
- Technical compatibility. OnLive is known to not work well with "marginal" network connections -- which includes WiFi, 3G/4G, Cell Phone, Satellite broadband, etc.
- Limited resolution. OnLive started out doing "SD" resolution (640x480 or 800x600 IIRC) but has now stepped up the resolution a little bit -- 1024x576 or 1280x720 if I read their documentation right.
- Compression artifacts. You simply can't send a 60 Hz video stream at high definition and 6.1 sound stream over a 2 Mbit connection without degradation in quality.
- Market acceptance. Players like having their own machine that they can control the experience through. Paying a subscription just to be able to pay for games is a hard sell.

Some of these (acceptance, resolution) can be fixed with time; others are kind-of hard-coded into the fabric of the solution (latency, artifacts.)

Regarding "getting your own stream":
The OnLive service look like a reasonably regular PC with a mid-line CPU and graphics card. If you can play your game on a PC with GamePad input, it's apparently not hard to convert it to work with the OnLive system.
If you want to sign up as an OnLive developer, they have a contact form: https://www.onlive.c...ntact#developer
If you want to set up a similar system yourself, then you need to figure out how to run many instances of the same game on a server that you manage, how to compress the frame buffer and sound in real time, how to deliver that stream to users who can decode and play it, and how to send control inputs back to your server. I know of no solution that does this "out of the box" with low enough latency to be useful. All the "live video" broadcasting systems I've seen introduce unacceptable latency. Then again, many gamers clain that OnLive also introduces unacceptable latency for competitive games like Counter-Strike or Unreal Tournament.


I'm not sure how much 3-6 extra frames of latency is?
I know what ping is and that a good ping is less than 60 ping IMHO.
Bad ping is above 80-120 and anything above that becomes a bit unplayable.

But it depends a lot on the type of combat system and mechanics too..
If you're interested in going further into this offtopic i have made a thread about it already that would love more input:
http://www.gamedev.net/topic/623162-should-you-design-combat-mechanics-so-it-expects-players-to-have-50-or-100-ping/
Which is about solutions to make it more playable even if players have bad ping.

Also another thing is that you can make games that dont require too precise timing..
But yeah.. I'm really not sure how much extra delay we're talking about with 3-6 extra frames latency?

#6 Bacterius   Crossbones+   -  Reputation: 8277

Like
0Likes
Like

Posted 15 July 2012 - 04:54 AM

The facts are that current technology is not quite up to the task of streaming that kind of data to any significant amount of users. It might be ok if you live a few km away from the server, it might even be decent if you are in the US with a reasonably good internet connection, with little network congestion. For anyone else in the world, it simply does not work. (of course, it depends on the game - different types of games require more or less latency to provide acceptable gameplay, for example for a first-person-shooter you usually cannot deal with more than 400ms of latency whereas other games like casual mmo's could still be playable with a couple seconds of latency). Bandwidth is also a problem, many ISP's are currently not able to sustain many of their users streaming Netflix videos at the same time at maximum speed, you can only stream so much before clogging up the cables. So if OnLive takes off, it will still have "peak times" where you will be unable to play in the evenings because everyone else is busy streaming (as well as contributing to the problem itself by being a streaming service too)

It's a great idea in theory, but at its heart it is still a brute force solution - it will be interesting to see how OnLive works around them.

I know what ping is and that a good ping is less than 60 ping IMHO.
Bad ping is above 80-120 and anything above that becomes a bit unplayable.

I'm lucky to get 60ms ping to australian servers (I'm in new zealand). Yet when I connect to USA servers (which puts me well within your "unplayable" zone at 250-350ms) I can still kick butt play relatively well (humans are actually pretty good at adjusting to predictable latency). It depends on the game and on the latency of the opponents you are facing. I certainly wouldn't be able to play a twitch reaction-based game at 250ms like an ultra-fast-paced first person shooter as well as I would with a 30ms ping. However, I could probably play a karaoke game - think guitar hero - equally well (or almost) by anticipating the delay and negating it. Latency can be defeated by being creative with your game mechanics, but it certainly is a problem most of the time.

I'm not sure how much 3-6 extra frames of latency is?

Assuming your game has a 60Hz framerate, this corresponds to a latency of 50 to 100 milliseconds. But the issue is that the user needs to have visual feedback quickly after he presses a key or moves the mouse, or the game will appear to be unresponsive (effectively, "lagging" behind). This kind of delay is actually very noticeable, especially when it is compounded over many different actions. When the player hits the mouse button to shoot, he expects the gun to shoot now, not three frames (i.e. 50 milliseconds) later, since the target will probably have moved or killed him by then. The player can always attempt to adjust to the delay and lead his target to compensate, but he then needs to predict the target's path (usually a constant velocity, straight-line trajectory), which is a pretty good estimation for small delays but gets increasingly worse as the latency increases.

If you're interested in going further into this offtopic i have made a thread about it already that would love more input:
http://www.gamedev.n...50-or-100-ping/

This thread is a bit old, I'm not sure if it should be raised from the grave. Perhaps creating a new one with a broader scope would be better?

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





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.



PARTNERS