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
Related
I am working on a smartwatch project. I want the display to be turned off and only come on when the user brings his hand into the watch-viewing position.
I am running my application on the NRF52 MCU which means machine learning is out of the question. I am using a 3-axis accelerometer from STM.
How can I detect when a user moves his hand into the typically watch viewing position? How is this achieved in smartwatches?
I have the following ideas so far:
- Constantly poll accelerometer and calculate pitch and roll values. Then determine what range of pitch and roll values corresponds to this gesture. This seems a bit wasteful because the CPU will have to be always active.
Is there a simple signal processing algorithm or something similar that can achieve this?
Look into Galvanic skin response sensor - It can measure electrical connectivity of the skin.
When internal or external forces cause arousal — of any kind — the skin becomes a better conductor of electricity. Essentially, when you start to sweat, either from exercise or something else, the band will be able to monitor that.
Detecting when someone is sweating gives the software more information about what a user is doing, which allows for better health tracking. Being able to correlate the level of activity with a different source than just gravity from the accelerometer, allows these programs to take on a more trainer-like role — recommending specific exercises and levels of exertion.
Hope this helps!
I am working on a project that involves many clients connecting to a server(servers if need be) that contains a bunch of graph info (node attributes and edges). They will have the option to introduce a new node or edge anytime they want and then request some information from the graph as a whole (shortest distance between two nodes, graph coloring, etc).
This is obviously quite easy to develop the naive algorithm for, but then I am trying to learn to scale this so that it can handle many users updating the graph at the same time, many users requesting information from the graph, and the possibility of handling a very large (500k +) nodes and possibly a very large number of edges as well.
The challenges I can foresee:
with a constantly updating graph, I need to process the whole graph every time someone requests information...which will increase computation time and latency quite a bit
with a very large graph, the computation time and latency will obviously be a lot higher (I read that this was remedied by some companies by batch processing a ton of results and storing them with an index for later use...but then since my graph is being constantly updated and users want the most up to date info, this is not a viable solution)
a large number of users requesting information which will be quite a load on the servers since it has to process the graph that many times
How do I start facing these challenges? I looked at hadoop and spark, but they seem have high latency solutions (with batch processing) or solutions that address problems where the graph is not constantly changing.
I had the idea of maybe processing different parts of the graph and indexing them, then keeping track of where the graph is updated and re-process that section of the graph (a kind of distributed dynamic programming approach), but im not sure how feasible that is.
Thanks!
How do I start facing these challenges?
I'm going to answer this question, because it's the important one. You've enumerated a number of valid concerns, all of which you'll need to deal with and none of which I'll address directly.
In order to start, you need to finish defining your semantics. You might think you're done, but you're not. When you say "users want the most up to date info", does "up to date" mean
"everything in the past", which leads to total serialization of each transaction to the graph, so that answers reflect every possible piece of information?
Or "everything transacted more than X seconds ago", which leads to partial serialization, which multiple database states in the present that are progressively serialized into the past?
If 1. is required, you may well have unavoidable hot spots in your code, depending on the application. You have immediate information for when to roll back a transaction because it of inconsistency.
If 2. is acceptable, you have the possibility for much better performance. There are tradeoffs, though. You'll have situations where you have to roll back a transaction after initial acceptance.
Once you've answered this question, you've started facing your challenges and, I assume, will have further questions.
I don't know much about graphs, but I do understand a bit of networking.
One rule I try to keep in mind is... don't do work on the server side if you can get the client to do it.
All your server needs to do is maintain the raw data, serve raw data to clients, and notify connected clients when data changes.
The clients can have their own copy of raw data and then generate calculations/visualizations based on what they know and the updates they receive.
Clients only need to know if there are new records or if old records have changed.
If, for some reason, you ABSOLUTELY have to process data server side and send it to the client (for example, client is 3rd party software, not something you have control over and it expects processed data, not raw data), THEN, you do have a bit of an issue, so get a bad ass server... or 3 or 30. In this case, I would have to know exactly what the data is and how it's being processed in order to make any kind of suggestions on scaled configuration.
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 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.
It's about latest Juggernaut gem (https://github.com/maccman/juggernaut)
I'm thinking of architecture, for, let's say, 'Dots games'. This meta-game is very simple: each logged in user (subscribed to channel, in terms of Juggernaut) is a dot of random color on JS canvas. User can move his dot any direction. That's it.
Juggernaut should transport and push all data for clients connected.
Currently i immagine architecture as:
1) Client(s) pushes coordinates of dot and player's id ([1, [10,299]]) as ajax to, for example, Rails.
2) Rails pushes this data to Juggernaut
3) Juggernaut push coordinates back to all clients who listen to this channel.
Juggernaut.publish("coordinates_channel", [1, [10,299]])
Problems:
1) When i need to pixel-by-pixel movement for 'dot' object on js canvas, i'll need to send too many AJAX requests. For example, if my dot moves 20 pixels per second, i'll need to send 20 requests per second. Unacceptable.
2) Should i wrap Juggernaut.publish into asynchronous loop (using EventMachine for example)? Because, just immagine 1000 of clients (1000 of dots, and constant flow of data with updated coordinates)...
Or maybe i get wrong client-server using Juggernaut gem? What do you think of this implementation?
Thank you.
WebSockets/Long polling/other comet techniques have low latency, your game will lag. I have seen implementations of real time games via websockets, they either lag, either game mechanics are made specific, like making the players move really slow to account for low latency. Classic AJAX is definitively out of the question.
Here's some resources on improving lag
Valve Source Multiplayer Networking
Unreal Source Multiplayer Networking