[April 12] Initial Development Manifesto Feedback
" The server doesn't resend. It just sends what it thinks the state of the character's environment is on a regular basis (say every 100ms). Both sides regularly receive updates from each other about their local view of the environment, incorporate that into their calculations (and display for the client), then send an update to the other. Unless there is network congestion somewhere along the way, you don't expect to lose more than one packet in a row, so generally you would be 200ms or less out of sync at any time. With TCP, if a packet gets lost, the side expecting the packet can tell the sender to send (and that request itself needs to be acknowledged by the recipient) or if the sender doesn't receive an acknowledgement from the recipient in 3x the time that it is programmed to wait for an acknowledgement, it will resend the packet automatically. In my trace, I saw my machine ask the server to resend a packet. |
|
|
As an addendum, what I am talking about is the data. It is entirely possible to have a separate control stream that is TCP. Videoconferencing that uses the H.323 standard does this. It sends all the data streams (up to 8 between two points) as a form of UDP called RTP (Real Time Protocol). The control stream, RTCP, is TCP.
|
|
|
So the overall strategy for desync sounds like it's to increase the number of resync points. I wonder how much more you can get out of "no sync" strategies, though?
For example, it is common for the server to give the clients a list of random number results in advance of their usage (eg. connect to server and get a list of 1000 random numbers which will be cycled through whenever a random number is called for). This can be further refined by giving each client multiple lists of random numbers which are separated by synchronization domain. What I mean is, the client can have 1 list of random numbers for server-generated actions, and another list for client-generated actions (eg. click on a monster to attack it... the random numbers generated as a result of that action such as "accuracy roll," "critical roll," etc are all client-generated because they are direct consequence of client action), and additional lists for each other player connected to the game. Since the server and client would always execute these actions the same number of times and in the same order, your local actions can be predicted with much higher accuracy. It works better if you give some leniency on the player's position when it becomes out of sync with the server, but that part is very tricky to do. The first part with random numbers separated by synchonization domain is easy to do though, and gets some results on its own. |
|
|
I've read through a few pages so far, seen plenty of constructive feedback. Much better than the suggestions board in general!
Of all the brickwalls I've encountered in terms of game mechanics, the map drop system has by far been the most annoying. First of all, different maps have different mob densities and amounts, which highly favors some maps over others in terms of map drops. Knowing which maps to even consider investing currency into is a science in itself. Secondly, affixes like % increased magic and rare mobs, pack size and area size add a whole different set of multipliers to map drops, complicating things severely and making certain combinations of affixes much more vital to ensure map drops rather than the IIQ modifier in the map description. In my opinion, this ruins a big part of the endgame experience. My preferred solution would be to change map drop mechanics from % chance per monster to % chance per map. Maps should only drop from the unique boss, and with two or more bosses chance is divided between all the bosses. Only the IIQ from the map tooltip should affect map drops, simplifying the ordeal of finding maps and allowing players to choose maps for their difficulty and IIQ rather than the amount and rarity of mobs. I realize this could possibly make spending regals and exalts on maps a thing of the past, thus inflating the economy. However, economy can't be the only factor in deciding issues of gameplay mechanics. Besides, I'm of the opinion that without regular "ladder resets" the default ladder will become an economical nightmare no matter what currency/gear sinks are implemented. |
|
" I'm no expert, but maybe this is related to their prediction system. Where they need as much data as possible for it to be accurate? "The harder the game, the better."
| |
|
The thought that came to me today, and this is pure speculation on my part, is that using TCP and small packets (the ones I captured were no larger than 250 bytes) would be for support of noisy dial-up lines. I personally don't know anyone still using dial-up (other than my 80-year old father-in-law), but I imagine some people out there are still using it. If that is the case, it is limiting the experience of people with broadband in order to support that population of dial-up users.
I'm no expert on game design/coding either, but I would think that all online games have an element of prediction in them, if they want to be able to operate in near-real time. |
|
|
I only have one question left, its just overly obvious at this point that some things are rigged. No idea why, but what ever, its no matter to me. Anyway, why the heck is there no uninstaller to uninstall this with? Control panel isn't that hard to use, its just convenience but still .'/
The games great, it really is. In any online only game the network is probably the most important part, and although some players play almost desync free, you screw some of us totally over. Online only and not so good networking don't mix. Best of luck to you all. | |
" PoE has to ACK that SYN. But seriously, I don't do any packet capturing on my online games so good on your for taking a look. And, yes, it is a problem that a real-time online game is using TCP on the trasport layer rather than UDP. The amount of info that needs to be sent back and forth form client to server in this context is huge so it's no longer an issue of accuracy of data but the speedy delivery of data. | |
|
i have a suggestion: if a player has multiples of certain items or gems they should be able to venor them for higher quality versions of the former gem Quality% should be able to reach 100% and increases a low amount like 2%-5% per doubles vendored EG. cleave gem at Q10% + cleave gem Q 1%-9% = cleave gem Q 12%-15% ect. same with items like gloves boots and helms armour ect.
| |
|
I don't quite understand why you guys at GGG feel that server sync is unacceptable for an ARPG while admitting that it's perfectly acceptable for games like Dota 2 and LoL. The genres share way more in common than they do in differences, and I imagine that if you had a more broadly spread server infrastructure rather than having all your servers centralized into 3 relatively poor locations, a system where players have to deal with a constant and predictable 50-120ms delay would probably look much more appealing than a system that just predicts actions and hopes they're within some ballpark of accuracy. I for one would take lag I can adjust to over random desync that kills me before I can react A N Y D A Y.
|
