> Many game designs require that all players have up-to-date information at all times

Related to the early-1990's time period, after the Exxon Valdez oil spill I wondered, how on earth can we not have up-to-the-minute location info on every oil tanker (for multiple sources of warning). Based similarly on only small changes to projected courses needing to be distributed.

I read Carlo Rovelli's book The Order of Time about time, relativity, etc. One of the striking things - that I couldn't fully follow, frankly - was something along the lines of there's a limited cone of spacetime for which you can even tell what relative order things happen in. That there's not a valid concept of "simultaneity" for places far, far, far apart due to speed of light, time dilation, whatnot.

So: just design a game where your players are so far apart that the speed of light is the mechanism that guarantees no interactions between some players. ;)

But more relevantly, this seems to be one of those problems that's been hampered by the slowing of single-core performance. Though disk and memory and network keep getting faster, so I wonder what the absolute limit if a game really focused on processing single state globally above all else would be. Maybe even at high bandwidth the latency to thousands of players wouldn't be good enough to get all the updates out?

> just design a game where your players are so far apart that the speed of light is the mechanism that guarantees no interactions between some players. ;)

EVE Online :)

Honestly it's one thing that almost convinced me the universe is really a version of the Matrix - like an ant farm running in some alien bedroom.

For a single person in VR, you can track 6 positions, 3 with orientations too, using about 36 bytes. Add some more state and let's say 50 bytes per update. If you update the hundred most visible people at 60fps, and the rest at 10fps, then you could have 3000 people walking around the same area with about 14Mbps of bandwidth.

That's quite doable!

Gunplay adds more data for bullets but also you probably don't need such detailed positioning, and you can get away with sending the positions of only the nearby players and bullets.

Your math is wrong and 6 positions and 3 orientations is not enough to communicate an entire player's skeleton. It's important to send skeletons that way each player only has to solve for bone positions and orientations for just themselves instead of for thousands of players. You will also want to send weights for blenishapes for face tracking. Another thing you left out was the audio data for voice chat.

> Your math is wrong

You can't just say that. Show your work.

4 bytes can give you 2mm resolution within a 2.5x3.5x3.5 meter box. 1250x1750x1750 < 2^32

4 bytes can also give you orientation within 1/6 of a degree. ~42000 square degrees on the surface of a circle x 360 for rotation x 6^3 < 2^32

This could be slightly more optimal but it's a good round baseline. Improving it is a matter of a handful of bits.

> It's important to send skeletons that way each player only has to solve for bone positions and orientations for just themselves instead of for thousands of players.

How long does it take to calculate? Modern CPUs have a lot of cores, and GPUs can do so much math.

> Another thing you left out was the audio data for voice chat.

I did, because you don't need to hear 3000 people. And the server could merge large groups of further-away people into single tracks if you really wanted it. A hundred Opus tracks can fit into 2-3Mbps.

It's incumbent upon you to show your work first, before telling somebody else to. And if really helps if your math and understanding of bandwidth and latency isn't wrong, and even more if you can show you have some actual first hand experience in the field.

I don't think your numbers add up either, and you're wildly underestimating the difficulty and complexity of the problem. Which real time multi player VR simulations have you shipped?

Here's my work, an application called "Pantomime" that I developed and shipped 7 years ago, which runs over local wifi. And my work that I'm showing you tells me that merely 2mm translational resolution and 1/6 degree rotational resolution would totally ruin the physics simulation and sense of immersion and realism:

https://www.youtube.com/watch?v=NEeFdDluEJ8

The person giving the Pantomime demo is my colleague David Levitt, who used to work with Chuck Blanchard and Jaron Lanier at VPL, and whose definition of the three goals of "good" VR I've written about before:

https://news.ycombinator.com/item?id=8023893

DonHopkins on July 12, 2014 | parent | context | favorite | on: What I mean when I say "I think VR is bad news"

