Press "Enter" to skip to content

FFP: Upcoming Changes to the TaskQueue

Hey, fellow players. My name’s melkon and after a year of being part of the great West-Team, I’m finally feeling confident enough of telling you about the stuff I’m working on 😉 While the current community Hot Topics are the new Job-System and the amount damage you receive while doing jobs, I don’t want to put any more fuel into that discussion. Seriously, those topics are as heavily covered in our office as in the forums and, luckily, you players are far more civilized when arguing about the pros and cons than we are. Sometimes it even escalates into a good ol’ western-style shoot-out:

That used to be our Game-Designer’s monitor but nowadays he’s utilizing it as a shield against the developer’s wrath. That said, you definitely should take part in the recently launched Beta contest – those nerf-guns are a good way to compromise someone’s authority and are a lot of fun too.

Anyhow, we have been a little bit suprised that the update to 2.0 on the Beta worlds went quite smoothly. Of course, there are still a lot of small bugs and balance issues which have to be addressed, but really big “OMG EVERYONE’S GONNA DIE!!!”-bugs are notably absent. One big issue though is the performace – especially when starting a new world. Therefore we continued the FFP: Fight For Performace. The team already did a good job and, in general, the performance is much better than it has been in 1.36 but we still have a couple of areas where we can improve.

Performance issues regarding the new tutorial have already been addressed, but to further smoothen the starting experience, there’s another heavily used game mechanic: doing jobs. Particularly during the starting phase, players are way more active and queueing up way more jobs than in the midgame. This increased activity results in more requests which itself results in a higher server load which, in the end, usually leads to some kind of lag on the clientside.

So, what are our plans to reduce that load?

There are several approaches but the one I’m currently working on is to reduce the requests made to the server. Where to start? An educated guess was pointing us to the action which starts a job and the taskqueue overall. Analyzing the logs confirmed our assumption. Players are hitting the “Start” button in a very short interval to queue up jobs and therefore sending one request with every click. A player who wants to add 9 new jobs to his queue will accordingly fire 9 requests. Multiply that with the amount of players who are starting on a new world and you have a ton of requests made, in a very short amount of time.

Now back to the idea of reducing requests. If a player hits the button in a couple of times in a short interval, why do we have to send every click as a single request? That was the question we have been asking ourself and that’s what I’m working on right now. When I’m done, hitting the “Start” button will not instantly result in a request but will add it visually to the taskqueue.

After an amount of time, say, 500ms, the actual request will be triggered. If the player hit the “Start” button again before those 500ms have been passed, the timer will reset, waiting another 500ms before the actual request will be made. After the 500ms, every added job will be send to the backend, resulting in only one request instead of 9. The backend then processes the request, adding the jobs to the player’s queue and send one single batched answer back. The client on the other hand will parse the server’s answer and update the tasks which are already in the queue with the proper information. Everything in one request!

Thing is, it’s easier said than done: the complete task-system was never designed to be batchable. It’s quite a big task which will take sometime until’s finished and there are always things, like bugs you guys report, which have to be dealt with first. Speaking of which, we have still a lot of things to do. Besides fixing bugs, we’re working for example on the backend to bring back your beloved highlights when you get a new report or telegram and on properly refreshing your health, energy and experience. We’re doing all that while we’re constantly reading the forums and are discussing your feedback. We are very thankful for your constructive criticism, good ideas and we’re keeping it in mind when doing changes to the system, so keep it coming!

