Conversation started May 22, 2013 at 0:50.
John McDonald
John McDonald
May 22, 2013 00:50
How does tool development change as a project (GW2) ages @JoshPetrie?
user4704
It follows, generally, an offset cycle from the rest of the game (in that we can start developing newer things earlier).
user4704
But mostly it's more about adapting to the evolving development paradigm than the project itself. Building a game is very different, workflow-wise, than maintaining one.
John McDonald
John McDonald
Right
user4704
So you have to shift your focus to supporting and anticipating those needs.
user4704
Since we aren't really set up to make the actual tools for new features (that's done by the consumers of the tools), we focus almost entirely on architectural issues.
user4704
May 22, 2013 00:53
Or optimizations.
John McDonald
John McDonald
hmm, ok
user4704
For example, we've built a system for managing "future packages" of content in a fashion that allows those packages to be inserted and rearranged inside a release schedule at-will.
user4704
Which helps support our need to have multiple, independent teams working concurrently on releases with disparate ship dates.
John McDonald
John McDonald
Interesting
user4704
And also tools to support a branching model, because branching in reality is a lot more complex than "p4 copy"
user4704
May 22, 2013 00:58
All the quaint, almost academic discussion you find online and in SCM "best practices" documents tends to be oriented around a lone developer (often a programmer) working on a branched feature or topic in relative isolation.
John McDonald
John McDonald
Really?
That seems a little unusual
user4704
Well, you have a ton of things to branch, to start with, so there's simply coping with that kind of volume. Then you have to have tools to support the automation of branch setup, mapping branches to a user machine, switching around between them appropriately.
user4704
Then you have to interface with all the tools you don't control, especially those used by non-technical people (typically artists) and make sure any workflows are adjusted to deal with problems there.
user4704
Then you have the task of managing the Perforce (or whatever) syncs of all mapped branches and accounting for which branches need to be the "fast branch" (the one the user works on the most) versus reference branches or branches need occasional bug fixes.
user4704
Then you have "service team" challenges: groups like UI art or technical art (or tools!) that tend to provide functionality across all features.
user4704
May 22, 2013 01:03
Then you have the sort-of opposite of a service team, a consumer like localization or audio, which must be able to consume all pending content well in advance of the actual ship date for that content in order to apply appropriate transforms to that content
John McDonald
John McDonald
Man, I kinda wish I was in a larger team
user4704
And then push the transformed content back into the respective branches (or not)
user4704
And then you have the killer:
user4704
Online worlds require online tests.
user4704
You can't have a feature built in isolation in a branch and tested only by a handful of people, most of the time. Especially for an MMO, you need to be able to test many features at scale, and you need a combination of both bot and human testing.
John McDonald
John McDonald
May 22, 2013 01:04
Yeah
user4704
So you need a completely server deployment for the game in the branch (you need this anyway since you'll potentially need to make game server changes).
user4704
Plus a deployment of all the build servers and build systems to allow the branch to build, or have its build altered, by the developers of that feature.
user4704
Non-trivial problem is non-trivial.
user4704
:D
John McDonald
John McDonald
.. yeah
And my co-workers are confused by a single branch in SVN
lol
:(
user4704
May 22, 2013 01:08
hehe
user4704
There's also, I guess I didn't mention that, the re-education problem.
user4704
When you work on a non-branching workflow, as we did before, there's a lot of "well okay, but when I do my change how do I push it right to the other branches since I want them to see it right away?"
user4704
When you say "you don't, you go through QA and get it into mainline, then it can be pulled by anybody else who wants it," there's a lot of O_O
John McDonald
John McDonald
heh, nice
Sounds like it can be quite a bit of fun being a tool developer
user4704
May 22, 2013 01:41
It's awesome.
 
Conversation ended May 22, 2013 at 1:41.