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
Related
i need a bpm counter witch send a message if a tempo of incoming Audiosignal changes. Have anyone an idee?
It sounds like you're really new to Max MSP and audio processing in general so I really can't stress the importance of understanding how audio processing works in general and how much you'll learn just going through all the built in tutorials in Max. Beat detection is a pretty complex thing though, take a look at how even pro softwares like Ableton and Traktor have trouble tracking beats sometimes, and they have people who've worked on their algorithms for years.
There are a number of ways you can do an implementation in Max, it really depends how much time you want to spend and how complex you want to make it. The simplest would be to put a low pass filter on your track (if you're measuring against the kick drum), and then get the level of the signal, then set a numeric threshold that triggers when the level goes over a certain value, and have that connected to a bang that is connected to a tap tempo calculation. You can find an example of a tap tempo at this link: https://cycling74.com/forums/topic/tap-tempo-2/
Another option is to use the beat~ object found here: http://web.media.mit.edu/~tristan/maxmsp.html
For the message sending side of things, who are you sending a message to? You can use udpsend to send messages over the network, you can send midi out values, or just use the built in send and receive objects if you're just sending data around in Max.
I have an app that goes out and gets a large number of points for each zip code in a given geography. It then turns those points into a polygon roughly (since the data had to be shrunk down to send in a timely manner) representing the boundaries of a zip code and then places them on GoogleMaps. Each zip code has a popup and a color with additional info.
My question is: What is the best method of trying to keep the script from crashing on devices like iPad when the script has not hung but just needs time to process through all the data coming back to make a shape and draw it on the map?
My current thought is web workers doing part of the computation but since it still needs to come back to the main thread because it needs the window and document object there might be alternatives that I havent thought of.
The fastest way to do it would be to move the heavy rendering to the server-side, though that may not be practical in many cases.
If you do want to take that route, check out Google Maps Engine, a geo DB that can render large tables of polygons by rendering the shapes server-side and sending them to the client as map tiles.
If you're keen on keeping it client-side, then you can avoid locks on platforms like the iPad by releasing control back to the browser as much as possible. Use setTimeout to run the work asynchronously and try to break it up such that you only process a single row or geometry per setTimeout call.
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.