Here are three goals for "good VR" from David Levitt, with whom I work at Pantomime Corporation, and who used to work on VR at VPL:

http://pantomimecorp.com/pantomime-technology/virtual-realit...

When Pantomime co-founder Levitt was a research scientist and product manager with VPL Research, the inventors of virtual reality, they had three prerequisites for a VR system:

1) a way to reach in, in 3D

2) shared reality — support for multiple users and viewpoints

3) graphically and physically realistic worlds

VPL offered a DataGlove to provide 3D input, while its flagship Reality Built for Two VR product offered networked multi-person worlds. Expensive graphics computers and custom hardware brought the full 1992 price to $500,000, which only a few huge corporations could afford.

When Dr. Levitt joined VPL, thanks to an amazing infrastructure by lead VPL engineer Chuck Blanchard, he added realistic gravity, collisions, and throwing a ball into the VR system for physical realism.

But two decades later, the public and technologists have become so impatient that the new systems calling themselves VR have punted even on the core original criteria.

Head-mounted systems like the Oculus Rift offer no way to reach in. In demos, visitors twiddle a 1980s style game joystick. And users don’t natively network — in an Oculus demonstration you don’t see the other users in the VR world — not even the other players sitting alongside you in the demo.

http://pantomimecorp.com/2014/06/10/facebook-vp-to-pantomime...

David Levitt: "I work in Virtual Reality, and everyone’s wondering what you can say about your acquisition of Oculus VR. In particular, I’ve had demos of it: I could look around but I couldn’t reach in. Do you have solutions for that that you can talk about?"

Jay Parikh: “You can’t interact with anything. These are big, hard problems … what you do with your hands, because you can’t do anything with your hands — or it’s hard to be using a controller when you can’t see your hands and you have the goggles on — these are problems we have to solve in a good and seamless way.”

More on the VPL DataGlove:

http://www.britannica.com/EBchecked/topic/630181/virtual-rea...

[...]

> [My software] runs smoothly over local WiFi, but terribly over long haul internet.

I'm pretty sure that this is the core of your confusion. We're talking about software that handles ~3000 simultaneous participants. You're not going to find a userbase that large all running on a LAN (wired or not) outside of a convention hall or research facility. So, we're necessarily talking about networked software that users run on their (often abysmally designed) home networks and connect to other players over their (frequently terrible) Internet connections.

I expect that the tolerances you've specced out are absolutely correct for simulation of the local player. They may have even been reasonable for remote players on a LAN. However, those tolerances are overkill when you're designing a system that's designed for use by the general public on the greater Internet. This means that it _must_ do latency compensation for 100->500ms of potentially-highly-variable RTTs, deal with 1%+ packet loss, and also -if it has any even-vaguely-serious adversarial gaming components- have a server component that handles anti-cheat by way of player input validation.

There's certainly value in the high-fidelity VR software that your company wrote. However, the fact that it worked poorly over the Greater Internet suggests that you folks either didn't have experience with writing mass-market networked video games, or that your focus was exclusively on a high-fidelity simulator that would never have to paper over the messes that you get on the regular from the home Internet connections of your typical gamers. (As one example, because of the general shittiness and unpredictability of the Internet, it's fairly common practice in networked video games for all clients to run their physics simulation locally. Clients get notifications of events that will affect objects in the simulation, and then they slam those events into their local sim and play the results locally. For events that might matter to all players in the game, -say some physics object gets bounced around that might block pathing- the server will do a comparatively low-fi simulation of that and validate clients' attempts to move into or through the blocked area.)

> It's incumbent upon you to show your work first, before demanding somebody else do it first.

My math is right next next to that demand!

> My work that I'm showing you taught me that merely 2mm translational resolution and 1/6 degree rotational resolution would totally ruin the physics simulation and sense of immersion and realism

That's a much much smaller workspace, so at that scale it would be a fraction of a millimeter. I don't see why the degrees aren't enough though; that tablet looks to me like there's a small amount of jitter but enough to make it not matter.

