A Queue System Design

Archeage Queue Issues

The major news from the Archeage launch are the queues. The queues are very long at the moment, especially for F2P people. I have not been able to play my first character for several days as the queues are always upwards of a thousand players. I made a second character, an archer, on a newer server. Since the server seems to be primarily made up of F2P people, the queue times for me as a patron are negligible.

Still, it's interesting to see how Archeage's game design has interacted with the queues. There is one significant design element which is making the queues much worse than they should be. For all non-combat activities in Archeage, there is one primary resource: Labor. All crafting and gathering activities cost Labor, which regenerates over time. Labor is shared across the entire account, not per character.

However, for F2P accounts, Labor only regenerates when you are online! So that provides extra incentive for people to stay online. Not only do they avoid the queues, but they get the resource needed to play the game. So naturally Archeage is now full of people AFKing and making macros to avoid being kicked off. This, of course, makes the wait time for the people in the queue longer.

In some ways, Archeage would be better off right now if this design had been reversed: if F2P people only regenerated Labor when they were offline. That would give people incentive to log off, and let new people onto the server.

The problem here is that the queues are temporary, for the launch rush. For general play, when the population is at a steady state, it's better that the F2P players have an incentive to stay online to provide content for the paying players.

Finally, because Archeage is an open world where players can obtain property, Trion cannot use the "normal" method of opening up extra servers or extra instances and then merging them together. Merging claimed property would be a nightmare.

My Queue System

Here's my design for a queue system for a game:

1. A queue to enter the game always exists, and players always go through the queue when first connecting to a server. Of course, if the server is not full, going through the queue is pretty much instantaneous.
2. When a player reaches the front of the queue, the game assigns the player a "window" of X hours, and lets them log into the game proper. If you reach the front of the queue at 6pm, your window might be from 6pm to 8pm.
3. If you disconnect and reconnect anytime during your window, you bypass the queue and automatically enter the server.
4. When your window closes:
1. If there are people waiting in the queue, you are logged off the server and re-enter the queue at the end.
2. If there are no people in the queue, you are issued a new window of X hours and can continue playing. You are not logged off in this case.
5. If the server goes down for Y minutes, all current windows are extended for Y minutes.

I think this is a reasonably fair queue system. It guarantees that you get to play for X hours once you sit through the queue. You can log off for a few minutes, and then log back on. But after you've played for a bit, you have to log off and let someone else play. It's like taking turns on the playground.

Because everyone has a window at all times, even those who logged in when there were no people in the queue, people start getting logged off naturally once a queue forms.

The major issue with this system that I can see is that the number of people who are currently logged into the server is now different from the number of people who could be logged into the server. For example, if you play for an hour, then log off and go to sleep, the system doesn't know that you are not coming back. It has to make the assumption that you could come back. Thus you have to be careful when determining how many active windows you can have, and the length of a window. But those are variables which can be tuned.