I am programming a MMO Tower Defense game (Client Server architecture). Because of cheating protection, the server needs to have the logic. But I have real design problem. When lets say 10 People fight deathmatch against each other, every tower shoot needs to be calcuted and send over to the players. When many towers are build. (Like 10 Players * 10 Tower = 100 Tower ) the traffic is very high. (One player causes many messages per second) How can I solve this problem?
Server is written in Java ( Smartfox 2x)
Client is written in C# ( Unity 3d)
Thanks in advance.
Use strong simplified Units and combat rules on the server. Just program your damage algorithm by affecting continuous damage over time if someone is stepping into the "Damage area" around the tower.
U can use tow dimensional battlefields on the server where all units and towers and damage areas are just circles or oints and circles. U can also use several rings of damage with damage per second is lower in the outter circles and higher at the inner circles around the defense tower.
U can use queues for managing single target damage / multi target damage and area damage. Just the first in the queue is affecting by the damage area if single shot, just the first, second and third is affected by multi shot etc.
If a tower shoot a bullet every 5 seconds and does 40 damage per bullet u just calculate on the server by affecting a damage of 8 per second for every target standing in the "Damage area" or "damage circle".
On the client u can all the things like flying bullets and hitting and splish and splash and fireworks and so on.
But on the server do all the stuff by entering damage areas and then get damage per second. (sorry for bad english)
Because of cheating protection, the server needs to have the logic.
This is a false assumption. The server needs to have sufficient logic to run game logic and make sure that all players' actions make sense, but it does not need to send back the results. The clients can all run that same logic in parallel and figure out the results on their own.
Related
From here maps Voice Guidance ,Exactly When Google TSS will speak about Maneuver Take left into X road ,Now take Right, like that.
Consider Navigation Distance 10km ,when trip started there is Turn left in 500m meters ,so when Google TTS will speak?before 300m or 200m ?
I want to know the triggering point to speak for My task to complete.
--suppose speaking Text is long(eg:Now keep right and then turn slightly right onto JC Road) Speaking logic distance will also change?
--Apart from TBT(Turn By Turn Info) here maps also triggering in middle to speak like ( After 250 meters keep left towards Hosur Road ) how this is calculating
So many questions is single please excuse me
Interface for notifying NavigationManager.AudioPlayer functions used by NavigationManager. Clients can take over playback of audio files and TTS text strings by implementing this interface and submitting to NavigationManager.AudioPlayer.setDelegate
The audio will be played during the entire route, playing the audio based on distance calculation logic can not be done.
I’m developing a multiplayer network pong game, my first game ever. The current state is, I’ve running the physic engine with the same configurations on the server and the clients. The own paddle movement is predicted and get just confirmed by the authoritative server. Is a difference detected between them, I correct the position at the client by interpolation. The opponent paddle is also interpolated 200ms to 100ms in the past, because the server is broadcasting snapshots every 100ms to each client.
So far it works very well, but now I have to simulate the ball and have a problem to understanding the procedure.
I’ve read Valve’s (and many other) articles about fast-paced multiplayer several times and understood their approach. Maybe I can compare my ball with their bullets, but their advantage is, the bullets are not visible. When I have to display the ball, and see my paddle in the present, the opponent in the past and the server is somewhere between it, how can I synchronize the ball over all instances and ensure, that the it got ever hit by the paddle even if the paddle is fast moving? Currently my ball’s position is simply set by a server update, so it can happen, that the ball bounces back, even if the paddle is some pixel away (because of a delayed server position).
Until now I’ve got no synced clock over all instances. I’m sending a client step index with each update to the server. If the server did his job, he sends the snapshot with the last step index of each client back to the clients. Now I’m looking for the stored position at the returned step index and compare them. Do I need a common clock to sync the ball?
EDIT:
I've tried to sync a common clock for the server and all clients with a timestamp. But I think it's better to use an own stepping instead of a timestamp (so I don't need to calculate with the ping and so on - and the timestamp will never be exact). The physics are running 60 times per second and now I use this for keeping them synchronized. Is that a good way?
When the ball gets calculated by each client, the angle after bouncing can differ because of the different position of the paddles (the opponent is 200ms in the past). When the server is sending his ball position, velocity and angle (because he knows the position of each paddle and is authoritative), the ball could be in a very different position because of the different angles after bouncing (because the clients receive the server data after 100ms). How is it possible to interpolate such a huge difference?
As you are developing your first game, I think you should try the simplest but brute-force method first. Then you will experience the first exciting result, then you will get courage and try the better methods.
Like Source Engine method, process the game play in one side and send every object state to the other for each 1/30 second. This is a brute method but it works in LAN environment.
Now you will find problems that occur WAN environment where latency is more than 1/30 second.
I am not sure it works actually, but I think that:
Assume that the movement of ball does not change by only player's hit.
Send ball position P, velocity and player A position only when player hits the ball to B.
At B, receive it but process it as if time L is already passed (L=latency between A and B * 2) However, rendered ball should be keep its previous movement until it reaches the ball position P.
Values which never are affected can be masqueraded, even if it is time value. :)
From a programming/network point of view, what are the reasons why there are very few/no larger scale games than 16v16?
There are some 32v32 games but these are seeming exceptions to the rule.
Quite simply, scaling is hard and/or expensive, and O(n^3) is usually a pipe dream. For a game of 2v2, and a naive communication algorithm, you need each computer to communicate with ((2*2)-1) = 3 other computers (not counting some sort of connection mediation server), which comes to ((2*2)!/2) = 12 connections altogether ; likewise, for n versus n players, each computer needs to communicate with ((n*n)-1) computers, which comes to (n!/2) connections altogether.
That becomes ridiculous rather quickly, and other approaches are needed, such as "all players communicate with a central server, which provides them with updates". That is slightly more scalable, but only up to a point. Calculating state for 64 players and communicating with them (and keeping the game state synchronized, even through short disconnections!) isn't exactly simple, especially for games where latency matters (e.g. FPS).
Having massive server farms (with huge pipes to the net) which are dedicated and customized for this, can help, but it's expensive (that's a large part of your WoW subscription); if one of the players' computers is doing this work, lags will become drastically more apparent - both for lack of processing power, bandwith, and latency.
I presume you are talking about mostly first person shooter game, as MMO game supports more than 32 players online at the same time.
From a programming/network point of view, there are no reason that most computer games are no more that 16vs16. A common server can handle the load without problem, and bandwidth wouldn't be a problem.
It's really a game issue. Game that have more than 32 players is more chaotic that nothing else.
OK, I was just fooling around in my spare time and have made this cool interface and game-playing code for a Connect-4 type game, written in Flex and playable by 2 human players in Flash. It accurately detects wins, etc. I'm smart enough to know that I've done the easy part.
Before I dig into an AI for game play, I wanted to ask if this is the kind of thing that can really be handled computationally by a Flash plugin. It seems to me that for every turn up until the end there are 8 possible moves, 8 responses to each move, etc. So wouldn't a perfect engine have to be able to potentially see 8^8 moves (over 16 million), and a fairly good engine see up to a million? I don't know game coding so this is new to me. What's a reasonable move horizon for such a game to be able to see?
Connect-4 has been solved mathmatically, so your AI could win every time (if it plays first) with the right database of correct moves.
Otherwise, your brute-force 'looking ahead' scenario would not be as easy as you suggest: connect-4 has a 7 wide by 6 high board (yours may be different) - so the longest game could take 42 turns (7 possible moves each time, or fewer towards the end), so a perfect engine might potentially need nearly 7^42 moves (ie more than 3x10^35)... this is obviously a LOT more than 16 million.
It would still be an interesting project, though...
I'm thinking about making a networked game. I'm a little new to this, and have already run into a lot of issues trying to put together a good plan for dead reckoning and network latency, so I'd love to see some good literature on the topic. I'll describe the methods I've considered.
Originally, I just sent the player's input to the server, simulated there, and broadcast changes in the game state to all players. This made cheating difficult, but under high latency things were a little difficult to control, since you dont see the results of your own actions immediately.
This GamaSutra article has a solution that saves bandwidth and makes local input appear smooth by simulating on the client as well, but it seems to throw cheat-proofing out the window. Also, I'm not sure what to do when players start manipulating the environment, pushing rocks and the like. These previously neutral objects would temporarily become objects the client needs to send PDUs about, or perhaps multiple players do at once. Whose PDUs would win? When would the objects stop being doubly tracked by each player (to compare with the dead reckoned version)? Heaven forbid two players engage in a sumo match (e.g. start pushing each other).
This gamedev.net bit shows the gamasutra solution as inadequate, but describes a different method that doesn't really fix my collaborative boulder-pushing example. Most other things I've found are specific to shooters. I'd love to see something more geared toward games that play like SNES Zelda, but with a little more physics / momentum involved.
Note: I'm not asking about physics simulation here -- other libraries have that covered. Just strategies for making games smooth and reactive despite network latency.
Check out how Valve does it in the Source Engine: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
If it's for a first person shooter you'll probably have to delve into some of the topics they mention such as: prediction, compensation, and interpolation.
I find this network physics blog post by Glenn Fiedler, and even more so the response/discussion below it, awesome. It is quite lengthy, but worth-while.
In summary
Server cannot keep up with reiterating simulation whenever client input is received in a modern game physics simulation (i.e. vehicles or rigid body dynamics). Therefore the server orders all clients latency+jitter (time) ahead of server so that all incomming packets come in JIT before the server needs 'em.
He also gives an outline of how to handle the type of ownership you are asking for. The slides he showed on GDC are awesome!
On cheating
Mr Fiedler himself (and others) state that this algorithm suffers from not being very cheat-proof. This is not true. This algorithm is no less easy or hard to exploit than traditional client/server prediction (see article regarding traditional client/server prediction in #CD Sanchez' answer).
To be absolutely clear: the server is not easier to cheat simply because it receives network physical positioning just in time (rather than x milliseconds late as in traditional prediction). The clients are not affected at all, since they all receive the positional information of their opponents with the exact same latency as in traditional prediction.
No matter which algorithm you pick, you may want to add cheat-protection if you're releasing a major title. If you are, I suggest adding encryption against stooge bots (for instance an XOR stream cipher where the "keystream is generated by a pseudo-random number generator") and simple sanity checks against cracks. Some developers also implement algorithms to check that the binaries are intact (to reduce risk of cracking) or to ensure that the user isn't running a debugger (to reduce risk of a crack being developed), but those are more debatable.
If you're just making a smaller indie game, that may only be played by some few thousand players, don't bother implementing any anti-cheat algorithms until 1) you need them; or 2) the user base grows.
we have implemented a multiplayer snake game based on a mandatory server and remote players that make predictions. Every 150ms (in most cases) the server sends back a message containing all the consolidated movements sent by each remote player. If remote client movements arrive late to the server, he discards them. The client the will replay last movement.
Check out Networking education topics at the XNA Creator's Club website. It delves into topics such as network architecture (peer to peer or client/server), Network Prediction, and a few other things (in the context of XNA of course). This may help you find the answers you're looking for.
http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1
You could try imposing latency to all your clients, depending on the average latency in the area. That way the client can try to work around the latency issues and it will feel similar for most players.
I'm of course not suggesting that you force a 500ms delay on everyone, but people with 50ms can be fine with 150 (extra 100ms added) in order for the gameplay to appear smoother.
In a nutshell; if you have 3 players:
John: 30ms
Paul: 150ms
Amy: 80ms
After calculations, instead of sending the data back to the clients all at the same time, you account for their latency and start sending to Paul and Amy before John, for example.
But this approach is not viable in extreme latency situations where dialup connections or wireless users could really mess it up for everybody. But it's an idea.