Gamasutra: The Art & Business of Making Gamesspacer
Interview: The Shape of God of War III
View All     RSS
November 13, 2018
arrowPress Releases
November 13, 2018
Games Press
View All     RSS
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Interview: The Shape of God of War III


March 17, 2010 Article Start Previous Page 2 of 4 Next
 

What's interesting about that is that when you guys moved on from God of War II and announced III, you were basically, since you had the engine built, playing the game right at the beginning of development and playtesting for fun right at that point.

SC: Yes. We had an evolutionary process, too. We had the good fortune of working on the same game product three times in a row, and we were immediately optimizing the process and pipelines each time we would undertake a process. That held true for all of the processes in the game, including testing. God of War was a very heavily tested game. God of War II was even more so. And I think we had even more playtesters with God of War III than we did with the previous games.

The process really evolved, and it's an important part of the process. We raised it a little bit on God of War III by having sooner, more informal playtests. By that, I mean our designers would work together to create a level or puzzle or challenge within the game, and they would be playing it. It wouldn't be on paper.

It would start on paper, from a communications standpoint. You need to get people in a room and they need to understand what's being discussed, and paper designs and documents and whiteboards are very important in that very early stage of communication. But then, very quickly after that point, we get it built in Maya.

We call it a designer's sheet. We have blue box, gray box... it's basically very rudimentary geometry that's rigged up and scripted up to behave like it would in the game, and it's playtested.

The designers would get it to the point where they feel it plays good, and they get the lead designer and director to play it and say, "Yeah, we think this is good." Then we'll grab someone internally who might not be familiar with the area and might not necessarily be a hardcore or great game player, and we'll have them come down and play it at the designer's desk.

We'll have little questionnaires for them asking, "What did you find frustrating? What would you change? If you had to read it, what would you read it as?" There was feedback, right then and there. If it makes them flustered at that point, then it continues in the process and gets refined. If we're fortunate, we can get art laid on it, and then it goes into a public playtest where people from outside the studio and company come in and play it.

We don't afford the opportunity of sitting over their shoulders and saying, "No, no! Go left! No, that's supposed to be this!" We just put them in a room and we watch what they do. The important part for us in developing this game is the iteration and the evolution. It's very important for our group, and it's something we strive for all the time. It's a hands-on process. We get nervous when things languish as ideas. It's like, "Hey, have we started that yet?" It's very important for us to start everything and get it functional and working.

Tell me a little bit more about the team's perspective on documents. Is that something you just do at the beginning stages, and then you move on to a more hands-on type of game design?

SC: Our philosophy is that documentation is a key tool in the communication of what the ideas are and what the objectives are, but it's not the end-all. The end-all for us is the physical playing of the game. One of our most critical milestones in the development of a God of War product is being able to play the game from start to finish, uninterrupted. It's not the finished game, but you're able to get from the beginning to the end and experience it.

For us, it's the hands-on. Documentation is an early part of the process for us, but it's a communication process. It's also a memory tool. By that I mean that we don't do a lot of design documents in Microsoft Word or those kinds of things. We have an internal wiki, and all information gets put up on a wiki. Not so much for the idea that we have this massive design document, but more for the idea, "What did we talk about last week?" We have a place where we can go and say, "Oh yeah, we did want it blue, and this is why we wanted it blue."


Article Start Previous Page 2 of 4 Next

Related Jobs

XSEED Games
XSEED Games — Torrance, California, United States
[11.13.18]

Localization Editor
Sixteen Tons Entertainment GmbH
Sixteen Tons Entertainment GmbH — Tuebingen, Germany
[11.13.18]

Unreal Engine Developer / C++
Digital Extremes
Digital Extremes — London, Ontario, Canada
[11.13.18]

Multimedia Designer
Playful Corp
Playful Corp — McKinney, Texas, United States
[11.13.18]

UI Designer





Loading Comments

loader image