Multi-player Online feature (part 4— creating newly connected player’s sprite and deleting disconnected player’s sprite)
In last week’s blog, we successfully added in the game logic for rendering all existing players’ sprites for a newly connected player. However, the existing players don’t see a newly connected player’s sprite being created. Today we will add that final logic and that’s the last feature we need to do when a player connects to the server.
Before we start, you can download today’s code here and follow along.
Besides sending the existing players’ data to the new player, we also want our server to send the new player’s data to all the existing players. So whenever a player connects, a new sprite will be rendered.
This is relatively easy to achieve. After we generate a random playerId, x and y coordinates for the new player, and send it back to the game, we can also broadcast this information to all existing players, like so:
Before we push the new player into the players array, we broadcast his/her information to all players, all we need to do in our game now is listen for this event, create a sprite based on those information.
As you can see from lines 58 to 60, the game logic is exactly the same as the currentPlayers block on lines 51 to 56. The only difference is that, for currentPlayers (that is, the players array in our server), it could be zero, one, or more players sent back to the new player. For newPlayer, the server will always send back only one (newly connected) player’s data to everyone.
With that done, let’s test out the game. Save the files, and run server.js. Open a few tabs and go to localhost:5500. You should see the below:
Again, for each screen, the main player’s sprite is the one with the normal color, and everyone else is ones with darkened sprite.
Now each time a player connects, not only does the server sends him/her every other players’ data, his/her data is also sent to everyone, so a sprite is created for that new player.
Congratulations for making this far! The player connection is probably the most difficult and confusing to implement because there’re a lot of steps involved. When you implement it from scratch, I recommend breaking it down step by step, and outlining each step whether it’s a server action or a client action. We will take a look at deleting a disconnected player’s sprite next, which is the simplest feature in the whole game.
Back in our server.js, let’s broadcast the disconnected player’s data to everyone except that player:
On a disconnection , we again go through the players list, then broadcast to everyone the playerId of the disconnected player. Before we forget, we also have to remove that player from our players array in the server file.
Now back to our scene1.js, since all players are stored in our otherPlayers class variable, we can simply destroy the player sprite whose playerId matches what we receive from the server.
We can call the getChildren() method for otherPlayers because we initialized it as a group earlier. Then we loop through each player, grab the one we need, and destroy the sprite.
Let’s restart our server, open a few tabs, then close one or two to test it out:
Our next blog will conclude the mini series by implementing the update movement logic, as well as deployment to Heroku, so you can show your project to your friends and you’re not limited to localhost. As an additional challenge to you, try to have the other players play their movement animation and face the correct direction when moving. You can call the setPosition(x, y) method on a sprite. Or even add a chat feature to the game. See if you can make it work and we will go through the solution next week. You can download today’s finished code at my Github page. Have fun!
