Ping times are a source of complexity and gameplay challenges, but they are not a source of scalability problems.
Ping times for wired connections will not drop dramatically in the future, because they are bound by the speed of light -- current internet is already within a factor of 50% of the speed of light, so the maximum possible gains are quite well bounded.
Ping times are a source of complexity and gameplay challenges, but they are not a source of scalability problems.
Ping times for wired connections will not drop dramatically in the future, because they are bound by the speed of light -- current internet is already within a factor of 50% of the speed of light, so the maximum possible gains are quite well bounded.
does the relativity efects show in the gameplay ? ;/
i understand that "showing" of the problems is the response delay
that server give to the client, and the art is to keep it low below some treshold.. could maybe someone know how the treshold is (is this a sum
of time of sending info to server + server processing time + time of sending response to the client?) how values are this to feel tha game is really fine?
(sorry for basic questions in more advanced thread but if I get an opportunity i wold like to understand things a bit, maybe also some thoughts will appear ;/)
Ping times are a source of complexity and gameplay challenges, but they are not a source of scalability problems.
Ping times for wired connections will not drop dramatically in the future, because they are bound by the speed of light -- current internet is already within a factor of 50% of the speed of light, so the maximum possible gains are quite well bounded.
does the relativity efects show in the gameplay ? ;/
i understand that "showing" of the problems is the response delay
that server give to the client, and the art is to keep it low below some treshold.. could maybe someone know how the treshold is (is this a sum
of time of sending info to server + server processing time + time of sending response to the client?) how values are this to feel tha game is really fine?
(sorry for basic questions in more advanced thread but if I get an opportunity i wold like to understand things a bit, maybe also some thoughts will appear ;/)
Since there is always a delay in the information passing through the server (the ping), in order to not show it to the player, you need to either:
-Show the server answer to the player after a set time X.
**Play some animation of length X before showing the player whether you succeeded in something or not (which is dictated by server)
**The player cannot tell the lag because the only way to tell lag is the time it takes for the server to answer, and we have hidden that information
**This breaks down if the ping gets higher than X
-Predict the servers answer accurately
**This can probably never work to 100% accuracy, but it can be used to hide most of the lag resulting from the ping
**Eg predict actions of other players at current time, although you cannot know this until X seconds later because this info comes from the server (and thus has delay)
**You can also predict the result of your own actions if an authoritative response is required from server. Eg if you open a chest, the client can ASSUME that theres nothing in there (with the clients luck), which is most often correct, to hide the ping, but this might be wrong and then has to be corrected when the 'real' information is available.
So you can either hide the lag of obtaining information, or predict the information before obtaining it.
Absolutly. Mostly because of mass increase of the data packages starting to be significant at about one third of lightspeed. If you throw a stone onto another player it will magically produce more hitpoints. This is why many people change place into countries that are closer to the game servers.
does the relativity efects show in the gameplay ? ;/
@up
Im curious what are the response times of todays internet infrastructure,
assume such model: world and a 1000 players no it
there is NOW frame, everything is perfect ok on the map, each player moves and sends its new position to the server, it takes various times to them +10 +30 +70 ms (i dont know)
When server will receive the last position we can count the FUTURE frame (also perfect) then w send this future state back to the players
now we can do it again
(this is a kind of my imaginary model but probably can be realized)
this kind of working will "pulse" with the frequenzy of more laggish player,
so lets take an approach that when some most lagish players will delay
after some treshold we can throw them off out the game
I wonder how theshold in milliseconds can be set that will allow to alive at least a half of most speed connections? (I got no idea as i am not programming network or even not playing network games)
It would be interesting to me estimate this time. I worry that if each sending times has some variation (i mean like gaus 10+-300) this killing connection approach will kill most of the players - but wold very like to
get some idea how many players will be survive in such a test
(i know games uses some techniques that allow masking delays etc
but would be curious how much it wold take in raw perfect sate of things)
has someone as they say some "intuition" how many players would stay alive at which delay treshold here?
Absolutly. Mostly because of mass increase of the data packages starting to be significant at about one third of lightspeed. If you throw a stone onto another player it will magically produce more hitpoints. This is why many people change place into countries that are closer to the game servers.
does the relativity efects show in the gameplay ? ;/
as far as i know variety effect could appear, for example when you will send the data with near light spead and it will bac the data should be much younger than the data that was staying at home
Ping times are a source of complexity and gameplay challenges, but they are not a source of scalability problems.
Ping times for wired connections will not drop dramatically in the future, because they are bound by the speed of light -- current internet is already within a factor of 50% of the speed of light, so the maximum possible gains are quite well bounded.
I wouldn't put so much trust on "how web developers approach scalability".In recent discussions with web and app developers one thing has become quite clear to me - the way they tend to approach scalability these days is somewhat different to how game developers do it. They are generally using a purer form of horizontal scaling - fire up a bunch of processes, each mostly isolated, communicating occasionally via message passing or via a database. This plays nicely with new technologies such as Amazon EC2, and is capable of handling 'web-scale' amounts of traffic - eg. clients numbering the the tens or hundreds of thousands - without problem. And because the processes only communicate asynchronously, you might start up 8 separate processes on an 8-core server to make best use of the hardware.
So this is an interesting topic actually. The trend is to move reliability back up to the layer that defined the need in the first place, instead of relying on a subsystem to provide it.
Just because the network layer guarantees the packets arrive doesn't mean they get delivered to the business logic correctly, or processed correctly. If you think 'reliable' udp or tpc makes your system reliable, you are lying to yourself.
http://www.infoq.com/articles/no-reliable-messaging
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt
http://doc.akka.io/docs/akka/2.3.3/general/message-delivery-reliability.html
Ok, but I'm still not following. Of course reliable transport doesn't mean correct business logic. But these are 2 separate issues.
Your first link basically makes the argument for application-level sequence numbers because it wants to preserve business logic even when the transport is down. That's reasonable, but it's not a key concern for most games. If game server 1 has lost its connection to game server 2 for some reason, you probably have bigger problems than making sure Jimmy's Magic Missile is propagating across servers properly. There's no guarantee you can recover in a meaningful way so it is arguably best to abort entirely. The exception would be for any sort of real-money transaction or similar, but as I hope was made clear in earlier posts, I'm happy with those being done in a more complex and yet more robust way, as they are a small minority of what a game server normally handles.
The other two links elaborate on this and say things like "The only meaningful way for a sender to know whether an interaction was successful is by receiving a business-level acknowledgement". That's fine, but not necessarily relevant. As above, a reliable transport layer will give you (short of astronomically unlikely occurrences) a guarantee one of two things happened:
With this in mind, the reliability guarantee given by the OS is going to be sufficient for any typical gameplay functionality.
So the problem with a pure message-passing approach remains that of whether it is practical to code all gameplay features to work in that way, given that it's not necessary.
First: Try writing a robust real-time physics engine that can support even a small number like 200 players with vehicles on top of the web architecture that @snacktime and @VFe describe. I don't think that's the right tool for the job.
I was going to add the caveat of no real-time Newtonian physics, but I left that out to keep things simple. Perhaps that was a mistake.You'd think that, given how much has been said on the matter, that there would be at least one instance of people talking about using different methods, but I've not seen one.
Personally, I've actually talked a lot about this in this very forum for the last ten-fifteen years. For reference, the first one I worked on was There.com, which was a full-on single-instance physically-based virtual world. It supported full client- and server-side physics rewind; a procedural-and-customized plane the size of Earth; fully customizable/composable avatars with user-generated content commerce; voice chat in world; vehicles ridable by multiple players, and a lot of other things; timeframe about 2001. The second one (where I still work) is IMVU.com where we eschew physics in the current "room based" experience because it's so messy. IMVU.com is written almost entirely on top of web architecture for all the transactional stuff, and on top of a custom low-latency ephemeral message queue (written in Erlang) for the real-time stuff. Most of that's sporadically documented in the engineering blog: http://engineering.imvu.com/
