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" notifications@github.com 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
#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: c951f31

[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 😄

[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. 😄

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. 😢

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 😮 :
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 👍