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!