Rewards from TOTAL Achievement Points.

#13 - May 27, 2013, 8:17 a.m.

Thorquist.8126:

Down the road, we’ll also be adding a reward structure to total achievement points, and we’ll be looking at revamping portions of existing UI to help players understand all the different kinds of content they can play and the types of rewards available. Once we have that framework in place, we’ll be able to really expand on the content accessible through the achievements system and provide you with even more new and exciting ways to play the game.

This feature is still in development and will be added to the game, yes. No ETA since it hasn’t been signed off testing wise yet, but it’s absolutely still something you’ll be seeing this year. This is part of an over-all project to update reward systems across the game, you’ve seen some of the stuff already (daily/monthly overhaul), rewards for giant boss chests in the open world, etc. Some arrives next week release (rewards for WvW ranks) and the rest will arrive over the course of 2013.

As a reminder, what we’re working on high level strategy wise can be found here:
https://www.guildwars2.com/en/news/colin-johanson-on-guild-wars-2-in-the-months-ahead/

We’ll update this blog post in a few months with our status so far and the plans for later in 2013. (edited to clarify we’ll update the blog)

#20 - May 27, 2013, 8:41 a.m.

Behellagh.1468:

It’s just players have a different definition for “down the road” and “in the future”, just like “rare chance”. Causes a lot of misunderstandings. Also most players aren’t software developers, it can take months from idea to implementation that doesn’t break something like the economy, profession balance, etc.

True enough, we also try to avoid putting timelines on anything due to the volatility that comes with live development, and if we’re ever wrong folks tend to not respond terribly well to it.

One of the fun things about live MMO development: all the steps that things have to go through to make it live. Generally a feature needs to be done 2+ weeks before it can go live, so it can get locked down and separated from everything else in development to be tested in isolation with the live game to verify it doesn’t function different in a server filled with development code vs. what’s going to go live. Before this lock down, the feature needs to be done with core development about 1-2 weeks earlier to allow downstream teams like localization, editing, and audio to have time to complete their work after the content teams are complete so content isn’t changing out from under them. And if any VO is used in the feature, all the recorded text needs to be completed 4+ weeks earlier than that to allow all of our localization VO partners to get all the correct staff in studio to record all the VO to match the english recording after the first batch of VO is recorded.

Most of this year we’ve been having a release once every month, which means if a feature has a lot of issues during testing and we need to make a lot of updates and pukitten back, it could be multiple months until it gets into the next one due to all the lead time required before something ships in game. The amount of steps required to get something live is pretty staggering, I just covered some of the high level steps above but there are a lot more than this.

We’ve actually been re-working this pipeline a bit lately in the background to try and speed it up (thus 2 releases in a row with 2 weeks separating instead of 4) but it still makes it really hard for us to give exact dates. A little peak behind the curtain how development works, there are around 300 folks working at ArenaNet, but a lot of them have nothing to do with building the feature, and instead provide all the support required to get that feature live. It’s why very few live games do frequent updates to their products, but we’re trying to find innovative ways to buck that trend and update more frequently.

#25 - May 27, 2013, 10:39 a.m.

rootnode.9546:

And as for the dev code vs live code: they should test both. It’s of no use now if they test againkittenture code and not the current live code. It shouldn’t be that hard to boot a server with the currently running live code as a snapshot and then run test by test.

Sorry if it wasn’t clear, we do test both, which is part of what takes a while for stuff to get live. =)

But yeah, we do miss stuff sometimes, and we’re constantly working to update that pipeline to make it better, automation is certainly one part of that.