Game Engine: Improved shotgun net traffic

NapalmEnima · 2011-10-07, 04:02 PM

There are several ways you could tell the server and those around you trajectories of all the shotgun pellets a player just spawned into the game world.

1) Tell the world about each pellet individually
2) Tell the world about the central vector of the spread, and an RNG seed for a vector generation algorithm or a fixed pattern ID. vector, location, time, and a few bits. 3 bits would give you 8 different possibilities, fer instance.

With method #1, the number of pellets fired dictates the amount of web traffic. Developers are discouraged from using large numbers of pellets due to traffic concerns.

With method #2, the server already knows which weapon you have equipped ergo how many pellets are involved. Everyone who can see you can also see you're weapon, so all the clients have to know it too. Point of origin, direction, and a seed/pattern ID, vs N points of origin, N directions. (probably each 3 floats, maybe doubles).

So for ten pellets you've got either 60 32-bit values, or 6 32-bit values and an extra byte on the outside.

I attribute this idea to two origins.

1) There's an article in Game Programming Gems 1 about how the original game Elite for the Apple ][ (which I loved) was able to have such a Huge Universe on machines with 32kb of memory. You share an algorithm and a random number seed, and you can generate the same information ("universe" in this case) consistently. Given an N-bit value, and a big pile of logic, you can generate patently recockulous amounts of data.

Recursive, or otherwise. Take the mandelbrot set for example. Giant shit-tons (infinite really) of information generated from a relatively small bit of math.

2) Net Trek. When you fire a photon torpedo, it's assigned one of 8 different wobble patterns. 2D vector, 2D location, 3 bits for a wobble pattern ID, maybe an event time. Much cheaper than updating all the torpedo locations in real time to all your clients. Once the clients and server all have the same info, they can all determine where that torpedo is at any given time.

You could also apply this sort of logic to high RoF weapons. Say each client tells the server about weapons fire every tenth of a second. You tell the server the exact local timestamp of the start & end times, the start and end directions and locations of the weapon muzzle over the course of that 0.1 seconds, and an RNG seed.

Now your RoF has no bearing on your network load. 10 or 1000 rounds per second, it's all the same amount of network traffic. You still have to do more hit detection, but the network traffic is unaffected (if a bit higher for sub-10-rounds-per-second weapons).

CoF bloom is deterministic for a given combination of weapon, attachments, and certifications. Barrel climb can again be generated "randomly-but-identical" with same RNG seed/algorithm.

Given the CoF/barrel jumpiness of such high RoF weapons, turning the player's curved directional path into a connect-the-dots-sampled-10-times-per-second isn't likely to be noticed on the client side. You could also include x/y/z directional "eccentricity" to better approximate the client's actual movement.

But I suspect the state-updates-every-10th-of-a-second thing isn't how the net traffic will work. Or maybe it will... this is an MMO FPS after all. A certain loss of precision is to be expected when dealing with a couple hundred players at a time. Half of "looking right" in a video game is knowing how to fake the expensive parts, and the parts people won't notice.

At 1000 rounds per second with a wide cone of fire, I don't think anyone will notice if their game client silently goes behind the scenes to ****** the bullet origins/directions to PRECISELY match what the server and other clients know about.

EDIT:

You actually don't need to give the current muzzle position as part of the weapon data. You're already sending the location and facing of the character as part of their current state.

Furthermore, why send the initial ray at all? You can just generate that from your RNG seed too. All you need is a precise time stamp and a seed value.

And the full auto data need not include the start & end points. The start point of one update will always be the end point of the next (or versa visa depending on how you look at it). And again, your current facing is part of the data you're already sending to the server. All you really need are precise trigger up and down times. Everything else can be deduced.

That leaves a lot of room for floating point errors and the like. Errors that can be different on different processors, and they certainly add up. You'd need pretty frequent Full Updates. Say every half second. And you'd want to update 1/5 of the players every 1/10th of a second. The server might chop it up even finer than that to smooth out its net traffic output. A big spike stuffed into the queue every tenth of a second could mean that someone could get their data 0.09 seconds late simply because their packets were waiting to be sent off for A While. Might as well try to smooth that out and give them more up-to-date info.

