An AMA (or rather, AMAA, as in “ask me (almost) anything”) just concluded today! This session is hosted on reddit, as usual. Since only programmers were here to answer questions, the session’s scope is mainly limited in things that are technical, rather than design and balance decisions like “if we can have feature X”. Nonetheless, abundant information is given, confirmed, and reiterated. Here’s a list of important answers from the devs concerning player experience and game mechanics:
- A team of developers is investigating the overwhelming FoV complaints (currently locked at 65, while most modern PC games default to 90 and let players to customize this value). No definite answer is given, however, as they still don’t rule out that there may be a bug involved.
- Player culling (“invisible army”) issue in WvW is troubling the devs as much as us players, and they reiterated that the fix is not simple and require much more work before a fix is possible. And of course, no ETA of any sort, but it is work in progress.
- There is something in development that will “greatly increase” number of concurrent players in WvW. (!!!)
- Understandably, ANet is not sharing details on the process of detecting and removing bots, other than reiterating that they are banning bots in waves. It is also said that players should see a noticeably decrease of bots in the next few weeks.
- Broken SP challenges: the devs are focusing on addressing the root cause of the issue, which presumably, once fixed, will benefit old and new content alike.
- Multiple trait set is on the “cool to do” list.
- There’s no plan to support an official Linux version of the game, however the devs has optimized its usage with Wine.
- The game is still largely CPU-bound. Optimizations are still being made for a wide range of specs. Though it seems the priority is still to have the game running smooth on lower spec PC.
- DX11 support is still under review by the devs, and it is unlikely to include DX11-only features that don’t work on lower spec hardware. Anti-aliasing options are also being explored.
- The biggest challenge in fixing bugs is the broken dynamic events, as they are hard to reproduce outside of live environment. It seems that there are tools that are being developed to tackle this issue.
- Preview equipment via trading post is possible, although it’s not a priority at this time, and has things to do with API support and more polish to the TP system.
- A more enhanced LFG tool is likely trimmed in order for meeting shipping deadline, and is now being looked into.
- Player character profiles on the web feature can be realized by using APIs, which is under development.
Other replies include the programmers answering many inquiries regarding Computer Science/Engineer students and programmers on tips of getting into the industry. That’s outside of the scope of this post of mine, however, and given the sheer amount of replies in this AMA, it’s likely that I missed a few things. Hopefully they aren’t too noteworthy :p
Anyway, my appreciations to ArenaNet for this excellent community interaction. I really wish more game developers do this.
Original post on reddit (over 2.6k replies atm woohoo!)
Below is a (poorly formatted) copy&paste of the verbatim of the related direct quotes from the devs; a personal source record, really. Wall of text warning.
Will you ever implement or even consider a FoV slider?
> We’ve heard players loud and clear on this one. But we’re not prepared to answer yet because we just convened a team to investigate, on Monday in fact, and we want to give them time to investigate. For example, there may be a bug affecting FoV calculations in widescreen resolutions. We want to know what’s a bug and what’s by design before we change the design.
>Ok, so this is kinda secret, but I’ll tell you anyway. I can tell you because it’s easy to say and really hard to do.
We have a system which lets us run the old build and the new build at the same time. So we don’t need to take the old build down when there’s a new one, we just also host the new build.
That’s it, it’s that simple in concept. But complicated to implement.
>It also requires great care because our back-end servers must support the old and new build at the same time. Sometimes (not too often) we have to write code that only runs while both builds are live just to keep things compatible; then we remove it. As Cam hinted, it’s something you have to architect in from the very beginning.
> The issues with invisible players in WvW comes down to a couple of factors. One is to do with when the servers notify any given client about other characters in the game (I’ll call this reporting/culling) and the other deals with the time it takes the client to present the character on the screen after it has received that notification (I’ll call this asset load).
The asset load issue is all about how quickly the client can show you something it knows it should show you. We’re looking in to ways that we can make that process faster, but it’s always going to take non-zero time. However, that’s not where the bulk of the invisible players come from. For that we have to look at the reporting/culling side of things.
In the situation where the local population density is relatively low, when another character comes in reporting range of your character the server sends a notification to your client with all of the data that it will need to track and render that character. That includes appearance data, race, gender, profession, weapon sets, etc. etc. It’s an easy model to think about and works well, until the local population density goes up. When there are a lot of characters in reporting range we start to get into a situation where, under the current system, there’s an overwhelming amount of data to send to the client (hello n-squared problem!) — after all, resources like client CPU/Memory/etc. and bandwidth are finite. In order to deal with this situation we elected to change the criteria for reporting characters slightly. Rather than just using a fixed range we instead also limit reporting to the closest N characters. By doing this we help to ensure that we’re not overwhelming the available bandwidth and, since clients clearly can’t draw or process characters they don’t know about, we get some savings on client performance “for free”. This works out pretty well in PvE and doesn’t seem, at least as far as I can tell, to have a detrimental impact on gameplay.
Unfortunately in WvW, where large battles are quite common, we find that players are bumping into these limits quite often and the effect has a real, and unfortunate, impact on the gameplay experience. Do I like the state that it’s currently in? No, honestly I don’t. WvW has been my baby (though not mine alone!) for quite a while now and I really want to see EPIC battles play out in all of their glory. If there was a switch I could flip to just make this work then I would have flipped the hell out of it by now, believe me. However, when you’re dealing with resource utilization issues like this there are rarely any easy answers. I’m currently, actively looking into what exactly our options are in this regard. The fix is likely to be large-ish in scope, with changes on both the client and server, but we have some ideas that look like they may work out. So, will it get better? I can’t make any promises because we’re still experimenting and building new tech, but as a person who works on this every day I certainly believe that it can and will do everything in my power to make that happen.
> Qustion: “Why not compromise for the time being (Until a more appropriate solution can be implemented) and show the nearest N/2 allies and the nearest N/2 enemies only when the total number of allies + the total number of enemies is > N? (N = max number of players to show).”
This is actually something that we’ve tried. The first pass worked exactly as you describe and the very first thing that became clear was that the “only when the total number of allies + enemies > N” bit isn’t a good rule in practice. The problem is that you get a bunch of weird edge case behavior when e.g. you’re running with N allies and then you stumble upon a group of N enemies. Suddenly a bunch of your allies vanish and a bunch of enemies pop in. It’s quite jarring.
Once we pulled out that part and had a distinct limit on allies and enemies things felt a bit better but we ran into some performance issues. There’s a bunch of specific details about what, but the short version is that a generic way of determine who is currently your ally (that could be applied to the whole game, not just WvW) is computationally expensive and the performance hit wasn’t worth it. We could certainly spend time optimizing that process, but we decided that it would be better to spend that time pursuing more complete solution rather than just making the current culling feel a bit better. If the avenue that we’re currently pursuing pays off then we’ll be able to get an improvement that’s a lot better than the N/2 improvement would be.
tl;dr the improvement to gameplay wasn’t great enough to warrant the amount of work it would take to make this approach performant, and we think we have a better plan in the works currently.
> Apologies in advance for only hitting one of your questions, but I’m not certain of the answers to the rest of them, so
As for bots: we’re very reluctant in general to discuss our strategy publicly because we don’t want to tip our hand; however, I can say that we have a lot of great progress in detection and prevention in the pipeline, and we should start seeing a noticeable decrease in botting over the next few weeks.
- Is there a point to reporting bots any more? Not “hey you aren’t doing anything about them,” but more along the lines of the activities I recognize as botting (identical pathing, attacking thin air, identical (default) appearance, and so forth) seems like it should be able to be recognized via an automated system.
- If I see twelve bots running an identical path killing ALL the things, and only report ten of those (hard to remember if I’ve already reported xzxcczccx as well as vbcvvbcxxxvb), do those other two get to keep on going? Or can I report only a handful to have them all looked at?
- Is bug reporting in game more effective than on the forum? Or the reverse? Or are they about the same?
- Are there more town clothes on the way? More additions to the gem store?
- For issues like the broken skill point in Metrica Province (with the dead Hylek NPC), is it really much more complicated than “if dead, resurrect”? Surface level it seems so trivial to correct, wondering if there’s more to it that players aren’t seeing.
- We’ve seen some information on the breakdown of the number of players choosing races. Will we be seeing more of that type of information? (side question — closing in on two months after release, did any of the player demographics surprise the team?)
- Looking back, if you could change one thing about the game at release, what would you have changed?
>
- Yes.
- We ban bots in waves. Those two aren’t getting a pass.
- There are several advantages of using the forums for both developers and players — we can ask for additional specific information, and also we can respond to threads on the forums. Both bug reporting and the forums are very useful for us.
- Yes and yes.
- We’re focused on addressing the root causes of these issues, as both existing and future content will benefit. If we fix the cause, it won’t happen again.
- I’d assume so — I think John Smith is always working on finding interesting things to share.
- Personally, I wish we’d been better prepared with the Trading Post, and that we’d been better prepared with content problems with things like events and skill points.
> That would be cool. I’d use that! We have a lot of things on the “cool to do” list though — we’re working through it!
Now that the Mac client is available, any chance of a linux client?
> We have no official plans to launch a linux client. Having said that, I personally use linux a lot (starting with Slackware on those sweet A/D/etc floppy disks) and would love a native client. It’s also really healthy for your code to support different platforms and compilers.
And as stuzart mentions, GW2 does actually run pretty well in Wine.
> We are actively working on client performance improvements across a wide spectrum of hardware configurations. This effort is focused in two key areas: improving multi-core utilization and reducing overall CPU workload. The client is generally CPU bound, so more + faster cores will contribute to better performance. There are exceptions (high-end CPU paired with a low-end GPU, scenes with sub-optimal culling results, etc…), and this is something we are also working to address.
> We are always monitoring and improving performance.
> We are CPU bound on systems with mid to high spec GPUs because we have well optimized art assets and aggressive culling. Our environment art team rocks at making beautiful looking maps that fit within budget. Also the nature of being an MMO lends itself to CPU intensive problems–animating many on screen characters, loading and decoding gigabytes of assets as you move across a map, many unique particle effects, etc. etc.
> On dual-core CPU we’re mostly CPU bound. Usually lower spec CPU comes in combination with lower spec GPU so even if we weren’t CPU bound in that case we would be GPU bound. But we’re actively working on improving game performance, and we’re using lower spec machines to determine bottlenecks and prioritize what to tackle next. This is ongoing process since release, and with every update there are improvements to performance.
Are there any plans to improve the performance on AMD systems?
> No.
Just kidding
Of course we’re always working to improve performance; it’s basically a never-ending battle. I don’t know of anything vendor-specific at the moment, but that doesn’t mean general improvements won’t have a noticeable impact for you.
WvW queue and number of players
>
Hmmm this is probably secret, but we’re all friends here! We have something in development which will greatly increase the number of people who can play WvW at the same time.
I think that answers most of your questions…
> Initial support for DX11 in GW2 would be have to be limited to features that don’t require massive art changes and effects that are not affecting game play, but going forward adoption of real DX11 hardware, will dictate how fast we move into that direction.
> The main problem with supporting DX11-only features is that you automatically exclude a huge portion of the player base from ever seeing them. That’s not to say we don’t want to do them, because as gamers and graphics nerds we love making the best use of our gaming rigs. Just for now though, there are much higher priorities for us to get straightened out before we can focus on adding candy like this.
As for actually doing it, it would involve adding a DX11 codepath to our engine, which is definitely non-trivial and essentially doubles the amount of code that could potentially contain a bug.
Mostly DX11 is about having a nicer API that more closely matches the hardware, and for that reason alone it’s a good thing to use, but as for specific features there are a few that we’ve talked about, such as the hardware tessellation features for more detailed terrain and models.
» We’ve definitely considered other AA solutions; in fact, I’ve personally looked at adding SMAA support. Unfortunately there are tons of other more important things to get done first, but I’d like to see this added at some point in the future. I agree that SMAA produces a much nicer effect, especially on some of our chain mail armor in harsh specular lighting.
DirectX and OpenGL questions:
1 — Why use DirectX? why not openGL?
2 — Aren’t you using an openGL renderer for the mac version? if yes would that mean a port to linux would be “easy”?
3 — Was there any technical limitation for using openGL on windows?
>
- Just technical decision made while back. OpenGL nowadays is way much more important than when when GW2 development started.
- On Mac we’re using Cider wrapper from Transgaming (it’s like Wine on Linux). If do native Mac port, then Linux port would be easy.
- It’s just time required to develop for both APIs. Each feature for the game we developing has to be supported by both APIs, so it takes time to support both API targets. The biggest time sink when supporting both APIs are shaders. There are ways to make cross platform shaders but none of those are ideal and each has it’s own tradeoffs.
> One of the biggest defects right now is events randomly breaking. This is happening for a variety of reasons, including NPCs failing to path to their destination, players pulling NPCs out of the event area, and content scripts failing to handle edge cases. A big part of the problem is tracking down what broke minutes or hours after the bug has occurred. One restricting factor to keep in mind is that we’re dealing with a live environment now with significantly more code and content being exercised than our development environment. Some bugs only reproduce for us at live scale, which makes it very difficult to diagnose the problem and work with it in a sandbox. This requires improvements to the debugging tools we’ve taken for granted all along in the dev branch in order to make them work efficiently at live scale, which we’re actively working on now.
What are the chances of getting a Preview option in the Trading Post?
>
There’s no technical reason that we can’t do it, the Trading Post is a website but it can also ask the game client to do stuff via a defined set of APIs. The problems are twofold:
1) The API to preview things is in development but has a few bugs still, and other things have taken priority.
2) The current TP doesn’t have a good place for actions like this to live. There’s some groundwork there that needs to be done to make it not a terrible experience.
For elements like the Black Lion panel we need to try and be sure they meet a minimum level of polish. Preview on the TP isn’t there yet.
Character profiles on the web?
> It’s definitely something we want to do! We’re still determining how exactly we want to go about making more character info available online. It’s a question of resources.
I think the most likely thing you’d see first would be APIs to allow fans to get character data & do something useful with it. I love that sites like GW2 spidy exist and would really love to provide better documented APIs for people to do cool things we couldn’t even think of with.
Something interesting?











Comments