Also, when you are talking out loud about your approach to a game like this, particularly with RPGs, you have that really broad audience spectrum, and the second you start saying things like that, the vocal minority will be like, "Oh, you're dumbing it down, and taking things away."

JA: Whenever you try to do something that's outside the norm, you definitely will run into people who will be critical of it. One of the things we started out with was taking some steps away from the RPG-ness of the game.

That's not to say we don't have a leveling system, and all the RPG fun that players like, but we definitely tried to take a couple strides more toward the action experience because we felt like first off, that's accessible and something that would be good for players and give them something unique to Fable as well.

Fable has always been kind of an action RPG, not a hardcore RPG, so for us to take strides away from the RPG side for the GUI really fit with what wanted to do with the franchise.

Something I've spoken about with other designers is how complexity is often mistaken for depth in games.

JA: That's a great point. Some of that is built on the foundations of where we came from. A lot of us grew up -- at least I did -- in the PC heyday, and made our console transitions from anything from NES, Genesis, to maybe Atari.

The reality is that that great PC era was full of complexity, and we look back to that as a good way to do things, and for some games it is. The real trick is to build something that has that layer of depth that the player can explore if they want to, but not something that they have to.

I think the question is: how do you identify what is depth and what is complexity?

JA: We have a whole property management system, and we have our sim, our economy, and all the pieces of that. If we couldn't explain the rules of our sim, our economy, our house management, and the rest of it... We didn't explain it clearly to ourselves, and clearly it spiraled a bit and got to the point where our consumer wasn't going to be able to understand or use it.

To maintain control of it, we made sure we could explain it in one or two sentences: "This is how it works, you do this, and that happens." You can get a lot of depth out of interlocking systems that are not particularly complicated, so long as they are clear.

When it came to documentation, how much time was spent before you got into the production of the game?

JA: It depends what aspect of the game you are talking about. I think when it came to our missions or our script, those are very detailed, living documents. They start out in a form, and as the script and dialog changes -- by script, I mean mission script by the way, not just dialog script. As our mission and dialog scripts changed, we kept those documents up to date, and they were very much the living, breathing thing you'd expect them to be.

Some of our docs, depending on what you are talking about, are mind-map, stream of consciousness, and we distill from those what we are going to do. Once we get stuff into the game, we tend to work more on the game than the document. It's only the documents that other people use that we keep the most up-to-date. The document for us is the starting point, in most cases.

You mentioned earlier the team of you, the writer, and the scripter, and you just mentioned scripts for missions, could you clarify what you are talking about there in terms of role, and document?

JA: The team is broken up -- and it's slightly unique, [though] I think other teams probably are structured this way -- but from a design standpoint, we essentially have a scripting team. The scripting team consists of the guys who make the story and the gameplay come together. They are essentially very high-end Lua scripters. If we want to create a scenario, they go and built it.

From a toolset standpoint, it does require us to have some really talented and smart people on our scripting team because it's not very visual; it's very code-driven, or very high-end scripting driven system. Everybody works hand-in-hand, but our level designers are about building the world, and some of the experiences you have in the world, but they are not level designers in the sense of a first person shooter.

They are level designer in the sense of, "This is this town. What makes this town have personality? How is this town built so it feels like a real place? What's at the center of the town? Where's the square? Where do people go during the day? Where are all the houses?" They build a world, more than a faux, one-off level. They do that as well, but mostly it's about world-building, from a level design standpoint, and scripting is more about creating good drama and beat-by-beat experiences.

That's interesting because it sounds like it's broken down on one end as a very tech-centric design role, and the other is very art-influenced.

JA: That's very true, and on top of that you have the combat team, who are very animation- and code-compatible. My philosophy, for whatever that's worth, is that you can break designers into categories; you have art-focused designers, visual-focused designers, and I think you also have technical-focused designers.

Our combat team is made up of two designers that split that curve but fall on the technical side overall, the scripters are definitely very technical with a flair for the dramatic, and or level designers are very artistic, with a flair for the technical to get it all to run, if that makes sense.

It sounds like it's tough to find the right person for the job potentially. That's something the industry struggles with; teams develop idiosyncratic ways of working that work well for the styles of games they want to make.

JA: That's true; it's fair to say that the people we hire tend to be younger from a scripter and level design standpoint. We still have some of our hardcore veterans that have been with us for a long time, but our new guys tend to be people who come in from university or come in through test, or some facet like that, and we do that because our way of building Fable -- because it's such a unique game -- is different. We found a way to make Fable, but because there are so many facets to the game, it tends to take a certain kind of methodology to build it.