This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Do you just identify that at your level? You say everybody knows it, but doesn't want to face it. But how do you determine? Some companies will use a lot of playtesting. Do you just eyeball it?
DA: We do usability tests, but at the end of the day, you've just got to use your judgment. With usability tests, you get a lot of information that's only partially useful, because people... they'll get mad at one thing, even though it's something else that's screwing them up.
Funny story in Darksiders 1 is, we did a usability test and they hated everything about the game -- they hated the story, they hated the character, they hated the art, they hated it all. And then you look at the play time, and they were spending an hour in an area that's supposed to be 10 minutes.
So we fixed that, so they got through there quicker, and suddenly they loved everything else. Changed nothing else -- "The story's great, I love the main character, the art looks awesome!" [laughs]
JM: I don't think anyone is harder on our stuff than we are internally, especially Dave. I don't know, we have our own quality bar and... before it even gets to anyone else, we get it to a point where if we're happy with it, it's probably pretty good, because we are really picky and hard on each other.
We have a relationship now, with each other at the studio, where we can be really honest and just be like, "Hey, this sucks." "Yeah, I know. It's pretty terrible. Let's just redo it."
The experience, too, of our team has helped, because I don't think we've cut as much stuff in this one. In the first one, we threw out stuff that we spent like a year on. There was a dungeon we redid twice and still threw it all away. We don't do stuff like that anymore.
How do you not get too precious about the stuff you're making? How do you maintain that sort of distance?
DA: You do. You totally get attached to stuff... It usually comes to a series of painful realizations, where you try to fix it, and it's still not good, and you try to fix it, and it's still not good. And on your third or fourth time trying to fix it, you're like, "It's just something we can't do". For whatever reason, we don't have the time to commit to it, or we don't have the right people... But yeah, I don't think it's possible to not get attached to stuff; we're human beings.
JM: You just have to be honest about it, too, and play other games, and see how you measure up. And if something's not good, we all know it; you can see it. Even if you worked on it for two months, it doesn't really change the fact that it's just not very good.
Sometimes you do get really attached to something, and you're sad to see it change, but... And there's morale hits -- there's all that stuff that you mentioned -- but it's just part of working in games. I think the longer you work in games, the more you're just cool with it.
I think people that just are fresh out of school, and super excited, sometimes get crushed by how hard it actually is. And once you've been doing it for a while, you just expect that stuff's going to change at any given moment, even after we've worked on it for a long, long time.
You talked about how you come with a ton of ideas at the beginning. Is this all kinds of ideas? Do you set the scope for the story and the character, and that's sort of set in stone, or is that something that can change as it feeds into the game and the direction the actual game is heading?
DA: Pretty much everything changes. I mean, the story and stuff is a little more solid, because you've got to write a script. There are certain things that there are so many steps that come after it that you definitely have to plan in advance, but...
Even the gear items in Darksiders II, like the different equipment you get, I think we prototype two or three times as many as we actually used in the game. Sometimes you've just got to try something that sounds cool in your head, and then you play it, and it's stupid. [laughs] Not everything you come up with is a gem; you've just got to try it out, and if it sucks, you move on.
JM: We actually had a wall run in the first game; War was able to do it. And then just the levels we were building just weren't really supporting that mechanic, and it was just a mess, and we took it out. But in this game, we knew we were going to start with it and the designers just built the levels from the ground up to support that stuff a lot more.
I just think it's a more solid game overall. Like, we introduced the horse late in the first game, too, so a lot of the levels leading up to it were designed to be running around on foot. And this time it was like right off the bat -- you start with a horse, there's way more exploration. It's just structured a little better, I think, or closer to what we envisioned the first time around.
You alluded to contingencies in development: things having to come in a certain order. I'm interested in how you manage the process of working on these prototypes and content while knowing these contingencies, and the fact that you try not to be precious about cutting things that aren't working.
DA: I think the only thing you can do to prevent it is just try to prototype fast and make decisions quick. Like, you've got to be able to call something as being not working without going too far down. Because let's say you keep a mechanic that's kind of lame, or it's not working right -- you know, like, "We'll fix it later."
Then you design like 10 levels that use that mechanic in various ways, and then finally you come back and you're like, "Alright, let's finish that mechanic up." And you finish it up and you're like, "Wait, we can't. It's actually kind of stupid." And you're screwed. [laughs]
A lot of times -- especially core game mechanics -- we try to take them really far in the beginning because, personally, I think you can't just prototype game mechanics. You've got to take game mechanics to near final, because you're going to start producing a bunch of content that's dependent upon those mechanics. And if you don't nail them right in the first place, all that, it's like fruit of the poison tree. You start making content for something that doesn't work. Then you're screwed.
How early in the process do you take those mechanics near final?
DA: The base traversal and gear mechanics for Death, we took them pretty far in the first couple months of the project.
When you are working with the early versions of the mechanics, do you do that in complete gray-box scenarios? Or do you actually start to build out stuff?
DA: Yeah, we just do it in prototype rooms.