I wonder how it's possible to "calculate" or plan/estimate what kind of combat system I can make for a game in my example an mmorpg.
Because some mmorpg's I've played have sooo slowpaced combat.. where each special move you make takes several seconds and isn't spammable.
When I ask why they say the servers can't handle more fast paced combat.
But WoW has a pretty fast paced combat.. and it's somewhat spammable abilities etc.
It also depends on what server you have too.. but is it really so much more expensive to get a quality server?
I guess it has something to do with messages you send and receive to server..
is that all?
Or is there more?
What are limits on what kind of combat system you can make for different games?
It depends entirely on your game.
What is your game? How is it designed? How is it implemented? Those questions define your answer.
What is your game? How is it designed? How is it implemented? Those questions define your answer.
Author
It depends entirely on your game.
What is your game? How is it designed? How is it implemented? Those questions define your answer.
I don't really know how to answer your questions..
What is my game?
mmorpg.
how its designed?
open seamless world.
implemented?
Dont know what you mean.
Another example of a mmorpg with fast paced combat is ultima online..
i mean there you do more than just spamm abilities.. you feint spamm them... start attack and cancel it repeat spamm thats like abilities used every half sec or less.
and ultima online is an old game too.. not sure if that makes a difference but I would guess so.
UO was open and seamless world too.
One thing has nothing to do with the other. You're basically asking if a car will travel faster with a specific color of paint. They are design and stylistic choices.
Games with fast paced combat have fast paced combat because the designers wanted to make a game with fast paced combat. If bandwidth or processing power becomes a limiting factor, then you either have fewer players per instance, or you dial back the design a bit.
Also don't confuse what you see on the screen with what is actually being processed in the game's internal logic, or what information (at what frequency) is being sent back to the server. The drawing on screen is just an illusion to represent the current game state visually.
eg: If a user in a war game with 60 players running around climbs a tower and starts firing a chain gun, it doesn't mean you have to process all the fake bullets or send a stream of stuff to the network. You need only create a cylinder to represent the area of fire for the duration of the shooting, and only send messages to change the direction or cease. Anything that enters that area will take X damage per second.
Same with a shotgun blast. All you need is the origin + the direction. The pellets can be represented by a cone that is the size of the known pellet spread * the known distance.
Simple enough.
In a lot of MMOs you aren't controlling your character directly, just clicking buttons to add action/command objects to a queue that will be played out. The animations, exact positions, and speed is just being played out for you on your client and will often not match what is seen on the other player's screens.
Games with fast paced combat have fast paced combat because the designers wanted to make a game with fast paced combat. If bandwidth or processing power becomes a limiting factor, then you either have fewer players per instance, or you dial back the design a bit.
Also don't confuse what you see on the screen with what is actually being processed in the game's internal logic, or what information (at what frequency) is being sent back to the server. The drawing on screen is just an illusion to represent the current game state visually.
eg: If a user in a war game with 60 players running around climbs a tower and starts firing a chain gun, it doesn't mean you have to process all the fake bullets or send a stream of stuff to the network. You need only create a cylinder to represent the area of fire for the duration of the shooting, and only send messages to change the direction or cease. Anything that enters that area will take X damage per second.
Same with a shotgun blast. All you need is the origin + the direction. The pellets can be represented by a cone that is the size of the known pellet spread * the known distance.
Simple enough.
In a lot of MMOs you aren't controlling your character directly, just clicking buttons to add action/command objects to a queue that will be played out. The animations, exact positions, and speed is just being played out for you on your client and will often not match what is seen on the other player's screens.
One major limitation is bandwidth. Even if you can in principle scale out external bandwidth almost indefinitely, your internal bandwidth is limited. Also, external (and internal) bandwidth translates directly into money (the same is true for CPU time).
Usually you pay for some quota, but whatever it is, it is never free, and is never unlimited (if someone tells you "unlimited", you either have to pay a 5-figure bill every month upfront, or they're simply lying). If you significantly exceed your quota, one of two things happens. Either you get a bill that will make you faint, or your server is shut down without notice. Or, both...
Now, take these two examples in comparison:
a) a game which lets you do at most 1 attack per second with the best premium gear (and with most available weapons, rather one attack every 2-3 seconds)
b) a game that lets you spam 20 attacks per second
Let's assume that the communication overhead of sending an attack request is 10 bytes, similarly the communication overhead for updating client state is 10 bytes, and the average processing overhead per attack (including reading from socket, de-serializing, collision and reach checks, etc.) on the server is a mere 5,000 cycles (that is very, very optimistic!), and there are 10,000 people playing your game, with around 50 clustered in a battle every here and there.
Game a) will cause a total of 200kiB/s of data being sent to the server in the very worst case. It will consume about 2% of the CPU time on a typical server. And, it will have to send out 200*(50*50)*10 bytes = 5 megabytes of state updates to those fighting groups. Note that those 5 megabytes don't include NPCs moving or anything else happening in the game.
Game b) will, in the worst case, see 4MiB/s of input. On a "normal" 100Mbit ethernet, that's about half of what physically fits onto the cable. The server now already spends 40% of its time only on those attacks. It also has to send out a minimum of 100MiB/s for updates. That's a harsh number.
4MiB/s in and 100MiB/s out is more than what fits on a gigabit ethernet cable, if you also account for packet overhead. Also, at such a load, inevitably packets will be dropped and will have to be resent, there is no other way.
But even assuming that your network cable can take an infinite amount of data, and the router in the datacenter never drops a packet, and nobody else is using the backbone... at month's end you will have a very nasty surprise. That's when your hoster will come to you with the bill for a few terabytes of exceeded quota (if the amount of traffic you send out doesn't trigger an alert and your server is shut off the net right away).
And now look at the other end. In game a) 2kiB/s of data are received, whereas it's 40kiB/s for game b). You might think that this is no problem. Everybody has at least a 1Mpbs connection nowadays, don't they? And a 1Mbps connection is only 50% used by that, so no problem, right?
Now think about it... this means that you need half a second to push that data through the cable that goes into your house. Assuming that the whole internet between you and the server has zero delay, this is a ping of 500.
Your opponents can spam 10 more attacks at you during that time. Does that look appealing to you?
Usually you pay for some quota, but whatever it is, it is never free, and is never unlimited (if someone tells you "unlimited", you either have to pay a 5-figure bill every month upfront, or they're simply lying). If you significantly exceed your quota, one of two things happens. Either you get a bill that will make you faint, or your server is shut down without notice. Or, both...
Now, take these two examples in comparison:
a) a game which lets you do at most 1 attack per second with the best premium gear (and with most available weapons, rather one attack every 2-3 seconds)
b) a game that lets you spam 20 attacks per second
Let's assume that the communication overhead of sending an attack request is 10 bytes, similarly the communication overhead for updating client state is 10 bytes, and the average processing overhead per attack (including reading from socket, de-serializing, collision and reach checks, etc.) on the server is a mere 5,000 cycles (that is very, very optimistic!), and there are 10,000 people playing your game, with around 50 clustered in a battle every here and there.
Game a) will cause a total of 200kiB/s of data being sent to the server in the very worst case. It will consume about 2% of the CPU time on a typical server. And, it will have to send out 200*(50*50)*10 bytes = 5 megabytes of state updates to those fighting groups. Note that those 5 megabytes don't include NPCs moving or anything else happening in the game.
Game b) will, in the worst case, see 4MiB/s of input. On a "normal" 100Mbit ethernet, that's about half of what physically fits onto the cable. The server now already spends 40% of its time only on those attacks. It also has to send out a minimum of 100MiB/s for updates. That's a harsh number.
4MiB/s in and 100MiB/s out is more than what fits on a gigabit ethernet cable, if you also account for packet overhead. Also, at such a load, inevitably packets will be dropped and will have to be resent, there is no other way.
But even assuming that your network cable can take an infinite amount of data, and the router in the datacenter never drops a packet, and nobody else is using the backbone... at month's end you will have a very nasty surprise. That's when your hoster will come to you with the bill for a few terabytes of exceeded quota (if the amount of traffic you send out doesn't trigger an alert and your server is shut off the net right away).
And now look at the other end. In game a) 2kiB/s of data are received, whereas it's 40kiB/s for game b). You might think that this is no problem. Everybody has at least a 1Mpbs connection nowadays, don't they? And a 1Mbps connection is only 50% used by that, so no problem, right?
Now think about it... this means that you need half a second to push that data through the cable that goes into your house. Assuming that the whole internet between you and the server has zero delay, this is a ping of 500.
Your opponents can spam 10 more attacks at you during that time. Does that look appealing to you?
Author
good replies.
i guess reason i have hard to udnerstand this is because im real newb at networking.
now that i think about it how do you even make a person walk in your game?
if he click on the screen to start moving there then thats a message to the server?
what if he changes destination he wants to walk to by spamming that command 20 times per second?
people do that allthe time just from being bored even..
learning how to code networking seems to just be the beginning..
then you must learn how to implement networking into optimized playable code.
really complicated stuff.
is there any good guide that teaches about this stuff?
another example of something i dont know is for example in an open seamless world i noticed some kind of invisible borders.
when you walk over them theres a lag spike. i guess its because this seamless world is split into different servers but its all one open seamless world still and if you are standing on one side of a borderline and you can still interact with players on the other side of the borderline as if it wasnt even there.
maybe game engines do all this complicated stuff for you though?
depending on game engine ofcourse.
i guess reason i have hard to udnerstand this is because im real newb at networking.
now that i think about it how do you even make a person walk in your game?
if he click on the screen to start moving there then thats a message to the server?
what if he changes destination he wants to walk to by spamming that command 20 times per second?
people do that allthe time just from being bored even..
learning how to code networking seems to just be the beginning..
then you must learn how to implement networking into optimized playable code.
really complicated stuff.
is there any good guide that teaches about this stuff?
another example of something i dont know is for example in an open seamless world i noticed some kind of invisible borders.
when you walk over them theres a lag spike. i guess its because this seamless world is split into different servers but its all one open seamless world still and if you are standing on one side of a borderline and you can still interact with players on the other side of the borderline as if it wasnt even there.
maybe game engines do all this complicated stuff for you though?
depending on game engine ofcourse.
what if he changes destination he wants to walk to by spamming that command 20 times per second?[/quote]That's up to you.
Go to a lan party and watch as he ends up in a different place on everyone's screen.
1) Don't allow walk command spamming. If he clicks to walk 15 feet away. Let him finish walking before sending a new command.
2) Stop sending movement commands from the client. Limit the frequency. He can move all he wants on his own client. Eventually he'll sync up and end up in the right spot.
3) NON TECHNICAL: Don't let the user get bored in the first place.
You can just let the user click all he wants. Let the client only send equally spaced out updates. His last movement click will determine his final destination anyways. Let him dance the macarana on his own screen. Everyone else will see him walk from point a to b.
Author
what if he changes destination he wants to walk to by spamming that command 20 times per second?That's up to you.
Go to a lan party and watch as he ends up in a different place on everyone's screen.
1) Don't allow walk command spamming. If he clicks to walk 15 feet away. Let him finish walking before sending a new command.
2) Stop sending movement commands from the client. Limit the frequency. He can move all he wants on his own client. Eventually he'll sync up and end up in the right spot.
3) NON TECHNICAL: Don't let the user get bored in the first place.
You can just let the user click all he wants. Let the client only send equally spaced out updates. His last movement click will determine his final destination anyways. Let him dance the macarana on his own screen. Everyone else will see him walk from point a to b.
[/quote]
this sounds weird to me.. most games ive played dont do what you said.. if you spamm move you are where you are all the time.. you dont get teleported to somewhere else and everything is synced and looks good.
also what about if you only can walk with wasd keys.. what if he is just tapping for example the w key constantly spamming that key instead of holding it down.
would you suggest freezing him in place after tapping it? because tapping and quickly changing direction is pretty important and makes combat more actiony.
and if he holds down the key you send a message to server that he is going to be moving forward and then he keeps walking forward until he releases that key and then another message is sent to server that it was released, is this optimal way of doing it?
what about that borderlines in seamless open world?
The seamless aspect doesn't change anything.
Lots of games have the character run in place, or warp to the final destination when the messages catch up to each other. Every online game has a ton of little quirks where things get out of sync or lag strikes. Then everything syncs up, and there can be some oddities as things are corrected. A lot of times, it's just because the prediction (to keep things looking smooth) was wrong.
-The server will say UNTIL I TELL YOU OTHERWISE, BOB IS WALKING TO THE LEFT.
-So your client moves Bob to the left every tick.
-Bob stops moving, but the packet gets lost, dropped, is late, or is intercepted by some agency because they thought it said BOMB.
-The server knows Bob stopped moving, but your client keeps moving him left every tick. Every client may have him in a slightly different place too.
-Eventually a sync will happen, or the client will figure out, because it is told that bob fired his gun in direction A from position XYZ.
-So the client will have to shoot from position XYZ and then either wrap Bob to his correct position, or slide him, or maybe just cover it up and walk him over there.
-The other clients wonder why Bob didn't die when they shot him (because he wasn't really there), and/or why Bob killed them when he was standing outside the room, looking in the other direction.
Clicking on the ground to create a movement action to be queued, and handling things real time with WASD are different. But just because the user presses a WASD key 20 times a second, doesn't mean the client has to send everything.
All your questions about a user doing something undesirable can be answered the same way. Don't design something that allows the user to take that undesirable action in the first place. your code is in control of everything. You KNOW the user is mashing the W key. What to do about it is your decision.
If tapping W causes a footstep animation that takes 0.5 seconds to play out, then you can ignore any further presses during that time period if you like. Both at the client level, and the server level, by not needing to send it. Your game is busy for that 0.5 period as far as certain commands are concerned. Mashing W is fine now, it just means that the next step command will be played out at the first available opportunity.
You also know the amount of time a key is pressed for. You can require a key to be held down for a minimum amount of time before you process it. So tapping W at the speed of light produces no action. Or you can have the player start to move his feet at the exact moment of pressing W, but until 0.25 it doesn't become an actual movement event. If the user lets go, cancel out the animation on the client, tell nothing to the server.
Lots of games have the character run in place, or warp to the final destination when the messages catch up to each other. Every online game has a ton of little quirks where things get out of sync or lag strikes. Then everything syncs up, and there can be some oddities as things are corrected. A lot of times, it's just because the prediction (to keep things looking smooth) was wrong.
-The server will say UNTIL I TELL YOU OTHERWISE, BOB IS WALKING TO THE LEFT.
-So your client moves Bob to the left every tick.
-Bob stops moving, but the packet gets lost, dropped, is late, or is intercepted by some agency because they thought it said BOMB.
-The server knows Bob stopped moving, but your client keeps moving him left every tick. Every client may have him in a slightly different place too.
-Eventually a sync will happen, or the client will figure out, because it is told that bob fired his gun in direction A from position XYZ.
-So the client will have to shoot from position XYZ and then either wrap Bob to his correct position, or slide him, or maybe just cover it up and walk him over there.
-The other clients wonder why Bob didn't die when they shot him (because he wasn't really there), and/or why Bob killed them when he was standing outside the room, looking in the other direction.
Clicking on the ground to create a movement action to be queued, and handling things real time with WASD are different. But just because the user presses a WASD key 20 times a second, doesn't mean the client has to send everything.
All your questions about a user doing something undesirable can be answered the same way. Don't design something that allows the user to take that undesirable action in the first place. your code is in control of everything. You KNOW the user is mashing the W key. What to do about it is your decision.
If tapping W causes a footstep animation that takes 0.5 seconds to play out, then you can ignore any further presses during that time period if you like. Both at the client level, and the server level, by not needing to send it. Your game is busy for that 0.5 period as far as certain commands are concerned. Mashing W is fine now, it just means that the next step command will be played out at the first available opportunity.
You also know the amount of time a key is pressed for. You can require a key to be held down for a minimum amount of time before you process it. So tapping W at the speed of light produces no action. Or you can have the player start to move his feet at the exact moment of pressing W, but until 0.25 it doesn't become an actual movement event. If the user lets go, cancel out the animation on the client, tell nothing to the server.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement