I am wandering, cos of the double arena weekend as to how the queueing works.
once a player click the join/enter battle button, does your nick name goes into a queue, and game will assign 4 players every battle each side according to the time you click enter battle. i think thats logically it, right??
So I was thinking, what if, how about, Arena net change the queueing system to a click-pool-queue system? (i came up with that name :P) when all the players who click enter battle/join, these players will be chuck into a pool and the game system will jumble them, it then make random selection of 4 players to a team and put them into another waiting room, click-jumble-queue, hence lowering the possibility of a successful sync.
You think that could work? Do you have a good solution?
How does the queueing thing works in GW?
1 pages • Page 1
Quote:
|
Originally Posted by pumpkin pie
You think that could work? Do you have a good solution?
|
Good idea, that was already suggested IIRC, worth the investigation effort by the GW1 programmer that is left (if it wasn't done already...).
Edit: regarding waiting times, you can easily disable this system when there aren't enough players (a situation where sync would happen anyway).
c
I like that you're trying to come up with a solution for syncing players (who I like to call 'cheaters') You see them in every 'random' pvp arena (snowball, dragon arena, costume brawl as well as ra) Not exactly a perfect idea but it doesn't matter anyway since anet will not do that kind of overhaul at this point.
l
Longer waits would not be a problem; for everyone person that is waiting longer, someone just got in faster. Thus, the wait on average should be about the same. The only problem is the people who might get really unlucky that wait a really really long time.
This is the type of problem people encounter when programming an operating system. If I'm not mistaken, multi-threading is the issue: which thread should be the next to get a processor time? Using a queue or randomly picking one are both fine.
This is the type of problem people encounter when programming an operating system. If I'm not mistaken, multi-threading is the issue: which thread should be the next to get a processor time? Using a queue or randomly picking one are both fine.
A
Quote:
|
Originally Posted by Fril Estelin
I don't know the GW's server specifics, but I feel that (despite this being an excellent idea) it would add just a little bit more load to the server. Linked lists (which may implement queues effciciently) are used because it's easy to manage, thus fast. Your idea would require a "set" data structure, where you can basically pick elements in a non-sequential manner. Tables can implement that well, but then you have to keep track of empty slots, which adds to the management.
|
Players want to join ASAP. As such, they are given a window of 30 seconds, after which they are picked. Nobody knows how many players join in that time. But if this number is low, 4-12, then jumbling will not change much, since probability of syncers being selected isn't decreased much.
Quote:
|
Originally Posted by Antheus
Neither of these add to lag. From code perspective, both are trivial, and neither require linked list or set. Data structure overkill. We're literally talking nanoseconds to perform either selection.
|
Quote:
|
Originally Posted by zwei2stein
This is kind of reasoning which explains why we nowadays need quad core computers for simple word procesors.
|
Well let's hope that an Anet dev will read this thread and think "it's time we move from DoubleLinkedList objects to ComplexQueues"!
