Remove kevlar suit from players

[jgamedev]

From my test it seems that players are not currently affected by bullets Can you give me some orientation on how to properly add some sort of damage system to the engine?

I appreciate any help.

[jptosso]

You must get the angle using atanx_360_pi... then run some calculations, bullet speed is 10pps, add a new "services" that runs every fps and estimate the current position of the bullet Plus the position of the players, it requires many resources. On 2 Jul 2016 18:15, "jgamedev" [email protected] wrote:

From my test it seems that players are not currently affected by bullets Can you give me some orientation on how to properly add some sort of damage system to the engine?

I appreciate any help.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/arjanfrans/realtime-multiplayer-in-html5/issues/2, or mute the thread https://github.com/notifications/unsubscribe/ABLfzgSq6DCAZP9S4szvW9smXH7kf6rTks5qRuLpgaJpZM4JDwqg .

[arjanfrans]

I did not implement a damage system, but it would be nice to add it as an example.

[arjanfrans]

Got something that almost works: https://github.com/arjanfrans/realtime-multiplayer-in-html5/commit/c951f312a2d0afd4df77b69ce0c959ec117e16ab

[jgamedev]

Exciting! At some point I got different colors on each client, though, see here: https://drive.google.com/file/d/0B3KOxh0-cqDmdzNLOWVFczgtRWs/view

Haven't looked at the committed code yet

[arjanfrans]

Yes, I noticed that. That's why it almost works :smile:

[jgamedev]

I'm looking at it to see if I find anything but the staggering amount of data coming down the pipe is just staggering. For one thing, I'm receiving my own name at least once evry second. I think that even without resorting to binary, you'd be able to cut the message payload size to less than 10% of what it is now.

Just by implementing .toFixed(2) for all positions, replacing the use of UIDs for short IDs and ( along with player name mentioned above) would cut it down to less than 20%, for sure.

Your player.toJson() could look like this instead:

function toJSON (expanded) {
        let data = {
            id = roomId; // this is  2 chars long, max 100 per room 
            i: lastInputSeq,
            p: [position.x, position.y], // x, y array instead?
            h: hit.getValue() ? 1 : 0,
            f: fireing.getValue() ? 1 : 0,
            r: reloading ? : 1 : 0,
        };
        // when joining/leaving rooms send expanded info
        if(expanded){
          data.id = id // replace by actual player UID, stored on the client
          data.name = name
        }
        return data;
    }

Which would generate a payload the following payload:

{ "id":9, "i":555, "p": [ 333.5, 444.5] , "h":1, "f":1, "r":0 }

Compared to current:

{"id":"21b8f2be-d98d-43db-bbd8-cbf3bb317d55","name":"jay","lastInputSeq":"627","position":{"x":474.522,"y":289.076},"hit":false,"fireing":true,"reloading":false}

[jgamedev]

(Errata: forgot to use position.x.toFixed(1) in the last comment and github wont let me update it.)

This format would cut the size down even less: { "id":9, "i":555, "s":"333.5-444.5-1-1-0" }

.. where s is the player state, the first 2 elements of the state are the position and the others can be mapped back to their respective properties. :smile:

The following encode/decode are untested:

function encodeState(){
     return [
     position.x.toFixed(1),
     position.y.toFixed(1),
     hit.getValue()?1:0,
     fireing.getValue()?1:0,
     reloading?1:0
     ].join("-");
}

function decodeState(arr){
   position.x = arr[0];
   position.y = arr[1];
   hit.setValue(arr[2] ? true:false);
   fireing.setValue(arr[3] ? true:false);
   reloading = arr[4] ? true:false;
}

[jgamedev]

Btw, sorry to flood the issue with the unrelated topic of message size. Regarding the bullet collision, I noticed that you are just checking evry bullet against every player, but the would only be pratical for a very few amount of bullets and players. :cry:

Instead, I'd expect some algoritthm to be used to filter out which objects need to be tested: Here are a few topics on this theme discussed in the context of a javascript game:

Quadtree for bullet collision detection in javascript: http://blog.sklambert.com/html5-canvas-game-2d-collision-detection/

