How does the queueing thing works in GW?

1 pages Page 1
pumpkin pie
pumpkin pie
Furnace Stoker
#1
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?
Rampager
Rampager
Krytan Explorer
#2
sounds like more lag im alright thanks
Pleikki
Pleikki
WTB q8 15^50 Weapons!
#3
I agree that text above, sound more laggy
pumpkin pie
pumpkin pie
Furnace Stoker
#4
you mean lag as in the battle or waiting?

okay, for below answers, thanks , i guess you mean the waiting part then.
Rampager
Rampager
Krytan Explorer
#5
Quote:
Originally Posted by pumpkin pie
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,
12 characters and stuff
Fril Estelin
Fril Estelin
So Serious...
#6
Quote:
Originally Posted by pumpkin pie
You think that could work? Do you have a good solution?
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.

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
crazybanshee
Desert Nomad
#7
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
lord of all tyria
Lion's Arch Merchant
#8
Syncing is fun when I'm bored. Because more often that not we end up on opposing teams.
thedarkmarine
thedarkmarine
Lion's Arch Merchant
#9
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.
A
Antheus
Forge Runner
#10
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.
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.


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.
zwei2stein
zwei2stein
Grotto Attendant
#11
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.
This is kind of reasoning which explains why we nowadays need quad core computers for simple word procesors.
Fril Estelin
Fril Estelin
So Serious...
#12
Quote:
Originally Posted by zwei2stein
This is kind of reasoning which explains why we nowadays need quad core computers for simple word procesors.
I was going to reply, but fortunately I saw your answer (actually it's all about the server business, but the point is exactly the same). It disappoints me that there's a science for computers and yet no one can make a difference today in general computing public (aka geeks) between a linked list and a table. Efficient and top-notch implementation is the reason why GW is f2p (I read Jeff Strain saying that about GW1 several times and he said it again in the latest GW2 article in German).

Well let's hope that an Anet dev will read this thread and think "it's time we move from DoubleLinkedList objects to ComplexQueues"!
buckscrib
buckscrib
Frost Gate Guardian
#13
We already wait long enough. This would increase it.