Hybrid "targeting" / FPS combat??

[Ripper]

A post on a previous thread got me to thinking.

 

In some probing of Nyzaltar, some time ago, he proclaimed the game will feature targeting mechanics over fps style. So at the very least you wont be expected to dodge bullets with reaction times.

 

 

This makes a lot of sense from the single shard approach.   Hit detection becomes MUCH more difficult when the server has to account for rubberbanding. 

 

Of course there are those of us that would like to be able to hit specific parts of a ship to disable it. 

 

The player base is going to WANT "FPS Hit Detection" instead of "RPG Targeting".

 

Here's a thought:

 

Consider the missile "lock on" reticle.  Your ship usually has to face the target and have it close the the cross hairs in order for your missiles to lock on.

 

Now imagine an invisible "lock on" reticle (because the player doesn't need to see it).  This reticle is strictly an anticheat mechanism. This reticle is much more difficult to achieve, and the lock doesn't last very long.  The game client transmits a "locked on to player 2" packet to the server, which is verified.

 

This is essentially an "RPG Target".  Instead of clicking on a MOB the client selects it for me.

 

Then when Player1 shoots at Player2, the damage all hit detection is done client side.  If they're "locked on", the damage is applied to Player2.  (much like my lightningbolt hitting a MOB)

 

And consider this...  The server only has to transmit "locked status".

 

All damage could be transmitted between clients (with the occasional additional anti-cheat mechanisms in place).  This would reduce network infrastructure load.  EDIT - See Post 5 & 7 for clarification

 

What do you think?

[norab7]

Sounds like an interesting idea..

 

I haven't read anything about it yet, but when i get home i'm going to have to look up what they've already released about this because what about the larger ships?

 

If you have a 1km long ship, the 'Targeting' system is going to have to distinguish between different parts of the ship otherwise your just shooting always at the center and large ships become single entities.

 

There has to be something to do with this released from the Dev's and i'm going to make this the point of my day on the forums to find out about it.... Thank you for this post.. +1

 

EDIT: Apparently I can't +1 you because i've spent to much time posting and used up all my points... hmmm... Can someone else +1 them for me?

[Ripper]

Thanks,

 

WHY does "RPG Targeting" exist?  Its sole purpose is anti-cheat.  I have to be in range, and hopefully facing my target to do damage to it.  This prevents a malicious user from dropping a fireball on me from the other side of the game map. 

 

Once targeted, the player can click to their hearts content to apply damage, and the server sends "pre-defined" damage packets to Player 2, based upon the type of damage inflicted.

 

Hit detection on the average FPS is verified server side, and can be extremely complex which creates a load on the server.

 

If the detection and location of damage were client side, those packets could be sent from client to client.

 

The only other consideration is magnitude of damage.  There would need to be a way to indicate that the standard "Size 1 laser shot" does 20 points of damage, and an anti-cheat mechanism that would prevent player1 from modifying that value. 

 

Maybe.  The clients only transmit hit type and location.  Then the damaged client would request the amount of damage from the server.  In fact, the client would only need to request the "damage table" every so often.  That way it would reference the table instead of making a query every single hit.  This would prohibit the player from modifying the damage table, because it would be regularly overwritten.

[norab7]

 

If the detection and location of damage were client side, those packets could be sent from client to client.

 

Doesn't this open up a whole world of hacking the game?.. Client to Client sounds like a bad idea to me, what's stopping a person manipulating their output data since it doesn't go through the server?....

 

Maybe I'm just being devil advocate i dunno...

[Ripper]

Well,  What needs to be verified.

 

1. Did the player actually hit the target?
2. What did he hit the targe with?
3. Where did he hit the target?
4. How much damage did he do?

Answer:

1. He had to be "locked on" or the target had to be selected via "RPG Targeting" - Server Verified
2. Hit type ... (server supplied - see below)
3. The location can be determined client side and trasmitted to the other client.
4. A regularly updated damage table(once per second?  balanced for load), that's queried by the damaged player. - Server Supplied

Let's consider how we prevent the attacker from changing that "Size 1 laser" to a "Size 5 laser".

 

I seriously doubt a hacker is going to be able to specify a certain voxel to hit.  So, hit location shouldn't be an issue.

[norab7]

What if they chose to have their location as 'everywhere' or chose to hit the enemy 'everywhere'?...

 

From my little knowledge of games programming I'm imagining everything that is not going through the server is vunerable to hacking... this approach makes me worried.

[Ripper]

The Answer to hit type is the contents of the "locked status" packet.

 

The client would have a "Locked Table" array to account for multiple attackers targeting the player.

When attacker 1 "locks" The server verifies the lock, and transmits the attackers weapons loadout and playerID to the defender.  The server also updates the damage table to make sure it hasn't been modified.

 

Hit detection is performed client side, and the attacker sends "Attacker1, Hit Player 2, voxel location, weapon 1"

 

The client looks up weapon 1 in the lock table, sees that its a "Size1 Laser" and cross references its damage from the damage table.  Both of which have been provided by the server in the past few seconds.

 

UPDATE - The "Damage" table can be merged into the "Locked Table" with weapon loadout & damage.

[Ripper]

What if they chose to have their location as 'everywhere' or chose to hit the enemy 'everywhere'?...

 

Sadly, I'm not familiar enough with voxels or how NQ plans on displaying their coordinates to answer this question.  I would personally isolate all "hits" to a single voxel.  Even missile hits.  The clients would extrapolate the damage from there.

[norab7]

HMaybe I'm missing something.. I'm interpreting this as the clients decided where the attack is from and going to, and the only thing that comes from the server is weapon stats...

 

It just sounds to me very open to manipulating...

[Ripper]

Here's the deal,

 

Client to Client isn't necessary.  All of this can be ran through the server at the cost of increased overhead.

 

There's always a tradeoff for security, and it's NEVER 100%.

 

And there are always server side hacks.

 

If the alternative is a generic "RPG target", you're not going to get the granularity of FPS hit detection.

[Dreamstar]

Ah, I'm embarrassed i should have just linked originally to this obscure thread.

 

https://board.dualthegame.com/index.php?/topic/281-diversity-of-battles-and-wars/

 

 

 

Hi Klatu & Saffi !

 

Really important and delicate topics here 

Here are a few answers:

 

- About "Friendly Fire" and "Manual Targeting":

We would like to implement that. We really would like. But there a very high chance we won't, at least for now (maybe with computer technology evolving, it will change in the future). The fact that massively multiplayer single-shard sandbox games like EvE Online are able to reach several thousands of players at the same place and the same moment is possible due to some compromises (and while we are aiming to higher flexibility in this regard, we're still subject to compromises too): combat system using Targeting/Locking/Firing mechanics in this kind of game is not completely unrelated to the ability to create massive battles, as it's an efficient way to lighten a lot of real time combat calculations.

 