But if you want to 10x the precision of everything I said, that's only 11 more bytes.

> Representing user input and object rotations and positions as precise floating point numbers is absolutely necessary when there is a physics simulation involved (see "good VR" prerequisite #3 below, "graphically and physically realistic worlds").

I can understand that, but even before worrying about diminishing returns, you can only throw so many bits at a bad input:

> It was determined that the translational accuracy of the [Oculus Rift S] was 1.66 ± 0.74 mm for the head-mounted display and 4.36 ± 2.91 mm for the controller, and the rotational accuracy of the system was 0.34 ± 0.38° for the HMD and 1.13 ± 1.23° for the controller.

> Kreylos estimated the precision of Lighthouse tracking to be around RMS 1.5mm and the accuracy around RMS 1.9mm.

So you could fit the full precision of those devices into 36-40 bytes, and that's before we even consider that most people are only tracking 3 points, not 6. Even with some extra precision, I already tossed on some more bytes and it doesn't really matter in the end whether it's 14Mbps or 20Mbps.

> But two decades later, the public and technologists have become so impatient that the new systems calling themselves VR have punted even on the core original criteria.

> Head-mounted systems like the Oculus Rift offer no way to reach in. In demos, visitors twiddle a 1980s style game joystick. And users don’t natively network — in an Oculus demonstration you don’t see the other users in the VR world — not even the other players sitting alongside you in the demo.

That's a real shame, and worth keeping in mind, but I was talking about taking the kind of VR immersion that is currently widely deployed and adding more people.

I've learned so much from your disagreement. :) Thanks for sharing all of this information. Seriously

bandwidth is only one dimension. what about latency for example?

What about it? We're talking about how many players can go into an online game. Latency doesn't change as you tweak that number, only bandwidth.

>Latency doesn't change as you tweak that number, only bandwidth.

Uuuh, actually it does.

https://updater.com/guides/bandwidth-vs-latency

>Comparing bandwidth and latency

>Bandwidth is the amount of data your connection can handle, whereas latency refers to delays that impact how quickly data gets to your devices. Even though they’re very different, they are related in one important way: If you have less bandwidth, you may have more latency. This is because if your internet connection can only transmit a certain amount of data per second, such as 5 megabits, files that are larger than that will take longer to get to your browser.

>Here’s another way of looking at it: While bandwidth affects latency, latency doesn’t affect bandwidth. Returning to the freeway example, the width of the road itself is like your bandwidth, and the cars are like the data that has to travel from one point to another. If the police set up a checkpoint on the freeway, it doesn’t matter how many lanes it has. It’s going to take longer for the cars to reach their destination.

>It’s the same with bandwidth and latency in your internet connection. No matter how many megabits your ISP allows you to download per second, if the data has to pause for a security inspection or take detours through multiple locations, you’re going to experience latency.

> file transfer paragraph

It's a continuous stream of data. If you want to conceptualize it as "files", then you can consider each "file" as either sub-kilobyte, or sub-frame-length. With the former, there is exactly zero change on latency, and with the latter there is a handful of milliseconds.

In other words, bandwidth only affects the portion of latency between receiving the first byte and receiving the last byte. In this situation that's so tiny it's negligible. The latency to the first byte is what matters, and that number is basically independent of the bandwidth.

> freeway paragraph, last paragraph

If the police set up a "checkpoint" then that is directly going to delay packets. Obviously that changes latency. That has nothing to do with bandwidth though. The same with "data has to pause for a security inspection or take detours through multiple locations". I'm not sure why you quoted this part.

But let's consider a freeway that goes down to one lane (or alternatively that we 10x the number of cars we have), which is a bandwidth change. Well, we're sending a fixed amount of cars per second down the freeway. If they can't fit into one lane, then the whole thing will immediately back up and we'll lose connection entirely. It doesn't affect latency, it drops the connection.

Thanks for the explanation.