warthog710 / csc165-gravity-guys Goto Github PK

If the client exits unexpectedly, it never says "BYE". This is unavoidable. However, the server should be able to deal with this issue. The problem is... The server is completely reactive to requests while clients are proactive. This may involve overriding processPackets()...

• Add a timeout on the server... If no client update takes place... remove it.
• What if the client doesn't move? No packets are being sent? Send a packet type maybe... "ACTIVE" + client.UUID to tell the server that the client is still active.
• Make sure this doesn't conflict with the packet timestamp. Keep two separate values? Last active msg... Last update msg?

UDP guarantees no order! Inside our network protocol, we need to send timestamps so we don't overwrite a newer location with an old one.

I think it would be cool to be able to determine how much lag there is between a client and the server... This should be easy to implement with a timestamp in the packet. My intent was to already add this for packet order but... This could also be used to determine the lag between the client and the server. Let's do it!

I believe this has something to do with synchronization when the thread calls the parent's methods...

Game variables such as position and light values should be moved into the gameVariables.js script.

The client only says "BYE" to the server if the ESC key is used to exit the game. This is not ideal as there are other ways to exit... May overriding game.exit() with the correct method call will solve this?

Currently, the network protocol only implements a solution for syncing client movement. We should also be doing this for yaw/pitch. This can probably be done by sending over the 3 axes associated with the client when a yaw/pitch action occurs.

Sometimes collisions between the avatar and walls are not working... I think it has something to do with the avatar moving within the bounds of the physics object in a single frame. We may have to implement some form of collision detection manually on these to fix...

Currently, no prediction takes place between the client and the server. As a result, the value the server sends is the exact value used for the GhostAvatar. However, this has problems due to network latency. Implement a way in which the client can predict the movement of the avatar.

• Maybe use some form of memory of past moves with a curve fitting function?

• What if the client's prediction is way off? We need to gradually correct the prediction with the actual location sent from the server.

This will require overriding processPackets()... As we want to only do stuff in the method if we are connected to a server. In addition, server polling will have to be implemented. This will clean up update() and encapsulate networking things in the NetworkClient class.

If a client doesn't move between requests, the server still sends an update packet for them. Using a timestamp in the packet, only send updates for those clients that have moved when a request is made. Perhaps a boolean in the clientInfo class maintained in the GameServer?

NOTE: Marking as a bug as this fix should dramatically improve server performance as most of the time (in computer terms) a client does not move.

The code used for determining if an update has occurred since the last time a client asked for an update is buggy... If the client is on the same machine the game is running on... It works. Otherwise, it does not. This most likely has to be due to how the server is checking if an update needs to be sent back. Currently, this code has been commented out and is working, but a packet is currently sent even if no updates have taken place.

Currently, when a client requests updates for another client on the network the server responds with a single packet for each active client. This is probably not very scalable. Idea: Send back an object with only updated information for all clients. Therefore if a client hasn't moved no update is received. This would only require one packet. However, the protocol would have to be modified quite drastically to allow for this.

This will require overriding processPackets()... As we want to only do stuff in the method if we are connected to a server. In addition, server polling will have to be implemented. This will clean up update() and encapsulate networking things in the NetworkClient class.

The game server should print its public IP and not local... This should be easy to fix.