I'm coding simple game which I plan to make multiplayer (over the network) as my university project.
I'm considering two scenarios for client-server communication:
The physics (they're trivial! I should call it "collision tests" in fact :) ) are processed on server machine only. Therefore the communication looks like
Client1->Server: Pressed "UP"
Server->Clients: here you go, Client1 position is now [X,Y]
Client2->Server: Pressed "fire"
Server->Clients: Client1 hit Client2, make Client2 disappear!
server receives the event and broadcasts it to all the other clients.
Client1->Server: Pressed "UP"
Server->Clients: Client1 pressed "UP", recalculate his position!!
[Client1 receives this one as well!]
Which one is better? Or maybe none of them?
The usual approach is to send this information:
Where the player is
At what time he is there (using the game's internal concept of time, not necessarily real time)
The player's movement vector (direction and speed)
Then the clients can use dead reckoning to estimate where the other players are, so that the network latency will disturb the game less. Updates need to be send only when the player changes his direction or speed of movement (which the other clients cannot predict), so also network bandwidth will be saved.
Here are some links on dead reckoning. The same web sites contain probably also more articles on it.
http://www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php
http://www.gamedev.net/reference/articles/article1370.asp
i think the first approach is better. so you have equal data on all clients.
when the physics are simple and the results of the calculations are always the same the second approach is ok too. but if there are random numbers possible you will have different effects on all clients.
Related
I have a small Clojure game (think Snake but multiplayer; if you hit another snake, you lose) running over WebSockets - logic is in the Clojure backend, rendering is in the browser.
Every "turn" of the game takes 100ms, during which the game steps, which involves 1) calculating the next state of the game, 2) sending the game state to every player over WebSockets 3) checking if the game is over, and if not 4) sleeping for 100ms minus the time it took to do steps 1-3, and 5) looping back to 1.
There is a global atom games, which is a map from a UUID to a game map (has player coordinates, directions, etc.). When a player presses an arrow key, the browser sends a message containing the game's UUID, the player's UUID, and the move. On receiving that message (independent of the game loop), the server directly modifies the games atom to update its to-moves map to say that the player with some UUID wants to turn :right. Step 1) above takes the to-moves list and changes each players' directions accordingly before moving each player forward (every 100ms). This method works.
I learned about core.async (go, channels, parking, etc.) but I'm not sure if it would be applicable in this case. I was originally thinking that instead of a :to-moves map as part of the Game, I have a buffered channel instead. Then when a player submits a move I can do (>!! ch [<player-uuid> :left]), for example. And when I calculate the next game, I can get the moves with (
This is more of a learning project, so if core.async will pretty much be the same as my current method that's fine. But is it applicable in the first place?
Thanks.
Firstly, I'm assuming that when you say "running over websockets" you mean that you're running ClojureScript in the browser and that you want to use core.async in the browser to decouple your websocket communication implementation from the event generation.
In that case, core.async channels is a very neat fit since you can setup your websocket as a consumer on a channel and pass that to all the pieces like the keyboard event listeners to write to.
It also lets you then setup an outgoing channel that you can cleanly hook up to your game state and make the changes received from the server into the atom.
The point of it is to introduce the decoupling so that as long as you implement some kind of thing that gives you an input and output channel, it'll work. You could replace the websocket implementation with a dummy test or replace the events and game state management with simple listeners and emitters so you have a nice seam to isolate bugs with.
I'm currently trying to write (as a part of "simple multiplayer game as an example of real time client-server application" assignment) multiplayer game server for simple fast-paced game for few players (less than 20 i think). I'm using TCP sockets for packets that require guaranteed delivery (ie.: chat messages, login and logout requests, ping packets, etc) and UDP for everything that does not necessarily need to be delivered since only the last packet that got through is important (ie.: user input, game world and objects updates, etc).
I should mention here, how my game world looks like. Every object server side has its id, role and owner members. Id is basically identifier for clients so, once I send them object updates they know which object to update on their side. Owner is information about object owner, ie.: player which controls the actor. I use it to remove orphaned objects once player loses connection / logs out. Most objects however has this value set to Server. And finally role determines whether object is important to clients. This can be set to ServerSide (for objects that do not need to be replicated to clients as they are only used in server side game state calculation), RelevantToOwner (this objects get replicated only to their owner, ie.: player private inventory does not need to be replicated to everyone), RelevantToList (object gets replicated to all players from list, ie.: i have list of players to whom the object is visible and i replicate only to them) and RelevantToAll (replicate to everyone).
When user sends login packet I check whether I have free slot and if yes, then I replicate world to him (send current world state - every object that does not have role set as ServerSide or RelevantToList - unless of course the client is on the list for that object).
Then after each iteration of server game state update loop I send exactly same thing - whole world state.
When users send logout packet I remove him from logged in clients, free slot, and remove all orphaned objects from game world (objects that had this user as owner).
Here are my questions:
Is this model suitable for real-time multiplayer game or am I doing it horribly wrong?
Is there a way to reduce amount of packets sent after the initial world replication (ie.: updating only objects which state has changed since last iteration. I've given it a thought and so far I've encountered one huge problem with this approach - if UDP packet from previous iteration is lost and state of the object haven't changed in subsequent iterations, the object will not be updated on the player side.)
How can i pack multiple object updates into one packet (I'm currently sending one object / packet which is inefficient and also probably horribly wrong.
Could someone point me to some working example (source would be nice) of simple Client/Server game so I can see how professionals do it? C++ or C would be nice but Java / C# / Python are fine too.
This depends a lot so much on what type of game you're talking about - example: Im doing roughly the same thing in a text based muck game.. My updates are simple, on arrival, send room details. On change, send messages to say people/object came/went. Done.
UDP is how most online games work just because they need to deal ith 100k+ connectios. UDP loss is often why players "warp" in game. If you're doing 20 people and you can guarentee that, then sticking with tcp will help.
do you need to send them the whole world? Is your world not made of zones/rooms. Normally you send the smaller area. It also depends on how much data on the objects within that you should send, for example. If a player has an inventory, no point sending that to all the other players unless they specifically ask for it - items worn (if a visual game then yes you need to or it draws them wrong)
Just because we have much faster connections these days doesnt mean we shouldnt take into consideration some people dont. You should try and send updates only and have the client maintain its own state, and then, when you change zones, and reload the area, you ensure sync.
To pack object changes in a packet, most likely Im guessing its location changes, eg co-ordinates, and availability, eg, person picks up item. Have an upate structure, item_id, update_type, update_values[], then you can send a chunk of updates.
Are you after text based or more mmorg type? text based I can say google tinymuck, or tinymush, tinymud, there are plenty, graphics ones? thats harder, you could lookup some of the old EQ code and WoW emulators maybe..
Question: Is it possible to update 100+ objects in the Flash Player over Socket Connections? More details and my own try's below!
Details
For my internship I got the time to create a multiplayer physics game. I worked for a steady three months on it. My internship is coming to an end and I couldn't finish my game.
My problem is that its hard to send multiple packets each time-step to the server and back. The packets I send are position updates of the objects and mouse of other clients.
I will try to explain the network/game flow.
Client connects to the server using the binary Socket class in AS3
Server ask for verification and client sends name and thumbnail.
Server waits until 4 clients are connected (Some matchmaking etc)
Server picks 4 clients and makes them run on a separate Thread(Combined as a Team)
Client sends his performance score to the server range 1-100.
Server makes the best client the host machine for the physics and the other 3 slaves
Host game sets up the level and makes around 1-100 shapes in the level(primary shapes and complex shapes like bridges, motors, springs)
Every time-step the host gets all updated property's of the shapes and sends them to the clients (x, y, rotation, sleep)
The client applys all the shape property's to the correct shapes
I tried different time-steps and noticed that until a time-step of 1/15 second the client(slave) won't notice any lagging in the game. I also tried to pick a lower time-step and tween the movement of the shapes but that did give some strange movement on the client(slave) side.
I will give an example of a single object update packet.
<O|t=s:u|x=201|y=202|f=automaticoo</O
<O|t=m:p|x=100|y=345|f=automaticoo</O
I noticed that the Flash Player can stack a lot of packets in the buffer before sending. For example if I send a lot of packets at once it stacks them up and send them together to the server. With faster time-steps you don't get more updates on the client(slave) side but more updates in the same packet row.
Tries
Use the new RTMFP(udp & p2p) protocol for updates. (little bit better in performance but less in reliability)
Code my entire socket server in c++ instead of Air(with the ServerSocket) (better in performance but noticed the lagging part is not the server but the Flash Player)
Use the ByteArray compress method and the AMF serialized format (performance about the same except the c++ server can't unserialize the messages)
Do you guys think it is possible in the Flash Player too handle so many update request each time-step.
Discoveries
There is a stick arena game that is multiplayer in ActionScript 3.0. They used a lot of tricking and even then I get a ping of about 300ms and it only updates the players constantly (4 players in a lobby).
Sorry for the long post.
I believe your problem comes down to type of game and data.
This again is broken up into:
server speed (calculations need in CPU + RAM requirements for world/player data)
connection speed (bandwidth on server)
data size (how much info is needed and how often)
player interaction form (event or FPS)
distance from client to server (ping)
MMORG
Eg. World Of Warcraft, is to my knowledge on the none-PVP worlds using a "client is a viewport" and "client sends keystrokes", "server validates and performs, and tells client what happens" on a CLIENT-SERVER base.
This gives the game a lot of acceptable latency as you only need to transfer commands from client and then results to the client. The rest is drawn on the client.
Its very event driven and from you click an icon or press a key, its okay that your "spell" needs some time to fire on the server. Secondly there is no player collision needed. This lets the server process less data too and keeps the requirements to the server CPU smaller.
Counter-Strike / Battlefield etc.
FPS, fast paced action, with quick response needs to get information about every detail all the time. This makes a higher demand on precision. Collision is a must for both player and weapons.
This sort of game usually doesnt handle more than 32 players on a single map, as they all need to be able to share their positions, bullets, explosions etc. very fast and all this data has to go through the server-validation which again is a bottleneck for any type of online game.
Network latency
In a perfect world this would be 0 ms, but as we all know. All the hardware from client to the server and back takes time. Both going through the network stacks and through the internet connection (switch, router, modem, fiber centrals etc) so the way many modern real time games fixes this is by "prediction". The let the server look at your direction and speed. Then they try to predict (much like the GPS do in a tunnel too) that you were last seen moving forward with a speed of +4 so given timeframe you have moved (timeframes x 4) - but what if you had slowed down or speeded up? then they either instantly "hyperjump" you from A to B in a split second and this you feel like a lagging game or they easy up to the real position so your "hero" slides a little faster or slower into the right possition.
This technique is explained many places on the net, so no need for details in here, but it takes time and tweaks to get a good performance from this - but it works and saves a lot of headaches for the programmers.
What network data is needed?
I read your question and thought: that could be compressed quite a lot. Secondly, I have made a Flash socket chat with pure ByteStream and that worked awesome. It was hard to get running for a start, but once I got it up and running it was fast.
The flash client/player itself isnt the biggest networking client, so expect a lot of lost speed there too. I would go for 10-15 fps for the networking part and then use a more RAW approach for the data sent back and forth.
Lastly, try to keep the data as simple as possible.
Eg. use COMMANDS/SHORTCUTS for certain data/events.
Like a server data bytestring could be: 0x99, 0x45,0x75,0x14,0x04,0x06
Where 0x99 means : BIG EXPLOSION at the following COORDS: (0x45,0x75)
Then 0x14 means: PLAYER 0x14 (player 20 in decimal) has moved to (0x04, 0x06)
So the staring opcode tells the networking protocol handler in your client and server what to expect next. (Its how a CPU knows how to read memory btw.)
For my chat I had commands for each type of data parsed. One for login, one for broadcasting, for for telling the name of a user etc. So once the client made a login, the client received a command + a packed of online users. This was only transfed once to the client. After that each attached client received a "new user online" command too with the name of the new user. Each client maintained its own list with current users and ID's so that I only needed to tell which client number say the text. This kept the traffic at a minimum. Same would go for coordinates or commands of what to do. "Player #20 goes north" etc. could be be 0x14, 0x41, 0xf0 (0x41 could be MOVE, 0xf0 could be NORTH, 0xf1 EAST etc.)
This physical distance to the game
This one you cant change, but you can put in some restrictions or make the servers run in multiple locations worldwide, depending on what type of game you wanna make. Amazon EC2 is a great platform for such projects as they have data-centers all over the world and then you can benchmark the users network against these and then redirect the users to the nearest datacenter where you are running a server.
Hacking/cheating
Also remember, if something gets popular and you start earning money on it, sooner or later SOMEONE will try to break the protocols or break down the accounts to gain access to servers, informations or cheat to get further items/points in the games. You could also be attacked by DDOS where they bomb your network with wrong data just to crash everything and render the game unusable.
Dont mind it so much for a start, just remember that once you go online, you NEVER know who in the world or where in the world they are. I'm not trying to make you paranoid, but there are sick people who will try to earn money by cheating others.
So think this into your structures, dont show data in network packages that isnt needed. Dont believe data from client always is correct. Validate data on server-side.
This also takes time if you have 100 active players at the same time.
But once you do it, you can sleep much better if it gets to be a big success for you, which I really hope.
That was my thoughts from experience. Hope some of it might be usefull eventhough I didnt quite answer if 100 players are possible.
Infact I would say: YES 100 players is possible, but it depends if they all move at the same time and there is collission testing involved and if you will accept lag or not.
Question: Is it possible to update 100+ objects in the Flash Player over Socket Connections?
Phosphor 2 seems to pull it off.
Maybe the best option was do the physics on server AND on each client, with synchronization (server object positions are overwriting client's). This way all clients get equal lags. Until discrepancy is low (as it should be) corrections will not be noticeable. If you use Box2D, you have both AS3 and C++ version ready. But this is totally different architecture, worth 3 month to implement by itself. What lag do you get on empty/simple arena? In limited time, simplification may be your only option.
I am making a multiplayer game in c++ :
The clients simply take commands from the users, calculate their player's new position and communicate it to the server. The server accepts such position updates from all clients and broadcasts the same about each to every. In such a scenario, what parameters should determine the time gap between consecutive updates ( i dont want too many updates, hence choking the n/w). I was thinking, the max ping among the clients should be one of the contributing parameters.
Secondly, how do i determine this ping/latency of the clients ? Other threads on this forum suggest using "raw sockets" or using the system's ping command and collecting the output from a file .. do they mean using something like system('ping "client ip add" > file') or forking and exec'ing a ping command..
This answer is going to depend on what kind of a multiplayer game you are talking about. It sounds like you are talking about an mmo-type game.
If this is the case then it will make sense to use an 'ephemeral channel', which basically means the client can generate multiple movement packets per second, but only the most recent movement packets are sent to the server. If you use a technique like this then you should base your update rate on the rate in which players move in the game. By doing this you can ensure that players don't slip through walls or run past a trigger too quickly.
Your second question I would use boost::asio to set up a service that your clients can 'ping' by sending a simple packet, then the service would send a message back to the client and you could determine the time it took to get the packet returned.
If you're going to end up doing raw-packet stuff, you might as well roll your own ICMP packet; the structure is trivial (http://en.wikipedia.org/wiki/Ping).
The enet library does a lot of the networking for you. It calculates latency as well.
I've already developed some online games (like chess, checkers, risk clone) using server side programming (PHP and C++) and Flash (for the GUI). Now, I'd like to develop some kind of game portal (like www.mytopia.com). In order to do so, I must decide what is a good way to structure my server logic.
At first I thought in programming separated game servers for each game. In this way, each game will be an isolated program that opens a specific port to the client. I thought also in creating different servers to each game room (each game room allow 100 clients connected on the same time). Of course I'd use database to link everything (like highscores, etc).
Then, I guess it is not the best way to structure a game portal server. I'm reading about thread programming and I think that is the best way to do it. So, I thought in doing something like a connection thread that will listen only to new connection clients (that way every type of game client will connect in only one port), validate this client (login) and then tranfer this client to the specific game thread (like chess thread, checkers thread, etc). I'll be using select (or variants) to handle the asynchronous clients (I guess the "one thread per client" is not suited this time). This structure seems to be the best but how do I make the communication between threads? I've read about race conditions and global scope variables, so one solution is to have a global clients array (vector or map) that need to be locked by connection thread or game thread everytime it is changed (new connection, logout, change states, etc). Is it right?
Has anyone worked in anything like this? Any recommendations?
Thanks very much
A portal needs to be robust, scalable and extensible so that you can cope with larger audiences, more games/servers being added, etc. A good place to start is to look into the way MMOs and distributed systems are designed. This might help too: http://onlinegametechniques.blogspot.com/
Personally, I'd centralise the users by having an authentication server, then a separate game server for each game that validates users against the authentication server.
If you use threads you might have an easier time sharing data but you'll have to be more careful about security for exactly the same reason. That of course doesn't address MT issues in general.
TBH I've been doing a voip system where the server can send out many streams and the client can listen to many streams. The best architecture I've come up with so far is just to bind to a single port and use sendto and recvfrom to handle communications. If i receive a valid connect packet from a client on a new address then I add the client to an internal list and begin sending audio data to them. The packet receive and response management (RRM) all happens in one thread. The audio, as it becomes ready, then gets sent to all the clients from the audio thread. The clients respond saying they received the audio and that gets handle on the RRM thread. If the client fails to respond for longer than 30 seconds then I send a disconnect and remove the client from my internal list. I don't need to be particularly fault tolerant.
As for how to do this in a games situation my main thought was to send a set of impulse vectors (the current one and 'n' previous ones). This way if the client moves out of sync it can check how out of sync it is by checking the last few impulses it should have received for a given object. If it doesn't correspond to what its got then it can either correct or if it is too far out of sync it can ask for a game state reset. The idea being to try and avoid doig a full game state reset as it is going to be quite an expensive thing to do.
Obviously each packet would be hashed so the client can check the validity of incoming packets but it also allows for the client to ignore an invalid packet and still get the info it needs in the next update and thus helping prevent the state reset.
On top of that its worth doing things like keeping an eye on where the client is. There is no point in sending updates to a client when the client is looking in the other direction or there is something in the way (ie the client can't see the object its being told about). This also limits the effectiveness of a wallhack packet sniffing the incoming packets. Obviously you have to start sending things a tad before the object becomes visible, however, or you will get things popping into existence at inconvenient moments.
Anyway ... thats just some random thoughts. I have to add that I've never actually written a multiplayer engine for a game so I hope my musings help ya a bit :)