Hacker News Reader

Comment by vvanders | Hacker News Reader

This stuff always seems to be just around the corner, however there's some fundamentals that are always going to keep it from working.

1. Some games just aren't built for any latency. I'm talking fighting games(1 frame windows), majority of FPS' and anything that has a reaction instead of a prediction game model. These can be made network compatible with a time-rewind gamestate resolution(which many good ones do), however they aren't drop-in.

2. The market that's interested in this tends to be much more demanding than your traditional consumer. Drop ~150ms of packets at a critical time? You've got a really frustrated customer where a game designed for network degradation will handle this gracefully.

Kudos to them for trying but you're not dealing with just technical issues, there's fundamentals of design that need to be adjusted for that can't be done without direct developer involvement.

View on HN

I don't disagree with you, but there is multi-ms latency typically in local setups as well, so certainly some latency must be tolerated by basically all the games. Carmack had an interesting point about this: http://superuser.com/questions/419070/transatlantic-ping-fas...

Sure, but as they allude to in that article local latency is consistent(dropping a frame in games is considered a cardinal sin for anything competitive).

Game design is built with these latencies into account, if people were to see the raw network updates they'd be shocked at how jerky and unplayable it is.

Generally if you're building a game to be tolerant of network latency you want a design where you're trying to be predictive than reactive. The former tolerates latency well since you're trying to guess where something will be in the future. The latter has latency in the feedback loop which is incredibly painful without some complex(time-rewind) mitigation measures.

The games you're talking about (competitive games, games where 1 frame drop is unacceptable) are a very small & niche part of the market. Look specifically at modern consoles- every console has builtin architecture that leads to a minimum input latency of 67ms. The game can add more latency (and most do), and a lot of popular TVs add more latency on top of that. Here's a database of game input latencies, it shows that even a lot of successful games have latencies of above 100ms: http://www.displaylag.com/video-game-input-lag-database/

So if you're talking about the "highly latency sensitive" players, then by definition those are only PC gamers, and only a small fraction of those players. The addressable market of gamers who tolerate 100+ ms of latency is very large, definitely large enough to build a business on top of.

So the point I was making(and a little poorly on re-reading) is that latency is fine up to a point(about 200ms) as long as it's consistent with no jitter. Input systems -> rendering fall under that category, you don't have your TV dropping frames or delivering them late. You can adjust for a constant latency and "lead" it, which is why game design that's predictive works so well in multiplayer.

Latency sensitive players are actually large part of the market, any action based multiplayer game will fall under that category, which includes FPS games which make up a large portion of game revenue. About 10% of the market makes 90% of the revenue so missing certain use cases excludes a large chunk.

The normal packet jitter on my connection is between 2 and 20 milliseconds. You could stream games to me with a fixed network delay of 120ms (plus 80ms for input/rendering) and there wouldn't be dropped or late frames.

> normal packet jitter

What's the 99th percentile for that? How about packet-loss?

None of this is new stuff in gamedev, we've been build action games successfully since the days of 28.8 modems and 200ms pings.

Maybe that makes me a bit of an entrenched player(which is a poor position to argue on HN) but I've yet to see anything fundamental in these technologies that will address the latency issues in the same way you can with an interpolated client-side simulation.

Checking this ping I have open, the 99th percentile jitter is less than 20ms, and packet loss is about .2%

It doesn't have to be as good, it just has to reach a certain level. And for a lot of games it works fine to have a bit of lead time on controls.

I'm working on a game with my own GL engine, and i found locally even <5ms jitter is noticable, if only because the jitter occasionally causes a "frame time overflow", leading to a skipped frame or a frame being displayed twice.

No, no, that's not what I'm saying.

You set up a fixed delay, that is large enough to contain your jitter. It doesn't matter if one packet takes 80ms and the next takes 105ms when you don't display it until the 120ms mark. There will be no visible jitter.

One thing you have to take into account is that the vast majority of modern console gamers have never experienced PC gaming @ 120hz on a CRT connected to a good old 15-pin VGA connector...

If you were to take a console gamer that was just fine playing a game at 100ms+ latency, and let them play the same game, while magically removing 95% of the latency, they would probably be amazed, and never want to go back to their previous setup with horrendous latency.

These are good points, but I'd like to add that unless someone is dealing with extreme latency (ie: > 150~200ms), jitter is typically a bigger problem.

If you have a consistent latency of, say, 100ms, you can account for that. People adjust. They can plan for being a little slower to react.

On the other hand, if you're playing a shooter and you're constantly bouncing from 20ms to 100ms, you're likely going to feel pretty unhappy. You'll be forced to constantly adjust for actions happening slightly too fast or too slow depending on the direction/severity of the jitter.

You know what, there can be long and drawn-out arguments about this, or we test it.

I've been wanting to give this one a real try: http://store.steampowered.com/app/369530/

Sadly my laptop sucks too much for it. It can run it at ~40-60 fps, but i really feel the input latency already.

I'll try and see what it feels like with their AWS AMI, playing on a 25mbit line from hannover, to an EC2 instance in Frankfurt.

Edit: Turns out there's an issue with my laptop hardware, so results from me will be delayed until a fix can be found.

