Planetside 2 Hit detection

[SKYeXile]

Originally Posted by ArmedZealot

Where'd you find the information on this?

If this is true it makes me feel a whole lot better about PS2 in general. A relationship between the GM's and Steam makes it easy to deter those from doing hacking and getting those that do out of the game. And VAC seems like an alright 3rd party client even though it doesn't stop much from happening on private servers used in most valve games.

its in the G4TV bideo i posted.

as for my opinion, i probaly can give a good one, i dont know enough about game design specfics, and know i have ends at movment prediction and netcode. anti cheat methods I'm not really sure on, but SSHP is definatly more open to cheating than SSHD thats a definate.

with a hitscan weapon i think the server could easily factor in objects, because a shot wound intercept a wall or something and end. But using SSHP the server really has to trust the client for physics and shots, the server i dont beleive could sanity check a shots physics, just that a shot hit XYZ at A time and weather or not it had a target at that location at that time and confirm a hit.

heres so more stuff on what sort of system planetside will use, valve use alot of prediction on the client though, this is why the game runs so smooth, Planetside 2 may not run so many serverside confirmation checks: eg: player movment, weapon ROF...etc. so it maybe open to those sorts of hacks if they dont confirm those sort of things on the server. we'll see.

https://developer.valvesoftware.com/...yer_Networking
https://developer.valvesoftware.com/...d_Optimization

cant find any good articls on designing a game to prevent hacks though. but valuve give some insightful looks.

[Brusi]

As another Aussie gamer, i can attest that the worst, most frustrating kind of hit detection is server side. I'm far happier with getting killed after i'm behind cover than none of my hits ever registering.

Playing with 300 ping means having to lead your targets by an inch or maybe even more depending on how fast/erratic a target is moving, while you know that you are fighting against players in the US with <50 ping who are playing the game the way it was intended.

I'm not one to blame my FPS shortcomings on something like latency, but when i am getting my shit handed to me, it can be crushing to know that my opponents are not similarly handicapped.

Unfortunately, the flip side of this (client side) is never knowing if the opponent who is creaming you is just flat out hacking.

I've found the best solution is just keep your head in the sand, (lower the air-con, smoke a bowl, open a beer) and don't think about whats behind the presentation layer. L2P and just keep playing as hard as you can.

[Princess Frosty]

Originally Posted by ArmedZealot

What do you think the consequences of this hit model will be from a hacking standpoint, especially since, as you say, that valve uses this model in games like counter strike and team fortress? Considering that they are very full of such exploits and cheats, does that make the transition from those to Planetside 2 easier?

What are your opinions on having the the victim assumed shot rather than the shooter missing in cases of lag as the assumption in SSHP?

As far as cheating goes SSHP is the best possible system, it means that no client is trusted in terms of the packets the server recieves, the server goes back in time and and verifies what really what happened, that the player was really at Position P1 at time T1 and that their bullet trajectory was T1 and has a clean, uninterrupted path to the enemy T2.

It means the server can detect "bad" bullet hits and disregard them so they simply don't count as damage towards enemies, remember it's the server that tells you that you've lost some health from a bullet impact and not other clients.

There's hacks for a lot of games but games like CS and TF2 are generally quite well protected, I know it's lame when people use things like aimbots, and while these hacks can give the player godlike reactions they usually cannot break the rules of the server such as firing through objects, exceeding the rate of fire or magazine capacity of the weapons.

[igster]

Cracking post.

One other thing to consider about hit detection is that Planetside 2 has the largest challenge of all for hit detection because of the number of players that it is meant to support. When you have a small upper limit on number of players (up to 32 players per server) then you can use more processor and network intensive methods of hit detection.

Consider the situation with 100 or 150 players in a small area, e.g. inside a base. This might be a limiting factor on the accuracy of the hit detection since there are more targets and more geometry to process. Not to mention that the server has a lot more work involved when trying to simply update the positions and gamestate of many many more players.

[SKYeXile]

The problem is too, the more players you add it gets exponentially harder for the game to process.TF2 figures, but say you send packets to the server at 6kb/s the server is sending you data with 32 other players at 24kbs per seconds, lets just say that adding 1 extra player increases the server sent packet size by .05

so at 32 players the server is using up .9mb/s of bandwidth.

at 64 players it uses 1.95

at 128 it uses 4.07

256 it uses 8.94

Processing would become exponentially harder too, cant produce and numbers on that though.



now these are just examples of the exponential increase I'm talking about, to workout its actual usage you would need to factor that you would be getting a maximum data from 400 people, factor that to use a max of 100mb per hour tops, on the downstream. then work it backwards. to get its real use.

i say 400 people because i cant see you needing data for more than 400 players at once. i think you would simply not get data for stuff thats further away from you or out of draw distance anyway. anyway, its all too complicated for me

[Infektion]

Originally Posted by Princess Frosty

I think hardware is at a point now where we can handle that level of computation per second, we can build individual servers with dual 6 core CPUs with hyperthreading (12 physical cores, 24 logical) and write server side software to simply track it all, have 64gb of RAM to hold as much data from prior ticks as is needed. As a systems admin and hardware enthusiast I'd be interested in seeing what kind of server hardware they're going to run on.

We use this type of setup in our cloud host, dell 610's dual 6core 2.5Ghz+HT, 64GB ram w/ 6x300 GB SAS on raid 10. Each server hooked up to through a dedicated gb dell switch to a dell sans with SSD + HDD hybrid, I can install win08r2 start to finish in 5-8 mins, fully updated with slipstream iso.

[LongBow]

