Please contact me at robertbcorey@gmail.com if you are interested in programming tutoring. SOURCE CODE: Term. Collaborate on apps with your teammates, build starter apps for your next hackathon, or use Glitch to teach others how to create with code. This poker game server is created by Raymond Xie, published under MIT license. It can be used for FREE, but be aware that: It is provided as it is. (Not a mature commercial product, may be incomplete, or even lots of bugs). Casino-server -:fire: An online poker game server powered by Redis, node.js and socket.io 1071 Redis is an open source, BSD licensed, advanced key-value cache and store.

Multiplayer and browsers

When you consider making multiplayer games, there are many methods available for creating a game that friends can play online. There is a good variety of multiplayer game types - take for example a card game you play synchronously with friends. Turns are made, information is exchanged in (semi) real time and the game progresses in discrete steps. Another example, Chess, can be asynchronous. Players take their time, contemplating possible actions and play their next move one week from now. These types of multiplayer games exist in browsers, and have for a long time. The nature of the browser itself makes it easy to make semi real time games, but we want more-visceral real time action.

Card games and Chess both usually require communication with a server and communication with the other players in order to work online. This is the foundation of a multiplayer experience to be possible - and for a long time this has existed via HTTP, where POST and GET have always been used to manage games.

The trouble with these methods is the delay, posting a message and waiting for a response each time is just too slow. It works for the semi real time and asynchronous games, but real time games require messages sent and received sometimes in the region of 33~66 times per second, something that is not quite possible with HTTP alone.

Luckily, in modern browsers we can take one step higher, and have a real time connection between a server and clients. The purpose of this discussion is to present one overview of how multiplayer games are made. We will look at input prediction, lag compensation, client interpolation and more importantly - how to do this in your normal browser using websockets. The article will present a playable demo with parameters to play with, showcasing the concepts discussed.

The technologies that we have chosen and why

Socket.io

socket.io is a powerful and flexible server-side and client-side component that enables real time networking in your browser. Not only does it support newer technologies like web sockets, but it also falls back safely onto a Flash networking layer, XHR or JSON long polling and even an HTML file transport layer. Most appealing about it perhaps is the simplicity and inherently asynchronous nature it brings, which is extremely useful when writing server and client code.

Another benefit of using socket.io is the fact that it ties into Node.js seamlessly. When coupled with Express, on connection, it can serve the client-side includes, game files, and data, making the integration clean and easy. Once you set it up, the amount of code between first connection and communication with a client is nothing short of amazing. And it would work in all browsers, mobile included.

Node.js

node.js is an easy to use, flexible and cross platform tool. It is like a swiss army knife of evented IO. It has a massive following of dedicated users, developers and module authors. It is supported on a good number of server hosting platforms for web applications, and is easy to install on a dedicated server of your own, so finding a host should not be a problem.

Among many of these great modules available for Node.js, is a web framework called Express. It covers serving files, complex routing, client authentication and sessions, and much more. It fits perfectly into the stack between socket.io and our clients, where socket.io can serve its files to the clients through Express and Express can handle the game content for us.

Canvas/HTML5

This article uses a 2D canvas to demonstrate the methods we are going to cover, which allows us to draw some text and boxes really easily.

Getting started with a real time multiplayer connection in your browser

Covering all possible options and installations and configurations for the above technologyis a little out of scope for this article, but each of the above tools have their own documentationand should not take long to have set up and working together. For the sake of brevity we will dive right into making a simple game example instead. The information below is the minimum required to set up an empty canvas, connect to the socket.io server and receive messages.

Start with a simple web server, enter Express

The code for a simple Express server is really short and straightforward. It serves files on a port specified (4004 in this case) and it only serves files from the root folder (like index.html), and from a specific ‘game’ path we specify (like game/).

Socket.io, adding the real time component

Now we add the code for the socket.io part of the node.js server. It goes in the samefile as the Express code, just below it as shown in the gist. The server will attach itself to Express so that it may serve the client files when requested. We do not handle any sessions in this example specifically, but you can learn about using those from this site: http://www.danielbaulig.de/socket-ioexpress/.

Index.html, connecting a client to the server

The client side needs very little code to be able to connect to the server. As we go further, it becomes more intwined, but this is all that is required to connect to the server and send or receive data.

Getting into the gameplay

What we need now is a simple interactive example for this to tie into, to get our feet wet. We are going to have two blocks running around in the same space. There is a lot of code and logic that goes into creating something that runs smoothly over the internet, and any game related code getting in the way is not as useful to this article. Instead, we focus on the multiplayer and use a simple example to demonstrate.

Some notes on developing real time games

Not all developers make games. There are some things that are new to developersthat are entering the world of games that should be covered briefly.

Frame rate independence

When a block travels across the screen, it can be a simple line of code. block.position.x+= 1; This 1 here, what unit is that measured in? Actually, this is one pixel - but it is moving 1pixel per frame. Each time the loop runs, we move one pixel. That is - at 30 frames per second, it moves 30 pixels. At 60 frames per second, it moves 60 pixels. This is really bad for games, because hardware and performance can vary from one device or computer to another. Even between different browsers, thisproblem can be a huge difference. One player reaches the wall, the other barely moves at all.

In order to ensure that the block moves the same distance over the same amount of time, theconcept of delta time is used. This value is the milliseconds per frame (mspf), which is measured while updating your game. It is how long one update takes. By taking the time at the start of your loop, and the time at the end of the loop, you can work out how long the update has taken.

At 30 frames per second (1/30) the delta is about 0.033s. One frame, every 33.3 ms. At 60 frames per second (1/60) the delta is about 0.016 or 16.66 ms per frame. So lets say that the ball is moving at 1 pixel per frame. To solve the problem of frame rate dependence, we multiply any change in position by the mspf value, balancing out the time, making the distance always the same.

Our example calculation becomes ball.position.x += (1 * deltatime);. With bigger delta (slower frame rate) the ball moves more pixels - reaching the destination at the same time as ata smaller delta (higher frame rate). This gives us concrete units that will act the same atany render speed. This is critical for animations, movements and pretty much any value that changes over time: they all should be scaled to the mspf.

Planning for change

Nodejs Poker Server Bot

Games are often a dynamic thing: they require tweaking and changing of many values to feel good. Iteration is a big part of getting this right. This is common sense for most programmers, but always try and design your code so that you have as many values and variables as possible to tweak. Then expose them in a really easy to