This post is a follow up to a about building a multiplayer browser game. In this techsploration, I’m going to quickly brush over how latency can affect your game and how to combat that. I will briefly discuss a couple of game frameworks, including one I built at , and how to incorporate sound into your game. post I made a while ago BrickHack3 Latency and Laaaaaaaaaaaaaaaaaaaaaaag So firstly, what is latency? Well, if you’ve played any online game before, you might have experienced that phenomenon where you click or try to perform an action, and the nothing happens in the game until a bit later. Typically known as “lag”, this is incredibly frustrating to deal with for real time games like multiplayer shooters. Latency occurs simply because of the physical distance between your computer and the server you’re connected to. Remember how in we talked about authoritative server determination? That’s what causes the lag since it takes time for your input to be sent to the server, verified, and sent back. part one has fantastic resources and explanations on why this occurs and how to deal with it, and I will be linking lots of resources from his site. http://gabrielgambetta.com A single client-server interaction (image from ) gabrielgambetta.com To combat lag, I’m going to introduce an idea called client prediction/extrapolation. This concept basically involves playing the animation before an action on the client side BEFORE it has been acknowledged by the server to emulate seamless gameplay. The client is basically predicting the state of the server after the acknowledgement. Especially for player movement, this becomes easy to implement if you have a deterministic model for the world. If your game world is governed by predictable and calculated physics, then the client side can make educated assumptions that its input is valid so that the player move animation can begin before the acknowledgement from the server has been received. Client prediction (image from ) gabrielgambetta.com Aside from these awesome diagrams, Gabriel Gambetta’s site has a lot of cool visualizations of how this works and an explanation of some of the problems with this as well. . Since this post is mostly for introducing the idea in the abstract, I highly recommend that you check out his as well if you’d like to implement this in your own code. Definitely check out his live demo sample code incheon.gg The homepage to incheon.gg In the comments of , recommended the framework to me as a way to abstract away most of the problems that I discussed in the first part of this article. This framework is pretty cool and allows for games with discrete and continuous physics, all while handling most of the client-server synchronization logic. I’ve been checking it out and playing with their sample code and I highly recommend using this framework as a start if you don’t want to implement the network code yourself. It is extremely well documented and easy to read. How to Build a Multiplayer Game (part one) Opherv incheon.gg Granted, it was a little difficult to get started (mostly since I had to learn ES6 style classes) but since its such a dense topic with a lot of great discussion points I’ll make another post soon on how I explored the framework and what I made with it. (But huge shoutout to for linking me to this!) Opherv Writing my own game framework at BrickHack3 If you don’t care too much about network lag and you want to try customizing and writing everything including the physics, sound, and animation, you can also check out the . game code that I use Karl Coehlo (left), me (center), Dan Giaime (right) at BrickHack3 I participated in at the Rochester Institute of Technology this weekend, and since my team submitted a ( ), I actually spent some time writing to build the multiplayer game with. BrickHack3 multiplayer game we won the Best Game Award my own framework I build multiplayer games a lot and over the years I’ve recycled a lot of the code. This framework is simply a culmination of what I’ve learned over the years. Unlike , is much more tailored to the type of open world multiplayer games I like to build and doesn’t have any of the aforementioned networking functionality built in. It’s geared more for people who want to learn about game architecture by writing the code for every part themselves. incheon.gg my framework While it’s still a work in progress, works much closer to the node.js architecture that powers it and allows for more of it to be customized. If you’re a game dev beginner or node.js beginner and you just came from , then I’d probably recommend you take a look at this code and tinker with it to understand what it does. my framework part one . This repository contains a refactored, commented, and cleaned up version of the mockup we built in . In the next section, I’ll explain each part of this framework in detail. I suggest cloning the repository if you’d like to follow along. Here’s a link to the GitHub repository part one git clone https://github.com/omgimanerd/game-framework Files included in the game framework Let’s start with , the bread and butter of any node.js project. The main dependencies I have are , , , , and . The only ones absolutely necessary to this project are socket.io, and hashmap though. morgan is a just a useful logging tool, express is a widely used middleware framework, and pug is a template engine, but if you wanted to, you could very easily swap them out for something you’re more comfortable with. The hashmap package is used to map each client’s socket ID to their Player instance, while socket.io is needed of course to power the real-time communication. package.json express hashmap morgan pug socket.io Next is , which contains two client side dependencies, and . Neither is really necessary, but makes your life easier, and is that powers the sound for the game. I’ll discuss how I use later. bower.json jquery howler.js jquery howler.js a cool library howler.js The “lib” folder contains the server side files that handle and store the state of the game and its entities. and are that encapsulate an entity with basic physics and a circular/spherical hitbox. If you wanted to get ambitious, you could implement more elaborate physics, gravity, hitbox meshes, etc into the class. Entity2D.js Entity3D.js ES5 style classes Entity2D.prototype.update = function(deltaTime) {var currentTime = (new Date()).getTime();if (deltaTime) {this.deltaTime = deltaTime;} else if (this.lastUpdateTime === 0) {this.deltaTime = 0;} else {this.deltaTime = (currentTime - this.lastUpdateTime) / 1000;}for (var i = 0; i < DIMENSIONS; ++i) {this.position[i] += this.velocity[i] * this.deltaTime;this.velocity[i] += this.acceleration[i] * this.deltaTime;this.acceleration[i] = 0;}this.lastUpdateTime = currentTime;}; Note how we implemented the framerate independent updating discussed in here. Updates to the position and velocity are done using a deltaTime so that we get consistent behavior. is just an extension of and simply handles user input on top of the basic physics for the purpose of the mockup demo. part one Player.js Entity2D.js is a bit more interesting. Game.js function Game() {this.clients = new HashMap();this.players = new HashMap();} On top of this basic constructor, we have methods that facilitate the connecting and disconnecting of players. Essentially all this class does is handle the updating and broadcasting of the server state. Game.prototype.update = function() {var players = this.getPlayers();for (var i = 0; i < players.length; ++i) {players[i].update();}}; Game.prototype.sendState = function() {var ids = this.clients.keys();for (var i = 0; i < ids.length; ++i) {this.clients.get(ids[i]).emit('update', {self: this.players.get(ids[i]),players: this.players.values().filter((player) => player.id != ids[i])});}}; Game.prototype.update() simply updates every entity in the game, and Game.prototype.sendState() broadcasts the game state to every client connected to the server. The only interesting thing to note (and this is specific to my implementation) is that we filter out the currently connected player and send them separately. You could implement this your own way however. That’s just the way I chose to do it to since it makes my life easier on the client side. Moving on to the “public” directory, this folder contains all the statically served client-side JavaScript files. Remember how we mentioned that it was a good idea to refactor stuff in ? This is just one way of doing it. Building a set of modules that each specialize in handling a specific part of the functionality is always a good idea and good software design in general. part one , given a HTML5 canvas context object, will handle the drawing of all the game sprites onto it. The client side uses to run a game loop on the client side for sending user input to the game server as well as rendering the received game states. Drawing.js Game.js window.requestAnimationFrame() Game.prototype.animate = function() {this.animationFrameId = window.requestAnimationFrame(Util.bind(this, this.update));}; Game.prototype.update = function() {if (this.selfPlayer) {// Emits an event for the containing the player's input.this.socket.emit('player-action', {keyboardState: {left: Input.LEFT,right: Input.RIGHT,up: Input.UP,down: Input.DOWN}});// Draws the state of the game onto the canvas.this.draw();}this.animate();}; This snippet shows a bit of how that functionality works. Here’s a if you don’t know what it does. In case you were wondering, Util.bind() creates a function that binds the context of the Game object to the update() function so that it can be called by requestAnimationFrame(). It’s a nitty hack that goes into the technicalities of JavaScript, so I won’t really discuss that since you can easily achieve the same thing with an anonymous function. link to the requestAnimationFrame documentation is a file I reuse very commonly in my games (with some variation). It binds the necessary event handlers to track user keyboard/mouse input and stores them for easy access. By abstracting away this functionality and keeping it contained in a single class, I don’t have to worry about fetching user input anywhere else. Input.js Although isn’t used in the mockup demo, I’ll explain it quickly here. This file wraps some of the functionality of the amazing library , which I use to play sounds in my games. Upon initialization, it creates Howl objects for every sound that will be used in the game, which can then be played using Sound.prototype.play(). The way I have it implemented, all your sound files must be stored in a folder called “sound” inside the public directory, but this can easily be changed and tinkered with however you see fit. I highly recommend looking through the . Sound.js Howler.js howler.js documentation Moving on, the “shared” directory only contains one file, . Util.js is another one of those files that I recycle frequently between my projects. It contains a variety of useful utility functions that are used on both the client and server side. The “shared” folder is served statically so that I can include the script from an HTML file and require() it from the server side wherever I need. Feel free to relocate this file if you wish; this is just the organization that I found worked for me. Util.js Another way I use the “shared” folder is to store game constants that need to be accessed by both the server and client. For example, I’ll have a class that looks like this: function Constants() {} Constants.PLAYER_HITBOX = 10; Constants.WORLD_SIZE = 2500; if (typeof(module) === 'object') {module.exports = Constants;} else {window.Util = Util;} This allows the class to be handily loaded into the client or server side. The “views” folder is relatively uninteresting and contains the template for the mockup demo. doctype html htmlheadtitle Game!bodycanvas(id='canvas' width='800px' height='600px')script(src='/socket.io/socket.io.js')script(src='/public/bower/jquery/dist/jquery.min.js')script(src='/shared/Util.js')script(src='/public/js/game/Drawing.js')script(src='/public/js/game/Game.js')script(src='/public/js/game/Input.js')script(src='/public/js/game/Sound.js')script(src='/public/js/client.js') I use the , but you could easily plug in any template of your choice. pug templating engine And finally, we have in the root directory. This file is a pretty standard node.js server using the . There are two important snippets to take note of though. server.js express middleware framework const FPS = 60; io.on('connection', (socket) => {socket.on('player-join', () => {game.addNewPlayer(socket);}); socket.on('player-action', (data) => {game.updatePlayerOnInput(socket.id, data);}); socket.on('disconnect', () => {game.removePlayer(socket.id);})}); setInterval(() => {game.update();game.sendState();}, 1000 / FPS); The socket event handlers were covered in , this is the refactored and cleaned up implementation, where we take advantage of the methods we defined in the from earlier. The setInterval() game loop simply runs the game updating and state broadcasting over and over at approximately 60 FPS. part one Game class Next Steps From here, I highly suggest you take this framework and tinker with it. Make it your own, write your own code, print it out and burn it, I don’t care. Try upgrading the physics or writing your own animation engine. I hope you learn something from messing around it and I hope you make something cool. If you do make something cool, please share it with me! I’d be super interested in checking out anything you make. That’s all I have for now. Thanks for reading! Please hit the ❤ button down below if you enjoyed this article :) Follow me on Twitter: @omgimanerd
