A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.
7

Sure it is an overhead, but if your packets generally ain't much larger than the example you give it is not much overhead, pretty insignificant relative to general overhead of sending a package. Of course a denser format is a small performance improvement, and it should be considered. At the early development however I'd stick to something like JSON for ...


7

I take it all the variable name are broadcast as well. Isn't that a huge overhead? That's the case, and yes that's quite an overhead. Wouldn't it be better if I glued all data together using delimiters like this (...)? The disadvantage here would be that I have to split the string each time I receive it. But isn't that much better for latency? That ...


7

Hello visitors of Jindsay's Card Game Forum. Here is your friend xXx_GameH4x0rPhilipp_xXx with another cheat for you. Do you want to win every game? Here is a simple hack which works with every web browser: Press F12 Click on "Debugger" Select check_win.js There is now a window with lots of programming code. Don't worry, you don't need to understand any of ...


6

If you need an active connection and literally real-time gameplay, then go with WebSockets, or a similar technique like Comet. Note that WebSockets requires a recent browser, while Comet is probably good enough for most purposes with better support for older browsers. For example, Facebook and Google use Comet for their technologies (Facebook Chat, Google ...


6

Nic explained this to me briefly yesterday. Check out the explanation on his blog. http://nic-gamedev.blogspot.com/2011/11/mmo-architecture-creating-ghosting.html


6

Yes. You definitely should. Use Let's Encrypt to get a free SSL certificate (or as many as you want or need). SSL is always good to have: without it, man-in-the-middle attacks will be launched, by the NSA if no-one else. Most multiplayer games (e.g. Minecraft) just use raw packets. There's little reason to encrypt packets after one is authenticated as only ...


5

This is too broad, you need to work out some things. What do you call a high-performance server. You can get some very powerful servers with 4 CPU sockets and such. But it is likely 4 servers with a single socket may be cheaper. Real time (meaning each game instance must be processed all the time at some frequency) or turn based (meaning you just need to ...


5

If you're willing to ease on the requirement that a client should be informed of other clients that are exactly 200 blocks away or closer, then here's an idea: split your map to squares of, say, 200 blocks each side. Then you can keep track of where the client is, and inform the client of all other clients in the adjacent squares. More detailed discussion ...


5

Introduction There are pros and cons to each method of synchronization you gave that depend on a couple of factors. First, is your game singleplayer or multiplayer, second, how real-time is your game? If your game is only single player, you may want to consider having a client side only game which would make things simpler. However, assuming you need a ...


5

Doing basically anything on client-side apat from the inputs is a bad idea. And believe me, if the programmers could collect inputs on the server side, so the client couldn't fake them, then they would happily do so. Literally anyone can change the code to always register a winning condition. If they make it send it back to the server, than it's even worse. ...


5

1: Should the client wait for confirmation before moving the player? Websockets use the TCP protocol, which can have very irregular latencies from time to time (which is usually why UDP is recommended for real-time games, but that's not available to browser-based Javascript). When the reaction to each input is not just delayed but delayed irregularly, your ...


4

It's quite an advanced topic, and as word of warning I'm hesitant to indulge too much in to this because I only know some theory and haven't actually produced an MMO. In MMOs, optimization is perhaps the primary factor in decision making on the technical side. The more users you are able to host, the better. It's easy to accidentally use poorly scaling ...


4

Websockets are a very elegant and fast way to implement asynchronous communication between client and server. But they are far from the only. When low latency isn't that important for you, you can substitute it with XmlHttpRequest (aka "AJAX"). But for a real-time action-oriented game, WebSockets are usually the superior solution.


4

Socket.io will emit connected event for every connected socket. So in your case you will create loads of loops there. It is better to have list of sockets, and one loop separately. As you've said - your case is simple - so keep it simple, do not overcomplicate. var sockets = { }; server.on('connected', function(socket) { // runs for every connection ...


4

ajax / html request Slowpoke. Good for loading pages without navigating to another url. No good for action games but should be fine for turn based games I imagine. That is unless it's a very fast paced turn based game (think roguelike fast). The good thing is that the server only needs to handle one request at a time. So the server code is serial and not ...


4

Unless you want players to be able to teleport through walls using their browsers build-in JavaScript debugger, you will have to implement any game mechanics worth manipulating on the server. This will lead to more noticeable lag, so you might implement it both on the client and the server. That way the client can perform the action locally so the player ...


4

System.Net.WebSockets seems to be completely built-in to .Net and freely available in Unity. Here's a full Websockets client for Unity for example: using System; using System.Text; using System.Threading; using System.Net.WebSockets; using UnityEngine; public class Comms: MonoBehaviour { Uri u = new Uri("ws://blah blah.us-west-1.compute.amazonaws.com:...


3

You don't necessarily need a timer on the server but you do need the server to be checking time(1) That is, that game should keep track of when the turn started, so that it can compare against this timestamp when it receives moves from the client. (1) Assuming the time limit for turns has any effect on the game results. The rule of thumb with these things ...


3

If you want to use sockets, you should probably choose a different language, perhaps Python or Node.js (server-side JavaScript); PHP is best suited for generating HTML in response to requests. Sockets would be used for truly real-time data, but PHP would be adequate for data that can be a few seconds delayed; you would just need to have the client keep ...


3

I'm far from an expert but I've been working on an HTML5 version of Pong that uses Websockets for multiplayer so I can share what's been working for me. The general maxim I've been living by is: "Send the minimal amount of information necessary as infrequently as possible." In my case I maintain the state of the keyboard by listening for the keyup and ...


3

Refer to this article: http://gafferongames.com/game-physics/networked-physics/ In short: Physics is run on the server according to a stream of input from clients This means the actual physics/collision runs on the sever, and client simply sends player input and renders server output to screen. Server continuously broadcasts required rendering ...


3

SockJS has a test suite which includes some smoke tests that report latency. For example, here's a test that does cursor tracking. Select 'websockets' from the drop down and click 'connect'. Mind that it's hosted in Europe; I get about 30ms. Also note that it polls at 5Hz, so the cursor movement is not an indication of latency, only the 'latency' field is. ...


3

Send as few packets as possible, with as much detail in them as needed, without impacting on the players' experience of the game. Do not send every entity's movement to every player. "Activate" entities for players based on whether they're within a certain range (sight + 20%, perhaps) and inform them about actions only then. As for the attack function, it'...


3

When you have a massive multiplayer game, then giving everyone information about everyone is often overkill (upload bandwidth on the server would increase quadratic with the number of players). In many cases it is completely sufficient to only send updates about those players which are close enough to appear on the player's screen and omit updates for those ...


3

Websocket sharp: https://github.com/sta/websocket-sharp It has a unity version which I've used as part of a cross-platform library and on a couple of local multiplayer games, and worked well. I have not tried using the server part of it though - only the client. That said are you sure you want to have a unity app be the server? It might be more trouble ...


2

Take position of player A. Subtract position of player B. Get the length of the resulting vector. If it's under the sightrange, add the other player to a list that a player can see. This will help you with all updates, ie you don't need to send all movement/socials that a player that isn't visible is doing. You can do the initial check fairly seldom(say once ...


2

Does this mean I have to maintain a list on the server which player can see another? Basically, yes. The way we did it on a previous project was that each character had 2 lists: one of IDs of the characters that it knew about, and one of IDs of characters that knew about it. (Obviously it's possible to derive the 2nd list from the 1st but it's quicker just ...


2

Websockets are definitely the way to go. There are indeed solutions out there that allow you work with websockets smoothly and very fast. A couple were already addressed here and I work for Realtime.co. One of our priorities was precisely providing developers with a way for them to start working with this new technology (with fallbacks, of course) in a very ...


2

Your players may hack your game. Verifying things on the server is good to combat that but potentially bad for performance. Collision detection can fail if not done carefully. Say the particle is moving quickly and you're only testing for intersection with an object. If the particle moves from one side of the object, through the object, and on to the far ...


2

With an authoritative server, there is no way of being 100% fair without exposing the player to latency. There is always the possibility that the player made a sudden move that didn't reach the server before the ball passes the paddle, resulting in the player failing even when he should have hit it. But if the ping is low enough and 100% fariness is not ...


Only top voted, non community-wiki answers of a minimum length are eligible