The first step with this project is the server. I’ve set up a very simple Node environment and have installed planck-js , socket.io , and web3 .

The first step is to initialize our imports.

This gives us access to important planck variables (our physics engine), our server, our websocket io (socket.io) and Web3 (Ethereum).

Now we need to set up our physics engine, initialize Web3, and create some variables for keeping track of clients.

We first initialize Web3 using the Ropsten testnet. This’ll let us test stuff without having to actually spend, or even have any Ethereum.

We then set a fixed time step for the server and initialize the physics world. Note that the gravity is set to 10, but the default for Planck is -9. We need this to be positive to play nice with Phaser.

We create a simple ground for the players to stand on and create an object to hold the client information. This will act as a map with the connection id (given to us by socket.io) as the key and their client object as the value. This makes it much easier to interact with specific clients.

Now let’s get some players in the game and set up Web3!

io.on(‘connection’) will get called any time someone connects to our server. Once this happens, we can set up functions to be called for specific packets regarding this client. The first one of these being the Join message.

When a player joins, we just need to add some information to their client object. Now, we could do all of this when a player simply connects, but there’s some stuff we need to wait for. Specifically, we want the client to make sure they have a valid Ethereum account and that they’ve actually sent us that account information before we allow them to actually join the game.

When a Client Sends the Join Message

The rest of these will go where TODO 1 is.

First, lets set up the player’s stats and physics body.

Once they join, we set their stats to the default we set above (because we haven’t gotten setup the smart contract to hold stats yet) and give them a new physics body.

The client will send us their Ethereum account address so we add that as an attribute.

To test out our Web3 functionality we then get their balance and add that as an attribute too. Later on we’ll send this to the client so they can display it.

We add this client to the clients object and then broadcast to all the other clients that this player has successfully joined. This will tell the other clients to start rendering this player.

When we call client.broadcast.emit , socket.io will send this message to every client that’s connected EXCEPT the current client.

Next Steps

These next steps will go where TODO 2 is.

Input

This adds a listener for the input packet. This is a simple object with a boolean for each important key (WASD). The client will only send this packet when the input has changed. This allows us to keep track of which keys are being held down without having to send an update from the player every 1/20th of a second.

Player State Requests

Some players will be joining later than others. We don’t want to be constantly sending a player’s ENTIRE state just to update something small like their position. When a client connects, they’ll be able to see that other players are connected, but won’t have any information for them. When a client detects a player with no information, they send a playerStateRequest packet.

This will simply send that player’s state to the client so they can be up to date.

Player Disconnected

When a player disconnects, we need to do a few things. First, we need to tell all the other players that they have disconnected. This CAN be inferred by the clients by adding some sort of timeout (maybe updates for that player haven’t come in for a while). In the past, I’ve found it really annoying to do it that way though.

If we simply remove a player once we don’t receive messages from them for a while, it means we have to send a heart beat to keep them from timing out on each client. This is definitely useful when using UDP, but with WebSockets (essentially TCP) we don’t want to do that. Every message we send is reliable, so lets make every player reliable too!

Game Loop

This code is now outside of the io.on(‘connection’) function.

This is the powerhouse of our server. It will be executed every 1/20th of a second ( FIXED_TIME_STEP ). It’s pretty straight forward so I’ll just brief over it.

Lines 4-5 We want to loop over all the clients, so we get all the keys from the clients object and loop over that.

Lines 7–9 A client could have potentially been removed within this time so we make sure this client still exists.

Lines 14–27 Adjust the players physics body according to their current input state.

Lines 30–36 To make sure every player isn’t the Flash, we cap their velocity.

Line 39 Emit the new state to EVERY CLIENT. This includes the client we’ve just messed with. This is because we need keep that client up to speed too!

Line 42 Step the physics forward in time. I halved the speed of the physics to simple slow the game down a bit. This part is just preference.

Final Touches

All we do here is create an interval that will call the gameLoop function every 1/20th of a second and then we get the server to start listening!

Conclusion

We now have a game server that’s connected to Ethereum using Web3!

In Part 3 I’ll show how I set up the client and upload the game so we can actually start using this guy!