- About "Bigger means more complex":

Well bigger ships will certainly be harder to destroy/invade if they're built in a smart way by players. However we do have some ideas to balance their toughness: They will be slower, less agile than smaller ships, due to their mass. Big Weapon Turrets will also at disadvantage against very fast ships. But nothing will prevent builders to create specialized ships: like a huge battlecruiser full of small weapon turrets to hunt down hostile small and fast ships. But there will be a choice to make: Energy consumption. Every module in a ship will require energy. So it won't be possible to have everything in infinite number, even on a big ship.

 

- About "Terrain":

We have already planned to have asteroid belts (even if it won't be for the Alpha).

But having specific cosmic phenomenon producing side effects in some areas in space (like strong gravitational fields or ionized clouds) is a great idea. I will transmit it to the dev team! 

 

- About "Arms Diversity and Rock/Paper/Scissors":

This is already planned: We are thinking about weapon families, with each type of weapon very efficient in some cases and not very efficient in others. Right now we plan to have at least 4 different types of damage, but it might still change in the future.

 

Best Regards,

Nyzaltar.

[norab7]

Ah, I'm embarrassed i should have just linked originally to this obscure thread.

 

https://board.dualthegame.com/index.php?/topic/281-diversity-of-battles-and-wars/

 

How do you guys keep bringing me threads i've not see before... Thank you saffi

[KlatuSatori]

Looks like Saffi beat me to it in linking you that thread

 

I think allowing clients to perform the hit detection algorithms would be vulnerable to cheating.  Something so important needs to be done entirely server I think.  What would stop clients transmitting hits at a 100% success rate every 0.1s or something?

 

What I would really like to see is a system that incorporates the possibility of friendly fire, but Nyz has said it is highly unlikely.  But as you guys say there is already an issue with location of a hit on huge vessels.  That would require some kind of pointing/line of sight mechanism, so perhaps the solution to that would allow for FF.

[norab7]

Looks like Saffi beat me to it in linking you that thread

 

I think allowing clients to perform the hit detection algorithms would be vulnerable to cheating.  Something so important needs to be done entirely server I think.  What would stop clients transmitting hits at a 100% success rate every 0.1s or something?

 

What I would really like to see is a system that incorporates the possibility of friendly fire, but Nyz has said it is highly unlikely.  But as you guys say there is already an issue with location of a hit on huge vessels.  That would require some kind of pointing/line of sight mechanism, so perhaps the solution to that would allow for FF.

 

I'm sure I read something somewhere that describes friendly fire being a core part of massive battles because it adds to the 'counter-balance' of fights where if you have the bigger numbers you also have the bigger chance of destroying your own fleet and what knot... Something about firing shots will 'travel' to the target and can be intercepted by any other ship so this gives friendly fire a possibility... 

 

But that's from a old old post or a DevBlog or something so I wouldn't be able to say anything about its current accuracy..

[KlatuSatori]

I'm sure I read something somewhere that describes friendly fire being a core part of massive battles because it adds to the 'counter-balance' of fights where if you have the bigger numbers you also have the bigger chance of destroying your own fleet and what knot... Something about firing shots will 'travel' to the target and can be intercepted by any other ship so this gives friendly fire a possibility... 

 

But that's from a old old post or a DevBlog or something so I wouldn't be able to say anything about its current accuracy..

 

Haha that's from my thread which is the one Saffi linked above.  Nyzaltar's reply:

 

 

 

- About "Friendly Fire" and "Manual Targeting":

We would like to implement that. We really would like. But there a very high chance we won't, at least for now (maybe with computer technology evolving, it will change in the future). The fact that massively multiplayer single-shard sandbox games like EvE Online are able to reach several thousands of players at the same place and the same moment is possible due to some compromises (and while we are aiming to higher flexibility in this regard, we're still subject to compromises too): combat system using Targeting/Locking/Firing mechanics in this kind of game is not completely unrelated to the ability to create massive battles, as it's an efficient way to lighten a lot of real time combat calculations.

