We first spoke to the game's producer, Alan Van Slyke, during PAX 2009, when he explained a bit of the techno-wizardry which powers the game's internal servers. Yesterday, we got a chance to speak with Van Slyke once more -- this time about the pressures associated with developing a game of this (forgive the pun) magnitude, whether the game's rigorous beta testing paid off, and how one of MAG's three factions has evolved into an unstoppable victory machine.
Joystiq: When did Zipper Interactive decide on making a multiplayer game with 256 players? None of your studio's earlier games are nearly that large in scope – what kind of factors led to that decision?
Alan Van Slyke: Well, I think that specific number actually came more from design than it was just an arbitrary number -- but definitely the early thinking was we want to build something big.
We wanted to replicate the scale of a real battle, you know, in first-person. That was the initial goal, and then we started looking at what we'd need to do to organize that: Organize people into squads, have an OIC and have squad leaders. You know, I think 256 just kind of came out naturally. It was more "we need something massive" than it was "we want a specific number."
What kind of things did you learn while working on the SOCOM series that you brought to mind when working on MAG, and what things did you want to do differently?
Well, actually I and a lot of the team came on specifically to work on MAG, so we actually post-date the SOCOM series. But there's definitely a lot of experience and veterancy in the studio with third-person shooter games. And so we took a lot of the existing knowledge that people had, and I think Zipper was also known as a networking-strong, networking savvy studio. We took that and we really built upon it.
We hired even more people with complementary strengths, and hired on even more networking people specifically for this project, and started prototyping the networking stuff out early. And so I think we had a lot of core design and technology strengths to draw from in the beginning. And then of course as we're trying to push the boundaries and go beyond, there's a lot of learnings as well, right?
What kind of challenges did the game's size present? How did it affect the usual multiplayer shooter concerns that developers face? Like balancing and mapmaking?
Yeah, mapmaking presented a lot of new challenges for us. We really had to come up with lots of new tools, technology, processes, and design thinking. I mean maps, for instance, you bring that up, our earlier environments were assembled in Maya for the SOCOM series.
And we knew for MAG, just by sitting down and looking at the scale of environments and the number of objects we were going to have in them, that we actually needed to build a new tool chain, a new pipeline that included a new world assembly tool, and libraries of assets that we could assemble in a more traditional map authoring paradigm. So we really had to start from scratch with the tools and the way that we assemble them.
And then once we have a new tool that means art is no longer doing all of the assembly – now we have a tool that's both available to design and art. And so we need all new processes to figure out how art and design can essentially be cohabitating, working with each other to build great maps with a single tool.
We also used beta probably more than we have in the past as a testing tool, to give us a lot of high player load, high game counts that we could parse through all the data, and look at the heat maps, and see exactly what's going on. It's something we just couldn't replicate internally as you could with a smaller game or a single player game.
That's interesting. I'm imagining like a gigantic, cross-Sony championship –
[Laughs.]
Were there any rivalries that sprung up between Sony's development studios?
I think most of the rivalries were internal rivalries, especially with design. Design and QA are ultra competitive, and we definitely had a lot of other studios play, but internally, it's vicious. [Laughs.]
Zipper has a history of being pretty prolific. When you guys were working on the SOCOM series, you were knocking out a title or two every year. MAG took a little bit longer to develop – was that because of the game's size, or because it was Zipper's first project on the PS3?
It was more of the latter, and a little bit of the former. When we came in, the PS3 wasn't quite ... you know, early dev kits, early code base, new tools, new pipelines, new thinking, wiping the slate clean, new networking layer, right?
We pretty much wiped the slate clean to build this game, and the studio was making the transition from the PS2 to the PS3 as well. Really, the first eighteen months of the project was standing up core technologies, and just building our run-time engine, building our tool chain, building our renderer, and things like that. It took some amount of time just to get the core engine running on the PS3 before we even had guys up and running around in the game and could actually start laying down game mechanics on top of the core engine that design had been pondering for some time.
A lot of it was just that the studio was setting up the foundation for migrating to the PS3. And then on top of that, there was a small additional expense incurred. I think we were quite efficient in building MAG, but there was definitely an additional expense incurred just in the learnings and scale of the game we were building, that probably no one else has tried to do. We definitely took a little bit of extra time and care and after each event, or after each showing, we would kind of go back and rethink what we were doing and refactored what needed to be polished up and refactored to make them fun at that scale.
You know, it happens a lot, doesn't it, where someone comes up with a work-in-progress name or prototype name and it ends up sticking. That's really what happened with MAG. I mean, it started as an acronym and we kind of divested from that.
We went through usability and showed people the game and had them get their hands on it - typical usability tests we'll do, and present people with a bunch of different names. We narrowed those down, but then on top of that, when you find a couple that you are really happy with, you have to get all the international territories on board. It's a very heavy endeavor to find a name, especially an embedded name, a name that already has some weight to it, some history to it. Then to try to get everyone on board to change that and to find one that everyone's happy with is a hard thing.
When you start coming up with these super-long names with multiple syllables, it can get washed out pretty quickly. MAG is just a really solid name. |
Are there any other names you'd use, if you could go back in time to that first big reveal and change it to something different? Like Really Big Shooter?
I'm quite happy with the name. You know, there's a ton of different names that were pitched around. We had spreadsheets of literally, like, hundreds of names, some of which have already been picked up by the competition and run with, so I hesitate to mention any of them. [Laughs.]
I think what we were really trying to hone in on was a name that, you know, sounds solid, that conveys scale, and a name that sticks, right? And when you start coming up with these super-long names with multiple syllables, it tends to kinda get ... It can get washed out pretty quickly. MAG is just a really solid name.
What kind of information did you glean from the beta testing? What kind of information were you looking for?
We were looking for information across the board. Really half of it was tech, and half of it was product, or design.
So on the tech side, we had to put to bed all of our concerns with matchmaking and scale – the behind the scenes stuff, like the number of players that can be hosted on each physical server, the location of the servers geographically, to make sure that people in Europe and people in North America are getting the lag-free experience that they'll enjoy. Then just scaling for the tens, or hundreds, or thousands of users -- you know, for confidence that when we launched, that tech would be there to support us.
And on the design side, again, we were really looking for – we can test it internally, and we can play tens of rounds, potentially, but playing it in beta really enabled us to get thousands, or tens of thousands of rounds of data that we can aggregate and look at. We can look at all the weapon tuning data, we can look at all the armor, we can look at the distances of the attackers and defenders to their objectives, and where any imbalances might lie.
On top of that we had our community manager who would pore through the forums and aggregate all the information, all the problems, all the bugs that people were complaining about, and we were really able to just find and fix and balance an incredible amount of stuff during beta that we would have had a hard time finding internally. So, it gave us confidence, and it also improved the product.
As valuable as that information sounds, wasn't the cost for running all those beta phases just a little prohibitive?
Most of the cost incurred is really delivering the builds. The run-time cost for us is like – we're generating the builds regardless, you know what I mean? We're charging towards alpha, beta, gold master internally, and so really this is just giving us hundreds of things we want to put on the Blu-ray, so the cost in development is almost nothing. I mean, it's a win-win. We're going to be generating those builds anyway, and then essentially we're just finding the good stuff to put into them and re-releasing them to the public.
Now, the operational cost, sure, you're patching out a couple a gigs a pop times four stages or five stages, so that has a little bit of kick to it, but after you've invested millions of dollars in a AAA product, paying tens of thousands of dollars for patching to get all these fixes is a no-brainer.
