8
\$\begingroup\$

Is it possible to make a networked game, where each client displays a pixel array sent to it by the server, and sends inputs back to the server? This would be much simpler to implement than using client-side prediction, but I would imagine it would be too slow. Would it be possible?

\$\endgroup\$
7
  • 1
    \$\begingroup\$ You'd be better off sending the entire world state every frame than sending up huge pixel buffers every frame. If the frame rate requirement was very low, you might be able to get away with sending the pixel buffer but it would be a waste. \$\endgroup\$ Commented Nov 29, 2014 at 16:24
  • 6
    \$\begingroup\$ There is a service called OnLive that does precisely that, for existing games. But they have powerful server hardware, insanely fast connectivity and possibly proprietary video compression algorithms to make this feasible. So it's not simpler and definitely not cheaper. The notion that something like this would be easier to implement comes from the misconception a lot of people have, that writing network code is something that's extremely hard to do, much harder than coding the rest of the game. It isn't. \$\endgroup\$
    – T. C.
    Commented Nov 30, 2014 at 0:22
  • 1
    \$\begingroup\$ Client side prediction does not become necessary due to client side rendering. Client side prediction is necessary because some games are designed for worldwide internet gameplay and due to the speed of light, the absolute minimum latency between two points on opposing side of the earth is about 133ms, which is about 8 times slower then what's needed for a 60fps game. A server side rendering would not solve the latency problem, your dumb client will still have to send the input, and wait for at least 8 frames before it can render the output. \$\endgroup\$
    – Lie Ryan
    Commented Nov 30, 2014 at 2:02
  • 1
    \$\begingroup\$ Latency is not a problem in all games. Most people probably wouldn't mind playing online Scrabble with a one-second delay. \$\endgroup\$ Commented Nov 30, 2014 at 3:18
  • 1
    \$\begingroup\$ For example Ultima Online is very close to that - server sends position and types of visible objects (not their graphics and static props, though), client only sends 2-3 bytes long input (move/attack/spell + direction/target/type etc.) \$\endgroup\$ Commented Nov 30, 2014 at 23:04

3 Answers 3

5
\$\begingroup\$

Yes it's feasible and no it's not cost effective or performant. Think about how Netflix works, it is able to service millions of customers with 1080p and even 4k streaming.

Why it will not be worthwhile to attempt what you suggest with current technology:

  1. Latency, the client will need to send the user's input to the server and wait for the visual feedback from the server, this could take as much as half a second for clients abroad. Even if it only takes 0.1 seconds, it makes the game seem sluggish an less responsive.
  2. Rendering costs: first, you would need a GPU per client(?) to render the graphics. What about game logic and physics, you will need pretty much a CPU and ~3Gig memory per user.
  3. Compression: When Netflix sends video, it's a compressed format. Compressing the video just in time would be hard, which would contribute to latency and hardware costs.

You could probably get away with running all the logic on the server side; I would never recommend running the rendering on the server side. Also, you should leverage the power of the client to respond to input (even if you correct it afterwards) before response is coming back from the service to improve fluidity.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ I disagree with using netflix as a comparison model - the video sent via netflix is already highly compressed and created using a low frame rate, designed for compression. Those techniques that are used for movies are WAY too demanding for a game to match, and thus games focus on no compression (since HDMI cables carry TONS of bandwidth relative to an internet connection), and fast frame rates (60hz is standard, vs 24 or 30 for movies/netflix). Netflix also uses caches since many users view the exact same video - not possible for different players since they need different information. \$\endgroup\$ Commented Nov 30, 2014 at 19:53
  • \$\begingroup\$ @user2813274: exactly, there're was info that Netflix uses ~120 precoded versions of the same movie with different bandwidth. \$\endgroup\$ Commented Dec 2, 2014 at 11:00
  • \$\begingroup\$ Hi @user2813274 I think I mentioned that compressing just in time isn't viable in #3 in my answer. Besides compression, rendering costs are absurdly high. There are many reasons why not to do it. I listed a few. It is not impossible technologically. It is simply absurd. \$\endgroup\$
    – AturSams
    Commented Dec 9, 2014 at 15:40
6
\$\begingroup\$

This is exactly what NVIDIA is doing with GRID. The idea is that the game runs completely on a server. The client sends their keyboard- and mouse input to the server and receives a video stream (compressed with a video codec, not uncompressed pixel arrays) from what the server is rendering.

How are they going to solve the latency problem? I don't know, but NVIDIA seems to be quite confident that they will manage to deploy a network infrastructure which will provide low enough latency to make games enjoyable. At least they seem to bet a lot of money on it.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ OnLive also does this and has for a while. \$\endgroup\$
    – Kevin Reid
    Commented Nov 29, 2014 at 17:47
  • 1
    \$\begingroup\$ @KevinReid I tried playing a racing game and a shooter on OnLive, those games were unplayable. While they have been in business for years, they still haven't delivered the promised product. \$\endgroup\$ Commented Nov 30, 2014 at 21:14
6
\$\begingroup\$

It is working already. Many games were running through telnet connection. Even now you can play NetHack and many other ASCII compatible games with 80x25 console. It means for pretty fast gameplay you should pass 2000 characters with 2-5 rate per second. That would be 10 kilobytes per second which is fine.

If you will increase window which you are looking with, you will hit the wall very fast. It is not bandwidth wall, but latency wall. With increased package you send through net, your responce will be more reluctant. It looks like "bandwidth-latency window", while increasing bandwidth, your latency rises because of caching everywhere.

Modern games can not solve this problem, and even multiplayer once, even the best - like Counter-Strike or League of Legends, have limitations which decrease quality of play if you do not have computers connected directly via LAN. Good gamers which are playing on tournaments, are different from casual ones because they are constantly playing with latency <1ms.

But network design of League of Legends have very good synchronization, so if you ask them they may point you where you can buy it or use.

Other alternative - "pass by elements", which means you are passing vector graphics via net. Many standarts is developed, but most known example is "xorg-server". I was thinking a little about writing some nice small vector graphics network sender-receiver, but in my expirience all those are suffering from "small bandwidth--latency windows". It means that best expirience can be achieved with connected directly computers.

If you want simply send image via net, there is h264 codecs with open source. FFmpeg project was working on different codecs. Many open packages exists, which are easily distinguishable by *VNC. Usually this software is used to get remote administration.

For small refresh rate games, like "hidden objects" and so on, ideally would be just implement on-demand downloading with caching. Browsers allow this, but I do not know much about writing browser games.

\$\endgroup\$
1
  • \$\begingroup\$ +1 for beating me to pointing out telnet games, which were doing this decades ago. \$\endgroup\$
    – reirab
    Commented Nov 29, 2014 at 23:46

Not the answer you're looking for? Browse other questions tagged .