Here's who will be participating, their names, titles, and Reddit usernames:
- Cameron Dunn - Technical Director - cameronjdunn
- Chad Taylor - Engine Programming Team Lead - ArenaNetChad
- Stephen Clarke-Willson - Server Programming Team Lead - StephenClarkeWillson
- Braeden Shosa - Gameplay Programming Team Lead - ArenaNetBraeden
- Josh Petrie - ArenaNet Programmer - jpetrie
- Mike Lewis - Security Coordinator - ApochPiQ
- James Wright - Senior Game Engine Programmer - ArenaNetJamesW
- Habib Loew - Gameplay Programmer - ArenaNetHabib
- Ryan Diederich - Gameplay Programmer - ArenaNetRyanD
- Evan Lesh - Gameplay Programmer - ArenaNetEvanL
- Eric Rane - Gameplay Programmer - ericrane
- Kat Dugan - Gameplay Programmer - KatDugan
- Caleb McCombs Gameplay Programmer - ArenaNetCaleb
- Branimir Karadzic - Engine Programmer - bkaradzic
- Felipe Romero - ArenaNet Programmer - ArenaNetFelipe
- Patrick Laukaitis - ArenaNet Programmer - ArenaNetPatrickL
- Patrick Mera - Engine Programmer - meranator
- Mike Popoloski - Engine Programmer - ArenaNetMike
- Francis Crick - Content Pipeline Programmer - fcrick
- Stanlo Slasinski - ArenaNet Programmer - ArenaNetStanlo
- Garett Bass - Content Pipeline Programmer - ArenaNetGarett
- Jordan Massey - Gameplay Programmer - ArenaNetJordan
- Steve Bikun - Server Programmer - ArenaNetSteveB
Quote
- What programming methodologies does your team use? ie. agile, scrum, etc.
- What do you use for source control and how do you handle refactoring code for optimization? Or do you try for best optimization on the first pass?
- What standards and practices do you use?
- How does someone that is a new graduate get into the game programming job market when most jobs require being part of a published title already?
- What is your engine written in?
- How often to you dive down to the bit level of data manipulation?
- Ever have to write Assembly code?
- This depends on the phase of the project which we're in - during "normal" development (like now!) we use a customized scrum-based project. When we're finalling we tend to go back to a traditional team-based just-fix-the-bugs process.
- We use perforce for source control. We have a few branches which we can work in to do refactoring (for optimization or any reason) so we can roll things out when they're ready.
- Game development is actually pretty normal software development - we use technical design documents, coding standards, code reviews, etc, etc.
- Write games in your spare time! They don't have to be massive, just small polished games. People who are passionate about game development can't help themselves - they write games no matter what. That's how I got into the industry - I wrote a Game Boy emulator.
- It's mostly in C++
- Very often :-)
- Sometimes, although these days it's fairly rare [Source]
Quote
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. [Source]
Quote
Ok, that's general programming, how about graphics? OpenGL or DirectX? I read a lot of discussion about this topic and found lot of opinions. "Don't learn openGL or DirectX, start with libraries like SDL or Allegro5","Don't start with libraries, go for DirectX, it'll be hard at first, but easy later on" "DX sucks, openGL rules!"
What's really important is learning the core concepts behind programming and graphics. The actual APIs change all the time, and you have to be adaptable. Lots of beginners get hung up on choosing the "perfect" starter language/API, when really they just need to get making things with whatever they happen to know.
That said, C# and XNA are a great way to get into game development; we use C# for our biggest content tool. [Source]
Quote
Start making games! There are now many online communities where you can be part of a team, like Kongregate, or you can just work on your own project on your own. The most valuable experience you can only get by just working on projects and solving the real problems those projects face. Also, there is a difference between wanting to do something you've never done, and knowing it's what you want to do after doing it for a while - prove to yourself and others that it's actually what you want to do by putting in the time. [Source]
Quote
Just take as much math and computer science as you can and apply it to actually making a game or modding an existing game. Nothing will prepare you more for making games than actually making games. [Source]
Quote
- Guild Wars 2 started development in 2007-08 I believe? Over the years I imagine new technologies that were discovered may have outperformed old technologies. What would you suggest that others start to learn today that you would have like to have known in ’07 –’08.
- I don’t know how well the programming team delved into the design portion of the game but I imagined everyone had a “Wouldn’t it be cool if…” What was the best “Wouldn’t it be cool if…” that never made it into the release?
- Finally I would like to thank you guys for working on such a wonderful game. It has truly blown my expectation out of the water.
Although, that said, concurrency and concurrent programming techniques have become even more important in recent years than they already were.
(2) Asuran paratroopers.
(3) Thanks! The feedback we've gotten from the players has been wonderful and inspiring. [Source]
Quote
- Do you think a Master's or PhD help or hurt an applicant's chances of being hired as a programmer?
- What was the interview process like?
- What's it like to work at ArenaNet?
- It certainly doesn't hurt! Especially if you have a game-related thesis topic.
- Mostly it's in-person interviews. We have a few technical tests which we ask people to do depending on where they are and on their background.
- I've worked at a few games companies, and for me this is the best place I've ever worked. I honestly think that we have one of the best teams in the world (not just the programming team, everyone). [Source]
Quote
- How did you learn to code?
- What programming language is your favorite and why?
- How was it to work on Guild Wars 2?
- Do you prefer working on a small game or a big game? Why?
- Do you have any tips for a "youngling"?
2.We mostly use C++ - so I guess that's officially my favorite language for writing a game like GW2. But from a pure language perspective, C# is probably my current favorite. I used to use Delphi (ObjectPascal) a lot, so that's probably why.
3.Working on it was fun. Shipping it was amazing.
4.When I started in the industry I worked on a bunch of smaller "boutique" titles, so I feel like I've done that, and now I love the challenge of big games.
5.Write games! Seriously, just write lots of code and put something together in your spare time. Or anything technically challenging - I wrote a Game Boy emulator, that's how I got into the industry. [Source]










