I'm creating a simple multiplayer turn-based game.
I can't decide where to draw the line between putting all the logic on the client or on the server.
Should the client be used just to send input to the server and print/display the responses?(This is my current solution, but seems to make the client too "stupid")
If not, how do I decide what goes on which side?
The game is very simple so I do think I could have any lag or bandwidth problems in any case.
You should always put all the game logic you can in the server, as clientside can be modified and cheat. Never trust the client.
Think of the server as the "game" and the client as the "player". Keep the client as minimal as possible. Restrict the client's influence on the game as much as you can. The client should really only be able to ask to do this and do that, it shouldn't be able to decided for itself what the result of a move be.
A real world example where the client behaved as the server was Halo 3 multiplayer where the game chose a player, part of the match, as the host (server).
Cons:
Players could lag switch other players and cause them to lag. Those players couldn't do anything and the host player just killed them and won the match.
Players chosen as hosts had bad internet and so everyone lagged to the point where a new host had to be selected.
If the host player left the game the match would stop and try to find another host (player) which wasn't always successful or take minutes.
Related
im new to networking and currently im making a multiplayer game via java socket. so i want to ask a simple question. the game will be like this :
the game needs 3 player to start
the tile is 3x3
if all the player already join the server the game will be started
each player will be given a turn to clicking the button that contain image , example : player a clicking button 1 , and then the turn will be given to player b , player b clicking button 2 and then the turn will be given to player c , etc
MY QUESTION IS :
how do i give a timer for each player turn? what i want is if the player doesnt clicking/idle for a period time the turn will be throw to the next player. am i need to manage it in my server or client? and how?
how to handle a player that disconnected? if the player disconnect i want the turn will automatically given to the next player.
In theory, both the client and the server could handle the timer. If the server does it, it starts the timer after giving the turn to player X, and after the timer ran out, it stops the turn of player X. If you do it on client side, the client could just start the timer after receiving the turn, and then send a specific response to the server if the user did not provide input.
Now what is better? Of course the server solution. If your client disconnects, the server would keep waiting for an answer from your client, which might not even come back anymore. So you are better off doing this on server side.
As a client disconnect is a likely cause of such a time-out, you would most likely need to implement it on the server. You can do this for instance by creating a Timer, see e.g. here. Once the timer thread ends, a message could be send to the client that did not respond within time. When doing so, you should take into account that the client is unreachable, of course
So im doing an MMO, i was progressing alot, 6 months progrramming this thing.
The problem is that i was testing offline my game, today i have the brilliant idea to port foward my server and make it online, i knew it was gonna be slighty slower, but its awful! too much lag!!! the game is unplayable.
Im managing my packets like so....
Player wants to move up, client send movePacket to the server, the server recieve it, move the player in the server and send the new position to all clients...
Each time a monster move, the server send a the new position to all clients...
I thought i was over sending packets, but i test it just with the movement of the player... it seems to have a significant delay to recieve the packet and sending them to the client....
Im I doing this whole thing wrong?
Lag is always a problem with online games. While your current method is the standard way of doing things, as your finding out the lag becomes unbearable (a common problem in 1990's and early 2000's games). The best approach to take is the same approach that almost all modern games take which is do as much as you can client side and only use your authoritative server to resolve differences between predictions that clients make. Here are a some helpful ways of reducing perceived lag:
Client-side prediction
For an MMO this may be all you need. The basic idea of client-side prediction is to locally figure out what to do. In your game when Player wants to move up he sends a packet that says [request:1 content:moveup] then BEFORE receiving a response from the server, the client displays Player moving up one (unless there you can already tell that such a move is invalid i.e. moving up would mean running into a wall). If your server is really slow then Player may also move right before receiving a response so your packet next packet may look like [request:2 content:moveright] at which point in time you show your player to the right. Keep in mind at this point Player has already moved up and right before the server has even confirmed that moving up is a valid move. Now if the server responds that the new player position after packet 1 should be up and the position after packet 2 should be right then all is well. However, if lets say another player steps happens to be above Player then the server may respond with the player in a new location. At this point Player will 'teleport' to wherever the server tells him he's supposed to be. This doesn't happen often but when it does happen it can be extremely noticeable (you've probably noticed it in commercial fps games).
Interpolation
At this point your probably fine for a MMO game but in case it isn't (or for future reference) interpolation is your next step. Here the idea is to send more data regarding rates at which values change to help make the movement of other players smoother. This is the same concept as using a taylor series in mathematics to predict values for a function. In this case you may send position as well as velocity and maybe even acceleration data for all the entities in the game. This way the new position can be calculated as x = x + v*t + 0.5*att where t is the frame rate. Again, you show the player's predicted position before the server actually confirms that this is the correct position. When the next packet from the server comes, you'll inevitably be wrong most of the time but the more rate data you send, the less you'll be off by and thus the smaller the teleportation of other entities is.
If you want a more detailed outline of how to deal with lag in online games read the mini bible on multiplayer games: http://www.gabrielgambetta.com/fast_paced_multiplayer.html
I'm using Opengl and Jbox2d to write a real-time 2d game in Java.
I want to start coding the networking components.
Although it uses box2d, my game is very small and I want to create a bare-bones architecture using the Kryonet library.
The program itself is a 'match game' like chess. The most logical system I can think of would be to have dedicated server that stores all player data.
PlayerA and PlayerB will connect with the dedicated server which will facilitate a TCP link between their computers.
When the match is complete, both players will communicate the resulting data back to the dedicated server, which will authenticate and then save over their respective player data.
For those familiar, Diablo2 implemented a similar setup.
I want this TCP connection to simply send the shape coordinates Vector data from the host (lets say playerA) to the client (player B) which the client will then render on its own.
Then I want the client to send mouse/keyboard data back to the host. All of the processing will be run on the host's computer.
My first question: Are there any flaws in this network logic?
My second question: How does one implement barebones server/client packet transferring (as described) using Kryonet?
Note: I have done this exact type of packet transferring in C++ using a different library. The documentation/tutorials I've found for Kryonet are terrible. Suggesting another library with good support is an acceptable answer.
I know this is an old question, and I'm sure OP has gotten their answer one way or another, but for fun I thought I'd respond anyway. This exact question has been on my mind since I've been playing around with game development using Kryonet very recently.
Some early network games, such as Bungie's Marathon (1994) seemed like they did exactly this: each player's events would be sent using UDP to other players. Thus, if a player moved or fired a shot, the player's movement or shot's direction, velocity, etc. would be sent to other players. There are some problem with this approach. If one of the player's actions are temporarily lost over the network, a player or players appeared to be out of sync with everyone else. There was no "truth" or "reconciliation" of game state in such situations.
Another approach is to have the players compute their movements and actions client-side and send the updated positions to the dedicated server. With a server receiving all player state updates, there is an opportunity to reconcile them. They also do not become out of sync permanently if some data is lost on the network.
To compare with the previous example, this would be equivalent of each player sending their positions to the server, and then having the server send each player's position to all the other players. If one of these updates gets lost for some reason, a subsequent update will correct for it. However, if only key presses are sent, a single lost keypress throws the game out of sync because all clients are computing the other clients' positions separately.
For action games you can use a hybrid approach to minimize apparent lag. I've been using Kryonet successfully in this manner for an action game. Each player sends their state to the server at every render tick (though this is probably excessive and should be optimized). The state includes position, number of shots left, health, etc. The player also sends the shots they take (starting velocity and position.)
The server simply echos these things back to clients. Whenever a shot is received by a client it is computed client-side, including whether or not the shot hits the receiving player. Since the receiving player only computes their own state, everything appears to stay in sync from their own point of view. When they are hit, they feel the hit. When they hit another player, they believe they've hit the other player. It is up to the player "receiving" a shot to update their health and send that info back to the server.
This does mean that a shot could theoretically lag or "get lost" and that a player may think their shot has hit another player, while on the other player's screen no hit occurred. But in practice, I've found this approach works well.
Here's an example (pseudocode, don't expect it to compile):
class Client {
final Array<Shot> shots;
final HashMap<String, PlayerState> players; // map of player name to state
final String playerName;
void render() {
// handle player input
// compute shot movement
// for shot in shot, shot.position = shot.position + shot.velociy * delta_t
// if one of these shots hits another player, make it appear as though they've been hit, but wait for an update in their state before we know what really happened
// if an update from another player says they died, then render their death
// if one of these shots overlaps _me_, and only if it overlaps me, deduct health from my state (other players are doing their own hit detection)
// only send _my own_ game state to server
server.sendTCP(players.get(playerName));
}
void listener(Object receivedObject) {
if(o instanceOf PlayerState) {
// update everyone else's state for me
// but ignore my own state update (since I computed it.)
PlayerState p = (PlayerState)o;
if(!p.name.equals(playerName) {
players.add(p.name, p);
}
} else if (o instanceof Shot) {
// update everyone else's shots for me
// but ignore my own shot updates (since I computed them.)
Shot s = (Shot)o;
if(!s.firedBy.equals(playerName) {
shots.add(s);
}
}
}
}
class Server {
final HashMap<String, PlayerState> players; // map of player name to
void listener(Object receivedObject) {
// compute whether anybody won based on most recent player state
// send any updates to all players
for(Connection otherPlayerCon : server.getConnections()) {
otherPlayerCon.sendTCP(o);
}
}
}
I'm sure there are pitfalls with this approach as well, and that this can be improved upon in various ways. (It would, for example, easily allow a "hacked" client to dominate, since they could always send updates that didn't factor in any damage etc. But I consider this problem out-of-scope of the question.)
This is a school project, please do not provide any code, I am only looking for hints to guide me in the right direction.
Write and test a game server that clients subscribe to. Once subscribed, the client receives
a list of games (the same game, just different 'instances' of it) currently in play. The client may then elect to join a game or start a new
one. A game must have at least two players before actually starting. The system must support multiple clients all playing one game, or multiple clients playing multiple games.
The objective of this project is to gain experience in Java, TCP, and threading.
My current design and implementation has 2 files: server.java and client.java
The server file has 3 classes: Server, Lobby and Game
The client file has 1 class: Client.
The implementation of the "game" is trivial, I am fine with that.
Currently, the server class establishes the TCP connection with the client class.
Each time a client is instantiated, the socket is accepted in the server class, and the program continues.
Continuing on, the server class creates the lobby class.
The lobby class is where I am having trouble with. By default, I am creating 1 "game" object, and passing in the clientSocket:
game g = new game(clientSocket, playerID);
g.start();
The game class extends thread, which I think is the correct way of doing it. Each "game" will be a separate thread, so to speak, so players A and B can share 1 thread, and players C and D can start a new game with another thread.
I am new to threads, but this is the best implementation I could think of. I ruled out having multiple threads for lobby's, since that doesn't really make sense, and multiple threads for clients is pointless too, so I think multi-threading the games class is ideal.
Right now, when I create 2 instances of the client, they are both joining the same 'thread' (they are both in the same game and can talk to each other).
How am I supposed to do it so that, a new player can type "new" or whatever in the lobby and create a new "game", where it's a new thread.
I'm sure I mis-understood certain parts about threading or whatnot, but I appreciate any help.
I wouldn't map games to threads. Instead, map clients to threads. Each client will have their own thread that does work initiated by the receipt of commands from that client. When you need to create a new game, just create a new object in a shared collection of games. Track, in the client instance, which game, if any, it's associated with.
If you find you really do need a thread to manage a game, then you can create one. When a client sends a command to a particular game, just put that command on a queue of commands that's read by the thread managing that game. The game thread only needs to know which game it's managing. It can terminate itself when that game is finished.
Firstly, I would suggest you read on multiplayer game development and networking in Java (UDP/TCP). I am no game-developer but simply happenned to take a Java networking course in college and had a similar project (a networked game).
Secondly, dealing with multiple threads is proportional to complexity. You want to minimize complexity. I would suggest to abandon an "I have to find a place to use threads" mentality. (Don't force a square peg in a round hole ;))
Continuing, following through the requirements:
Write and test a game server that clients subscribe to.
IIRC, this is fairly straightforward (and you're probably past this part).
Once subscribed, the client receives a list of games (the same game, just different 'instances' of it) currently in play
This should be fairly straightforward as well since a TCP connection between the server and client have been established already.
However, there are a couple of things to understand at this point. The most important, perhaps, is that there will be a single central server that will hold information on all connected clients and existing games. This consequently means that it has to be the one to deal with the state of the system (e.g. tracking currently existing gamerooms), client requests (to create/join gamerooms), as well as updating clients with relevant info on the system's state (e.g. created/closed gamerooms).
Another consideration at this point is the scope of client's functionality in the system. A typical implementation would probably be a fat-server, thin-client architecture. Basically, this means that a client does no real processing of data (from user input) and instead relies on the server. Most of the time, then, the client is only waiting for input from user or a response from the server. On the otherhand, the server deals with the processing of data from clients, updating the system state (including individual game states), and notifying concerned client of relevant changes in the system/game state.
The client may then elect to join a game or start a new one
What actually happens here is a client sending data "I elect to join a game" or "I elect to create a game" to the server. The server acts on this and notifies concerned clients (I say concerned and not all since some clients could possibly be playing and do not need to know whether new games have spawned).
A game must have at least two players before actually starting.
-
The system must support multiple clients all playing one game, or multiple clients playing multiple games.
Again depending on the client-server architecture, either the server will be doing all the processing (fat-server, thin-client) or the clients (thin-server, fat-client) do the processing while the server mainly serves as a relay point to other clients. I have no definite (or even confident) suggestion on this, however, as I am simply overwhelmed by the sheer number of possible implementations and their consequences. Thus, I can't really encourage enough to read more on networking and game development. Individually, those 2 topics are incredibly vast, much more when combined.
Lastly, with regards to the use of threads. IIRC, dispatching separate threads for opened sockets are useful in preventing the application from getting blocked waiting for input. I don't really agree with your idea of "hosting" a game in a thread but since you're in school I can only admire your trying things out.
This may help you further: Lesson: All About Sockets. And you might perhaps also be interested in UDP.
I am making an multiplayer game in Java, and i am using a tcp connection for client/server communication. I tried to optimize the transmission by making it send packets only when there are changes in the game, googling the issue, flushing the objectstream and socket after each transmittion, and i set the setTcpNoDelay to true. But i still can see lag, and sometimes the incoming packets stall for a few seconds(sometimes forever(or a very long period that i didn't try to wait)), until another packet is sent(sounds like buffering to me).
I didn't test it over lan, just on my localhost.
I know that Minecraft is written in Java, and it works very well with minimal lag, so there must be a way to fix this...
Are there any other tips that i can implement to speed up the tcp client/server communication?
Edit: The player instance includes the player speed, so between two incoming packets the game runs the other players from last known position with the last known speed.