This technique makes it impossible for you to hack your RoF. Everyone Else except you would have a different (correct) model of your firing rate. Both the giver and receiver could be asked if a given shot hit. If they disagree, you put both of them under some scrutiny. Packet loss and such will inevitably cause the occasional disagreement, but folks who are consistently disagreeing with their targets (or their attackers) need a flogging.

That would make a great way to pick out which bullets get evaluated by the server. Just the disagreements.

This technique makes it impossible to shoot anything you're not looking at. Aim-bots would make your whole character twitch around instead of shooting people behind you.

Down Sides: In order to correctly determine the current CoF/RoF/etc, the client has to know every player's cert tree (at least the portions that affect the gear they're currently using), and every character's load out. You need to know some/all of the loadout anyway to draw them properly, and I suppose a player's certs boils down to a bunch of yes/no values (bits). Still, calculating it all for each player could... eh... it won't really be all that bad actually. When you first learn about a players certs/loadout, you calculate all the relevant values once and store them. That's still quite a bit of data per character. You could end up with Many Kb of data for each player... but I guess that's not such a big deal compared to textures and suchlike.

You might have other ways of communicating weapon fire when that client doesn't (yet) know about that particular character. It could be a general location (rounded to the nearest 5 meters or some such) and an audio ID if you have no chance of seeing it. It could be all the relevant parameters (time, location, direction, CoF/kick info, etc) plus the seed with no character info attached to it.

The good news: Character info (loadout and certs) need not come from the same machine as the game server. A client on entering a continent might get a list of players from the game server, then query the General Player Info server for certs and possibly loadout (though that would change more rapidly). You could probably share a character info server among several different "world" servers, given the relatively low data demand.

Clients also don't need to know what a given character is training or when they started, just when they'll be finished so that client can refresh the player's info.

dobs · 2011-10-07, 07:27 PM

i guess they already used algorithms like that for ps1. no way they could send all shots through the pipe. But i guess instead of calculating it from the direction the weapon looks it would get alot of jittering because of movement prediction.
Using a Packet like "High RoF Weapon starts shooting + Direction" then packets with "High Rof Weapon continues/stops fire + direction update" would be more appropriate. + Send all the single shots that actually hit something near you.

Traak · 2011-10-07, 11:55 PM

Interesting info. Funny how a shotgun shot in PS takes more coding expertise than entire old games probably took.

dobs · 2011-10-08, 07:43 AM

Movement prediction is a *****

The difference nowadays is that you need more time on polishing the games than you needed in the past. Back then actually coding the stuff was more of a challenge. Now you have better programming languages/suits but more complex algorithms ^^

Traak · 2011-10-08, 10:52 AM

How about a snapshot of the view from your reticle inside the COF. Anyone in the COF can be hit, but it assigns only as many hits as there are shotgun pellets.

It's like Duck Hunt with that gun that pointed at the bright flash on the screen. The shotgun, wherever it is pointed, effectively selects seven pixels on the screen if all of them are damage-taking items, such as soldier, vehicle, turret, whatever, you score seven hits.

Whatever randomly-selected pixel in the COF that is not a damage-taking object, such as a rock, tree, wall, then no damage assigned. Puts the burden of hit detection on the client, not hard to code.

This makes it so shotguns are insta-shoot. A delay could be programmed, but it would be a lot more CPU brains to wait whatever delay there was for whatever distance pixels 1-7 are from the shooter, as one target item may be 1 foot away, another one 75 feet, another one 150 feet.

Easier to just limit the range of the shotgun than try to do the delay and time of flight math for seven separate pellets.

I think just the randomly selected seven pixels, are they damage-taking items, assign damage based on whether they were a tank, a cloaker, head, body, whatever.