Usable implementation of quadtrees for use in the browser and with Node: https://github.com/p1100i/grid2.js

This one has a nice demo to go along :open_mouth: : https://github.com/sombra2eternity/quadtree http://jsfiddle.net/sombra2eternity/vNS7m/

[redblobgames]

BTW there are some benchmarks and links to JS libraries for collision here:

https://0fps.net/2015/01/23/collision-detection-part-3-benchmarks/

[arjanfrans]

I kept it simple for now. But yes, it can get out of hand pretty quick with too many bullets.

Thanks for the links!

[arjanfrans]

The hit events should work now, I put it in the master branch. I created a new issue for performance improvements for bullet collisions: #12.

[jgamedev]

Thanks, will test and report back in 1 hour :+1:

[jgamedev]

Hi, sorry, I'm a bit late.
So.. it seems to be better but still has bugs.
(Btw, How can I be sure that I'm running the latest version? I tried to pull but I git tells me I'm up-to-date in master.)

I was only able to test it for a few minutes. Heres a screenshot showing the problem:
https://dl.dropboxusercontent.com/u/1631393/test/nodeserver1.png

This problem can be reproduced by firing on the very edge of the enemy.
So I'd guess that the "other" client detected a collision and killed the bullet while the server did not see a colision and has no way of correcting the client? I have to confess I haven't studied the new code completely.

If my assumptions are right, it seems the clients currently have authority to detect hits independently from the server? Is this a good idea? I'm guessing them that the fix would be to always rely on the server to authorize hit events. @arjanfrans , @asdfuken , @redblobgames what do you think?

[arjanfrans]

@jgamedev You are correct. If the client hits someone, it will hit optimistically, not waiting for a server response. This is indeed not a good idea.

The client should be corrected by the server. I am wondering, does the client even need to perform detection, or just always wait for the server?

[jgamedev]

I believe the most optimistic your clients could be is to render bullet movement locally, but hits (and the corresponding bullet suppression) should definitely fully rely on server commands only.

See the comment from user PrimeDerektive in a similar discussion here: http://forum.unity3d.com/threads/projetiles-how-to-handle-a-bullet-over-the-network.97606/

Also if the user renders bullets optmistically ( which I definitely think it shoud) and the server doesnt correct bullet position at least once, I think could cause the opposite problem where hits that are only aknowledged after the bullet already went past the user, due to a late server response. Not 100% sure what to do there... :confused:

[redblobgames]

@jgamedev The “standard” answer is to never trust the client, and do everything on the server, but I've seen other architectures that work too. It depends on the game. Client hit detection sometimes feels better because there's no lag and it can be pixel perfect.

[jgamedev]

@redblobgames thanks for commenting!

I think that a hybrid approach would be to allow the client to optimistically remove bullets for unconfirmed hits, but maybe not render the damage sprite?

This could prove to be a nice balance, because it would prevent the annoying body traversing bullets scenario, at the same time that it doesn't completely misinform the local player, since he will not see rendered damage unless the server confirms it.

Bellow are a couple of possible limitations that could potentially arise from using this hybrid approach:

Resurrecting bullets anomaly:

Once removed by the local user the bullet should be gone forever and further references to the same bullet should be disregarded in order to prevent reappearing bullets.
Damage commands coming from the server would still be rendered, but not the bullet sprite itself.
End result: If bullet removal is made to be permanent this could cause bullets to re-appear out of thin air, due to them being "resurrected" by the server.

Damage by invisible bullets anomaly:

Say i have 2 enemies one is in front , the other enemy is a little behind.
The Local client sees the bullet hitting the enemy in the front and optimistically removes the bullet, but shows not damage because that's the job of the server.
Server doesn't see the same trajectory and lets the bullet travel further, hitting the enemy behind.

End result: Because the bullet has already been optimistically removed by the local client, damage will be a applied to the second enemy but without a bullet visually hitting him. So in this scenario, from the perspective of the local user, he sees enemy 1 intercepting the bullet while enemy 2 is the one actually getting and displaying the damage.

Thoughts?