I'm currently creating a very simple Pong game in Java that is supposed to work over a network. I based the network design off a previous chat client-task I made earlier which consists of a server and a client. The clients connected to the server have separate threads waiting for them to send information to the server (clients are limited to 2 in the pong game obviously)
The way I designed the pong game is that all game logics are calculated on the server since it's such simple calculations and the data is saved in a PongData object that consists of 4 ints and one point (2 ints for players y-positions, 2 for the score and 1 point for the balls positions), this is then broadcasted to the 2 clients through a ObjectOutputStream and all the clients do is display it on the screen. Whenever they press a button on the client that is broadcasted through a DataOutputStream to the server.
When I run the game locally with a server and 2 clients it works perfectly but as soon as I run one of the clients on a separate computer it laggs very badly basically making the game unplayable. I'm unsure what the best practice to design games like these are, I've looked around stackoverflow and the internet and sending objects through UDP seems fairly complicated and most of all very unsafe but I'm not sure how to do it better through TCP without getting such a heavy lag.
Some additional information I can give is that the game loop thread carries out all the calculations, broadcasts the information and then sleeps for 10 ms before repeating it again which gives the game a good speed (locally at least).
Flush your streams, and call Socket.setTcpNoDelay(true) when creating the socket.
Related
I kinda understand that Websocket is the protocol that is used for real-time data flowing back & forth.
My question can be very pre-mature but couldn't find much help on the web.
Say 1000 clients are connected to a server which sends out real-time stock prices. When there is an update on the server front, how will server know all the 1000 clients to which it needs to send an update?
If this is some sort of looping that happens on the server side where all connected clients details are cached & then update will be sent out to all of them, isn't is an overhead ?
This SOF answer made some sense but didn't clear my doubt.
How does Server keep track of all Client(s) connected in Real time data pushing scenario?
It doesn't... it only keeps track of the clients it's serving specifically.
This answer is not node.js specific.
Say 1000 clients are connected to a server which sends out real-time stock prices. When there is an update on the server front, how will server know all the 1000 clients to which it needs to send an update?
To actually understand this a little better, we should consider larger numbers. i.e., let's assume 1 million clients connected to a service.
Obviously, a sane design will require redundancy, so no single service will hold all 1 million connections (and if a single server instance fails, clients can re-connect to a different server instance).
In this case, there's no single server that is aware of all clients.
It makes more sense for each server to manage it's own internal subscription / client list. Each server will also act as a pub/sub client for a centralized pub/sub service (such as a Redis cluster or whatever).
Assuming 1000 server instances, each serving 1000 clients, we would have find that the pub/sub service is aware only of 1,000 "clients" (server instances). Each server is unaware of the other clients, it's only aware of the 1,000 clients it's managing.
If this is some sort of looping that happens on the server side where all connected clients details are cached & then update will be sent out to all of them, isn't is an overhead?
The algorithm itself is implementation specific, but in general, each server will incur some overhead in order to manage the pub/sub layer.
However, since each server only manages a small subset of the total client count, the overhead is distributed across a number of systems.
Channel Oriented vs. Connection Oriented Design
I should probably note that the pub/sub design isn't connection oriented.
The server isn't (or shouldn't be) looping over all the connections asking "are you subscribed to this channel"?.
Rather, pub/sub design assumes a "channel" oriented design, where it locates the channel object(s) and loops over a client list.
On one hand, this approach might (or might not) consume more memory. Since each "channel" should contain a list of clients listening to that channel, a single client object might belong to more than a single list.
On the other hand, the loop has less code branches and experiences less overhead than a connection oriented design. Also, this approach allows for pub/sub clients that aren't connection bound (such as internal hooks / callbacks).
Say 1000 clients are connected to a server which sends out real-time stock prices. When there is an update on the server front, how will server know all the 1000 clients to which it needs to send an update?
Socket.io already keeps track by itself and its pretty easy to emit to all connected clients.
Socket.io - Emit Cheatsheet
If you are worried about what would happen when your user-base grows, you can scale your service to multiple nodes.
If you actually end up scaling and have more than one server node, then you can use
socketio-redis.
Adapter to enable broadcasting of events to multiple separate socket.io server nodes.
i search the "best practice" to create a simple multiplayer browser game. i have choose nodejs for the backend and maybe Phaser for the front. But i have a question about the algorithm.
In each tutorial the server respond after a client event. But a lot of generic article speak about a loop which send world data at regular interval to all client (for example the valve article).
So what is true ? What is the correct procedure ? It depends of the game type ?
For your information i want to do a simple twin stick shooter with a little world where we must survive as long as possible. And i want to do a cooperative game.
Thanks for help.
You need to distinguish between
updates directly affecting your player which are triggered by actions of other players
and updates which are triggered by actions of your player
If you build your app using Node.js, I assume you are going to work with one web socket connect per client.
You can send data over the web socket connection any time in both directions. There is no restriction at all, as long as the amount of data is moderate.
The server actively sending world data in a loop (implemented using setInterval in JavaScript) is definitely a good choice for informing players if they are affected by actions of other players. You can also use the loop to let the server respond to actions of your player.
If you assume the loop always informs the clients in the same order (e.g. client #1, client #2, client #3, client #1,... and so on), you could optimize performance by preferring clients that are active right now, and are doing heavy activity (that is "the server responds after a client event"). Particularly if you have many players in the game, this could improve user experience.
I am writing a multiplayer real time game for the browser with the server as a master instance and the clients as input devices and slaves to show the graphics.
I have to send out changes in the game world very often and very fast and it doesn't matter if some of the data sometimes gets lost on the way because a couple of milliseconds later there will be the next update anyway.
Right now I am using Socket.io to talk between the server and the clients but this uses TCP which makes the update come in unnecessary late sometimes.
I know that there is WebRTC with data channels where I would be able to send my updates through wit UDP which would be very awesome and exactly what I want. And it even seems to be implemented in Firefox and Chrome already https://stackoverflow.com/a/12864512/63779
What I now need is some Node library which would allow me to use data channels to send my data (for now just JSON strings) with help of UDP to the clients which are browsers. On the browser I would be able to use webkitRTCPeerConnection() but I have no idea how to start something like that on the Node server. Any suggestions? If there is no Node module for that, would it be possible to write something in some other language and just send the data via Unix domain sockets or something?
I'm in process of making realtime multiplayer racing game. Now I need help writing game logics in Node.js TCP (net) server. I don't know if it's possible, I don't know if i'm doing that right, but I'm trying my best. I know it's hard to understand my broken english, so i made this "painting" :)
Thank you for your time
To elaborate on driushkin's answer, you should use remote procedure calls (RPC) and an event queue. This works like in the image you've posted, where each packet represents a 'command' or RPC with some arguments (i.e. movement direction). You'll also need an event queue to make sure RPCs are executed in order and on time. This will require a timestamp or framecount for each command to be executed on (at some point in the future, in a simple scheme), and synchronized watches (World War II style).
You might notice one critical weakness in this scheme: RPC messages can be late (arrive after the time they should be applied) due to network latency, malicious users, etc. In a simple scheme, late RPCs are dropped. This is fine since all clients (even the originator!) wait for the server to send an RPC before acting (if the originating client didn't wait for the server message, his game state would be out of sync with the server, and your game would be broken).
Consider the impact of lag on such a scheme. Let's say the lag for Client A to the server was 100ms, and the return trip was also 100ms. This means that client input goes like:
Client A presses key, and sends RPC to server, but doesn't add it locally (0ms)
Server receives and rebroadcasts RPC (100ms)
Client A receives his own event, and now finally adds it to his event queue for processing (200ms)
As you can see, the client reacts to his own event 1/5 of a second after he presses the key. This is with fairly nice 100ms lag. Transoceanic lag can easily be over 200ms each way, and dialup connections (rare, but still existent today) can have lag spikes > 500ms. None of this matters if you're playing on a LAN or something similar, but on the internet this unresponsiveness could be unbearable.
This is where the notion of client side prediction (CSP) comes in. CSP is made out to be big and scary, but implemented correctly and thoughtfully it's actually very simple. The interesting feature of CSP is that clients can process their input immediately (the client predicts what will happen). Of course, the client can (and often will) be wrong. This means that the client will need a way of applying corrections from the Server. Which means you'll need a way for the server to validate, reject, or amend RPC requests from clients, as well as a way to serialize the gamestate (so it can be restored as a base point to resimulate from).
There are lots of good resources about doing this. I like http://www.gabrielgambetta.com/?p=22 in particular, but you should really look for a good multiplayer game programming book.
I also have to suggest socket.io, even after reading your comments regarding Flex and AS3. The ease of use (and simple integration with node) make it one of the best (the best?) option(s) for network gaming over HTTP that I've ever used. I'd make whatever adjustments necessary to be able to use it. I believe that AIR/AS3 has at least one WebSockets library, even if socket.io itself isn't available.
This sounds like something socket.io would be great for. It's a library that gives you real time possibilities on the browser and on your server.
You can model this in commands in events: client sends command move to the server, then server validates this command and if everything is ok, he publishes event is moving.
In your case, there is probably no need for different responses to P1 (ok, you can move) and the rest (P1 is moving), the latter suffices in both cases. The is moving event should contain all necessary info (like current position, velocity, etc).
In this simplest form, the one issuing command would experience some lag until the event from server arrives, and to avoid that you could start moving immediately, and then apply some compensating actions if necessary when event arrives. But this can get complicated.
I need to write backend for a flash game. The game it self is not complicated. The game itself is a small session(around 2 minutes long) but there are many sessions active at a time. What I though of is making a gateway server which accepts connections and multiple servers that host game sessions. Gateway will tell the game server to create new game session and will forward all messages to it's message queue. Game server will process it and reply back to gateway, which in turn will send response back to the client. I want to do this using mono and run on linux as daemons. Can you give opinions about how to make this architecture better?
UPD: The game is not realtime and avg packets per second from a single game session will be around 5-15. Game session has 2 to 4 players. They all have average size of around 10 to 50 bytes. Udp is possible but will be an overkill, so it will to go with tcp.