yeh - tbh I have no doubt SOE will come up with an awesome solution, their other titles trust the client a lot more than we are used to but it works!

besides you don't need to check things like rate of fire very often (not in game loop terms anyway)

[Princess Frosty]

Originally Posted by SKYeXile

The problem is too, the more players you add it gets exponentially harder for the game to process.TF2 figures, but say you send packets to the server at 6kb/s the server is sending you data with 32 other players at 24kbs per seconds, lets just say that adding 1 extra player increases the server sent packet size by .05

so at 32 players the server is using up .9mb/s of bandwidth.

at 64 players it uses 1.95

at 128 it uses 4.07

256 it uses 8.94

Processing would become exponentially harder too, cant produce and numbers on that though.



now these are just examples of the exponential increase I'm talking about, to workout its actual usage you would need to factor that you would be getting a maximum data from 400 people, factor that to use a max of 100mb per hour tops, on the downstream. then work it backwards. to get its real use.

i say 400 people because i cant see you needing data for more than 400 players at once. i think you would simply not get data for stuff thats further away from you or out of draw distance anyway. anyway, its all too complicated for me

I don't think additional players creates an exponential growth in CPU processing or bandwidth, I think it's more or less a linear increase, the example you gave is more or less a linear increase, as you double the number of players you double the amount of bandwidth required.

The clients still only send back to the server whatever information the client is doing, moving, shooting, so that remains the same for the client and is a linear increase for the total incoming packets for the server.

The processing also is a linear increase in effort, hit detection in terms of projectiles and similar is only performed on information from the clients, if 5 clients are shooting and creating 5 vectors to resolve then 10 clients create 10 vectors which again is a linear increase.

The data back to each client is really the only problem, they need to receive updates for all players in their vicinity and there is an exponential increase in bandwidth out to each client for every tick because you have to send n clients information about n other clients. However optimization help ease the issue somewhat, idle players or players very far away from you might only get updated once every few seconds or not at all, players who are close will get updated to you at the normal rate.

Bandwidth is cheap these days anyway, I have 50mbit FTTC installed and 100mbit comes later in the year, followed by up to 300mbit FTTH, and as infektion pointed out, server hardware is there if you have the money for it, servers do a fairly simple job compared the clients they dont render anything they just resolve vectors, perform hit detection etc.

I suspect that with PhysX being used that they'll go the GPGPU route with either high end video cards or Nvidias GPGPU cards in the servers, these can resolve millions of physics interactions per second.

[SKYeXile]

Rich Lawerence(SOE technical executive) explains the problem better here, i dont think this this is his original interview, cant find that but it contains the key points.

http://www.bbc.co.uk/dna/collective/A13770371

Certainly Planetside was a gamble, and an enormous technical challenge. “Primarily the problem was scale,” Lawrence continues. “We weren’t going to have just 16 or 32 people slugging it out and treat latency as a ‘tough luck and try logging into another server’ issue. We wanted 500 people in battles.” And this is where it gets a bit technical. “There’s the famous ‘N-squared’ issue, in which logic iterates every player in a list then considers every other player for comparison. For 32 people, that’s 1024 comparisons. For 500, it’s 250,000. What was easily within your CPU budget in a 32-player environment completely falls apart with 500.”

What the game achieved in terms of latency management and server responsiveness, “no other product could do at the time, and most people still can’t do to this day.”

that was 2006 though, clearly SOE are the "top men" for this job though and if anybody can pull it off they can.

[Princess Frosty]

Right, so the N squared is what I just mentioned, n number of players compared to n number of players does give you an exponential growth, however what sort of calculations are you doing that directly compare players to players in that manner? Not many I would guess.

And even then the trick is not to compare n to n but write some functions which intelligently filter out players, there are lots of commonly used methods for optimizing this sort of things, plotting all players in a grid and then only comparing users in the same grid tile or within a certain number of tiles of each other, or even more basically within a certain radius, for example if no projectile exists over 100m or can't do damage at 100m then you'd ignore players more than 100m away.

It's not really an N squared problem, that's only an issue if you're unintelligently comparing all players to all other players all of the time.

[SKYeXile]

Found the elusive higby quote.

As in Battlefield 3, hit judgement is split between server and client-side, meaning where you shoot will be where you hit. The game has a realistic ballistics model: “When you fire a weapon it takes time to hit the location. If you fire a sniper rifle from a distance, you’ll have to aim your headshot a little above your target.”

http://www.pcgamer.com/previews/planetside-2-preview/

[Crator]

^^^ Why does that statement contradict itself?

"where you shoot will be where you hit"
"If you fire a sniper rifle from a distance, you’ll have to aim your headshot a little above your target."

[SKYeXile]

Originally Posted by Crator

^^^ Why does that statement contradict itself?

"where you shoot will be where you hit"
"If you fire a sniper rifle from a distance, you’ll have to aim your headshot a little above your target."

I beleive thats in refence to where he says realistic bullets models, but i think the "where you shoot will be where you hit" part is refering to the game using CSHD / SSHP where you dont have to compensate for latency, but you still need to comensate for bullet travel time and range.

[selmu]

I dont know what kind of model it use, i dont live in america, and most os my shots in moving target show has a hit(the thing in the crosshair showing the hit) but deal no damage.

If the guy exploit the lag, press adadadad its, impossible to hit, i mean deal damage, i hit(the crosshair thing) but no damage.

And i die a lot after hide or turn the corner.

[Tatwi]

The solution to this is obvious: We need Quantum Entanglement chips for PCs.

Make it happen, SOE.