Networking trends in computers operate in a cyclical pattern. At some point, and probably soon since we're now overdue, we will be talking about 'private clouds' or 'home servers' and houses having one expensive, modular computer and a lot of tablets and televisions being driven off of it.

In that world, this sort of technology could be adapted to shipping video a short distance, say less than 10ms away. As a platform instead of a service these sorts of things might work as well as a port of the game to your platform of choice.

You throw your playstation 5 into a closet in the basement and you can play games anywhere in the house, or maybe at your friend's house a couple blocks over.

Isn't this already happening? I stream games to devices around my house from my office where I have my desktop, and a small Debian server as a media server, mumble hosting and the occasional chivalry or CoD4 server with friends. I get that the server has a bit of a barrier for entry, but the game streaming, that's just Steam. Granted you need some kind of i386 or x86_64 device at the streaming end that can install steam.

Oh my, yes. I had forgotten that Steam streaming was live now.

But that's just Steam. Expand that to everything in a couple of years, and you're there. Maybe Valve could get into that business themselves.

Yeah, it's technically here with media servers too but the barrier for entry is still higher than your average Joe will bear. The idea of an out-of-the-box solution has been tossed around here a few times I think; a little server that manages networking, storage and other services for your home. One that just works after a simple gui walkthrough for setup, and doesn't make us so dependent on cloud services that exist to sell advertising space.

I don't disagree completely. A certain subset of gamers (the hardware enthusiasts, pros) will NEVER use something like this.

But certainly over wired LAN it does offer near native performance for most games, past the threshold where many gamers would even be aware they were playing remotely. The real questions are: how good will the internet get, and how quickly will it get there?

While it's true that quite a few games (especially multiplayer/competitive games) have strict latency requirements, those are far from being all the games out there.

I think this model has many big features that makes it a worthy, even if it's not for everyone. Here's a few obvious ones:

- No download or even load time, jump straight in the game - Can play on almost any device, even mobile - Online co-op/multiplayer for local only games - Easy to spectate friends (don't need good upload speed)

So if you are a gamer who plays a moba/fps every single day, then sure, having your own rig is nice. But if you're someone who likes playing the latest single player story game, or some indie games, but don't want to invest into a gaming PC/console every few years, this model could be very useful.

1) You can simply have vector clocks, and resolve differences like anything else. Most of the time the game's prediction would be correct. Sometimes there would be a small adjustment.

2) Yes, anything real-time is like this.

Prediction requires full game emulation on client, defeating the purpose of streaming.

It doesn't defeat the purpose of streaming. You don't have to emulate everything in the game, just everything in your vicinity that can possibly affect what you see and hear.

That is how client-server games already work. The server has the full world state, and each client has a subset necessary to render the world for that player. Ideally the absolute minimum subset, so as to reduce the potential for cheating (wallhacks, etc.).

The purpose of streaming is to remove the need for the simulation and rendering at all. The client is a dumb terminal that just renders frames and records input.

The moment you start making the client smart again — making it aware of a subset of the world state, making it do its own rendering based on the input — you've just reinvented current client-server gaming.

Maybe with remote rendering though. Which has advantages already, such as ease of spectating, lack of multi-GB texture downloads.

You still get to run a physics model and game logic though and that is a non-neglible part of modern games.

That would be extermely complicated and would require additional support from every game. Streaming right now takes every frame, compresses it and forwards it, as simple as that and works for everything.

The cost you are talking about is only for physics and logic in multiplayer games, it doesn't apply to single player games. And even then it is negligible compared to the biggest cost in gaming: rendering. Prediction requires rendering being done on the client, which requires a hefty video card and defeating the purpose of streaming.

Except you don't have access to game state in these cases so there's no adjustment that can be made.

You can only move forward in the frames you display. You can't walk back in time to evaluate a player's action in relation to their latency and then reconcile game state with all other clients.

Yes you can. When the server sends the "official" record of moves made, if the client detects any discrepancy with expected results, it resets the game to a slightly earlier time and replays the "real" moves to reach the current point. All this is done instantaneously, and only at the end is the interface refreshed.

> resets the game to a slightly earlier time and replays the "real" moves to reach the current point.

That's exactly what properly engineered network games do. However we're talking about video streaming here, in which you don't have access to any game state. It's not possible to do without the developer going in and adding specific feature support for your streaming service.

GC of vector clocks is a major issue for highly concurrent systems.

Yes you are right, but in this case we have a central server farm AND clients can time out. The server can drop the vector clock of all connected clients for tick X once all clents receive tick X updates or time out for tick X.

Can you go into more detail with (1)? It's unclear to me how vector clocks could help with, say, a fast-paced FPS. The "small adjustment" might often be bringing a dead character back to life, if his bullet packet's vector clock claims he shot first. (Hack potential, too...)

There is always hack potential. All the server can do is make sure that the claimed move is legal (eg fits the rules of chess) and realistic (check a string of inputs to see if they probably have been made by a human).

As for the adjustment... Yes bringing a character back to life after a momentary error, in one place on the map, as seen by one person, is a small adjustment that happens rarely.

Reply on news.ycombinator.com