Simple selection, client does most of the work, only thing sent over the 'net are seven damage infos, which might not even take up one packet of data, because it would only need to include identifier for person or object, and amount of damage.

Light on the net code, light on the server, and not very heavy for the client to digest and process, especially when compared to the gobs of computations for video effects. (Which, I know, are not leaning on the CPU so much).

dobs · 2011-10-08, 03:52 PM

Originally Posted by Traak

How about a snapshot of the view from your reticle inside the COF. Anyone in the COF can be hit, but it assigns only as many hits as there are shotgun pellets.

It's like Duck Hunt with that gun that pointed at the bright flash on the screen. The shotgun, wherever it is pointed, effectively selects seven pixels on the screen if all of them are damage-taking items, such as soldier, vehicle, turret, whatever, you score seven hits.

Whatever randomly-selected pixel in the COF that is not a damage-taking object, such as a rock, tree, wall, then no damage assigned. Puts the burden of hit detection on the client, not hard to code.

This makes it so shotguns are insta-shoot. A delay could be programmed, but it would be a lot more CPU brains to wait whatever delay there was for whatever distance pixels 1-7 are from the shooter, as one target item may be 1 foot away, another one 75 feet, another one 150 feet.

Easier to just limit the range of the shotgun than try to do the delay and time of flight math for seven separate pellets.

I think just the randomly selected seven pixels, are they damage-taking items, assign damage based on whether they were a tank, a cloaker, head, body, whatever.

Simple selection, client does most of the work, only thing sent over the 'net are seven damage infos, which might not even take up one packet of data, because it would only need to include identifier for person or object, and amount of damage.

Light on the net code, light on the server, and not very heavy for the client to digest and process, especially when compared to the gobs of computations for video effects. (Which, I know, are not leaning on the CPU so much).

Thats what my post said

Traak · 2011-10-08, 09:00 PM

I think PS's model was a percentage of the shots hit who or whatever the reticle was on, but anyone, no matter how closely crowded in, was hit by the weapon, as if the pellets only knew about the one person or thing in the reticle, but you couldn't aim a JH at a crowd and expect to hit more than one person at a time.

I would have to play to verify that, but that is how it seemed to me.

NapalmEnima · 2011-10-08, 11:51 PM

Originally Posted by dobs

i guess they already used algorithms like that for ps1. no way they could send all shots through the pipe. But i guess instead of calculating it from the direction the weapon looks it would get alot of jittering because of movement prediction.

That's why you want to include time stamps and player location/direction updates with all this stuff. That way folks can precisely duplicate incoming shot data, if only after the fact.

"He started shooting with this seed 73ms ago. That means these projectiles should all already exist in these locations".

A given packet can hold what... 512 bytes of data?

Traak · 2011-10-09, 12:13 AM

Originally Posted by NapalmEnima

That's why you want to include time stamps and player location/direction updates with all this stuff. That way folks can precisely duplicate incoming shot data, if only after the fact.

"He started shooting with this seed 73ms ago. That means these projectiles should all already exist in these locations".

A given packet can hold what... 512 bytes of data?

It depends. You can set your packets at larger sizes if you find your packet loss is low, so you can speed up your network speeds.

Check here for lots of useful stuff.

I have used it to extensively modify my network connection from Roadrunner in Hawaii, when I lived there. It made a big difference in download speeds for me.

Keep in mind that downloads are a different animal than a real time game. Downloads are verified with CRC checks, etc, and games don't have the time to do that, so you will have to experiment.

Think of it as overclocking for your network connection.

NapalmEnima · 2011-10-18, 03:05 AM

Actually pulled out my "Game Programming Gems" book. The relevant section is "2.0 Predictable Random Numbers".

"This article is a study of a technique that can be used to provide the depth of play that the audience deserves, even in limited-resource environments, such as that faced by the original Elite, without sacrificing any of the other vital ingredients that make up the perfect game."

The original Elite was written for the BBC Model B computer in 1980. It had a total of 32kb of memory, only 16kb of which was RAM, the rest was ROM.