EDIT
I'm completely rewriting this since I realized it wasn't very clear what I needed.
So, I'm going to implement an online game. The idea is quite simple. All players have to answer the same set of questions that is downloaded from the server. To answer each question the player has a given amount of time that depends on question difficulty. The questions are presented one at a time. After the time to answer the current question elapses the next one is presented to the player. After the last question the client should display the leaderboard with the scores of all currently online players. The leaderboard is (of course) computed on server and clients should download it when the game finishes.
OK that's the idea. What I require is some suggestions on how to implement the whole client-server communication. I don't need details but just some ideas. Most important I'm not sure how client-server time-sync could work. It's important that all players have the same amount of time to answer each question. I also have a solution that is very simple but I'm not sure about possible pitfalls. What I have in mind is that when the player first connects (or when a new game starts) the client downloads the whole list of questions for current game. Also some time-sync messages are exchanged to get current game time. Then after questions and time-sync are known at the client, a local timer is started and the game runs completely offline. When the game finishes each client sends its own score/result to the server. When the leaderboard is ready the server sends it back to all clients. Once again a local timer could be used to know when a new game is starting and to download the new list of questions.
Please post your suggestions and comment my solution. Thanks
Related
So I had an idea for a program, but I really have no idea if it would work, and I didn't really know where to post this question. I used which computer science programming stack exchange sites do I post on in order to determine, that since this is an algorithmic question (can this algorithm be written), I thought this would be the best place.
So the idea is this. Imagine you are sitting at a table with someone else each of you have a mic, as if you're doing a podcast or something. Your voice is being heard by your mic, and the other mic, albeit faintly.
The question is, can you use the distance between the two mics to act as a filter on your voice only?
Your voice is heard by the mic in front of you first, then by the mic further away from you at a very specific interval, since they are stationary. Any audio elsewhere in the room reaches the two mics at different interval signatures, for instance, if at a perpendicular angle the audio would reach the two mics at the same time.
It seems to me that this relationship could be used to isolate audio coming from a certain angle and filter out all the rest. Is this possible? Is it done already?
So I am trying to make an online webpage board game hybrid of chess and Go where the player clicks on the board to place his/her pieces. My problem is, there are a lot of algorithms that come into play in order to make such a board game possible, that are difficult to write out myself. There are good npm packages that already have a lot of that sorted out (I'm thinking primarily of godash), but in order to use the algorithms the packages provide I believe I have to make some sort of data representation of the game, pass the data to the back-end, use the algorithm on it, and return the result to front-end.
The issue is that, just like chess, the game would require the player to make moves on the board in a relatively short amount of time. The question is, if I decided to make this API call with every move the player makes, would that make my game too slow/unresponsive? Do I have to knuckle down and code those algorithms in front-end so that the game isn't too slow?
You should look into the Websocket API. You can establish a session between your client and server without having to call your server each time a user plays
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've created a multiplayer server for Unity that works like this:
Every client/player connects to the server and says 'hi'.
Server accepts the player and adds him to the players online list.
Every client start sending his position.
Server listens for client's positions and X times per second sends them to all other players online.
This is made by one bucle on all online players, so the server is configured to send say 10 times per second the updated positions to all the players.
Every client listens the server for other players position. When the server says "this player just said he's there", the client moves him there.
With this basic system, I can create a multiplayer game with Unity easily (already did it). But what if there's more than a couple of thousand players online? Then, say that every player sends his position to the server about 10times/sec. And the server has to send those position to all players around, say 100m. So, the server would run a loop for all online players (2000) comparing his position with the all 1999 players and if it's less than a 100m, send the position to the player. Or, maybe better, save all the players updated position in one array and send it to the player. (Only one message every 10s to the player should be better than hundreds, right? Anyway, the loop has to go through 2000*1999 10 times per sec, that could be painful..
I want to use Unity3d as client, I don't want to hold any physics on the server because using the unity's physics engine is good/fast/easy to work with. And I think it could be enough, maybe do some anti-cheating checking on the server-side just to get rid of badplayers.
Now, the questions :)
How does a proper mmo server work? Does every player send its position to the server X times per second and it goes through that HEAVY loop and sends his position to all players around? what about performance?
I would implement a prediction system for the next move and interpolate the current position wit the updated one received from the server. is it right?
If I have to detect player collisions with each other or with objects (bullets and more) would you do it on the client-side? or implement a players-player & player-object collision detection system in the server side and do it in the big loop?
If the player moves is with the keyboard so it doesn't have just a single position to go, how would you send the position to the server, like 10times per second and interpolate the position received by other players to create a smooth movement?
If the movement of the players is by setting force physics to them, like when you go forwards it's because there's a strength pushing you, how would you transmit this information to the other clients? Send just the position to the server and it sends it to the other players? But then, the physics would look weird... The plan b) I thought of is to send the force used to the server and every clients applies the force received by the server to all the players around them, physics here would look awesome but maybe there's a latency problem... Would it be good to use this system and send the exact position every X time? say .5s?
Well, I think this is all! I hope this post can be useful for other indies!
I won't try to answer all your questions, sorry. It would be too long answer. Seems like you need to read a lot of stuff about game physics.
Shortly, if you have large number of online players you need to start thinking about server cluster and scaling. There're two main approaches:
Instances: you have multiple copies of your virtual world/map each handled by separate physical hardware with a hard limit of maximum number of players. Then you start reading about matchmaking.
"Shared universe": split your world to sectors each handled by separated physical hardware. Much more challenging to implement. Can support seamless world.
You can find tons of useful info on www.gamedev.net.
I am developing a simple fast-paced 2 dimensional real-time multiplayer game in Flash. Players can only shoot and walk in point to move fashion. I use TCP socket connection (AS3 doesnt offer UDP).
All I want is to synchronize players' actions so Player1 could see the same on its screen as Player2,Player3... or just see close representation (position,taking damage,etc).
I know movement vector coordinates and I can easily interpolate on them using latency.
However, I can not figure out an effective way to determine how much time (T1) did it take the state update to travel client1-server-client2 and then make corrections to client2's screen based on T1. (You know, ping times may fluctuate quite a bit).I need a way to do the above-mentioned, i need way which is as fast and as accurate as posssible but not extremely sophisticated. (what algorithm should i use? what is the solution - timestamps, maybe or what? - I dont know.)
First of all, I think the server should constantly have updated information about the entire "world". All the clients send their playing actions (that is, what the player does, like movements, shootings, etc) to the server, and using compressed data.
I would divide the "world" into regions. Each player has of course a limited view, so he can't see all the world at once (luckily), thus he needs to get updates to only the regions he can see.
So the thing is:
The server generates the world, and divides it into regions.
When a player enters the world, it gets general information about the entire world and detailed information about the regions in his sight
Each action of a player that has consequences, must be sent to the server (compressed) that acquires the information. If the status change has the effect of changing one or more regions, each user interested in those regions must receive the change notification
It looks like a publish/subscribe design pattern (Observer), but
each client is the publisher and the server is the subscriber for what concerns the player status change.
the server is publisher and the clients are subscribers for what concerns the world change, but only for the regions each player is interested in. this is a particular Observer in that the subscription changes over time (regions) due to movement
I want to make a 2 player pong game that uses websockets and node.js server. socket.io is used on both client and server. So far, my only experience is creating a chat application.
This is my first attempt at a multiplayer game so I'm not so familiar with network gaming. Should the server keep track of:
Every position the ball is at and how often or when?
player movement, player move left or right, what if I press and hold for awhile, how do I handle this? Should I send like a pressHoldStartPosition and pressHoldStopPosition? I guess this is easy if I only allow pressing but not holding down.
My thoughts:
When the ball hits a player, the client calculates velocity, start and end position and the other client should perform the correct animation from that.
No idea.
The clients calculates - nothing - unless you want it to predict next game step* (server anwser). The whole game runs on server which is one and only trustworthy source of data and calculations. In pong like games where there is less than 10 objects you can send data quite often (50ms interval will do). For a ball I'd send [x, y, velocity, or angle], for a paddles [x, y].
Then interpolate (animate in time - 50ms) between old (x,y on client) and new (x,y which you just got from server).
Don't send milion copies of - player pressed up - rather send one packet each period of time (100ms?) containing informations like "player is pressing up" for 100ms, or "player set position" to (32, 100) then check server-side was this move possible and accept it or reject.
Maybe this thread will help with your adventure:
Multiplayer JavaScript game built with Node.JS - Separating players
[*1] preditction is a lag compensation mechanism which you can implement later. In simplified way it means that server and client shares some of game logic code and when client has no current data from server it tries to simulate what is happening in the real game.
You are going to find books, upon books, about gaming networking.
In a brief description, here is what I find an interesting implementation:
The server and the client calculate the physics of the game. The server will be a master, and have a correct state of all the entities, while the client will attempt to "predict" the state of the entities and keep a smooth animation.
The client will get updated the correct state of entities from server periodically. In some games you might see entities suddenly teleport, and that is because client predicted position does not match the server actual position.
An entity state, such as the ball, or the players, usually contains information such as the position, velocity, button state (key down/key up).
Besides that, it is letting your imagination go wild and testing for the best solution and seeing what works. There are a lot to take into consideration, such as player latency and bandwidth.
There is a stackexchange site dedicated to game development: https://gamedev.stackexchange.com/
Best practice is to only send updates that the clients need to know about. Also, generally you send the result of user actions and not the actions themselves. Things that can be calculated (physics) don't need to be sent, except for periodic sync points to account for floating point errors that accumulate error over time and to sync with remote user actions. This also makes the game seem more interactive and covers some of the stutter that results from network latency and jitter.
The main downside to this model is that if you have high network latency or packet drops, you will get the diverging timeline effect when the physics calculation continues and suddenly you get an update from the remote user indicating that they did something to effect the physics that we hadn't caught with yet. But this is a standard problem in most network games and the alternatives are worse for most types of real-time games.