[Cavadus]

Not rally sure how we can have a legitimate cockpit view but not have twitch aiming.  That seems rather contrived.  I certainly hope something as antiquated as tab-targeting, or some variant thereof, is not a serious option.

It would completely kill my interest in this title if true.

EDIT:  I hope it goes without saying but I'm not talking about automated turrets and the like.

 

EDITx2:  Ummm, I'm seeing a lot of bad information spread in this thread.  FPS targeting =/= client side anything.  It could, sure, but RPG targeting can be client-to-client as well.

The fact of the matter is that any and all competitive multiplayer games have game servers verify virtually everything clients attempt to do and that's because clients lie.  A really good example of how to do things horribly is Tom Clancy's The Division (on PC).  They have no server-side checks of clients' packets and as a result the competitive multiplayer areas are dominated by hackers.

 

This is why there anti-cheat programs and why solid multiplayer games have the game servers verify every bit of data any and all clients send.  The simulated targeted method has nothing to do with that.  The distinction here is that manual FPS targeting requires the verification of (usually) more data.  That's it.

But for anyone in this thread to proclaim that all FPS targeting is client-to-client is ignorant or purposefully spreading false info.  Seriously, multiplayer architecture 101 here.

 

Here's a link a server engineer destroying the network model used by Ubisoft in Tom Clancy's The Division.