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.
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!
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 need to measure the time between 2 points. I can not use a simple watch because i have no free hands for this. (mountainbike - downhill)
My first idea was to set two GPS points and measure the the time between those points, but I think it will be to inaccurate.
my second idea was to set one bluetooth device to each Point and just measure the distance from me to the bluetooth device , check the shortest distance and save the time.
But than I realized that I would need 3 bluetooth devices to make a distance calculation, which is kinda annoying.
Any idea how i can measure the time between two points with an accuarcy <1sec ?
I want to control this via smartphone.
edit:
Okay i have another idea. Maybe i could set one bluetooth device to each point. I set the signal strenth to <=1m. Than i could easily start and stop the time until i receive the bluetooth signal on my android.
Do you think this would be the best approach ?
It seems you're trying to take total and split times for a course. Definitively, forget of using bluetooth for other things that are not constant transmissions, with slow connection time... (I speak from experience). Of course you want to do it in the cheap, because there already professional solutions for that (e.g.).
From my point of view, if you want something accurate and been able to integrate it with you phone, you'll need the following:
DIY photocell sensors. Maybe involving simple chip (e.g. msp430), phototransistor-diode pair, cheap 433mhz transmitter and batteries.
DIY 433mhz receiver for your phone. There already many boards that supports android open accessory library, (e.g. 49$ from sparkfun), so you only have to connect it to a 433mhz receiver and to your phone.
Custom code programming in your android phone. To be able to receive the signals from the split signal senders and keep track of all times.
It seems to be a pretty decent project for under $250-200(if you self made it :P).
One possible solution that does not require any special hardware would be to use a smartphone at the finish line. You would only need an extra smartphone (SP) with net connection, and some software.
SP sends the start signal to your phone. You start when you hear the signal.
SP uses its camera to detect when you reach the finish line.
SP calculates the time between start and stop and displays it, and possibly sends the info to your phone, too.
Maybe you could even record a video with time stamps.
(Of course, the low cost solution would be to let one of the guys to use a stopwatch at the finish line.)
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
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