9 Comments

  1. Katerchen
    Katerchen September 4, 2012

    Simple Question: Would it make a difference if instead of clicking nine times onto a button you can actually choose how often a job can be done by typing a number into a textfield?

  2. Surge
    Surge September 4, 2012

    what about grouping things in market? I am sure, this also makes a tons of requests to the server (especially when someone put it on market piece by piece). Because if seller won’t sell the particular things as a bundle, we have no other option than click manually dozens times

  3. i want play with you
    i want play with you September 4, 2012

    Now we all know what you do instead of working guys, you play Cowboy & Indian 😀

  4. Bluep
    Bluep September 4, 2012

    melkon :
    So, what are our plans to reduce that load?

    There are several approaches but the one I’m currently working on is to reduce the requests made to the server. Where to start? An educated guess was pointing us to the action which starts a job and the taskqueue overall. Analyzing the logs confirmed our assumption. Players are hitting the “Start” button in a very short interval to queue up jobs and therefore sending one request with every click…

    What about the most simple solution of them all?
    Bring back chosable job times, that would reduce the job clicks a lot – the average job time I’m doing with my new Character on W3 is far less than 5 minutes (and if I’d do the jobs I *should* do to gather crafting ressources on W1 with my lvl120 Char, I’d be way below 10mins, too)
    That would not even save more than 80% of job clicks, but also those massive amounts of reports..

    Btw, performance: What about the nearly daily “downs” at midnight, where the v2 worlds either become totally unavailiable, or the game loads but no more actions are possible (“You cannot add any more assignments!” with an empty task queue, no reports & rewards of finished jobs..)?
    Sometimes the game becomes responsive again at 2 or 3am, but most of the time we’ll have to wait until morning..

  5. melkon
    melkon September 4, 2012

    Katerchen :

    Simple Question: Would it make a difference if instead of clicking nine times onto a button you can actually choose how often a job can be done by typing a number into a textfield?

    That would achieve the same thing, indeed. But I bet I can click faster than you enter a number 🙂 – it’s also very error-prone.

    Surge :

    what about grouping things in market? I am sure, this also makes a tons of requests to the server (especially when someone put it on market piece by piece)

    Yes, that would be another area where we could increase performance and usability.

    Bluep :

    melkon :
    So, what are our plans to reduce that load?

    There are several approaches but the one I’m currently working on is to reduce the requests made to the server. Where to start? An educated guess was pointing us to the action which starts a job and the taskqueue overall. Analyzing the logs confirmed our assumption. Players are hitting the “Start” button in a very short interval to queue up jobs and therefore sending one request with every click…

    What about the most simple solution of them all?
    Bring back chosable job times, that would reduce the job clicks a lot

    The amount of clicks are higher with the new JobSystem, yes, but that’s not really a problem. It’s the short interval of a high amount of requests which basically do all the same. This issue also exists on the old worlds, where you queue up eight jobs in eight requests – in a very short interval (at least I do on the world I’m playing). So, reducing the number of requests would positively affect both versions, 1.x and 2.0.

  6. Bluep
    Bluep September 4, 2012

    melkon :
    The amount of clicks are higher with the new JobSystem, yes, but that’s not really a problem. It’s the short interval of a high amount of requests which basically do all the same. This issue also exists on the old worlds, where you queue up eight jobs in eight requests – in a very short interval (at least I do on the world I’m playing). So, reducing the number of requests would positively affect both versions, 1.x and 2.0.

    ..but with the old job system, you do these (up to) 8 clicks one time every 7 hours (if you have 150 energy to spend); with v2 you do that up to 75 times with 150 energy, 9 clicks every 9 minutes (for all those annoying 2-energy-1-minute jobs which are often needed for crafting items, quests, fort construction..)

  7. Diggo11
    Diggo11 September 5, 2012

    @Bluep A short time in computing is milliseconds, not ten minutes. I believe the problem is due to client-server lag, where the user sends/receives data too frequently, rather than lag from a general server overload.

  8. Petee
    Petee September 6, 2012

    Hello melkon,

    great to hear from you here :-). I’m really glad you introduce us to these technical issues, it gives scripters a much better idea of what to be aware of.

    My question is whether will batch-queuing jobs also be possible using the button located in the Work window that queues the nearest job.

    I also have two suggestion for fighting server load:

    ___
    Equipping and un-equipping items: in most cases, players can’t search for the items quickly enough in the Inventory window in order for time-driven request batching to be feasible. However, the request could be sent after the “wear” (unequipping) or “inventory” (equipping) window looses focus, plus some much lazier time limit.
    There is also one situation, when the player clicks on the items so fast that even time-driven batching is applicable – in our ClothCalc userscript window, when the player displays the best items for the chosen job. If some sort of client-side API (and related server-side code) was already done, we could adjust the script to use it. I believe changing equipment can make quite some server load – skills bonus, sets and their bonus, that is some work… The player usually changes at least 5 items in his equipment, so I think it would make a difference.

    ___
    Just a little note that might not necessarily be worth the little effort – I don’t quite understand why is item data sent in the quest book request. Unless this will be used to send information about items not available in the ItemManager, it’s just a waste of network traffic, although the quest book maybe isn’t opened often enough for it to matter.

    Thanks for your time, keep up the good job!

  9. melkon
    melkon September 6, 2012

    Petee :

    great to hear from you here :-) . I’m really glad you introduce us to these technical issues, it gives scripters a much better idea of what to be aware of.

    My question is whether will batch-queuing jobs also be possible using the button located in the Work window that queues the nearest job.

    Thanks for the reminder of checking the Work Window. Basically, *every* task you gonna add to the TaskQueue is batched. That includes founding a town, sleeping, walking, crafting etc. The Work Window feature does not excatly work the same way, but it probably can be adjusted to reduce the number of requests as well. I already have some ideas and I’ll look into them.

    Equipping and un-equipping items: in most cases, players can’t search for the items quickly enough in the Inventory window in order for time-driven request batching to be feasible. However, the request could be sent after the “wear” (unequipping) or “inventory” (equipping) window looses focus, plus some much lazier time limit.

    Well, changing the inventory or an item actually is not that common, at least it doesnt make a huge impact.

    There is also one situation, when the player clicks on the items so fast that even time-driven batching is applicable – in our ClothCalc userscript window, when the player displays the best items for the chosen job. If some sort of client-side API (and related server-side code) was already done, we could adjust the script to use it. I believe changing equipment can make quite some server load – skills bonus, sets and their bonus, that is some work… The player usually changes at least 5 items in his equipment, so I think it would make a difference.

    Well, maybe some time 🙂

    Just a little note that might not necessarily be worth the little effort – I don’t quite understand why is item data sent in the quest book request. Unless this will be used to send information about items not available in the ItemManager, it’s just a waste of network traffic, although the quest book maybe isn’t opened often enough for it to matter.

    Thanks for your time, keep up the good job!

    You’re probably right, we’re always cleaning up code. Maybe some day we also remove that unneeded information 🙂

Comments are closed.