When you came up with this concept of making everything transparently visible through just the game graphics, did you go down a lot of dead ends? Did you have to do a lot of testing to get to a point where people could actually perceive and glean that information? Or was it intuitive for you as a creative process?
OQ: We didn't approach it as a monolithic problem. It's more like, every time we wanted to put in some content we asked ourselves, "What is this content trying to say?" Whenever we put something in the game, we never put stuff in the game naively, as it were. No piece of content just goes in because we need some filler. Everything that goes in there goes in there for a reason. And then if there's something that we really need to show the player -- something that the simulation's showing the player -- we'll figure out what kind of content we can use to express that.
So it's a very iterative and incremental process. It didn't just spring forth fully formed as a finished project. It was something where methodically, brick on brick, we put in this content and said, "Well, what's the motivation behind this piece of content? What does the house really need to tell you as a player? What does the moving truck really need to tell you? What does the lawn need to tell you as a player? What does the driveway need to tell you as a player? What does the color of the car need to tell you as a player?"
Literally you go down the list through every piece of content in the game and figure out what it's trying to do. What is the simulation motivation for putting it in front of the player? And if there isn't a simulation motivation for it, either figure out, well, it's an opportunity to bind it to some simulation meaning or don't put it in there.
And so an accumulation of those sorts of decisions mean that, sure, there is stuff that we'd like to represent that we're having a hard time making literally represented in the ordinary realistic view of the city. We're going to have to put some of that stuff in bar graphs that overlay the city. But that does mean there's nothing in there that is superfluous. Everything in there is doing a UI job to tell the player what's going on.
When it comes to designing that, is that something where art and design have to really collaborate, or go back and forth? How does that work?
OQ: That chunk of problem was something [we tackled] when Andrew Willmott and I were first getting this game roughed in and prototyped to think about the stuff we were trying to do with it. We basically made that a rule from the get-go. That was kind of my core problem for the first maybe six, eight months of the project, to figure out what is the visual aesthetic of the game and why, what is it for.
And Andrew Willmott, in addition to writing the simulation, the underlying GlassBox simulation engine, is also a graphics engineer. He got his Ph.D. from Carnegie Mellon in global illumination. So he and I were able, just between the two of us, I as an artist and Andrew as an engineer, were able to kind of have the volley back and forth of, "How about this?" "Well, we can't really do that." "How about this?" "Well, okay." I would mock up and prototype stuff in Maya and in-game and say, "This is what I'm thinking about." He'd say, "Well, hmm, how could we hook that up to the simulation? What would be the mechanism for doing so?" That was just a core part of getting the game rolling.
I mean, the game can look like anything, right? It's SimCity; you can stylize it kind of however you want to. And there has to be some reason for making one aesthetic decision or another, and that is what we sort of settled on as the grounding aesthetic rule that would control everything. We just iterated on it back and forth, and back and forth, and back and forth. And now it's just become how we do things. It's ingrained after that.
In terms of getting the whole team on board with it, that was not just at the lead prototyping level, right? That's what I'm curious about as well.
OQ: Right. The way that we usually work on this stuff is -- for years and years and years I was a production artist. I'm a fairly technical production artist as well. So what I tend to do is -- first I make a prototype of what it's supposed to do, and then I'll build a few examples to work out the bugs and the kinks with it, and then I'll step out a workflow that lets us do that sort of thing.
And then I'll train up a lead artist in the workflow methodology and what the motivation behind that is. And then they take that to their team of artists, and do it at scale. What it kind of means in practice is I go out, and for each bit of content that we want to put in there, think through what it is that it's supposed to do, how we're going to make it work, what its job is, what the workflow for it is and then hand it over to a team of production artists to do it at scale. We've had the luxury of this project of a relatively slow build-up.
Andrew and I started this after we shipped Spore. That's a few years back, so we had the luxury of being a team of three or four people to work through this stuff and accumulate all these answers that we could roll out to the team at scale. When the project got green-lighted we could do it for real with a big team as opposed to, say, our little secret project, our little side project.