7

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 ...


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

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....


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

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

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

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

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

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

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 ...


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

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

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

As the documentation says, The Unity scripting API does not expose direct WebSocket access itself. But you can access the native web browser API by calling JavaScript from Unity C# scripts. Create a JavaScript file which defines the functions you need and implements them by calling native browser functionality. Give it the file extension .jslib Put it into ...


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 ...


2

As for the update frequency it depends from the type of game. For an action type of game 30 updates per seconds should be perfectly smooth, but for an mmorpg (where you have thousands of players) better use something like 10 per second, to save server time. I doubt there will be any reason to have 60 updates per second, that will just use a lot of server ...


2

Your game timing system should have its own internal clock that is started when the game begins (this can be setup by the server to force clients to be the same). Have you considered using this internal timer? It would be valid, and the same across all clients.


2

In desktop games this is usually resolved by having the client assume it's allowed to do something (and running it's own physics engine etc). You could do the same thing here. The client uses the server to sync for online save or multiplayer and the server can reject events sent from the client; if this is the case the clients environment is set to what the ...


2

The problem with REST is that it is based on HTTP, which is not a protocol designed for low latencies or minimizing traffic. When you just want to send a few bytes, the HTTP header will generate huge overhead. Keeping a websocket connection open is far better when it comes to overhead (although not as good as "naked" sockets), but they still have the ...


2

In my case the problem was the line endings being generated in part of the response header I was creating in LabVIEW. I had a pre-built string that included everything but the base64 handshake, and then manually added the line endings to the end. The first 3 lines only ended with \r instead of the necessary \r\n. I discovered the discrepancy when checking ...


2

I would suggest not using Socket.IO's rooms mechanism. It is not very flexible and isn't very appropriate for a robust server architecture. Here's a quick scribble of how you could structure your rooms on the server. Obviously you'll want to use your own class for Player instead of the socket object, lookup rooms by id etc, but I wanted to keep the example ...


2

What is clear for me is: any input the characters receive needs to be sent to the server and updated the other client. any map event logic will stay on the server and update clients when happening That is the gist of it. where do you place basic physics? like keeping the character on the map Given that you have decided on a central server... Physics ...


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