Game Engine: Improved shotgun net traffic

[NapalmEnima]

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.